I don't like Phil's suggestion to have non-lifted products:
* It messes up the uniform semantics for algebraic data types (all lifted).
For example
a) You have to explain that
f ~(z,a) = ... is the same as f (z,a) = ...
but
g ~(z:a) = ... is NOT the
(This message assumes we head for the strictness-annotation-on-constructor-arg
solution. I'll respond to Phil's comments in my next msg.)
The problem with polymorphic strictness
~~~
John asks what the problem is with strict constructor args. As Lennart and
I think there is another problem with having strict constructors. It messes
up parametricity even more than fix does. There are two reasons why this
would be a shame:
* Parametricity is cool. It lets you prove lots of interesting theorems
for very little work. These theorems help with program
So, as Lennart says, if we allow constructors to be strict in functions
then we have to change the semantics to distinguish _|_ from (\x - _|_).
I, for one, am deeply reluctant to do so; I certainly have no good handle on
the consequences of doing so. Does anyone else?
I thought this
Folks,
Warren Burton makes what appears to me to be a Jolly Sensible suggestion about
the syntax of type signatures. Haskell already has many dual ways of doing
things (let/where, case/pattern-matching). Warren proposes an alternative
syntax for type signatures.
Simon
--- Forwarded
Thomas Johnsson says:
If I recall correctly, the := to be used in array comprehensions was a
consession to the FORTRAN/Id/Sisal community, so that array comprehensions
would look more like they were used to.
Both Arvind and I think this is notation is awful, and I don't recall
1. We should get rid of Assoc.
I agree wholeheartedly! Do we have tp consider backwards
compat?
2. Arrays should be lazier.
I agree again. But I think both kinds should be provided.
3. AccumArray should mimic foldr, not foldl.
Right!
-- Lennart
Nikhil says,
| Thomas Johnsson says:
|
| If I recall correctly, the := to be used in array comprehensions was a
| consession to the FORTRAN/Id/Sisal community, so that array comprehensions
| would look more like they were used to.
|
| Both Arvind and I think this is notation is
John Launchbury says:
1. We should get rid of Assoc.
When explaining my programs to other people I find this is a point of
confusion. Imagine exaplaining array construction, "When I define an array,
the comprehension produces a list of index/value pairs, only they are not
written as
John Launchbury says,
| Here are three comments directed particularly at Haskell 1.3 people, but
| obviously open to general feedback.
|
| 1. We should get rid of Assoc.
|
| When explaining my programs to other people I find this is a point of
| confusion. Imagine exaplaining array construction,
But I think we can have the cake and eat it too, if we get rid of the
restriction (which I never liked) that operators beginning with : must be a
constructor: just define
a := b = (a,b)
Unfortunately that won't work if := had been used in patterns. I think
backward compatibility is an issue.
Oops! I should have underlined in my last message where I wrote
`newtype' instead of `datatype'. As a result, Simon seems to have
completely misunderstood my proposal. Sorry about that.
Simon seems to think I am proposing that if one writes
datatype T a_1 ... a_k = C t_1 ... t_n
Gerald Ostheimer notes that in Abramsky and Ong's lazy lambda calculus
that (\x - bottom) differs from bottom. That's correct.
But just because they call it `lazy' doesn't mean that it really is
the essence of laziness. I prefer to use the more neutral name `lifted
lambda calculus' for their
While we are proposing things, here's a further suggestion.
The great thing about this suggestion is that it only *removes*
a restriction, and makes the language definition simpler.
It is fully backward compatible.
The suggestion is:
Remove the restriction that type synonym
John Launchbury makes the suggestion, inter alia, that Haskell 1.3
`should get rid of Assoc.'
Reading some of the followup messages, I see that there is some
division on this point. Those closer to the scientific applications
community, such as Nikhil and Joe Fasel's acquaintances, seem to be
I have been following this discussion with interest and I'd like
some clarification.
Wadler writes:
But just because they call it `lazy' doesn't mean that it really is
the essence of laziness.
What is really been called `lazy' and how is the `essence of
laziness' defined?
Also, forgive my
16 matches
Mail list logo
