Richer (than ascii) notation for haskell source?

Probably a silly question, but for me one of the nice things about Haskell is that it's a lot like just writing math(s). But in contrast to math you lose a lot of notational flexibility being limited to the ascii character set in your source code. It would be nice to be able to use a richer set of symbols in your source code for operators and functions (e.g. integral, sum, dot and cross-product, ...), as well as variables (the standard upper and lower-case greek for example, along with things like super- and sub-scripting, bold/italic and what-not). You could imagine ending up with source code that reads just like a mathematical paper. Don't know how I'd actually then write/maintain the source-code - some WYSIWYG editor or effectively writing it in '(la)tex'? Maybe that's what Knuth is on about with his 'literate programming' weave/tangle stuff which I don't know much about - does that translate to Haskell? Patrick Patrick.Surry@portraitsoftware.com mailto:Patrick.Surry@portraitsoftware.com , VP Technology Tel: (617) 457 5230 Mob: (857) 919 1700 Fax: (617) 457 5299 Map <http://maps.google.com/maps?f=q&hl=en&q=125+Summer+St,+Boston,+MA+02110 &ie=UTF8&z=15&ll=42.353153,-71.057296&spn=0.022644,0.054245&om=1&iwloc=A
Portrait Software introduces Portrait Campaign Manager http://www.portraitsoftware.com/Products/portrait_campaign_manager : Easy, integrated campaign management for automated and highly targeted outbound marketing http://supportcentre.portraitsoftware.com/Vmail/emailfooter/balloon.gif http://www.portraitsoftware.com/ http://supportcentre.portraitsoftware.com/Vmail/emailfooter/portrait_sof tware_logo.gif http://www.portraitsoftware.com/ www.portraitsoftware.com http://www.portraitsoftware.com/ ________________________________________________________________________ DISCLAIMER: This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. If you received this email in error, please notify the sender and delete the message from your computer.

Hello Patrick, Wednesday, May 14, 2008, 5:43:44 PM, you wrote:
It would be nice to be able to use a richer set of symbols in your
ghc supports UTF-8 encoded haskell sources and there are lots of utf-8 enabled editors available -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

"Patrick Surry"
Probably a silly question, but for me one of the nice things about Haskell is that it's a lot like just writing math(s). But in contrast to math you lose a lot of notational flexibility being limited to the ascii character set in your source code.
Don't know how I'd actually then write/maintain the source-code - some WYSIWYG editor or effectively writing it in '(la)tex'?
Feel free to extend literal Haskell and e.g. LyX to support this. Shouldn't be too much of work, translating math formulae into plain Haskell code to keep it executable. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.

Patrick Surry on 2008-05-14 09:43:44 -0400:
Probably a silly question, but for me one of the nice things about Haskell is that it's a lot like just writing math(s). But in contrast to math you lose a lot of notational flexibility being limited to the ascii character set in your source code.
If you use emacs, there's some code that will display arbitrary words/symbols as Greek letters or math symbols: http://www.emacswiki.org/cgi-bin/wiki/PrettyLambda It's cute. It won't replace the actual text, just what's displayed, so if you need to share your code with someone else, they'll still be able to use it.

Hi
It would be nice to be able to use a richer set of symbols in your source code for operators and functions (e.g. integral, sum, dot and cross-product, …), as well as variables (the standard upper and lower-case greek for example, along with things like super- and sub-scripting, bold/italic and what-not). You could imagine ending up with source code that reads just like a mathematical paper.
You probably still want to write in ASCII, as keyboards have buttons for each of the letters in the alphabet, so its much easier. However, you can format your code nicely using lhs2tex - I use it for all my papers. I have things like: %subst alpha = "{\alpha}" Which means I can write: id :: alpha -> alpha The code is valid Haskell, and looks super-pretty in papers. Lhs2tex: http://people.cs.uu.nl/andres/lhs2tex/ Thanks Neil

On Wed, 14 May 2008, Patrick Surry wrote:
Probably a silly question, but for me one of the nice things about Haskell is that it's a lot like just writing math(s). But in contrast to math you lose a lot of notational flexibility being limited to the ascii character set in your source code.
Leksah supports visualizing keywords as fancy symbols: http://www.leksah.org/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 14-mei-2008, om 15:43 heeft Patrick Surry het volgende geschreven:
It would be nice to be able to use a richer set of symbols in your source code for operators and functions (e.g. integral, sum, dot and cross-product, …), as well as variables (the standard upper and lower-case greek for example, along with things like super- and sub-scripting, bold/italic and what-not). You could imagine ending up with source code that reads just like a mathematical paper.
People have already thought about this, and it partly works already in GHC. See http://hackage.haskell.org/trac/haskell-prime/wiki/ UnicodeInHaskellSource. I don't like, however, the tendency of many Haskell authors to use math-like variable names. There are far to many Haskell programs where you rarely find a variable name of more than three letters, and all those variables that have more than one letter are English names for Greek letters like 'phi' or 'mu'. It makes a difference for your style whether you are just talking to humans (a math paper) or to humans and compilers at the same time (a computer program). When talking to a compiler, the compiler is not interested in the semantical explanations, so programmers mostly leave them out. But when you do that, you must make sure that the formal language is still comprehensible to humans - I'd say by using descriptive variable names. Regards, Reinier -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgrH04ACgkQR3bgBiWODBfrBQCeLVEIiYDbXdCFJbTI4HZkJr7e qysAn2M3XDynT/NAINsVaeH23XVre1Kf =Zv7j -----END PGP SIGNATURE-----

Patrick Surry wrote:
Probably a silly question, but for me one of the nice things about Haskell is that it's a lot like just writing math(s). But in contrast to math you lose a lot of notational flexibility being limited to the ascii character set in your source code.
It would be nice to be able to use a richer set of symbols in your source code for operators and functions (e.g. integral, sum, dot and cross-product, …), as well as variables (the standard upper and lower-case greek for example, along with things like super- and sub-scripting, bold/italic and what-not). You could imagine ending up with source code that reads just like a mathematical paper.
Don't know how I'd actually then write/maintain the source-code - some WYSIWYG editor or effectively writing it in '(la)tex'? Maybe that's what Knuth is on about with his 'literate programming' weave/tangle stuff which I don't know much about - does that translate to Haskell?
Personally, I'd just like to be able to get rid of "->", "\" and other such hacks. Would it be possible to amend GHC so that it accepts "->" and [whatever the Unicode codepoint for "left arrow" is] and treats both the same? IIRC, GHC already accepts Unicode input. I seem to recall some people debating what to do about languages that don't have a concept of "uppercase" and "lowercase" - the Haskell language critically hinges on that distinction. But then, if you wanted to write your Haskell programs in arabic or something, I would think the fact that all the language keywords and every library ever written are in English, so...

On 2008 May 14, at 14:32, Andrew Coppin wrote:
Personally, I'd just like to be able to get rid of "->", "\" and other such hacks. Would it be possible to amend GHC so that it accepts "->" and [whatever the Unicode codepoint for "left arrow" is] and treats both the same?
Both of those are already there, along with some others. It's been discussed here but I can't find it in the 6.8.2 manual.... (boo, hiss) -XUnicodeSyntax -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Brandon S. Allbery KF8NH wrote:
On 2008 May 14, at 14:32, Andrew Coppin wrote:
Personally, I'd just like to be able to get rid of "->", "\" and other such hacks. Would it be possible to amend GHC so that it accepts "->" and [whatever the Unicode codepoint for "left arrow" is] and treats both the same?
Both of those are already there, along with some others. It's been discussed here but I can't find it in the 6.8.2 manual.... (boo, hiss) -XUnicodeSyntax
Mmm, I can see I'm going to have to test this... [That is, just as soon as I figure out how to even type in obscure Unicode symbols...]

On 2008 May 14, at 15:00, Andrew Coppin wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 May 14, at 14:32, Andrew Coppin wrote:
Personally, I'd just like to be able to get rid of "->", "\" and other such hacks. Would it be possible to amend GHC so that it accepts "->" and [whatever the Unicode codepoint for "left arrow" is] and treats both the same?
Both of those are already there, along with some others. It's been discussed here but I can't find it in the 6.8.2 manual.... (boo, hiss) -XUnicodeSyntax
Mmm, I can see I'm going to have to test this... [That is, just as soon as I figure out how to even type in obscure Unicode symbols...]
Unfortunately, while I thought there was a distinct lambda sign that wasn't the lowercase Greek letter, there isn't. (That said, I don't see why it couldn't be a keyword. You'd need a space after it.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 15 May 2008, at 7:19 am, Brandon S. Allbery KF8NH wrote:
Unfortunately, while I thought there was a distinct lambda sign that wasn't the lowercase Greek letter, there isn't. (That said, I don't see why it couldn't be a keyword. You'd need a space after it.)
There are three lambda letters: lower and upper case Greek, and Ugaritic (U+1038D). But there are also mathematical symbols: U+166CC mathematical bold small lamda (sic.) U+1D706 mathematical italic small lamda (sic.) U+1D740 mathematical bold italic small lamda (sic.) U+1D77A mathematical sans-serif bold small lamda (sic.) U+1D7B4 mathematical sans-serif bold italic small lamda (sic.) These things are visually letters, but as mathematical symbols they should not combine into words. Except that to my surprise, nay, to my utter astonishment, the Unicode 5.1 character data base classifies them as letters just like the letter "e". At least to give editors a fighting chance of matching their concept of a "word" with Haskell tokens, it might be better to use nabla instead of lambda. Other old APL fans may understand why (:-). Alternatively, didn't Church really want to use a character rather like a down tack, and have to squish it to get a letter his printer was happy with? Nah, nabla for me. -- "I don't want to discuss evidence." -- Richard Dawkins, in an interview with Rupert Sheldrake. (Fortean times 232, p55.)

Richard A. O'Keefe wrote:
At least to give editors a fighting chance of matching their concept of a "word" with Haskell tokens, it might be better to use nabla instead of lambda. Other old APL fans may understand why (:-). Alternatively, didn't Church really want to use a character rather like a down tack, and have to squish it to get a letter his printer was happy with? Nah, nabla for me.
nablabot anyone? Nabla calculus? (But wait, in differential calculus nabla is a gradient operator, so let's rename that lambda). And people misspelling nabla as nambla will find a surprise when they google it... Better use a Unihan character instead.

On 2008 May 14, at 22:07, Richard A. O'Keefe wrote:
On 15 May 2008, at 7:19 am, Brandon S. Allbery KF8NH wrote:
Unfortunately, while I thought there was a distinct lambda sign that wasn't the lowercase Greek letter, there isn't. (That said, I don't see why it couldn't be a keyword. You'd need a space after it.)
There are three lambda letters: lower and upper case Greek, and Ugaritic (U+1038D). But there are also mathematical symbols:
U+166CC mathematical bold small lamda (sic.) U+1D706 mathematical italic small lamda (sic.) U+1D740 mathematical bold italic small lamda (sic.) U+1D77A mathematical sans-serif bold small lamda (sic.) U+1D7B4 mathematical sans-serif bold italic small lamda (sic.)
Hm. Newer Unicode standard than the version supported by OSX and GNOME, I take it? That's not so helpful if nobody actually supports the characters in question. (My Mac claims 166CC is in an unassigned area, and no supplied font has the others. It does at least acknowledge that the others should exist and are "letters".) Hm, U+2144 as an approximation? I still suspect it would not be outside the pale to make λ a keyword. We already have several, after all.
At least to give editors a fighting chance of matching their concept of a "word" with Haskell tokens, it might be better to use nabla instead of lambda. Other old APL fans may understand why (:-). Alternatively, didn't Church really want to use a character rather like a down tack, and have to squish it to get a letter his printer was happy with? Nah, nabla for me.
:) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 15 May 2008, at 2:34 pm, Brandon S. Allbery KF8NH wrote:
Hm. Newer Unicode standard than the version supported by OSX and GNOME, I take it? That's not so helpful if nobody actually supports the characters in question. (My Mac claims 166CC is in an unassigned area, and no supplied font has the others. It does at least acknowledge that the others should exist and are "letters".)
Whoops. Sorry, typo. 166CC should have been 1D6CC. I was actually looking at the Unicode 5.1 character data base, but the copy I keep on my own machine is the 4.0.0 version, and those mathematical symbols were there back in 4.0.0.
I still suspect it would not be outside the pale to make λ a keyword. We already have several, after all.
I'd rather not have to write \x as λ x with a space required after the λ. I suspect that "λ is the lambda-symbol iff it is not preceded by any identifier character and is not followed by a Greek letter" might work.

On 2008 May 14, at 22:40, Richard A. O'Keefe wrote:
I still suspect it would not be outside the pale to make λ a keyword. We already have several, after all.
I'd rather not have to write \x as λ x with a space required after the λ. I suspect that "λ is the lambda-symbol iff it is not preceded by any identifier character and is not followed by a Greek letter" might work.
Adjacent different scripts in general is probably a reasonable token discriminator. A "token" combining LTR and RTL, for example, is just confusing. (Japanese might need to be an exception; I don't know if ideographs and romanji are ever mixed at the word level.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Brandon S. Allbery KF8NH wrote:
Adjacent different scripts in general is probably a reasonable token discriminator. A "token" combining LTR and RTL, for example, is just confusing.
So you would like to ban identifiers that contain both letters and digits for those who happen to speak languages whose letters are RTL? I must protest. Regards, Yitz

On 2008 May 15, at 3:03, Yitzchak Gale wrote:
Brandon S. Allbery KF8NH wrote:
Adjacent different scripts in general is probably a reasonable token discriminator. A "token" combining LTR and RTL, for example, is just confusing.
So you would like to ban identifiers that contain both letters and digits for those who happen to speak languages whose letters are RTL? I must protest.
Mmmm, more specification needed. Add "letter" to the constraint. (compressing messages) As to your assertion of discrimination against Greek: my point was that mathematical notation *already* discriminates against speakers of Greek by appropriating their alphabet for its own purposes, so if you want to enable a mathematical-notation language mode it's already difficult to support a Greek localization. (I do wonder how modern Greek mathematicians deal with this....) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

As to your assertion of discrimination against Greek: my point was that mathematical notation *already* discriminates against speakers of Greek by appropriating their alphabet for its own purposes, so if you want to enable a mathematical-notation language mode it's already difficult to support a Greek localization. (I do wonder how modern Greek mathematicians deal with this....)
This made me curious... so hunting around on the internet I found: http://el.wikipedia.org/wiki/%CE%8C%CF%81%CE%B9%CE%BF which, although almost the same as mathematics in English (notice 'epsilon' being used in the same sense), uses 'nu' as a variable to index over the integers, and 'lambda' as a upper/lower bound. Also I found a list of abstracts (mixture of English and Greek): http://users.uoa.gr/~apgiannop/pcma08/program-print.pdf which again looks almost the same as English mathematics (especially when they write it in English), although it seems like 'lambda' is being used as a variable with rather high frequency. Eric

On Thu, 2008-05-15 at 14:40 +1200, Richard A. O'Keefe wrote:
On 15 May 2008, at 2:34 pm, Brandon S. Allbery KF8NH wrote:
Hm. Newer Unicode standard than the version supported by OSX and GNOME, I take it? That's not so helpful if nobody actually supports the characters in question. (My Mac claims 166CC is in an unassigned area, and no supplied font has the others. It does at least acknowledge that the others should exist and are "letters".)
Whoops. Sorry, typo. 166CC should have been 1D6CC.
I was actually looking at the Unicode 5.1 character data base, but the copy I keep on my own machine is the 4.0.0 version, and those mathematical symbols were there back in 4.0.0.
I still suspect it would not be outside the pale to make λ a keyword. We already have several, after all.
I'd rather not have to write \x as λ x with a space required after the λ. I suspect that "λ is the lambda-symbol iff it is not preceded by any identifier character and is not followed by a Greek letter" might work.
λω. ... λα. ... λδ ε. ...

On 2008 May 14, at 22:57, Derek Elkins wrote:
On Thu, 2008-05-15 at 14:40 +1200, Richard A. O'Keefe wrote:
I suspect that "λ is the lambda-symbol iff it is not preceded by any identifier character and is not followed by a Greek letter" might work.
λω. ... λα. ... λδ ε. ...
Come to think of it, if you're after math notation, enough Greek letters are used as symbols that it might be necessary to just exclude them from use as letters. (Symbols would be fair game.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Brandon S. Allbery KF8NH wrote:
Come to think of it, if you're after math notation, enough Greek letters are used as symbols that it might be necessary to just exclude them from use as letters.
While I have not yet noticed anyone from Greece on this list, I don't think it would be appropriate for us to discriminate against Greek speakers as a built-in feature of Haskell. Regards, Yitz

"Yitzchak Gale"
Brandon S. Allbery KF8NH wrote:
Come to think of it, if you're after math notation, enough Greek letters are used as symbols that it might be necessary to just exclude them from use as letters.
While I have not yet noticed anyone from Greece on this list, I don't think it would be appropriate for us to discriminate against Greek speakers as a built-in feature of Haskell.
/me shudders and tries not to remember those occasions when he read code written in french. It's quite akin to decompiled obfuscated Java-code, where you're left with classes say a-j and mostly functions with the name a, discerned by types. Code should be written completely in English, for practical reasons. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.

Brandon S. Allbery KF8NH wrote:
Come to think of it, if you're after math notation, enough Greek letters are used as symbols that it might be necessary to just exclude them from use as letters.
Yitz Gale wrote:
While I have not yet noticed anyone from Greece on this list, I don't think it would be appropriate for us to discriminate against Greek speakers as a built-in feature of Haskell.
Achim Schneider wrote:
/me shudders and tries not to remember those occasions when he read code written in french.
He he, yes. I've seen C++ written in transliterated Russian, too. Very amusing - as long as I'm not the one who has to debug it.
Code should be written completely in English, for practical reasons.
Yes, of course, that's the standard today for software development. But I'm just saying that it would not be a good idea to hard-wire that policy into our language syntax. Just as an example - let's say you want to create an embedded DSL for speakers of a language other than English. The point is that it is always best to keep language syntax as simple as possible, for many reasons. In the case of Unicode, that means staying as close as possible to the spirit of Unicode and minimizing our own ad hoc rules. Adding one more keyword is way simpler than adding a bunch of complex rules to the lexer. A lot less moving parts to break. Especially if those lexer rules are not so consistent with built-in Unicode concepts such as letter and symbol, glyph direction, etc. So I think the best and simplest idea is to make the letter lambda a keyword. True, you need a space after it then. You already need spaces between the variables after the lambda, so anyway you might say that would be more consistent. I always find my thumb hovering indecisively over the space bar when I type a backslash "lambda" in Haskell. Haskell syntax has always been inspired by mathematical notation and reminiscent of it, never identical to it. Regards, Yitz

On 2008 May 15, at 4:33, Yitzchak Gale wrote:
Brandon S. Allbery KF8NH wrote:
Come to think of it, if you're after math notation, enough Greek letters are used as symbols that it might be necessary to just exclude them from use as letters.
Yitz Gale wrote:
While I have not yet noticed anyone from Greece on this list, I don't think it would be appropriate for us to discriminate against Greek speakers as a built-in feature of Haskell.
Achim Schneider wrote:
/me shudders and tries not to remember those occasions when he read code written in french.
He he, yes. I've seen C++ written in transliterated Russian, too. Very amusing - as long as I'm not the one who has to debug it.
True --- as one of the people who generally gets to fire-test heimdal (http://h5l.org ) and feed back changes, it's always fun to debug those parts where variable names and comments are in Svensk.
Code should be written completely in English, for practical reasons.
Yes, of course, that's the standard today for software development. But I'm just saying that it would not be a good idea to hard-wire that policy into our language syntax.
Suddenly I'm thinking of Lingua::Romana::Perligata....
I always find my thumb hovering indecisively over the space bar when I type a backslash "lambda" in Haskell.
Come to think of it, I find myself inserting spaces anyway because of emacs' tendency to use backslash as an escape character (and because I'm so used to it being an escaper instead of an active character in its own right). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

2008/5/15 Yitzchak Gale
So I think the best and simplest idea is to make the letter lambda a keyword. True, you need a space after it then. You already need spaces between the variables after the lambda, so anyway you might say that would be more consistent.
You could use a zero width space (U+200B) to preserve the appearance of mathematical notation. I don't know if this is already treated as whitespace but it probably should be. There are also several thin space characters (U+2008 punctuation space, U+2009 thin space, U+200A hair space) that might be better, particularly between variables in a multi-parameter lambda. Andy

On 15 May 2008, at 8:33 pm, Yitzchak Gale wrote:
The point is that it is always best to keep language syntax as simple as possible, for many reasons. In the case of Unicode, that means staying as close as possible to the spirit of Unicode and minimizing our own ad hoc rules.
In particular, Unicode has explicit guidance about what an identifier should be, in UAX#31: http://www.unicode.org/reports/tr31/tr31-9.html I've only recently started slogging my way through the capital-city-telephone-book-size Unicode 5.0 book. (I was tolerably current to 4.0) Imagine my stress levels on discovering that Unicode 5.1 is already out, with another "1,624 newly encoded characters", including a capital letter version of "ß". It is deeply ironic that one of the things that keeps changing is the stability policy. Another of the things that has changed is UAX#31.
Adding one more keyword is way simpler than adding a bunch of complex rules to the lexer.
Um, there's no way a Haskell lexer is going to comply with the Unicode rules without a fair bit of complexity. The basic idea is simply <id start><id continue>*, but there are rules about when ZWJ and ZWNJ are allowed. The real issue here is Unicode compliance, and the Unicode rules say that a mixture of scripts is OK. Er, it's not actually that simple. They do recommend that the scripts in table 4 _not_ be allowed in identifiers, so if you fancied writing some of your identifiers in Shavian, you may or may not be out of luck. (Just why a Coptic priest who is also a coder should be discouraged from using the Coptic script in his programs escapes me.)
A lot less moving parts to break. Especially if those lexer rules are not so consistent with built-in Unicode concepts such as letter and symbol, glyph direction, etc.
UAX#31 definitely allows identifiers with any mixture of left to right and right to left characters. The *intent* is that anything even remotely reasonable should be accepted, and should keep on being accepted, but of course the devil is in the details.
So I think the best and simplest idea is to make the letter lambda a keyword.
The lambda that people actually *want* in Haskell is in fact the >mathematical< small letter lambda, not the Greek letter. UAX#31 explicitly envisages "mathematically oriented programming languages that make distinctive use of the Mathematical Alphanumeric Symbols". I don't think there can be much argument about this being the right way to encode the symbol used in typeset versions of Haskell. There are three arguments against using it routinely: (a) It is outside the 16-bit range that Java is happy with, making it hard to write Haskell tools in Java. But then, about 40% of the characters in Unicode are now outside the 16-bit range that Java is comfortable with, which is just too bad for Java. Haskell tools should be written in Haskell, and should cope with 20-bit characters. (I used to say 21- bit, but Unicode 5 promises never to go beyond 16 planes.) (b) It is outside the range of characters currently available in fonts. A character you cannot type or see isn't much use. Implementations *will* catch up, but what do we do now? (c) People *can* type a Greek small letter now, and will not be interested in making fine distinctions between characters that look pretty much the same. So people will *expect* the Greek letter to work, even if a pedant like me says it's the wrong character. Of course, we could always take an upside down lambda and put some bars through it and use ¥ for lambda. (Pop quiz: why would some people not be surprised to see this instead of \ ?) [It's a joke.] All of this seems to leave Greek small letter lambda as a keyword as being the simplest solution, but it's easy to predict that it will cause confusion.
True, you need a space after it then. You already need spaces between the variables after the lambda, so anyway you might say that would be more consistent.
Who says there is more than one variable? \(x,y,z)-> doesn't have any spaces. \x -> \y -> \z -> needs spaces, but that's because ->\ is a single token, not because of the identifiers. -- "I don't want to discuss evidence." -- Richard Dawkins, in an interview with Rupert Sheldrake. (Fortean times 232, p55.)

On 2008 May 15, at 3:25, Achim Schneider wrote:
"Yitzchak Gale"
wrote: Brandon S. Allbery KF8NH wrote:
Come to think of it, if you're after math notation, enough Greek letters are used as symbols that it might be necessary to just exclude them from use as letters.
While I have not yet noticed anyone from Greece on this list, I don't think it would be appropriate for us to discriminate against Greek speakers as a built-in feature of Haskell.
/me shudders and tries not to remember those occasions when he read code written in french.
So far I've had to deal with: French, Spanish, German, Swedish, Russian (transliterated), Hebrew (transliterated), Arabic (transliterated). I've also dealt with serious spaghetti code (I'm a Perl programmer in my day job, 'nuff said). I'll take the former, thanks. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 2008 May 14, at 15:00, Andrew Coppin wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 May 14, at 14:32, Andrew Coppin wrote:
Personally, I'd just like to be able to get rid of "->", "\" and other such hacks. Would it be possible to amend GHC so that it accepts "->" and [whatever the Unicode codepoint for "left arrow" is] and treats both the same?
Both of those are already there, along with some others. It's been discussed here but I can't find it in the 6.8.2 manual.... (boo, hiss) -XUnicodeSyntax
Mmm, I can see I'm going to have to test this... [That is, just as soon as I figure out how to even type in obscure Unicode symbols...]
And, for future reference:
#if __GLASGOW_HASKELL__ >= 605 ,("?\x88?", ITdcolon, unicodeSyntaxEnabled) ,("?\x87\x92", ITdarrow, unicodeSyntaxEnabled) ,("?\x88\x80", ITforall, \i -> unicodeSyntaxEnabled i && explicitForallEnabled i) ,("?\x86\x92", ITrarrow, unicodeSyntaxEnabled) ,("?\x86\x90", ITlarrow, unicodeSyntaxEnabled) ,("?\x8b?", ITdotdot, unicodeSyntaxEnabled) -- ToDo: ideally, ?\x86\x92 and ?\x88? should be "specials", so that the y cannot -- form part of a large operator. This would let us have a better -- syntax for kinds: ?\x91?\x88?*?\x86\x92* would be a legal kind signat ure. (maybe). #endif
So ∷, ⇒, ∀, →, ←, ‥ currently supported. Others clearly could be, but probably not as built-in syntax (Prelude.Unicode: let × = *, anyone?). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Wed, 14 May 2008, Andrew Coppin wrote:
Personally, I'd just like to be able to get rid of "->", "\" and other such hacks. Would it be possible to amend GHC so that it accepts "->" and [whatever the Unicode codepoint for "left arrow" is] and treats both the same?
As said, the IDE Leksah can display code exactly like this ...

Henning Thielemann wrote:
On Wed, 14 May 2008, Andrew Coppin wrote:
Personally, I'd just like to be able to get rid of "->", "\" and other such hacks. Would it be possible to amend GHC so that it accepts "->" and [whatever the Unicode codepoint for "left arrow" is] and treats both the same?
As said, the IDE Leksah can display code exactly like this ...
I noticed the first time. Clearly this is another toy I'm going to have to try out sometime...

Andrew Coppin wrote:
Henning Thielemann wrote:
As said, the IDE Leksah can display code exactly like this ...
I noticed the first time. Clearly this is another toy I'm going to have to try out sometime...
...and then he discovers that Darcs isn't working any more. :-( I've recently reinstalled Windows, so I decided to go download the latest Darcs and set that up. Now it's complaining that I don't have curl or wget. (Never used to do that before.) The WindowsConfiguration file doesn't mention anything about it. [And the link back to the Darcs wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice touch...] Presumably this change is new in Darcs 2. I don't recall seeing anything about it when I read the announcement, and I'm now searching the wiki and I still don't see anything about it. Presumably I just need to discover a Windows binary for wget and put it in my search path somewhere? Would be nice if this were documented... Darcs used to just work by itself without any additional tools.

On Wed, May 14, 2008 at 08:37:53PM +0100, Andrew Coppin wrote:
Andrew Coppin wrote:
Henning Thielemann wrote:
As said, the IDE Leksah can display code exactly like this ...
I noticed the first time. Clearly this is another toy I'm going to have to try out sometime...
...and then he discovers that Darcs isn't working any more. :-(
I've recently reinstalled Windows, so I decided to go download the latest Darcs and set that up. Now it's complaining that I don't have curl or wget. (Never used to do that before.) The WindowsConfiguration file doesn't mention anything about it. [And the link back to the Darcs wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice touch...] Presumably this change is new in Darcs 2. I don't recall seeing anything about it when I read the announcement, and I'm now searching the wiki and I still don't see anything about it.
Presumably I just need to discover a Windows binary for wget and put it in my search path somewhere? Would be nice if this were documented... Darcs used to just work by itself without any additional tools.
It's just that the guy who built the windows binary didn't have libcurl installed. Since there don't seem to be many windows developers, we have to live with those few people willing to compile darcs on windows... David

David Roundy wrote:
On Wed, May 14, 2008 at 08:37:53PM +0100, Andrew Coppin wrote:
Andrew Coppin wrote:
I've recently reinstalled Windows, so I decided to go download the latest Darcs and set that up. Now it's complaining that I don't have curl or wget. (Never used to do that before.) The WindowsConfiguration file doesn't mention anything about it. [And the link back to the Darcs wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice touch...] Presumably this change is new in Darcs 2. I don't recall seeing anything about it when I read the announcement, and I'm now searching the wiki and I still don't see anything about it.
Presumably I just need to discover a Windows binary for wget and put it in my search path somewhere? Would be nice if this were documented... Darcs used to just work by itself without any additional tools.
It's just that the guy who built the windows binary didn't have libcurl installed. Since there don't seem to be many windows developers, we have to live with those few people willing to compile darcs on windows...
Well, it seems that simply adding wget.exe to my search path did in fact fix the issue. It hasn't hard to find with Google, but a small note to that effect somewhere in the documentation would be quite nice. Seriously, you have literally *no idea* how much trouble I've just had trying to achieve the simple task of getting Leksah to work. Every imaginable thing has gone wrong. Each impediment is fairly trivial in itself, but the sheer volume of them is... straining my patience! - Darcs now needs wget in order to work. [Easy to fix once you work out how.] - Leksah needs Gtk2hs, but I have GHC 6.8.2. [Thank the Maker for gname - I've have never found the URL for the unofficial Gtk2hs build to fix this!] - Leksah needs something called "binary". [Once you figure out that that's a package and you're supposed to get it from Hackage, it's quite easy to find. Figuring out what to do with a tarball on Windows isn't that amusing. However, for once, Cabal did actually build and install it without issue.] - When I try to install Leksah, it complains that a PNG file doesn't exist. [My guess is the author's Darcs repo contains it, but they forgot to tell Darcs.] So I _manually edit_ the Cabal file. [Eeek!] Obviously Cabal now makes me reconfigure and rebuild, but the program now installs just fine. - Gee, now I wonder *where* exactly Cabal installed it? Oh well, it seems to have put the binary in my search path anyway - that's a nice touch. Now, let's see what this IDE actually looks li-- oh you have GOT to be KIDDING me! It can't find the right GTK DLL?!? By now, I've been trying to "try out Leksah" for about an hour. As you can see, each problem is pretty small [although the "manually edit Cabal file" bit was scary]. However, add together enough small problems and you end up with a very frustrating experience. When it takes you 10 minutes or so to fix each problem, 6 small problems = 1 hour of your life. It adds up rather fast. :-( At this point, my best guess is that the unofficial Gtk2hs binary is broken somehow. [Although I don't recall hearing anybody yelling about it...] Maybe tomorrow I'll try again on my other box that has an older GHC on it and see how that goes. For tonight, I'm just too frustrated to continue. [I hope nobody takes my frustration *too* seriously. I'm just a little bit exasperated right now. I'll get over it. By tomorrow, this will probably seem very amusing... but right now it's quite late, and I'm sleepy.]

Hello Andrew, Thursday, May 15, 2008, 12:49:32 AM, you wrote:
touch. Now, let's see what this IDE actually looks li-- oh you have GOT to be KIDDING me! It can't find the right GTK DLL?!?
gtk2hs includes *developer* gtk2 environment. while it should work fine (as far as it's in your path), you may try to install *runtime* gtk2 environment from http://sourceforge.net/project/showfiles.php?group_id=71914&package_id=255391 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Thu, 2008-05-15 at 01:01 +0400, Bulat Ziganshin wrote:
Hello Andrew,
Thursday, May 15, 2008, 12:49:32 AM, you wrote:
touch. Now, let's see what this IDE actually looks li-- oh you have GOT to be KIDDING me! It can't find the right GTK DLL?!?
gtk2hs includes *developer* gtk2 environment.
Which includes all the runtime dlls.
while it should work fine (as far as it's in your path), you may try to install *runtime* gtk2 environment from http://sourceforge.net/project/showfiles.php?group_id=71914&package_id=255391
I would not recommend that. I'd use the dlls that come with gtk2hs. Of course if you're deploying a Windows program that uses gtk2hs then using just the runtime dlls is just the right thing to do. Though for that case we provide the runtime dlls: http://haskell.org/gtk2hs/win32/ As an example, here's an installer for a standalone prog that uses gtk2hs but doesn't need ghc or gtk2hs to be installed already: http://haskell.org/~duncan/gtk2hs/LSystemSetup.exe Duncan

Duncan Coutts wrote:
On Thu, 2008-05-15 at 01:01 +0400, Bulat Ziganshin wrote:
Hello Andrew,
Thursday, May 15, 2008, 12:49:32 AM, you wrote:
touch. Now, let's see what this IDE actually looks li-- oh you have GOT to be KIDDING me! It can't find the right GTK DLL?!?
gtk2hs includes *developer* gtk2 environment.
Which includes all the runtime dlls.
while it should work fine (as far as it's in your path), you may try to install *runtime* gtk2 environment from http://sourceforge.net/project/showfiles.php?group_id=71914&package_id=255391
I would not recommend that. I'd use the dlls that come with gtk2hs.
Well, gmane shows that Duncan sent a second message about this - but since I didn't receive it in my mailbox, I can't reply quoting that. [Most irritating...] Anyway, running Leksah today, it doesn't complaing about missing GTK DLLs at all, so you must be right about the search path thing. [Now instead it crashes with a completely different error.] I built a copy of Leksah at work, and noticed that I didn't get the issue with a missing icon, so apparently the Darcs repo must have changed in the last few hours. (Indeed, I guess I could ask Darcs and find out!) The copy I built at work [with GHC 6.8.1] worked just fine - not that I could figure out how to use it. ;-)

Hello Duncan, Friday, May 16, 2008, 2:05:53 AM, you wrote:
Of course if you're deploying a Windows program that uses gtk2hs then using just the runtime dlls is just the right thing to do. Though for that case we provide the runtime dlls:
As an example, here's an installer for a standalone prog that uses gtk2hs but doesn't need ghc or gtk2hs to be installed already:
i've just tried that. for me there is still one problem - my program includes a lot of other files beside exe and i will be glad to have gtk2hs put to separate subtree. is it possible? say, c:/Program Files/WinArc/winarc.* c:/Program Files/WinArc/gtk2hs/bin/*.dll c:/Program Files/WinArc/gtk2hs/etc/* c:/Program Files/WinArc/gtk2hs/lib/* and so on -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Mon, 2008-05-19 at 00:35 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Friday, May 16, 2008, 2:05:53 AM, you wrote:
Of course if you're deploying a Windows program that uses gtk2hs then using just the runtime dlls is just the right thing to do. Though for that case we provide the runtime dlls:
As an example, here's an installer for a standalone prog that uses gtk2hs but doesn't need ghc or gtk2hs to be installed already:
i've just tried that. for me there is still one problem - my program includes a lot of other files beside exe and i will be glad to have gtk2hs put to separate subtree. is it possible? say,
c:/Program Files/WinArc/winarc.* c:/Program Files/WinArc/gtk2hs/bin/*.dll c:/Program Files/WinArc/gtk2hs/etc/* c:/Program Files/WinArc/gtk2hs/lib/*
and so on
Not easily. Windows looks first for dlls in the same directory as your .exe program. So in the above layout you'd need your .exe to live in that bin directory. If we were able to use windows assembly manifests with ghc on Windows then it would be possible to put the dlls in a sub directory relative to your .exe program. At the moment I think we don't have any real support for assemblies with ghc, mostly because gcc itself doesn't help us there. Using assemblies is the right long term solution I think. Using an "isolated" assembly would also allow us to install Gtk2Hs without having to mess with the $PATH. Duncan

On Wed, 2008-05-14 at 21:49 +0100, Andrew Coppin wrote:
At this point, my best guess is that the unofficial Gtk2hs binary is broken somehow. [Although I don't recall hearing anybody yelling about it...] Maybe tomorrow I'll try again on my other box that has an older GHC on it and see how that goes. For tonight, I'm just too frustrated to continue.
Is this the "unofficial" Gtk2Hs installer you were using? http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.12.1.exe I've been told it works ok. If you've only just installed it then you do need to start a new command shell because existing open shells do not pick up the change to the environment variables. You can double check that Gtk2Hs installed ok by cd'ing to one of the demo directories and using ghc --make to build a demo. If then demo .exe runs ok then the dlls are on the %PATH%. If that fails, you can double check your user %PATH% and make sure it does have an entry that points to the Gtk2Hs/bin dir. The Gtk2Hs installer only sets the %PATH% for the user that ran the installer, not globally for every user. I hope you can get it working. Duncan
participants (17)
-
Achim Schneider
-
Alec Berryman
-
Andrew Coppin
-
Andy Smith
-
Brandon S. Allbery KF8NH
-
Bulat Ziganshin
-
Dan Weston
-
David Roundy
-
Derek Elkins
-
Duncan Coutts
-
Eric Stansifer
-
Henning Thielemann
-
Neil Mitchell
-
Patrick Surry
-
Reinier Lamers
-
Richard A. O'Keefe
-
Yitzchak Gale