RE: Proposal: Scoping rule change
Hi Iavor, In your example using import qualified would also resolve the clash, although if you were importing two symbols from Text.PrettyPrint you might like to be able to use the other one unqualified. In my experience using the current module name for qualification is pretty rare already, but perhaps it's just a question of different styles. Cheers, Ganesh -Original Message- From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-boun...@haskell.org] On Behalf Of Iavor Diatchki Sent: 25 July 2012 18:46 To: Lennart Augustsson Cc: Haskell Prime Subject: Re: Proposal: Scoping rule change Hello, I also think that this is a good idea. To address Manuel's nitpick, here is an example that would break if `I` starts exporting `foo`. module M(foo) where import I foo = True To Ganesh's point: I think that this change would be useful, even if one is willing to list all names in all imports explicitly, because it makes it possible to leave off qualifiers on names defined in the current module, which reduces clutter. Here is an example that I run into quite often: module Data.MyList (empty) where import Text.PrettyPrint as P (empty) empty = [] singleton x = x : Data.MyList.empty -- vs. singleton x = x : empty -- using new scoping rule ppList = ... P.empty ... -- We only need to qualify imported things Note that with the new scoping rule we wouldn't need to ever use the current module as a qualifier, which is kind of nice, especially since we have no way to give it a shorter name (like we can for imports). -Iavor On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson lenn...@augustsson.net wrote: It's not often that one gets the chance to change something as fundamental as the scoping rules of a language. Nevertheless, I would like to propose a change to Haskell's scoping rules. The change is quite simple. As it is, top level entities in a module are in the same scope as all imported entities. I suggest that this is changed to that the entities from the module are in an inner scope and do not clash with imported identifiers. Why? Consider the following snippet module M where import I foo = True Assume this compiles. Now change the module I so it exports something called foo. After this change the module M no longer compiles since (under the current scoping rules) the imported foo clashes with the foo in M. Pros: Module compilation becomes more robust under library changes. Fewer imports with hiding are necessary. Cons: There's the chance that you happen to define a module identifier with the same name as something imported. This will typically lead to a type error, but there is a remote chance it could have the same type. Implementation status: The Mu compiler has used the scoping rule for several years now and it works very well in practice. -- Lennart ___ 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 === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Proposal: Scoping rule change
The ... foo ... in my example was intended to show that module M does look up 'foo'. From: Manuel M T Chakravarty [mailto:c...@cse.unsw.edu.au] Sent: 25 July 2012 08:26 To: Sittampalam, Ganesh Cc: Lennart Augustsson; Haskell Prime Subject: Re: Proposal: Scoping rule change If Lennart's suggestion is combined with GHC's lazy checking for name clashes (i.e., only check if you ever look a name up in a particular scope), it would also work in your example. Manuel Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com: If you're using unqualified and unrestricted imports, there's still the risk that another module will export something you care about, e.g. module M where import I -- currently exports foo import J -- might be changed in future to export foo ... foo ... So I think you need to use import lists or qualified anyway to avoid any risk of future name clashes - given that, does this change buy much? From: haskell-prime-boun...@haskell.org mailto:haskell-prime-boun...@haskell.org [mailto:haskell-prime-boun...@haskell.org mailto:prime-boun...@haskell.org ] On Behalf Of Lennart Augustsson Sent: 24 July 2012 02:29 To: Haskell Prime Subject: Proposal: Scoping rule change It's not often that one gets the chance to change something as fundamental as the scoping rules of a language. Nevertheless, I would like to propose a change to Haskell's scoping rules. The change is quite simple. As it is, top level entities in a module are in the same scope as all imported entities. I suggest that this is changed to that the entities from the module are in an inner scope and do not clash with imported identifiers. Why? Consider the following snippet module M where import I foo = True Assume this compiles. Now change the module I so it exports something called foo. After this change the module M no longer compiles since (under the current scoping rules) the imported foo clashes with the foo in M. Pros: Module compilation becomes more robust under library changes. Fewer imports with hiding are necessary. Cons: There's the chance that you happen to define a module identifier with the same name as something imported. This will typically lead to a type error, but there is a remote chance it could have the same type. Implementation status: The Mu compiler has used the scoping rule for several years now and it works very well in practice. -- Lennart == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org mailto:Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime http://www.haskell.org/mailman/listinfo/haskell-prime === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Proposal: Scoping rule change
My point is that if you would rather not get that error when J changes, you need to use explicit import lists: Module M import I (foo) import J () definitioninModuleM = foo Lennart's proposed change makes explicit import lists unnecessary for the case where foo is defined inside M rather than being imported from I - but as it doesn't avoid the need for them in general I'm not sure that it is worth it. Ganesh From: Manuel M T Chakravarty [mailto:c...@cse.unsw.edu.au] Sent: 25 July 2012 10:25 To: Sittampalam, Ganesh Cc: Lennart Augustsson; Haskell Prime Subject: Re: Proposal: Scoping rule change Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com: The ... foo ... in my example was intended to show that module M does look up 'foo'. I did read that as foo is both defined and used in the body. In that case, everything should work just fine. If you use, but do not define foo, then you definitely want to get an error if J exports foo in the future. So, I think, that is fine. Manuel From: Manuel M T Chakravarty [mailto:c...@cse.unsw.edu.au http://cse.unsw.edu.au ] Sent: 25 July 2012 08:26 To: Sittampalam, Ganesh Cc: Lennart Augustsson; Haskell Prime Subject: Re: Proposal: Scoping rule change If Lennart's suggestion is combined with GHC's lazy checking for name clashes (i.e., only check if you ever look a name up in a particular scope), it would also work in your example. Manuel Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com mailto:ganesh.sittampa...@credit-suisse.com : If you're using unqualified and unrestricted imports, there's still the risk that another module will export something you care about, e.g. module M where import I -- currently exports foo import J -- might be changed in future to export foo ... foo ... So I think you need to use import lists or qualified anyway to avoid any risk of future name clashes - given that, does this change buy much? From: haskell-prime-boun...@haskell.org mailto:haskell-prime-boun...@haskell.org [mailto:haskell-prime-boun...@haskell.org mailto:prime-boun...@haskell.org ] On Behalf Of Lennart Augustsson Sent: 24 July 2012 02:29 To: Haskell Prime Subject: Proposal: Scoping rule change It's not often that one gets the chance to change something as fundamental as the scoping rules of a language. Nevertheless, I would like to propose a change to Haskell's scoping rules. The change is quite simple. As it is, top level entities in a module are in the same scope as all imported entities. I suggest that this is changed to that the entities from the module are in an inner scope and do not clash with imported identifiers. Why? Consider the following snippet module M where import I foo = True Assume this compiles. Now change the module I so it exports something called foo. After this change the module M no longer compiles since (under the current scoping rules) the imported foo clashes with the foo in M. Pros: Module compilation becomes more robust under library changes. Fewer imports with hiding are necessary. Cons: There's the chance that you happen to define a module identifier with the same name as something imported. This will typically lead to a type error, but there is a remote chance it could have the same type. Implementation status: The Mu compiler has used the scoping rule for several years now and it works very well in practice. -- Lennart == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org
RE: Proposal: Scoping rule change
If you're using unqualified and unrestricted imports, there's still the risk that another module will export something you care about, e.g. module M where import I -- currently exports foo import J -- might be changed in future to export foo ... foo ... So I think you need to use import lists or qualified anyway to avoid any risk of future name clashes - given that, does this change buy much? From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-boun...@haskell.org] On Behalf Of Lennart Augustsson Sent: 24 July 2012 02:29 To: Haskell Prime Subject: Proposal: Scoping rule change It's not often that one gets the chance to change something as fundamental as the scoping rules of a language. Nevertheless, I would like to propose a change to Haskell's scoping rules. The change is quite simple. As it is, top level entities in a module are in the same scope as all imported entities. I suggest that this is changed to that the entities from the module are in an inner scope and do not clash with imported identifiers. Why? Consider the following snippet module M where import I foo = True Assume this compiles. Now change the module I so it exports something called foo. After this change the module M no longer compiles since (under the current scoping rules) the imported foo clashes with the foo in M. Pros: Module compilation becomes more robust under library changes. Fewer imports with hiding are necessary. Cons: There's the chance that you happen to define a module identifier with the same name as something imported. This will typically lead to a type error, but there is a remote chance it could have the same type. Implementation status: The Mu compiler has used the scoping rule for several years now and it works very well in practice. -- Lennart === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Fixing floating point conversions.
Nick Bowler wrote: *** Idea #3 *** Use a multi-parameter type class: We couldn't go down this route until MPTCs themselves are added to the language, which I think is unlikely to be soon as the whole fundeps/type families issue is still unresolved. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Negation
Lennart Augustsson wrote: Of course unary minus should bind tighter than any infix operator. I remember suggesting this when the language was designed, but the Haskell committee was very set against it (mostly Joe Fasel I think). Are there archives of this discussion anywhere? Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: StricterLabelledFieldSyntax
Ian Lynagh wrote:
Hi all,
I've made a ticket and proposal page for making the labelled field
syntax stricter, e.g. making this illegal:
data A = A {x :: Int}
y :: Maybe A
y = Just A {x = 5}
+1: The precedence here is an ugly wart. It's particularly annoying when
teaching Haskell syntax to newbies; the simple rule juxtaposition binds
tighter than everything else doesn't quite work.
Ganesh
===
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Proposal: Deprecate ExistentialQuantification
One can use the following style of GADT definition, which avoids the
type variables in the declaration:
{-# LANGUAGE GADTs, KindSignatures #-}
module GADT where
data Foo :: * - * where
Foo :: Int - Foo Int
Iavor Diatchki wrote:
Hello,
Sorry for responding so late---I just saw the thread. I don't think
that we should deprecate the usual way to define existentials. While
the GADT syntax is nice in some cases, there are also examples when
it is quite verbose. For example, there is a lot of repetition in
datatypes that have many constructors, especially if the datatype has
parameters and a slightly longer name. Furthermore, I find the type
variables in the declaration of the type quite confusing because they
have no relation to the type variables in the constructors. Finally,
there is quite a lot of literature about the semantics of existential
types, while the semantics of GADTs seems quite complex, so it seems
a bit risky to mix up the two.
-Iavor
On Thu, Jul 23, 2009 at 2:47 PM, Niklas
Brobergniklas.brob...@gmail.com wrote:
Discussion period: 2 weeks
Returning to this discussion, I'm surprised that so few people have
actually commented yea or nay. Seems to me though that...
* Some people are clearly in favor of a move in this direction, as
seen both by their replies here and discussion over other channels.
* Others are wary of deprecating anything of this magnitude for
practical reasons.
* No one has commented in true support of the classic existential
syntax, only wanting to keep it for legacy reasons.
I'm in no particular hurry to see this deprecation implemented, and I
certainly understand the practical concerns, but I would still very
much like us to make a statement that this is the direction we intend
to go in the longer run. I'm not sure what the best procedure for
doing so would be, but some sort of soft deprecation seems
reasonable to me.
Further thoughts?
Cheers,
/Niklas
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
===
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Re[4]: Haskell 2010: libraries
Bulat Ziganshin wrote: Hello Ganesh, Tuesday, July 14, 2009, 11:59:00 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things The PvP isn't (proposed as) part of the standard, and without package qualified imports as implemented by GHC, it wouldn't help anyway. but package versioning implemented by ghc, hugs and probably other compilers. Do you mean the syntax that allows modules to be imported from a specified package? If so I didn't realise this was implemented by anything more than GHC. with your idea we will have two things that address the same problem, Arguably it is the ability to import from a specified package that duplicates the disambiguation mechanism provided by module names. and these will be miltiplied - i.e. we will carry several versions of base package, each having Haskell2010.*, Haskell2011.* and so on modules I'd expect the Haskell2010.* etc to be implemented in a haskell2010 package which depends on the relevant version of base. Obviously it would need to be updated when base was changed incompatibly. Having a library standard implies that implementations must support it for some period of time. I don't see why namespacing the libraries of that standard makes that any harder. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Specific denotations for pure types
Are you proposing to ban all implementation-dependent behaviour everywhere in Haskell? (Or perhaps relegate it all to IO?) From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 21 March 2009 00:56 To: Achim Schneider Cc: haskell-prime@haskell.org Subject: Re: Specific denotations for pure types yes, but dodgy isn't Bool, it's _a_ Bool. Right. dodgy is _a_ Bool, and therefore its meaning is an element of the meaning of Bool. If _any_ element of Bool (e.g. dodgy) has a machine-dependent meaning, then the meaning of Bool itself much have a complex enough structure to contain such an element. - Conal On Fri, Mar 20, 2009 at 5:13 PM, Achim Schneider bars...@web.de wrote: Conal Elliott co...@conal.net wrote: Consider big :: Int big = 2147483647 dodgy :: Bool dodgy = big + 1 big oops :: () oops = if dodgy then () else undefined Assuming compositional semantics, the meaning of oops depends on the meaning of dodgy, which depends on the meaning of big+1, which is implementation-dependent. yes, but dodgy isn't Bool, it's _a_ Bool. You're worried about the semantics of () :: Int - Int - Bool, (+) :: Int - Int - Int and that forall n 0 . x + n x doesn't hold for Int. There are infinitely many ways to get a Bool out of things that don't happen to be Int (not to mention infinitely many ways to get a Bool out of an Int in an architecture-independent manner), which makes me think it's quite err... fundamentalistic to generalise that forall Bool . MachineInfo - Bool. In fact, if you can prove for a certain Bool that MachineInfo - ThatBool, you (most likely) just found a bug in the program. Shortly put: All that dodginess is fine with me, as long as it isn't the only way. Defaulting to machine-independent semantics at the expense of performance would be a most sensible thing, and Conal seems to think _way_ too abstractly. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: PROPOSAL: Make Applicative a superclass of Monad
Haskell' is about fixing existing practice, if it did go in, you would need some mechanism (i.e. class aliases) to ensure that it didn't break code. ... which is why we need class aliases!! I want to see this change, *and* I want to see class aliases. :-) I want class aliases, and I want to see this change but *only if* we get class aliases. Functor =/= Monad is annoying enough, we shouldn't make it worse without fixing the underlying limitation first. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): add Make $ left associative, like application
Manuel Chakravarty wrote: Care for legacy code is important, but H' will have to break backwards compatibility in some places. And especially where you already rely on GHC extensions, you can't really expect that H' will adopt features that have been available as GHC extensions in exactly the form that they were implemented in GHC. Agreed. I was just motivating why we would want to upgrade code, not arguing that we should be able to do that with no pain at all. We should be careful about where we break existing code, and we should try to support automatic translation of H98 to H' code, but any changes that we do not make now will become even more difficult in the future when there is even more Haskell code. Look at what is happening now already, industrial users applying pressure on the committee to not change the language too much for the sake of legacy code. A clear indication that anything we don't change now, we will have to live with forever. I wasn't arguing for special treatment as an industrial user, just listing one datapoint that I have to counter any impression that the only or main cost to the community as a whole is fixing what's on hackage. Hence, anything that is *important* to change, we should change now. Agreed. It's just in this case the pain of changing will be huge and the benefits marginal at best. We should mitigate the pain by having a H98 to H' translator Such a translator would have to maintain existing layout etc, and produce reasonably nice looking code in places where it makes changes. Do we have any infrastructure that would make writing one easy? Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): add Make $ left associative, like application
but it also seems not to make much sense to standardise a Prelude which people strongly want to change. I'm strongly against this change, both on its own merits - in most cases when there is a real argument being passed, I find chains of $s easier to think about than your alternative - but most importantly because it would be enormously disruptive. It's the kind of completely unnecessary thing that simply lends ammunition to the people that claim Haskell is an academic language unsuited to the real world. Also, the Haskell 98 Prelude has already been reported on, and probably should continue to be supported in some way or another. How would you propose supporting multiple preludes at once? I have a feeling most of the pieces are in place and it's just a question of documenting the best practice properly, but it needs to be done and we need to get experience with doing it and with a gradual migration strategy before we even consider this kind of change. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): add Make $ left associative, like application
I believe that migrating code will be quite a task regardless of the outcome here, NonDecreasing indentation and the removal of n+k patterns are the only accepted proposals I can see that might affect existing code. The former is already standard practice and the latter is unlikely to be that disruptive, as their use has been discouraged for some time. but at least for the packages that are in Hackage, the system helpfully reports build failures, so we'll know where the breakages are, and roughly what's left to be done. There's plenty of code out there that doesn't have the benefit of a vigilant user community ready to spring into action. For example, Credit Suisse has several tens of thousands of lines of code written by internal users who are not Haskell experts, and it would be rather hard to explain to them that they needed to go through it all and fix it. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): add Make $ left associative, like application
Aaron Denney wrote: On 2008-04-23, Sittampalam, Ganesh [EMAIL PROTECTED] wrote: There's plenty of code out there that doesn't have the benefit of a vigilant user community ready to spring into action. For example, Credit Suisse has several tens of thousands of lines of code written by internal users who are not Haskell experts, and it would be rather hard to explain to them that they needed to go through it all and fix it. What makes them need to update to Haskell' instead of sticking with Haskell '98? (a) the fact that the code already uses several GHC extensions that will be in Haskell' and we would like to be closer to standard code (b) the expectation that at some point implementations will stop supporting H98 Is there not a general expectation when a new language standard comes out that people will migrate to it (perhaps over time)? Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): BangPatterns: probably accept == undecided
Incedentally I think we should use a different operator for array indexing, because ! is almost universally used to mean strict now: in bang patterns, strict datatype fields, and $!. See http://hackage.haskell.org/trac/haskell-prime/wiki/ArrayIndexing A lot of the discussion on that page pre-supposes that CompositionAsDot will be accepted. Does it really stand a chance? It would be enormously disruptive and uglify the language massively. Making it necessary to use non-ASCII characters would be a big practical problem, I think. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): BangPatterns: probably accept == undecided
Simon Peyton Jones wrote: Not allowing infix functions on the LHS would be a notable simplification. This would significantly weaken a useful property of Haskell, that definitions and uses often share the same concrete syntax. It's very natural to be able to define things that way and it would be a real shame to lose it (and I think it would break a lot of existing code). In any case, I've always thought this was weird: Just x == Just y = x == y It takes a little getting used to, but I don't find it that weird. I wouldn't mind if just infix definitions of (!) were banned, though of course that would be an unpleasant non-orthogonality. Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: List syntax (was: Re: help from the community?)
On 2/2/07, Kirsten Chevalier [EMAIL PROTECTED] wrote: On the other hand, with constant lists and tuples, you're probably not going to frequently edit the same constant list value. Am I missing something? Sometimes people maintain static configuration items and the like in lists. I've certainly found myself wishing for the trailing ',' to be allowed on some occasions, though it's not a big enough deal for me to argue for it strongly if there is significant opposition. I think record syntax is the other significant place where it'd be useful (more so than tuples, given that adding an item to a tuple generally involves a type change that has an impact in many other places, whereas adding a record item is often just a question of adding it to the type and to a few other locations.) Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
