lexer puzzle

[Brandon Michael Moore]

Note I've replied to haskell-cafe. This post is a bit chatty and low on
solid answers.

On Thu, 25 Sep 2003, Sean L. Palmer wrote:

> > >>A... should be split into "A.." and "."
> > >I found a compromise: let's make it a lexing error! :-)
> > At least that agrees with what some Haskell compilers implement. No
> > current Haskell compiler/interpreter agrees with what the report seems
> > to say, that is that "A..." should be lexed as the two tokens "A.." and
> > ".", and similarly, "A.where" should be lexed as "A.wher" followed by "e".
>
> Hi.  I'm really new to Haskell, just learning it, and I must say I'm pretty
> overwhelmed by the large variety of constructs. (=>, <-, \ to name a few)

Would that be \ as in TREX row variable polymorphism? Just remember most
operators are just library functions. It's only =, ->, =>, <-, :: that are
really part of the language, and {,},; for grouping. Did I miss any?

>
> But I'm just writing this to let you guys know (surely you know this
> already) that anyone from a C/C++/Java/Delphi background is going to
> completely misunderstand the meaning of A.anything in Haskell... it's
> completely nonintuitive to people with my background.  I kinda like dot
> notation because it ties together the symbols visually, for instance
> "myrec.myfield" is more of a unit than "myrec myfield".  It stays together
> better when surrounded by other code, and would result in fewer parenthesis
> necessary.

A Python programmer would understand instantly: Python uses exactly the
same syntax for module access, though Python modules are usually in
lowercase. It also seems to be very much in the spirit of "access a member
of this object" of an OO language.

Or was that supposed to be composition of a constructor with a function, A
. f? Function composition, and higher order functions in general are
likely to confuse an imperative programmer, but I think there isn't much
syntax can do there.

Or are you talking about the field access syntax? Maybe the problem is
that dot has two to five different meanings, function composition, naming
module members, building hierarchial module names, being a decimal point,
and making elipses, and is commonly used for yet another purpose in OO
languages.

> Haskell to me seems to be a great language with a syntax problem, and a bad
> case of too many ways to do the same thing; thus every programmer does
> things their own way and it's difficult to grasp the language by looking at
> various programs, since they're all so very different.  As a small example,
> there's 'let' vs. 'where'.  Maybe a bit of pruning would be in order.

Do you mean the syntax is bad in places? Haskell is the cleanest language
I know of, but I'm sure it has some grungy bits. I've had problems with
unary minus (can't slice binary minus), and precedence of with irrefuatble
patterns and type ascription. I would be happy for any confusing syntax to
be improved. Any good ideas? Syntax change is a possibility: do notation
is a relatively recent addition, and arrow syntax is in the works.

I think you might instead mean the syntax cuts down our market share
because it isn't like common (C derived) languages. I don't think Haskell
could borrow any more syntax from C without actually making the language
worse. It's a problem, but not with the syntax. If someone is so solidly
into a C++/Java/OO mindset that the syntax would be a problem, the
semantics would probably be even more of a problem.

I would suggest Python if Haskell was too much of a jump for someone. It's
still OO, but it encourages more flexible and interesting programs, and
you don't have to live in a Java type system. Plus, it has more libraries,
bindings, and PR, so it's easier to get permission to use it in a company.

If someone is used to Python's layout rule and lack of type signatures,
and gets their head around some of the fun you can have dynamically
picking which members of an object to access, assigning to __dict__ and so
on, then Haskell should be much less of a jump in syntax, and less
imposing in semantics.

> That said, I still think it looks more promising than any other language
> I've looked at that actually is being actively used and maintained and has a
> decent installed base and good cross platform support.  So I will learn it.
> I just wish the transition was easier and that it took less time to learn.
> ;)
>
> Sean

I learned Haskell from the "gentle introduction". It seemed gentle enough
to me but others disagree, so I'm probably not the best for advice for the
raw beginner. If you are interested in learning about monads though,
Jeff Newbern's monad tutorial seems accessible and as complete as anything
this side of Phil Wadler's paper.

I hope learning Haskell goes well.

Brandon