Re: module system/namespaces: separate with/use, allow local use
On Mon, Jan 30, 2006 at 10:13:36AM +0100, Johannes Waldmann wrote: I am not sure what a local fixity declaration would mean for an operator that is defined in some outer scope. It would mean a whole new class of obfusciation ability for haskell programmers :) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Wanted: local data, class, instance declarations
Hello Johannes, Friday, January 27, 2006, 1:00:42 PM, you wrote: JW let instance Ord Item where ... JW xs :: [ Item ] ; xs = ... JW in sort xs are you familiar with generic haskell? one of its features is the local definitions of the special cases for generic functions, what is close to what you propose -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: The dreaded M-R
[EMAIL PROTECTED] writes: Nhc didn't use to implement the M-R (maybe it does now). When porting code to nhc this caused a few code changes. Perhaps 10 lines out of 1 when I tried the Bluespec compiler. So my gut feeling is that the M-R is a rare beast in practise. I can confirm that nhc98 (and hence yhc) still does not implement the M-R. I haven't noticed any particular performance problems in code compiled by nhc98 that were down to a consequent loss of sharing. (But I can't claim to have explicitly looked.) But as Lennart says, you do get occasional type errors which mean you need to restructure your code. Almost always, these are local bindings, e.g.: Context required in LHS pattern is an error emitted for code like: do (x,y) - something complicated and numeric ... and the fix is do xy - something complicated and numeric let x = fst xy y = snd xy ... As I recall, there were about 4-5 of these I needed to fix in the entire nofib suite. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
On 30 Jan 2006, at 14:49, [EMAIL PROTECTED] wrote: Quoting Thomas Davie [EMAIL PROTECTED]: On 30 Jan 2006, at 14:28, Neil Mitchell wrote: Another argument in favour of this is that most editors with syntax hilighting will show -- as a comment, which again increases the confusion factor. I would rather argue that since we have editors with syntax highlighting, this isn't a big problem. The editor will tell you (if the highlighting is implemented correctly) that -- does not start a comment. Rather than changing the language we should fix the highlighting modes for the editors in question. This is rather hard, unless your editor is actually a thinly disguised programming language. Certainly for my editor of choice (TextPad) this cannot be done easily - and isn't needed for most other languages. Ditto the SubEthaEdit syntax highlighting mode - I guess most people have got used to editors being thinly disguised operating systems these days (not looking at emacs or vim here). Are you telling me that your text editor doesn't even give you a regexp for defining comments? If it doesn't, I'd say your editor needs to upgrade to some good 1960s text editor technology. It gives you regexp and nothing more - this makes it a pain in the arse to input every possible character that is/isn't allowed. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: The dreaded M-R
On 1/30/06, Simon Marlow [EMAIL PROTECTED] wrote: 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. Given that the discussion has focused a lot on how beginners would feel about this, I'll chime in with my two cents. I may not be a beginner in the strictest sense of the word, but I'm probably a lot closer to it than the rest of the participants in this discussion :-) I'm against it. People will want to *understand* the difference between := and =, and I don't think beginners will really grok something like that without significant difficulties. And it does add a significant extra clutter to the language, IMO. That symbols feels heavy, somehow, even if it's meaning is subtle (at least from a beginners POV). Also, since it's only a problem very rarely, it could be noted in an optimization faq somewhere. Plus, don't we already tell people to add type signatures when something is too slow? Isn't that the first thing you would try when something is surprisingly slow? /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Existential types: want better syntactic support (autoboxing?)
Seems like a convenient feature to me. Also, you may want to have a function which works on a list of any values which are both readable and showable. Say (mockup syntax): foo :: Show a, Read a = [a] foo = [ 1, True, myRocketLauncher ] Which would create a newtype called ShowReadAble or something with extistential types and also instantiate that type in both Show and Read. I do agree that this is something I'd like in a lot of cases, and it probably would be used quite a bit more if it were convenient (and standardised!). I leave it to someone else to figure out how to make this play nice with e.g. type inference. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: module system/namespaces: separate with/use, allow local use
Simon Marlow [EMAIL PROTECTED] writes: On 30 January 2006 09:03, Simon Peyton-Jones wrote: With the module system, we should make a distinction between declaring (1) that we want to use a module (2) how to bring the module's names into scope Perhaps 'import' should be allowed anywhere among definitions. Indeed. Requiring the import clauses to be at the top, and the fixity declarations, makes them easy to find -- but we don't require that for type signatures or class declarations etc. It'd be more consistent to allow imports and fixity declarations anywhere. This'd be a backward compatible change, but it's an utterly un-forced one. It's not something that people complain about much. I vaguely remember suggesting this for Haskell 98 or Haskell 1.4 (can't remember which) but nobody saw the need for it back then. (snip pros cons summary) Can one of you add a ticket / wiki page with this summary? I'd like to track things like this in case they come up again. Johannes, if you have any more specific proposals you'd like to make, please do so on the mailing list, then add a ticket once some consensus emerges. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
Quoting Thomas Davie [EMAIL PROTECTED]: I agree, this is not a great argument, but the fact that the language is inconsistent, and that it confuses people easily, and can't come up with great error messages when it does go wrong, (my original arguments) really are good arguments for fixing this. Yes, I buy those arguments. But it's also rather convenient to be able to use -- in operators. -- Lennart ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: what's the goal of haskell-prime?
No language can serve all of the people all of the time, but I think we should just do our best with a single standard. I think that the complexity of multiple languages / layers / standards would not be worth the payoff. My original understanding of the Haskell' effort was that it was *not* intended as going for Haskell 2, but rather as an update of Haskell 98. In other words, the target is Haskell 2005: - anything that was tried and tested by the end of 2005 is a potential candidate for inclusion in Haskell 2005. nothing else is. this would necessarily exclude much of the discussion here, for which I'd see only three ways out: - make an exception to rule one (bad, but occasionally needed) - ignore and leave for Haskell 2, whenever that might be (impractical) - standardise as an optional addendum to Haskell 2005, to lay the groundwork for Haskell 2010, and to narrow down on the more successful experiments (good, avoid adhoc Haskell 2 in favour of incremental approximations) and the third way seems the most likely to succeed. There'll always be Haskell xx+extensions (unless people stop experimenting) and some extensions are good enough to be standardised (perhaps with options), even if not yet good enough to be part of the current standard. Has the target changed, or was I misled to think of it this way?-) btw, I'd find it hard to track discussion on a wiki/ticket system alone. Could a member of the committee arrange for a Haskell'-weekly message, please (similar to Haskell weekly, but collecting news headers and links from haskell', wiki, track, and internal committee discussions)? cheers, claus ps. will haskell 98 support continue when the new standard comes out, or will there always be 2 languages (standard and standard+)? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
