help from the community?

[Brian Hulley]

Andres Loeh wrote:
>>> The only reasons that I could see in favor of allowing empty
>>> "forall"s is that it might be easier to automatically generate
>>> code. Haskell seems to be a bit inconsistent in how it treats empty
>>> constructs. For example, empty let and empty where seems to be
>>> allowed, but not an empty case?
>>
>> Just a little remark on the side: 'If' and 'case' demand exactly one
>> expression. In such cases allowing zero expressions is not a
>> generalization but an unnecessary complication. 'Let' and 'where'
>> allow any number of bindings, so allowing zero bindings (instead of
>> demanding at least one) is a simplification.
>
> I meant the branches of a case (the report specifies at least 1).

I think it's important to keep some possibility for the compiler to detect 
probable errors as syntax errors. If all syntax is inhabited by strange 
defaults then this just means simple errors will go undetected eg:

    let a = case foo of

Here, the user has probably got sidetracked into editing some other part of 
the program and just forgotten to get back to fill in the cases for the case 
construct. Allowing zero cases means the user will get a strange runtime 
error instead as the "function" part of the case is undefined.

    let z = \y (foo y)

Here, it seems clear that the user has just forgotten to type the -> which 
means a simple syntax error would get transformed into a much more puzzling 
(esp for a newbie) type error.

The difference between the above and 'let' and 'where' is that if the 
enclosing construct (eg a binding) is complete, we know that the contents of 
the 'let' are complete (since extra local bindings added afterwards would be 
irrelevant) similarly for 'where', and if the enclosing construct is not 
complete the compiler will detect this.

Therefore I think the original choices are the best since they don't seem 
inconsistent when looked at this way.

Brian.
-- 
http://www.metamilk.com