
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

Brandon Michael Moore
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.
I think there is a problem with too much overloaded syntax. Perhaps it is time to put non-ASCII characters to good use? For instance, function composition could use the degree sign: ° and leave the . for module qualification. Template Haskell could use double-angle quotation marks: « » and the section sign: § and avoid clashing with list comprehensions and the function application operator. Implicit parameters could use an inverted question mark: ¿ And so on, just look for places where the semantics depend on spaces in the right (or wrong) place. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

On Fri, Sep 26, 2003 at 08:59:12AM +0200, Ketil Z. Malde wrote:
Brandon Michael Moore
writes: 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.
I think there is a problem with too much overloaded syntax. Perhaps it is time to put non-ASCII characters to good use?
For instance, function composition could use the degree sign: ° and leave the . for module qualification.
why not the actual functional composition operator: · or ∘ we could also make good use of ∀ ∃ ⇒ ← ∧ ∨ and all the other fun mathematical operators.
Template Haskell could use double-angle quotation marks: « » and the section sign: § and avoid clashing with list comprehensions and the function application operator.
Implicit parameters could use an inverted question mark: ¿
And so on, just look for places where the semantics depend on spaces in the right (or wrong) place.
I would love to be able to use unicode to make my programs more readable. just as an alternate syntax for awkward ascii constructs. and as operator, function names when they make sense. this could probably be done with a preprocessor, but wolud be easier in the compiler to work out the layout rule and handle language extensions and whatnot. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------

John Meacham
For instance, function composition could use the degree sign: ° and leave the . for module qualification.
why not the actual functional composition operator: · or ?
Because: a) I've always used a small circle, the centered dot is for (dot) products. I guess this is just a matter of mathematical dialects. And b) I didn't find it :-)
we could also make good use of ∀ ∃ ⇒ ← ∧ ∨ and all the other fun mathematical operators.
Cool! However, I think most/some current tools use ISO-8859(-1 or whatever) input, and for legacy reasons it may be a good idea to stick to symbols in that (those) subset(s). As you may have noticed, I suggested mostly these symbols for the language extensions, keeping H98 in 7 bits may or may not be a priority. At any rate, extensions could probably more easily disregrard legacy.
I would love to be able to use unicode to make my programs more readable. just as an alternate syntax for awkward ascii constructs. and as operator, function names when they make sense.
Another thing; it should be possible to have (X)Emacs use display the glyphs you mention (∀ ∃ ⇒ ← ∧ ∨) instead of the underlying multigraphs.
this could probably be done with a preprocessor, but wolud be easier in the compiler to work out the layout rule and handle language extensions and whatnot.
Layout may be a problem. Not for type signatures, though. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

On vrijdag, sep 26, 2003, at 09:16 Europe/Amsterdam, John Meacham wrote:
On Fri, Sep 26, 2003 at 08:59:12AM +0200, Ketil Z. Malde wrote:
I think there is a problem with too much overloaded syntax. Perhaps it is time to put non-ASCII characters to good use?
For instance, function composition could use the degree sign: ° and leave the . for module qualification.
why not the actual functional composition operator: · or ∘
we could also make good use of ∀ ∃ ⇒ ← ∧ ∨ and all the other fun mathematical operators.
This is very readable, but not very writable. Until I get a keyboard with a ∀ key, I would prefer to restrict the syntax to ASCII/whatever and simply make it the editor's responsibility to display source code using special characters. フランクより

On vrijdag, sep 26, 2003, at 09:16 Europe/Amsterdam, John Meacham wrote:
On Fri, Sep 26, 2003 at 08:59:12AM +0200, Ketil Z. Malde wrote:
I think there is a problem with too much overloaded syntax. Perhaps it is time to put non-ASCII characters to good use?
For instance, function composition could use the degree sign: ° and leave the . for module qualification.
why not the actual functional composition operator: · or ∘
we could also make good use of ∀ ∃ ⇒ ← ∧ ∨ and all the other fun mathematical operators.
This is very readable, but not very writable.
Until I get a keyboard with a ∀ key, I would prefer to restrict the syntax to ASCII/whatever and simply make it the editor's responsibility to display source code using special characters. actually it is not that hard to write unicode characters. after all
hello, Frank Atanassow wrote: there are no capital letter keys on the keyboard either, but we can write them. i use vim and at least with it it quite easy to "teach" the editor to recognize certain sequences of characters and replace them with the appropriate mathematical symbol. a similar thing happens when you write Isabelle theories with x-symbol, and it really works quite nicely. i think it would be nice to allow programmers to write unicode for what is now done with sequences of ascii chars (not replacing the current symbols, but adding additional syntax). bye iavor
フランクより _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

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?
Yes, you missed \, which is used for function abstraction:
(\x -> x*x) 3
And ( , ) for tuples.
And I don't think "->" is part of the language - it only appears in the type syntax, not term syntax. If you allow it, you have to allow * as well.
--KW 8-)
--
Keith Wansbrough

Keith Wansbrough
And I don't think "->" is part of the language - it only appears in the type syntax, not term syntax. If you allow it, you have to allow * as well.
Errm, you just gave an example of -> in the term syntax...
(\x -> x*x) 3
Regards, Malcolm

Keith Wansbrough
writes: And I don't think "->" is part of the language - it only appears in the type syntax, not term syntax. If you allow it, you have to allow * as well.
Errm, you just gave an example of -> in the term syntax...
(\x -> x*x) 3
Guilty... sorry! :-(
--KW 8-)
--
Keith Wansbrough
participants (7)
-
Brandon Michael Moore
-
Frank Atanassow
-
Iavor Diatchki
-
John Meacham
-
Keith Wansbrough
-
ketil@ii.uib.no
-
Malcolm Wallace