- Haskell-prime - Haskell.org

separate class and type namespace
by John Meacham 04 Feb '06

04 Feb '06

What do people think about seperating the class and type namespaces? one can always tell the difference syntactically which is meant, the only thing keeping them in the same space in jhc is an artificial check to ensure you don't create some of the same name. the only issue is in export/import lists if you wanted to allow import/export of the type independently of the class. however the proposed explicit namespace change to the import/export syntax would solve this too and it is unlikely to actually be a problem in practice. this would allow things like one to have a class and a data type holding an arbitrary member of said class to have the same name. it is unwieldy to have things like FooClass and Foo be separate. John -- John Meacham - ⑆repetae.net⑆john⑈

8 14

Re: [Haskell-cafe] Re[2]: strict Haskell dialect
by John Meacham 03 Feb '06

03 Feb '06

On Fri, Feb 03, 2006 at 07:33:12PM -0000, Brian Hulley wrote: > One question is how to get some kind of "do" notation that would work well > in a strict setting. > The existing "do" notation makes use of lazyness in so far as the second > arg of >> is only evaluated when needed. Perhaps a new keyword such as > "go" could be used to use >>= instead ie: you can override (>>) in your monad instance Monad ... where a >> b = a `seq` b `seq` (a >>= \_ -> b) .... unless I am misunderstanding what you want. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

RE: The dreaded M-R
by Simon Marlow 03 Feb '06

03 Feb '06

I've put a wiki page with a summary of this discussion here: http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/Monomorph ismRestriction Hopefully I've captured most of the important points, please let me know if there's anything I missed, or misrepresented. I'll add a ticket shortly. Given the new evidence that it's actually rather hard to demonstrate any performance loss in the absence of the M-R with GHC, I'm attracted to the option of removing it in favour of a warning. Cheers, Simon

14 18

Dictionary definitions on wiki
by Philippa Cowderoy 03 Feb '06

03 Feb '06

I just added a ticket requesting that some definitions be added to the wiki (so that other pages and tickets can link to them, helping to demystify jargon for those who don't specialise in specific fields). I've also included quick definitions for "predicative" and "impredicative" in the ticket, as these were asked for on the mailing list earlier and will no doubt crop up again in type system discussions. Would anyone like to act on this or contribute more definitions to the ticket while it's waiting? -- flippa(a)flippac.org Performance anxiety leads to premature optimisation

2 1

Tim Sweeney talks about Haskell
by Robert Dockins 03 Feb '06

03 Feb '06

Somewhat apropos. The following recent post on LtU links to some slides by Tim Sweeney (Epic Games) wherein he discusses things he does and doesn't like about Haskell. Notable points: == Positive on ST (implies need for rank 2 types) == Positive on Concurrency and STM == Positive on list comprehension (but would like to see array comprehension) == Positive on declarative initialization == Wants static type guarantees about integer overflow, array bounds == Wants a good, safe way to do dynamic casts == Not happy with runtime cost of lazy evaluation, suggests lenient evaluation == Claims "purely functional is the right default"! == Doesn't like the syntax == Claims there are problems with programming in the large (see last slide) Anyway, some further fuel for the fire. http://lambda-the-ultimate.org/node/1277 There is a link to PDF of the slides a couple of posts down... Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

1 0

RE: ~ patterns
by Simon Marlow 03 Feb '06

03 Feb '06

On 30 January 2006 18:20, Isaac Jones wrote: > Can someone be sure to capture the pros, cons, and relationship to the > !-patterns proposal as a ticket / wiki page? I've been swayed by the arguments put forward by the ~-proponents, so I'm not going to champion the removal of ~ any more. We must find *something* to throw away though! :-) Cheers, Simon

17 28

RE: Comment Syntax
by Simon Marlow 03 Feb '06

03 Feb '06

On 03 February 2006 00:40, John Meacham wrote: > On Thu, Feb 02, 2006 at 06:19:43PM -0600, Taral wrote: >> Got a unicode-compliant compiler? > > sure do :) > > but it currently doesn't recognize any unicode characters as possible > operators. which it should, but I am just not sure how to specify that > yet until some sort of standard develops. Once there are more unicode > compliant compilers out there something will evolve probably. Right > now I am thinking of being able to add a PRAGMA to force some > characters to be interpreted as operators just so that they can start > being used now, even though there isn't a standard set you can count > on yet. GHC treats the Unicode categories Sm, Sc, Sk and So as symbols, FWIW. These are the same characters for which Data.Char.isSymbol returns True. How do you implement the Data.Char predicates in jhc, BTW? Cheers, Simon

2 1

RE: Unicode, was Comment Syntax
by Simon Marlow 03 Feb '06

03 Feb '06

On 03 February 2006 04:07, Taral wrote: > On 2/2/06, John Meacham <john(a)repetae.net> wrote: >> but it currently doesn't recognize any unicode characters as possible >> operators. which it should, but I am just not sure how to specify >> that yet until some sort of standard develops. Once there are more >> unicode compliant compilers out there something will evolve probably. > > Character attributes are defined in unicode: > > http://www.unicode.org/Public/UNIDATA/ > > It's just a matter of mapping. Perhaps this is worth considering > amending for Haskell'? The Haskell98 grammar talks about "symbol", > "uppercase", "lowercase", while Unicode is a bit more... diverse. This is already mentioned on the wiki: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/UnicodeInH askellSource Cheers, Simon

1 0

comment on: Make underscore 'caseless' (Ticket 72)
by Johannes Waldmann 03 Feb '06

03 Feb '06

http://hackage.haskell.org/trac/haskell-prime/wiki/Underscore I think it is basically the wrong idea to encode (type and) usage information in the name of an identifier. One should use the type system for that, or, failing that, annotations. Something like data Foo = Foo | @SuppressWarnings("unused") Bar See my proposal for unified and extendible annotations http://www.haskell.org//pipermail/haskell-prime/2006-February/000279.html http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html Of course compilers/IDEs are free to support whatever naming conventions they want but I think such conventions should not go into the language standard. Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

1 0

Unicode, was Comment Syntax
by Taral 02 Feb '06

02 Feb '06

On 2/2/06, John Meacham <john(a)repetae.net> wrote: > but it currently doesn't recognize any unicode characters as possible > operators. which it should, but I am just not sure how to specify that > yet until some sort of standard develops. Once there are more unicode > compliant compilers out there something will evolve probably. Character attributes are defined in unicode: http://www.unicode.org/Public/UNIDATA/ It's just a matter of mapping. Perhaps this is worth considering amending for Haskell'? The Haskell98 grammar talks about "symbol", "uppercase", "lowercase", while Unicode is a bit more... diverse. -- Taral <taralx(a)gmail.com> "Computer science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra

1 0