Douglas Philips wrote:
On 2007 Feb 2, at 11:25 PM, Brian Hulley indited:
Apart from the extra possibility for errors (yes I understood that
you'd define it to not be an error but this doesn't change the fact
that for people who always wrote their tuples using the normal
mathematical convention n
On 2007 Feb 2, at 11:25 PM, Brian Hulley indited:
Apart from the extra possibility for errors (yes I understood that
you'd define it to not be an error but this doesn't change the fact
that for people who always wrote their tuples using the normal
mathematical convention not using an optiona
Douglas Philips wrote:
On 2007 Feb 2, at 1:03 PM, Neil Mitchell indited:
Personally I'd make the rule that trailing commas are never allowed,
anywhere, but I do see an argument for adding them to import lists.
You just highlighted the inconsistency:
You refer to "import lists"... you appear to
On 2/2/07, Douglas Philips <[EMAIL PROTECTED]> wrote:
On 2007 Feb 2, at 1:03 PM, Neil Mitchell indited:
> An import list is not a value, you can't examine whats in the list,
> you can't enumerate it etc. As such, it doesn't really matter how many
> elements are in there, the important thing is wh
On 2007 Feb 2, at 1:03 PM, Neil Mitchell indited:
The argument that a trailing comma "means" "the programmer forgot the
last item" in a list / tuple is
inconsistent with the deliberately explicit permissiveness of a
trailing comma in the import / export lists.
In the import / export lists such a
Hi
The argument that a trailing comma "means" "the programmer forgot the
last item" in a list / tuple is
inconsistent with the deliberately explicit permissiveness of a
trailing comma in the import / export lists.
In the import / export lists such a trailing comma does not mean
"programmer forgo
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 cer
On 2/2/07, Douglas Philips <[EMAIL PROTECTED]> wrote:
Hmmm...stated another way:
I am proposing that the list and tuple syntax change to be consistent
with the import and export syntax.
The argument that a trailing comma "means" "the programmer forgot the
last item" in a list / tuple is
inconsist
On 2007 Feb 2, at 12:13 PM, Kirsten Chevalier inquired:
On 2/2/07, Douglas Philips <[EMAIL PROTECTED]> wrote:
I assert that the trailing comma is a feature, not a programmer
forgetting "the last element", and that this
is already explicitly allowed, as per the syntax fragments already
quoted, r
On 2/2/07, Douglas Philips <[EMAIL PROTECTED]> wrote:
I assert that the trailing comma is a feature, not a programmer
forgetting "the last element", and that this
is already explicitly allowed, as per the syntax fragments already
quoted, repeated here for convenience:
-- from: http://www.haskell
On 2007 Feb 2, at 11:32 AM, Brian Hulley wrote:
Douglas Philips wrote:
What would be the proper way to propose that:
( exp1 , ... , expk ) (tuple, k>=2)
[ exp1 , ... , expk ] (list, k>=1)
be amended to:
( exp1 , ... , expk [ , ] ) (tuple, k>=2)
[ exp1 , ... , expk [ , ] ] (list, k>=1)
I th
On 2 Feb, 2007, at 16:55 , Malcolm Wallace wrote:
Douglas Philips <[EMAIL PROTECTED]> wrote:
What would be the proper way to propose that:
| ( exp1 , ... , expk ) (tuple, k>=2)
| [ exp1 , ... , expk ] (list, k>=1)
be amended to:
| ( exp1 , ... , expk [
Douglas Philips wrote:
What would be the proper way to propose that:
( exp1 , ... , expk ) (tuple, k>=2)
[ exp1 , ... , expk ] (list, k>=1)
be amended to:
( exp1 , ... , expk [ , ] ) (tuple, k>=2)
[ exp1 , ... , expk [ , ] ] (list, k>=1)
I think a problem with the above proposal is that by a
Douglas Philips <[EMAIL PROTECTED]> wrote:
> What would be the proper way to propose that:
> | ( exp1 , ... , expk ) (tuple, k>=2)
> | [ exp1 , ... , expk ] (list, k>=1)
> be amended to:
> | ( exp1 , ... , expk [ , ] ) (tuple, k>=2)
> | [ exp1 , ..
On 2007 Feb 2, at 5:46 AM, Malcolm Wallace indited:
Since yours is the first actual flame I can remember ever being posted
to any Haskell list, I think this counts as the beginning of the
end of
civilisation as we know it. :-) At least, the beginning of the
end of
civilised discussion. And
| judgements (rather than boxes), no impredicativity, etc? As I recall the
| treatment of application expressions there (infer type of the function,
| then check the argument) was considered a bit restrictive. (It forbids
| runST $ foo, for example.)
That requires impredicativity, and that's the
Douglas Philips <[EMAIL PROTECTED]> wrote:
>.to fark around with that stoopid ass ...
> Pisses off users
> ... domineering compiler writer can feel smug 'bout 'mself.
> Feh. Feh^2.
Hey, man, take a chill
On Fri, Feb 02, 2007 at 08:35:01AM +, Simon Peyton-Jones wrote:
> * Rank-N is really no harder to implement than rank-2. The "Practical
> type inference.." paper gives every line of code required. The design
> is certainly much cleaner and less ad-hoc than GHC's old rank-2 design,
> which I d
John Meacham wrote:
luckily, pretty much all of this was worked out in a discussion a while
ago, the trick was to create a new type 'ACIO' which contained only
'good' top level operations. There will be an 'unsafeIOToACIO' of
course
Hmm. There was a long thread about this in Nov. 2004
on haskel
Iavor
Does your proposal cover only higher-rank types for *data constructors*? I
don't think there is any problem with extending it to arbitrary functions, as
our paper "Practical type inference for higher rank types" shows. But the web
page http://hackage.haskell.org/trac/haskell-prime/ticke
Thank you for the summery Iavor
On the rank-2 vs rank-N issue, I can say this:
* Rank-N is really no harder to implement than rank-2. The "Practical type
inference.." paper gives every line of code required". The design is certainly
much cleaner and less ad-hoc than GHC's old rank-2 design, w
21 matches
Mail list logo
