Re[2]: important news: refocusing discussion
Hello Ross, Saturday, March 25, 2006, 4:16:01 AM, you wrote: > On Fri, Mar 24, 2006 at 02:47:09PM -, Simon Marlow wrote: >> I think it would be a mistake to relegate concurrency to an addendum; it >> is a central feature of the language, and in fact is one area where >> Haskell (strictly speaking GHC) is really beginning to demonstrate >> significant advantages over other languages. We should make the most of >> it. > Essential for many applications, certainly, but central? How can you > say that? it becomes central language feature just because it's much easier to write concurrent programs in Haskell than in other languages and because ghc's implementation of "user-level threads" is blazing fast, outperforming closest competitor in hundreds (!) times in the Language Shootout concurrency testing so, the concurrent programming, may be, the only area at now, where real-world, commercial programmers should prefer Haskell over all other languages. in this light, leaving the concurrency outside of language standard will decrease our chances of pushing the language to the commercial arena and gathering "critical mass" of Haskellers -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Alternatives to . for composition
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 signature.asc Description: Digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Alternatives to . for composition
> 2218 RING OPERATOR > = composite function > = APL jot > 00B0 degree sign > 25E6 white bullet > > I don't think any other Unicode character should be considered. That's great but 1) I have no idea how to type it. Can I easily and comfortably? In emacs? 2) Will it show up in PuTTY (and everyone else's terminals/IDEs)? in everyone's mail readers (including Gmail)? 3) What encoding do my textfiles need to be in (i.e. how many bytes per char)? How do I do that? Does Haskell even support everything related to Unicode that we'd need? If the answers are satisfactory to all these questions, then Unicode is a good idea (and that's the ideal character). If not, we're sadly stuck in ASCII land. Jared. P.S. Plus that opens a lot of cans of worms for writing programs with all those fancy symbols! APL here we come! -- http://www.updike.org/~jared/ reverse ")-:" ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Alternatives to . for composition
On 2006-03-25 at 09:41PST "Jared Updike" wrote: > > 2218 RING OPERATOR > > = composite function > > = APL jot > > 00B0 degree sign > > 25E6 white bullet > > > > I don't think any other Unicode character should be considered. > > That's great but > 1) I have no idea how to type it. Can I easily and comfortably? In emacs? For emacs, just bind a key (C-. say) to (ucs-insert #X2218). ucs-insert comes from ucs-tables. > 2) Will it show up in PuTTY (and everyone else's terminals/IDEs)? Eventually. > in everyone's mail readers (including Gmail)? Eventually, I should think. I'm using nmh, which has to be one of the least trendy MUAs about, and that can do it. What does this: â look like in your email reader? > 3) What encoding do my textfiles need to be in Probably utf-8 > (i.e. how many bytes per char)? a bit more than one on average. > How do I do that? Depends on the OS you are using. I've got locale set to en_GB.UTF-8 and it all more or less works. > Does Haskell even support everything related to Unicode > that we'd need? Not now, but Haskell' jolly well ought to. > If the answers are satisfactory to all these questions, > then Unicode is a good idea (and that's the ideal > character). "Satisfactory" is in the eye of the beholder. > If not, we're sadly stuck in ASCII land. It's far worse than that. We are stuck in an idiotic land where the meaning of a file depends on the meaning of a user settable variable in the OS. This is one of the many unpleasant consequences of untyped filesystems¹. Oh, and Haskell claims already to have unicode source files, but the compilers can't handle it. > Jared. > > P.S. Plus that opens a lot of cans of worms for writing programs with > all those fancy symbols! APL here we come! It's a question of good style, isn't it? Using â instead of -> might be nice, but stringing together lots of arcane symbols like ââ°Ⱐwouldn't be. For Haskell 98 I argued against unicode, preferring that we should stick with ASCII, but nowadays a language that doesn't handle unicode properly is going to look shabby in a few years. Jón [1] Something about which something should be done in Haskell... -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Alternatives to . for composition
Gah! I managed to send that without a content-type field (for bizarre reasons which I won't elaborate right now). Here it is again with what I hope is the right (utf-8) type, which ought to make it more legible in some email readers. On 2006-03-25 at 09:41PST "Jared Updike" wrote: > > 2218 RING OPERATOR > > = composite function > > = APL jot > > 00B0 degree sign > > 25E6 white bullet > > > > I don't think any other Unicode character should be considered. > > That's great but > 1) I have no idea how to type it. Can I easily and comfortably? In emacs? For emacs, just bind a key (C-. say) to (ucs-insert #X2218). ucs-insert comes from ucs-tables. > 2) Will it show up in PuTTY (and everyone else's terminals/IDEs)? Eventually. > in everyone's mail readers (including Gmail)? Eventually, I should think. I'm using nmh, which has to be one of the least trendy MUAs about, and that can do it. What does this: ∘ look like in your email reader? > 3) What encoding do my textfiles need to be in Probably utf-8 > (i.e. how many bytes per char)? a bit more than one on average. > How do I do that? Depends on the OS you are using. I've got locale set to en_GB.UTF-8 and it all more or less works. > Does Haskell even support everything related to Unicode > that we'd need? Not now, but Haskell' jolly well ought to. > If the answers are satisfactory to all these questions, > then Unicode is a good idea (and that's the ideal > character). "Satisfactory" is in the eye of the beholder. > If not, we're sadly stuck in ASCII land. It's far worse than that. We are stuck in an idiotic land where the meaning of a file depends on the meaning of a user settable variable in the OS. This is one of the many unpleasant consequences of untyped filesystems¹. Oh, and Haskell claims already to have unicode source files, but the compilers can't handle it. > Jared. > > P.S. Plus that opens a lot of cans of worms for writing programs with > all those fancy symbols! APL here we come! It's a question of good style, isn't it? Using → instead of -> might be nice, but stringing together lots of arcane symbols like ₀∘°⁰ wouldn't be. For Haskell 98 I argued against unicode, preferring that we should stick with ASCII, but nowadays a language that doesn't handle unicode properly is going to look shabby in a few years. Jón [1] Something about which something should be done in Haskell... -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Alternatives to . for composition
> For emacs, just bind a key (C-. say) to (ucs-insert > #X2218). ucs-insert comes from ucs-tables. Sounds easy enough. I'll test emacs and my terminal and see about it. > > 2) Will it show up in PuTTY (and everyone else's terminals/IDEs)? > > Eventually. > > > in everyone's mail readers (including Gmail)? > > Eventually, I should think. I'm using nmh, which has to be > one of the least trendy MUAs about, and that can do it. What > does this: ∘ look like in your email reader? Looks great in Gmail. > It's far worse than that. We are stuck in an idiotic land > where the meaning of a file depends on the meaning of a user > settable variable in the OS. This is one of the many > unpleasant consequences of untyped filesystems¹. That's a bad situation (i.e. idiotic). >> Does Haskell even support everything related to Unicode >> that we'd need? > Not now, but Haskell' jolly well ought to. > Oh, and Haskell claims already to have unicode source files, but the > compilers can't handle it. I agree this ought to be rectified, but since I'm not volunteering to do it, I personally can't ensure its adoption. But I'll be cheerleader for it! > If the answers are satisfactory to all these questions, > then Unicode is a good idea (and that's the ideal > character). Your answers seem very satisfactory to me. I guess it's a question of support / using Unicode in practice. >> P.S. Plus that opens a lot of cans of worms for writing programs with >> all those fancy symbols! APL here we come! > > It's a question of good style, isn't it? Using → instead of > -> might be nice This seems reasonable. Haskell already has a lot of carefully chosen graphical notation that actually aids in readability. As long as the old version of "→" i.e. "->" works, I don't see this as a problem. Although all the lexers for all tools and compilers would have to be updated. If it's a new backwards-incompatible standard (like Haskell 2), then this isn't a problem. For Haskell', since the compilers don't already support things well enough it sounds like, (i.e. Unicode everywhere with all its complexities, plus "->" + "→", etc.) then maybe this is beyond the scope of Haskell'. But I hope these sorts of important improvements occur sooner than later. (Once again I'm only cheerleading.) > but stringing together lots of arcane > symbols like ₀∘°⁰ wouldn't be. And that's where APL breaks down. I don't see Unicode allowing for any more abuse than the current DIY infix operator already does. > For Haskell 98 I argued > against unicode, preferring that we should stick with ASCII, > but nowadays a language that doesn't handle unicode properly > is going to look shabby in a few years. True. Thanks for the enlightenment. Jared. -- http://www.updike.org/~jared/ reverse ")-:" ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the MPTC Dilemma (please solve)
On 2006-03-21, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: > Aaron Denney: >> On 2006-03-20, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: >> > IMHO if we consider deprecating a feature in Haskell'' again, >> > we should not include it in Haskell', but leave it as an optional extra >> > that some systems may experimentally implement and some may not. >> >> Possibly true, but it still needs to be standardized so that it will >> work the same on different implementations. > > It might be standardised as an add on to the language standard, instead > of as part of the language standard. Fair enough, but the time frame for it to be useful implies standardizing it now, rather than after the rest is standardized. -- Aaron Denney -><- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: important news: refocusing discussion
On Sat, 2006-03-25 at 13:17 +0300, Bulat Ziganshin wrote: > Hello Ross, > > Saturday, March 25, 2006, 4:16:01 AM, you wrote: > > > On Fri, Mar 24, 2006 at 02:47:09PM -, Simon Marlow wrote: > >> I think it would be a mistake to relegate concurrency to an addendum; it > >> is a central feature of the language, and in fact is one area where > >> Haskell (strictly speaking GHC) is really beginning to demonstrate > >> significant advantages over other languages. We should make the most of > >> it. > > > Essential for many applications, certainly, but central? How can you > > say that? > > it becomes central language feature just because it's much easier to > write concurrent programs in Haskell than in other languages and > because ghc's implementation of "user-level threads" is blazing fast, > outperforming closest competitor in hundreds (!) times in the Language > Shootout concurrency testing I don't think "central to the language" is a particularly helpful concept here. Let's try to frame debates like this in terms of "interests", not "positions". That is, an interest is "we should be able to write thread-safe libraries" and a position is "Haskell' should have concurrency". Once we understand each-others' interests, we can look to find solutions that satisfy a compelling set of interests. I'll try to frame some interests that various folks seem to have expressed, and I admit that I may miss some and be wrong, so please add to or correct the list below (maybe it should go on the wiki): 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. Ross and John Meacham I think have both expressed worry about 7 and 8. I have no idea if it would work, but one solution that Simon didn't mention in his enumeration (below) is that we could find a group of people willing to work hard to implement concurrency in Hugs, for example, under Ross's direction. That might satisfy interest number 7. Please help me to build this understanding of various folks' interests, an solutions to satisfy them. peace, isaac Simon Marlow Wrote: > It boils down to a choice between: > > (1) Haskell' does not include concurrency. Concurrent programs > are not Haskell'. > > (2) Haskell' includes concurrency. Concurrent programs are > Haskell', but there are some compilers that do not implement > all of Haskell'. > > (3) There are two variants of Haskell', Haskell' and > Haskell'+Concurrency. Compilers and programs choose which > variant of the language they implement/are implemented in. > > (4) The same as (3), but the two variants are Haskell' and > Haskell'-Concurrency (where -Concurrency is a negative > addendum, an addendum that subtracts from the standard). -- isaac jones <[EMAIL PROTECTED]> ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: important news: refocusing discussion
On Sat, Mar 25, 2006 at 05:31:04PM -0800, isaac jones wrote: > I have no idea if it would work, but one solution that Simon didn't > mention in his enumeration (below) is that we could find a group of > people willing to work hard to implement concurrency in Hugs, for > example, under Ross's direction. I'm no expert on Hugs internals, and certainly not qualified to direct such an effort, but I don't have great hopes for it. Apart from the fact that Hugs is written in a legacy language and uses a quite a bit of global state, it also makes heavy use of the C stack, and any implementation that does that will have trouble, I think. I think it's clear that the proposed concurrency model is feasible for some implementations but not for others. I've been assuming that Haskell' was intended to encompass a wide range of implementations. If that's the case, the key point is that a Haskell' module that does not use concurrency, but is thread-safe, ought to work with non-concurrent implementations too. To make that work, we'd need two interfaces: * one for applications that make use of concurrency. This would be unavailable on some implementations. * one for thread-safe use of state. This would be available on all implementations, and authors not requiring concurrency would be encouraged to use it for maximum portability. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
