On Tue, Nov 8, 2011 at 11:28 PM, wagne...@seas.upenn.edu wrote:
I don't agree that GHC's user interface should be optimized for newcomers
to Haskell. GHC is an industrial-strength compiler with some very advanced
features; the majority of its target audience is professional programmers.
Let
On 8 November 2011 11:43, Simon Marlow marlo...@gmail.com wrote:
Don't you mean 1 is what we have?
Yes, sorry!
Failing to roundtrip in some cases, and doing so silently, seems highly
suboptimal to me. I'm sorry I didn't pick up on this at the time (Unicode
is a swamp :).
I *can* change the
On 7 November 2011 17:32, John Millikin jmilli...@gmail.com wrote:
I am also not convinced that it is possible to correctly implement
either of these functions if their behavior is dependent on the user's
locale.
FWIW it's only dependent on the users locale because whether glibc
iconv detects
On Wed, Nov 09, 2011 at 11:02:54AM +, Simon Marlow wrote:
I would be happy with the surrogate approach I think. Arguable if
you try to treat a string with lone surrogates as Unicode and it
fails, then that is a feature: the original string wasn't Unicode.
All you can do with an invalid
How much does using ghc without cabal imply a newer programmer? I don't use
cabal when trying out small bits of code (maybe I should be using ghci),
but am otherwise always using cabal.
On Wed, Nov 9, 2011 at 3:18 AM, Duncan Coutts
duncan.cou...@googlemail.comwrote:
On 9 November 2011 00:17,
On 9 November 2011 13:53, Greg Weber g...@gregweber.info wrote:
How much does using ghc without cabal imply a newer programmer? I don't use
cabal when trying out small bits of code (maybe I should be using ghci), but
am otherwise always using cabal.
The main reason cabal has always defaulted
On 9 November 2011 13:11, Ian Lynagh ig...@earth.li wrote:
If we aren't going to guarantee that the encoded string is unicode, then
is there any benefit to encoding it in the first place?
(I think you mean decoded here - my understanding is that decode ::
ByteString - String, encode :: String -
On 9 November 2011 11:02, Simon Marlow marlo...@gmail.com wrote:
The performance overhead of all this worries me. withCString has taken a
huge performance hit, and I think there are people who wnat to know that
there aren't several complex encoding/decoding passes between their Haskell
code
On 08/11/2011 15:42, John Millikin wrote:
On Tue, Nov 8, 2011 at 03:04, Simon Marlowmarlo...@gmail.com wrote:
I really think we should provide the native APIs. The problem is that the
System.Posix.Directory API is all in terms of FilePath (=String), and if we
gave that a different meaning
On 09/11/2011 13:11, Ian Lynagh wrote:
On Wed, Nov 09, 2011 at 11:02:54AM +, Simon Marlow wrote:
I would be happy with the surrogate approach I think. Arguable if
you try to treat a string with lone surrogates as Unicode and it
fails, then that is a feature: the original string wasn't
On Wed, Nov 9, 2011 at 08:04, Simon Marlow marlo...@gmail.com wrote:
Ok, I spent most of today adding ByteString alternatives for all of the
functions in System.Posix that use FilePath or environment strings. The
Haddocks for my augmented unix package are here:
On 09/11/2011 15:58, Max Bolingbroke wrote:
(Note that the above outlined problems are problems in the current
implementation too -- but the current implementation doesn't even
pretend to support U+EFxx characters. Its correctness is entirely
dependent on them never showing up, which is why we
On Wed, Nov 09, 2011 at 03:58:47PM +, Max Bolingbroke wrote:
(Note that the above outlined problems are problems in the current
implementation too
Then the proposal seems to me to be strictly better than the current
system. Under both systems the wrong thing happen when U+EFxx is entered
My primary concerns are (in order of priority - and I only speak for myself)
(a) consistency across platforms
(b) minimize (unrequired) performance overhead
I would prefer an api which is consistent for both win32, posix or other
os which only did as much as what the user (us) wanted
for
14 matches
Mail list logo
