March 2006 - Haskell-prime

Concurrency (was: RE: Re[2]: important news: refocusing discussion)
by Simon Marlow 29 Mar '06

29 Mar '06

On 26 March 2006 02:31, isaac jones wrote: > Possible Interests: > 1. I can write tools like filesystems, web servers, and GUIs in > Haskell' > 2. Libraries that I use are thread-safe > 3. I can compile my code with any Haskell' compiler > 4. Tools such as debuggers and tracers that claim to support Haskell' > actually work on my code. > 5. That there not be "too many Haskell's" > 6. That there be a diversity of Haskell' implementations > 7. That concurrency be reasonable to implement for existing > compilers/interpreters. > 8. That it be reasonable to implement for new compilers/interpreters. > 9. Show off how effective Haskell can be in this area (possibly > attracting new users). > > By 5 I mean that it might be nice to have a "core" Haskell and a bunch > of addenda. But this could cause no two Haskell' implementations to > be the same. (My Haskell' might have concurrency and FFI, but no class > system, or something.) The more optional addenda we have, the more we > actually fracture the language. We could be in the same situation > we're in today. > > Isaac's Interests > * 1-6, 9 > > Simon's Interests: > * He's mentioned 9, I'm sure that there are others. I'd count all of 1-9 as interests - they're all desirable. But we haven't found a design that satisfies 1-9, and in the absence of that we have to compromise somewhere. But before we get carried away figuring out all the pros and cons of various options, let me point out once again that This is just a marketing decision Because (a) we're going to standardise concurrency anyway (b) it is unlikely that Hugs or JHC will implement concurrency even if it goes into the standard (c) the question is just whether the "brand" Haskell' encompasses concurrency or not (I thought I'd use that word because I know JL likes it so much :-) Yes there are several ramifications of this decision, but none of them are technical. As I see it, we either specify Concurrency as an addendum, or NoConcurrency as an addendum, and both options are about the same amount of work. So on that note, I'll restate my preference that Haskell' should include concurrency, and leave it at that. We can start the standardisation process without arriving at a conclusion on this issue anyway. Cheers, Simon

6 5

bringing discussions to a close
by isaac jones 29 Mar '06

29 Mar '06

Greetings, As mentioned in my email from Tuesday March 21 [1], I'd like to bring most threads to a close very soon, and to document your discussions on the wiki. The only topics that should remain open are concurrency and the class system. Instructions for modifying or creating proposals is here [2]. peace, isaac [1] http://www.haskell.org//pipermail/haskell-prime/2006-March/001008.html [2] http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/CreateProposal -- isaac jones <ijones(a)galois.com>

3 3

the following program can't be compiled with ghc 6.4.1
by Bulat Ziganshin 28 Mar '06

28 Mar '06

to be fair, it also don't work with Hugs 03 and Hugs 05 data UnboxedMutableArray i e = UMA !i !i type IOUArray i e = UnboxedMutableArray i e data Dynamic a i e = Dynamic (a i e) type DynamicIOUArray s = Dynamic IOUArray if second line substituted with the following type IOUArray = UnboxedMutableArray then all compilers are happy. i don't know, may be i should appeal to Haskell' committee instead of compiler developers (but you are the same persons, anyway :) btw, the kinds are trickiest language part, especially in Hugs what don't supports kind annotations. in one case compiler don't accept partial type (as here), in other case compiler don't accept "extraneous" parameters. as net result, making type definition that will work everywhere is a kind of shamanism -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

unicode/internalization issues
by Bulat Ziganshin 28 Mar '06

28 Mar '06

Hello haskell-prime, i've planned some time ago to open unicode/internalization wiki page, what reflects current state of the art in this area. here is the information i have, please add/correct me if i don't know something or wrong. 1. Char supports full Unicode range (about million of chars) instead of just 8-bit ASCII: implemented in GHC 6.0 and Hugs 2005 (i'm not sure about exact versions) 2. Character classification/convertion routines in Data.Char: all Unicode chars managed properly starting from GHC 6.4 and Hugs 2005. Author of this update, Dmitry Golubovsky, also provides it as additional lib for ghc 6.2.2, and i think it is possible to extend his work to work with any compiler supporting "wide" Chars. 3. Unicode support in I/O routines, i.e. ability to read/write UTF-8 encoded files and files what use other Unicode byte encodings: not implemented in any compiler, afaik, but there are 3rd-party libs: Streams library, New I/O library, and even CharIO module from jhc sources 4. Support for UTF-8 encoded source files: implemented in ghc 6.5 and jhc. afaik, ghc's support is more advanced because it uses abovementioned routines to classify Chars, so you can use any national characters in identifiers according to their case, and all other symbols in operators. because ghc 6.5 supports ONLY utf-8 encoded source files, these creates some problems when compiling files created for previous versions of ghc (or for other compilers) and using ASCII encoding with national (>chr 127) chars in comments and especially string literals. GHC team asked their users for best solution of this problem if i don't mentioned here any issues regarding unicode/internalization, please add this -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

RE: important news: refocusing discussion
by Simon Marlow 28 Mar '06

28 Mar '06

On 27 March 2006 18:51, Neil Mitchell wrote: > * Its simulated concurrency, if you have two processors, only one will > ever be used. The only exception is FFI, where a number of FFI calls > can run in parallel with some Haskell code. This means that no locking > is needed on the global heap. I don't consider this to be "simulated" concurrency. The fact that you don't get any actual parallelism on a multiprocessor is a performance issue, not a semantic one. In other words, your implementation is fine. Until very recently GHC had the same restriction, incedentally. Cheers, Simon

1 0

Liberal type synonyms
by Simon Marlow 28 Mar '06

28 Mar '06

I realised nobody had proposed this yet, so I just did: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/ticket/102 Cheers, Simon

1 0

Alternatives to . for composition
by Dylan Thurston 27 Mar '06

27 Mar '06

At http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot , there is a list of possible Unicode replacements for the '.' operator. Oddly, the canonical one is missing (from http://www.unicode.org/charts/PDF/U2200.pdf ): 2218 RING OPERATOR = composite function = APL jot 00B0 degree sign 25E6 white bullet I don't think any other Unicode character should be considered. (Is this the approved way to send minor updates like this?) Peace, Dylan Thurston

6 7

RE: important news: refocusing discussion
by Simon Marlow 27 Mar '06

27 Mar '06

On 21 March 2006 23:51, isaac jones wrote: > Concurrency is summarized here: > http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc y I have updated the concurrency page with a skeleton proposal. Cheers, Simon

5 5

Re: supertyping
by Jim Apple 26 Mar '06

26 Mar '06

Has this list yet discussed John's supertyping proposal? http://repetae.net/john/recent/out/supertyping.html Jim

1 0

the MPTC Dilemma (please solve)
by isaac jones 25 Mar '06

25 Mar '06

I've created a wiki page and a ticket to record solutions to what I'm calling the "Multi Parameter Type Class Dilemma". It's summarized thusly: MultiParamTypeClasses are very useful, but mostly in the context of FunctionalDependencies. They are particularly used in the monad transformer library found in fptools. The dilemma is that functional dependencies are "very, very tricky" (spj). AssociatedTypes are promising but unproven. Without a solution, Haskell' will be somewhat obsolete before it gets off the ground. I've proposed a few solutions. Please help to discover more solutions and/or put them on the ticket/wiki. Wiki page: http://hackage.haskell.org/trac/haskell-prime/ticket/90 Ticket: http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDil… peace, isaac -- isaac jones <ijones(a)galois.com>

13 42