G'day all. Quoting Conal Elliott :

That eta-expansion desugaring would lose sharing. Offhand, I don't know of a desugaring that would do the trick and preserve sharing. Any ideas?

How about this? f = let body = sort . nub in \xs -> case xs of [] -> [1] (_:_) -> body I suspect we're well out of the territory of mere "desugaring" here, though. Cheers, Andrew Bromage

Neil Mitchell writes:

I quite like the idea of permitting equations to have different arities. It removes restrictions, makes things more regular etc.

More regular??? My goodness... Of course, it removes restrictions. But in the history of humanity rarely the removal of restrictions made things more regular! Sometimes it is useful, but not where it "for free" gives you more opportunities to make bugs. I wonder whether f = g and f x = g x attributes *always* the same type to both variants of f... Jerzy Karczmarczuk

G'day all. Quoting Neil Mitchell :

I don't believe that. I suspect the type system will mop these up.

As previously noted, anything involving undefined (thanks to seq) is not equivalent. While undefined is arguably uncommon, error most certainly isn't: f1 (x:xs) = {- something -} f1 [] = error "empty list" -- add an argument, to get... f2 (x:xs) y = {- something -} f2 [] = error "empty list" f2 is type-correct, but is subtly different from f1, both semantically and (I think) performance-wise. On sharing: It's not generally appreciated, but in GHC, there's a subtle difference between: g x y = let z = p x in q x y z and: g x = \y -> let z = p x in q x y z the difference being that in the latter, the definition of z can be let-floated: g x = let z = p x in \y -> q x y z GHC does not float lets over lambdas if it would "break" a group of function arguments. Any proposed desugaring would have to either come up with a better rule than this, or find a way to preserve it. Cheers, Andrew Bromage

On 13 Jan 2008, at 4:15 PM, Achim Schneider wrote:

"Neil Mitchell" wrote:

...

i.e. lift the arities to the longest argument list.

Is there a reason this isn't done?

Most likely not, there are being made up right now.

I'm glad you are capable of ever so nobly assigning the purest imaginable motives to the designers of Haskell. You are an inspiration to us all. jcc

Jonathan Cast wrote:

On 13 Jan 2008, at 5:27 PM, Achim Schneider wrote:

...

"Neil Mitchell" wrote:

...

Hi,

It's nice to write functions in point free style:

f = sort . nub

But sometimes I have to add an extra case, on a certain value:

f [] = [1] f = sort . nub

But now these equations have different arities, and its rejected by Haskell. Why does this not simply desugar to:

f [] = [1] f x = (sort . nub) x

i.e. lift the arities to the longest argument list.

Is there a reason this isn't done?

Answer #2:

Because you can't write

f x = case x of [] -> [1] -> sort.nub

But why not?

Because arities aren't lifted to the longest argument list.

Treating case as syntax sugar for a higher-order function, so that all binding occurrences of lambdas in the unsugared code are associated with lambdas, is a good thing, and offers a natural way of desugaring the above, one case at a time.

What about f x = [1] f - = sort.nub ? You could also do things like f - x = (foo x).bar with it. No more rewriting of pointfree code because of added arguments... -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.

Jonathan Cast wrote:

On 13 Jan 2008, at 5:49 PM, Achim Schneider wrote:

...

Jonathan Cast wrote:

...

On 13 Jan 2008, at 5:27 PM, Achim Schneider wrote:

...

Answer #2:

Because you can't write

f x = case x of [] -> [1] -> sort.nub

But why not?

Because arities aren't lifted to the longest argument list.

I think you lost the point of my question...

I'm glad you are capable of ever so nobly assigning the purest imaginable motives to me. You are a true inspiration.

...

...

Treating case as syntax sugar for a higher-order function, so that all binding occurrences of lambdas in the unsugared code are associated with lambdas, is a good thing, and offers a natural way of desugaring the above, one case at a time.

What about

f x = [1] f - = sort.nub

?

You could also do things like

f - x = (foo x).bar

with it. No more rewriting of pointfree code because of added arguments...

So `-' as a pattern means `implicitly apply the RHS to whatever this pattern matches'? I like it.

Yes. I suppose _> is a better idea, or something else beginning with _, as the rest of the characters could be functions. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.