Re: [Haskell-cafe] Re: Float instance of 'read'
On 18 Sep 2008, at 3:20 am, Mauricio wrote:
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?"
For some sense of "possible", the answer is clearly yes. However, it is perhaps misleading to call commas "THE international notation". The plain fact of the matter is that whatever any standards body may say, there are MANY notations for numbers. You might as well ask "is it possible to change Haskell syntax to support only the *real* Arabic digits ... for ... numbers". The Arabic script is used in many countries, so it's international. I don't read Arabic letters at all, but to me numbers written in Arabic script are no weirder than numbers using commas instead of dots. I would draw readers' attention to http://engineers.ihs.com/news/2006/nist-decimal-international.htm which says that (1) China, India, and Japan use decimal points, not commas. (2) There was a resolution of the CGPM in 2003 "endorsing the use of the point on the line as a decimal sign". (3) In June 2006, ISO agreed to allow the use of dots as decimal points in international standards. As it happens, the decimal point character I greatly prefer is the traditional British raised dot, but I can live with a low dot. I am 100% behind internationalised input and output, but allowing commas in numbers inside programming languages that already use commas for other purposes is, let's be polite, not a terribly good idea. You could probably get away with it in Lisp, but how many numbers are there in (1,2,3)? One thing that definitely is missing from Haskell numbers, and which I greatly miss, is a "thousands separator". Ada got around the dot/comma/apostrophe/whatever issue for thousands separators by using the underscore. For an unsigned decimal integer, this means allowing [0-9](_?[0-9])* instead of [0-9]+. It works really well, despite not being ANYBODY's cultural convention.
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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
==================================================================== Auto Generated Mail Footer If this email is requesting your password then it is a HOAX. DO NOT reply to the email. Validate this footer at the Otago University web site keyword search: information security phish ====================================================================
-- If stupidity were a crime, who'd 'scape hanging?
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 (...)
For some sense of "possible", the answer is clearly yes. However, it is perhaps misleading to call commas "THE international notation". (...) You might as well ask "is it possible to change Haskell syntax to support only the *real* Arabic digits ... for ... numbers". (... + evindences that there isn't one single standard)
Well, utf-8 strings seemed to me a good way to initialize variables, and we could, for instance use something like "[1,2,3,4]" to initialize other kinds of lists besides the standard one. One example I got from gtk2hs are marked-up text on labels. So, I actually thought we could add support for arabic and japanese digits, and any other ways we get without ambiguities (continued fractions, I would like, and I also liked the idea of the raised dot). Well, after all the comments, I'm convinced changing the Show and Read classes are not the way to go. But I'll think of something like a InitializableByUFT8String class, and I'll advertize it here if I ever get something usable and interesting. Thanks for your comments, Maurício
Hi, Mauricio, sorry for hijacking your thread. : ) I have one question about handling or parsing decimal places. I noticed that Haskell doesn't accept values starting with just the point, e.g., .50 or .01. I suppose that's abuse of notation in the first place (and I'm guilty of it), but I often receive datasets that have numbers written that way. Do we have this behavior to avoid ambiguity with the dot operator? For example:
.1 <interactive>:1:0: parse error on input `.'
read ".1" :: Float *** Exception: Prelude.read: no parse
And then:
let (.) = (+) 1 .1 2
I often end up writing a function that will add a leading zero when
it's missing for decimal places, before feeding a string to read. Is
there a better way of handling this?
Thanks,
Paulo
On Thu, Sep 18, 2008 at 7:13 AM, Mauricio
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 (...)
For some sense of "possible", the answer is clearly yes. However, it is perhaps misleading to call commas "THE international notation". (...) You might as well ask "is it possible to change Haskell syntax to support only the *real* Arabic digits ... for ... numbers". (... + evindences that there isn't one
single standard)
Well, utf-8 strings seemed to me a good way to initialize variables, and we could, for instance use something like "[1,2,3,4]" to initialize other kinds of lists besides the standard one. One example I got from gtk2hs are marked-up text on labels. So, I actually thought we could add support for arabic and japanese digits, and any other ways we get without ambiguities (continued fractions, I would like, and I also liked the idea of the raised dot).
Well, after all the comments, I'm convinced changing the Show and Read classes are not the way to go. But I'll think of something like a InitializableByUFT8String class, and I'll advertize it here if I ever get something usable and interesting.
Thanks for your comments, Maurício
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Mauricio -
Paulo Tanimoto -
Richard A. O'Keefe