Hello, On Wednesday 27 February 2008 17:30, Ian Lynagh wrote:
On Tue, Feb 26, 2008 at 07:30:08PM -0500, David Roundy wrote:
On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote:
I think personally I'm coming round to the "always locale" point of view. We already have no cross-platform consistency for text files because of the lf vs cr/lf issue and we have no cross-implementation consistency.
I'm leaning in the same direction.
This has swung me too.
Let me be contrary, then: The "always locale" idea depends, as I understand it, on some relatively global setting. And, especially in the context of functional programming, global things dont strike me as particularly appropriate. This particular global thing also has the wonderful property of being modifiable. So it is actually a global variable.Some years ago, I had a hard time because some program that I hadn't written, but had to call from my program, occasionally changed the locale setting when called. The problem turned out, after much and exasperating work, to be that this changed the behaviour of sprintf: In Denmark we use commas for decimal points. I know that we are not supposed to discuss a new and marvellous IO library on this thread, but let me mention what I would consider a very valuable property of this new library that I believe may affect what we do now to clean up the present affair: I would very much like to be able to specify the desired encoding myself, as others have mentioned, at some level of using this new library. So that the present library in principle could be implemented on top of this by specifying any desirable encoding used, including using the current locale setting or utf-8 or letting the encoding depend on the device or whatever one prefers. So although my favorite choice at this moment is "always utf-8", I am much more concerned that the choice that we make does not exclude the possibility of creating this new and wonderful IO library that can be used easily to support the behaviour of the existing library (in whatever form it is changed into as a result of the present discussion).
...
Best regards Thorkil
On Wed, Feb 27, 2008 at 06:05:46PM +0100, Thorkil Naur wrote:
Hello,
On Wednesday 27 February 2008 17:30, Ian Lynagh wrote:
On Tue, Feb 26, 2008 at 07:30:08PM -0500, David Roundy wrote:
On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote:
I think personally I'm coming round to the "always locale" point of view. We already have no cross-platform consistency for text files because of the lf vs cr/lf issue and we have no cross-implementation consistency.
I'm leaning in the same direction.
This has swung me too.
Let me be contrary, then: The "always locale" idea depends, as I understand it, on some relatively global setting. And, especially in the context of functional programming, global things dont strike me as particularly appropriate.
This particular global thing also has the wonderful property of being modifiable. So it is actually a global variable.Some years ago, I had a hard time because some program that I hadn't written, but had to call from my program, occasionally changed the locale setting when called. The problem turned out, after much and exasperating work, to be that this changed the behaviour of sprintf: In Denmark we use commas for decimal points.
Of course, something like sprintf would be a pure function (and thus safe, but also perhaps incorrect) in Haskell... It'd be up to the implementors whether to indeed allow the locale setting to be modified during the course of a program running, there's certainly no requirement that it be mutable, and certainly it need not be externally mutable. If we only check the locale once, we're safe from all "locale rotating with the phase of the moon" bugs. Certainly stdin/out/err would be safe, because they'd only be opened when the program starts. -- David Roundy Department of Physics Oregon State University
Hi,
My preference would be for handles to have a "mode" that specifies the
encoding to use when reading and writing characters. By default, the
mode should be set to the encoding specified in the locale but we
should also provide an explicit "setEncoding" method so that
programmers can specify the encoding to be used explicitly.
-Iavor
On Wed, Feb 27, 2008 at 12:19 PM, David Roundy
On Wed, Feb 27, 2008 at 06:05:46PM +0100, Thorkil Naur wrote:
Hello,
On Wednesday 27 February 2008 17:30, Ian Lynagh wrote:
On Tue, Feb 26, 2008 at 07:30:08PM -0500, David Roundy wrote:
On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote:
I think personally I'm coming round to the "always locale" point of view. We already have no cross-platform consistency for text files because of the lf vs cr/lf issue and we have no cross-implementation consistency.
I'm leaning in the same direction.
This has swung me too.
Let me be contrary, then: The "always locale" idea depends, as I understand it, on some relatively global setting. And, especially in the context of functional programming, global things dont strike me as particularly appropriate.
This particular global thing also has the wonderful property of being modifiable. So it is actually a global variable.Some years ago, I had a hard time because some program that I hadn't written, but had to call from my program, occasionally changed the locale setting when called. The problem turned out, after much and exasperating work, to be that this changed the behaviour of sprintf: In Denmark we use commas for decimal points.
Of course, something like sprintf would be a pure function (and thus safe, but also perhaps incorrect) in Haskell...
It'd be up to the implementors whether to indeed allow the locale setting to be modified during the course of a program running, there's certainly no requirement that it be mutable, and certainly it need not be externally mutable. If we only check the locale once, we're safe from all "locale rotating with the phase of the moon" bugs. Certainly stdin/out/err would be safe, because they'd only be opened when the program starts.
-- David Roundy Department of Physics Oregon State University _______________________________________________
Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (3)
-
David Roundy -
Iavor Diatchki -
Thorkil Naur