No, it is not. Strings created by show are always supposed to be readable by read, no matter which system used 'show' and which system is using 'read'. Maurício Rafael C. de Almeida a écrit :

Mauricio wrote:

...

Hi,

A small annoyance some users outside english speaking countries usually experiment when learning programming languages is that real numbers use a '.' instead of ','. Of course, that is not such a problem except for the inconsistence between computer and free hand notation.

Do you think 'read' (actually, 'readsPrec'?) could be made to also read the international convention (ie., read "1,5" would also work besides read "1.5")? I'm happy to finaly use a language where I can use words of my language to name variables, so I wonder if we could also make that step.

Isn't it locale dependent? If it isn't, it should be. Try setting your locale right and see if things work. At least awk work fine that way.

Although I don't like too much that kinda stuff, I usually set the locale to C so I keep all my programs behaving consistently. I have problems with that stuff before (a file generated by an awk script had , instead of . and that would confuse other computers with a different locale).

Maybe. Doubles 'show' function always print something after the decimal separator, so 'show [doubles]' is easy to parse but difficult for human reading. It would be nice to have a space between elements of a shown list, though. It's an annoyance, but internationalization is really great, I think it deserves the effort. Best, Maurício Tilo Wiklund a écrit :

Wouldn't that make it hard to parse lists of floats?

On Tue, 2008-09-16 at 09:29 -0300, Mauricio wrote:

...

Hi,

A small annoyance some users outside english speaking countries usually experiment when learning programming languages is that real numbers use a '.' instead of ','. Of course, that is not such a problem except for the inconsistence between computer and free hand notation.

Do you think 'read' (actually, 'readsPrec'?) could be made to also read the international convention (ie., read "1,5" would also work besides read "1.5")? I'm happy to finaly use a language where I can use words of my language to name variables, so I wonder if we could also make that step.

Thanks, Maurício

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

------------------------------------------------------------------------

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

...

I'm happy to finaly use a language where I can use words of my language to name variables, so I wonder if we could also make that step.

Really?

There is a bunch of languages (like "Glagol") that use words of Russian language as keywords; AFAIK there aren't any Russian programmer who uses them. I've always felt sorry for English-speaking programmers: they HAVE to use the same words as keywords and as usual talking words at the same time.

Here I totally aggree with you. It's great that I can use words in my language for variables, but the same would be really annoying if the same was true for keywords. Best, Maurício

...

Do you think 'read' (actually, 'readsPrec'?) could be made to also read the international convention (ie., read "1,5" would also work besides read "1.5")? I'm happy to finaly use a language where I can use words of my language to name variables, so I wonder if we could also make that step.

That would be quite problematic in combination with lists, is

read "[1,2,3,4]" == [1,2,3,4]

or

read "[1,2,3,4]" == [1.2, 3.4]

Or something else?

As of today, at least in ghc, show ([1,2,3]::[Double]) will always produce "[1.0,2.0,3.0]". Since the requirement for read is to read what is produced by show, that would not be a problem.

Localized reading should be somewhere else, perhaps related to Locales.

No! If we had that, string from a program would not be readable by some program running in other machine, or other locale. As, actually, you describe below. Show and Read are for programs reading, not for user reading. That's a work for Pango :)

As an aside, this is one of the (many) places where Haskell has made the right choice. In other languages such as Java input functions suddenly break when the user has a different locale setting. While for user input this might be desired, in my experience much of the i/o a program does is with well defined file formats where changing '.' to ',' just shouldn't happen.

Best, Maurício

On 2008 Sep 17, at 14:38, Aaron Denney wrote:

On 2008-09-17, Mauricio wrote:

...

...

Localized reading should be somewhere else, perhaps related to Locales.

No! If we had that, string from a program would not be readable by some program running in other machine, or other locale. As, actually, you describe below. Show and Read are for programs reading, not for user reading. That's a work for Pango :)

While a thousands separator can improve readability, it's not strictly necessary. OTOH, a decimal separator is necessary. As the comma's not usable, that leaves us with the decimal point, and no thousands separator. Lo and behold, that's exactly what Haskell uses.

There are languages which ignore _ in numbers, allowing it to be used as a thousands separator if desired. ghc currently parses "1_234" as <1:number> <_234:symbol> and I'm tempted to wonder if anything depends on 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

...

Do you think 'read' (actually, 'readsPrec'?) could be made to also read the international convention (ie., read "1,5" would also work besides read "1.5")? I'm happy to finaly use a language where I can use words of my language to name variables, so I wonder if we could also make that step.

The purpose of 'read' is to read haskell notation, not to read locally-sensitive notation.

So the right question to ask is "should we change haskell's lexical syntax to support locally-sensitive number notation".

IMO, the answer is no. (...)

Agree about the answer, not about the question. The correct one would be "is it possible to change haskell syntax to support the international notation (not any locally sensitive one) for decimal real numbers? Would a change in 'read' be a good first step?" I know this looks difficult, but I'm sure it deserves at least some thinking. We have previous examples for less important issues: ghc does accept Windows end of line conventions, the minus and sign needs special syntax, and '.' can be used as decimal separator even if it's use as function notation. Best, Maurício