[eeps] Multi-Parameter Typechecking BIFs
Thu Feb 26 02:31:53 CET 2009
On 26 Feb 2009, at 12:17 am, mats cronqvist wrote:
> "Richard O'Keefe" <> writes:
>> That is *exactly* what Mats Cronqvist suggested.
>> In his message of 23-Feb-2009, he wrote:
>> Separating the pattern match from the condition is bad.
>> The 'when' keyword should have never been introduced.
> The proposal is to allow inlined type checks. My opinion is that
> 'when' was a mistake. That seems plenty clear to me, and I think
> we've once again reached the point were you're actively trying to
That is most unfair.
I interpreted what you wrote in good faith.
I went to a fair bit of trouble to ensure that I was
quoting you accurately.
In this whole thread I have never ONCE "actively tr[ied]
to misunderstand" anything whatsoever no matter by whom
expressed and I am deeply upset at the accusation that I have.
Guards allow many things other than "type checks".
If "The 'when' keyword should have never been introduced"
is true, then it must be the case that the things that
currently go in guards ought to go somewhere else.
Where else can they be put but the pattern?
Remember, in the case of
receive Pattern when Guard -> Choice
we *can't* move the guard into the Choice.
If 'when' is a mistake, then the *whole* guard has to
move into the pattern.
If you *don't* mean that everything in guards should be
in patterns, then you have expressed yourself most confusingly.
I paid you the compliment of taking you at your word
and supposing that when you said 'when' was a mistake,
without any restriction like "except for 'receive'")
you really meant what you said.
I invite you to recall that in Haskell, type checks are never
needed at all, because it is strongly statically type checked.
Nevertheless, guards are extremely common.
To quote Simon Peyton Jones, in the paper that introduced
pattern guards (an extension to guards),
The reason that Haskell provides guarded equations
is because they allow us to write down the cases
we want to consider, one at a time,
independently of each other.
Now, if either the lookups fail we want to fall through
to the second and third equations for clunky'. If we
write the definition in the form of a case expression
we are forced to make the latter two equations for
clunky' into a separate definition and call it in the
right hand side of fail. Ugh. Ugh. Ugh. This is
precisely why Haskell provides guards at all, rather
than relying on if-then-else expressions:
if the guard fails we fall through to the next equation,
whereas we can't do that with a conditional.
That is, even without any type tests at all, we'd STILL want
'when' (or '|' as Haskell spells it) for the purpose of
structuring our code clearly. Something that does that can
hardly be a mistake.
More information about the eeps