> >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 compatibil
> >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.
Nonsense. Of course construc
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
decl
Although Warren's suggestion is logical, it's not in any way standard.
(Most of the places where we have two ways of doing something, they are
both standard.)
It might be a nice idea, but I'm not at all convinced it's
nice enough to be worth putting into Haskell. -- P
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
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
th
To illustrate a need for recursive type synonyms, Joe suggests the example:
| nil f g = f
| cons x xs f g = g x xs
|
| fold f z xs = xs z (\x xs -> f x (fold f z xs))
Indeed, this doesn't type check in Haskell, and recursive type synonyms
would fix it. (So
Phil suggests that Haskell 1.3 might:
| Remove the restriction that type synonym
| declarations must not be recursive.
|
| In other words, one could write things like
|
| type Stream a = (a, Stream a)
|
| which is equivalent to the type (a, (a, (a, ...))).
I have some res
>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 issu
Phil writes,
| 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
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
> I thought this inequality was one of the distinguishing characteristics of
> lazy functional programming relative to the standard lambda-calculus. To
> quote from Abramsky's contribution to "Research Topics in Functional
> Programming", Addison-Wesley 1990:
>
>Let O == (\x.xx)(\x.xx) be t
> 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
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
> 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 i
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, "When I define an array,
the compr
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 Mess
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 sam
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
(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
K
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
w
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,
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 aw
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
e
Two of John Launchbury's suggestions for Haskell 1.3 would mesh well
with the pH (parallel Haskell) effort:
>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
25 matches
Mail list logo
