[Haskell-cafe] Re: Float instance of 'read'
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
Re: [Haskell-cafe] Re: Float instance of 'read'
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 [EMAIL PROTECTED] 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 (...) 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of 'read'
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). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of 'read'
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of 'read'
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of 'read'
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of 'read'
As of today, show ((1,2)::(Float,Float)) would not produce that kind of output. Dan Piponi a écrit : Mauricio asked: 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)? What would you hope the value of read (1,2,3)::(Float,Float) would be? -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of 'read'
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Float instance of 'read'
Given examples like (1,2,3) I don't see how comma could ever be used instead of dot, unless you insist on whitespace around all commas. And that doesn't look like the right way forward. -- Lennart On Wed, Sep 17, 2008 at 4:20 PM, Mauricio [EMAIL PROTECTED] wrote: 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 ___ 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
[Haskell-cafe] Re: Float instance of 'read'
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)? No, as read is really intended to be a language-level tool, not something that you should expose to end users. For locale-aware number input and formatting, you'd want to do something else. Sure. What I think would be great if possible would be a language-level tool. The same way '.' can be used as decimal separator even if it's the function composition operator. If it's not possible to change the syntax, changing 'read' could be a good step (since, sometimes, 'read' is a good way to inialize some variables if proper care is taken. I know this sound weird, but it is an issue, for instance, when teaching programming. Students who face programming classes usually start writing numbers the wrong way, and sometimes this leads to confusion. A similar problem we had in the days when zeros were cut so they would be different of O, and now we have a lot of grown up people still writing 0 as if it were a greek phi. (As my father used to complain, when his students had to write something like phi=0.) Read and Show are, IMHO, a great way to initialize variables. a = read 123 is an alternative to a = 123, and maybe even a replacement. If, for instance, both show and read used some kind of delimiter, it would be easy to use reasonable ways to write constants of any kind. A big effort, but not less than is needed for unicode support in strings, and almost as usefull. Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of 'read'
On 2008-09-17, Mauricio [EMAIL PROTECTED] 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 :) UI can be done with text, and in any case includes text and there should be some nice way to localize that. The locale system is the standard way to do that on Unix. These strings are not meant for program-to-program communication, whereas read and show are. IMAO, it's bloody well stupid to use commas for either the decimal separator or the thousands separator, as it has a well established role in separating the items in a list that conflicts with this. 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. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Float instance of 'read'
On 2008 Sep 17, at 14:38, Aaron Denney wrote: On 2008-09-17, Mauricio [EMAIL PROTECTED] 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] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of 'read'
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)? (...) IMAO, it's bloody well stupid to use commas for either the decimal separator or the thousands separator, as it has a well established role in separating the items in a list that conflicts with this. (...) After 10 years of professional experience, I'm getting used to the fact that almost every time someone says my idea is stupid I'm going in the right direction. Linux, firefox… And know everybody in the office uses nothing else. It's stupid to use anything but Java, that's what the whole world is using, and here I am writing software in Haskell. Really, no troll intended. This is an open source world, I'll try my own Read and Show classes. If others like it, great, if not, I was wrong in the first place :) Best! Thanks for your attention, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
