Re: String != [Char]
On Sun, Mar 25, 2012 at 3:47 PM, Gabriel Dos Reis < g...@integrable-solutions.net> wrote: > > We are doing our students no favor, no good, in being condescending to > them pretending that they can't handle teaching material that would > actually > be close real world experience. If we truly believe that they don't have > enough time to learn what would really be useful to them, then we are > truly wasting their valuable time teaching them things they would have to > unlearn before writing good and correct code. The education would have > been a complete failure and waste of resources. > > When people teach Haskell, it typically isn't to give them "real world experience", but to teach them an interesting programming language and all the great computer science it leads to. Types, laziness, higher-order abstractions are the hard bits to learn, not a string-processing API. If people want to learn how to deal with unicode correctly, I can think of several better places to learn about it than a Haskell course. I don't think it's condescending or impractical to focus on the things that make Haskell unique, rather than teaching a unicode-correct API that could conceivably be written in any other language. Learning that real human text cannot be treated just an independent list of characters is something that takes minutes to hours at most: someone tells you that there are all sorts of exceptions to the list-of-chars paradigm, and then you read an article or two on the language-specific difficulties, learn to use specialized API functions, and then you get on with what you were actually trying to do. So I think saying that ignoring unicode-correct strings a complete failure and waste of resources is a bit hyperbolic, honestly. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
If the input is specified to be UTF-8, wouldn't it be better to call the method unpackUTF8 or something like that? On Mon, Mar 19, 2012 at 12:59 PM, Johan Tibell wrote: > On Mon, Mar 19, 2012 at 9:02 AM, Christian Siefkes > wrote: > > On 03/19/2012 04:53 PM, Johan Tibell wrote: > >> I've been thinking about this question as well. How about > >> > >> class IsString s where > >> unpackCString :: Ptr Word8 -> CSize -> s > > > > What's the Ptr Word8 supposed to contain? A UTF-8 encoded string? > > Yes. > > We could make a distinction between byte and Unicode literals and have: > > class IsBytes a where >unpackBytes :: Ptr Word8 -> Int -> a > > class IsText a where >unpackText :: Ptr Word8 -> Int -> a > > In the latter the caller guarantees that the passed in pointer points > to wellformed UTF-8 data. > > -- Johan > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
I'm very happy to see all the work you're putting into the record discussion, but I'm struggling to see why people are fighting so hard to get the dot character in particular for field access. It seems like a huge amount of work and discussion for a tiny bit of syntactic convenience that we've only come to expect because of exposure to other very different languages. Is there some fundamental reason we couldn't settle for something like # (a valid operator, but we've already shown we're willing to throw that away in the MagicHash extension) or @ (only allowed in patterns for now)? Or we could even keep (#) as a valid operator and just have it mean category/lens composition. Thanks, Dan On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber wrote: > Similar to proposal #20, which wants to remove it, but immediately > less drastic, even though the long-term goal is the same. > This helps clear the way for the usage of the unspaced dot as a record > field selector as shown in proposal #129. > > After this proposal shows clear signs of moving forward I will add a > proposal to support a unicode dot for function composition. > After that we can all have a lively discussion about how to fully > replace the ascii dot with an ascii alternative such as <~ or <<< > After that we can make the dot operator illegal by default. > > This has already been discussed as part of a records solution on the > ghc-users mail list and documented here: > http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Reform of the Monad, and Disruptive Change
> Perhaps GHC could be released with two sets of libraries. This would give
> people time to experiment without breaking existing code. It would also make
> implementing individual changes much easier.
>
>
I fully support this. {-# LANGUAGE NewPrelude #-} or something similar would
be wonderful.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: On the Meaning of Haskell 7
I think it's more about readership. There's almost nobody on this mailing list, and haskell-cafe has way more traffic. You might actually get feedback about your ideas there. On Mon, Nov 30, 2009 at 2:56 PM, John D. Earle wrote: > This may be the last in the series given that Simon Marlow feels that I am > being non-sequitur. I on the other hand feel that I am being very much on > topic. To quote Dune, "They move in mysterious ways." I wanted to complete a > thought and I thought to end it on number 7. > > My guess is why the case-of construct is preferred is due to Haskell being a > functional language. In other words the world is to be wrapped up into a > ball and passed like a basketball. The if-then-else paradigm holds a world > view where the world consists of disparate parts to be accessed and tested, > however. This supports my thesis. It may be worth considering the removal of > if-then-else as opposed to fixing it. > > Simon Marlow wrote "haskell-prime@haskell.org is specifically for discussing > proposals for changes in future revisions of the Haskell language." I have > an anti-proposal. Do not change anything unless you know what you are doing. > Don't make a proposal unless you know what you are saying. > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
