help from the community?
brianh at metamilk.com
Tue Jan 30 23:14:41 EST 2007
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.
More information about the Haskell-prime