Hello, I would like to propose a feature from the FP language Clean[1] called Nested Guards. Example from [2]: example arg1 arg2 | predicate11 arg1 | predicate21 arg2 = calculate1 arg1 arg2 | predicate22 arg2 = calculate2 arg1 arg2 | otherwise = calculate3 arg1 arg2 | predicate12 arg1 = calculate4 arg1 arg2 I think the semantics are clear enough. Nested Guards should also be interoperable with Pattern Guards[3]. When a match on a pattern guard succeeds the environment is updated with the new bindings. Then the potential nested guards are matched in order in this new environment. What do you think? Bas van Dijk. [1] http://www.cs.ru.nl/~clean [2] ftp://ftp.cs.kun.nl/pub/Clean/Clean20/doc/CleanRep2.0.pdf (See 3.3 Guards) [3] http://hackage.haskell.org/trac/haskell-prime/wiki/PatternGuards
On 7/1/06, Bas van Dijk
I would like to propose a feature from the FP language Clean[1] called Nested Guards. Example from [2]:
example arg1 arg2 | predicate11 arg1 | predicate21 arg2 = calculate1 arg1 arg2 | predicate22 arg2 = calculate2 arg1 arg2 | otherwise = calculate3 arg1 arg2 | predicate12 arg1 = calculate4 arg1 arg2
I think this is great. Does it have fall-through semantics?
--
Taral
On Saturday 01 July 2006 18:44, Taral wrote:
Does it have fall-through semantics?
The Clean Report[1] is not really clear on that but to my knowledge nested guards do not have fall-through semantics. The report does mention this: "To ensure that at least one of the alternatives of a nested guard will be successful, a nested guarded alternative must always have a 'default case' as last alternative." Bas van Dijk. [1] ftp://ftp.cs.kun.nl/pub/Clean/Clean20/doc/CleanRep2.0.pdf (See 3.3 Guards)
On 7/1/06, Bas van Dijk
"To ensure that at least one of the alternatives of a nested guard will be successful, a nested guarded alternative must always have a 'default case' as last alternative."
Okay, that sounds like they don't have fall-through semantics in
Clean. Probably for the best -- accidental fallthrough might be a
nasty source of bugs.
--
Taral
Bas van Dijk writes (to the haskell-prime list):
The Clean Report[1] is not really clear on that but to my knowledge nested guards do not have fall-through semantics.
The report does mention this:
"To ensure that at least one of the alternatives of a nested guard will be successful, a nested guarded alternative must always have a 'default case' as last alternative."
I don't think this explanation is accurate. The reason that a nested guard must have a default case is syntactical, otherwise there could be the dangling-else ambiguity. If I remember correctly, the compiler can handle nested- guards with fall-throughs just fine. There have been proposals to use the offside rule to resolve the ambiguity, but I can't recall if this was implemented. See <http://mailman.science.ru.nl/pipermail/clean-list/ 1997/000175.html> for some examples. Cheers, Ronny Wichers Schreur
On 7/1/06, Bas van Dijk
I would like to propose a feature from the FP language Clean[1] called Nested Guards.
I do have to bring up that this is excluded from consideration for
Haskell' because it is not already implemented in any existing Haskell
compiler or interpreter.
Perhaps this could be forwarded onto the GHC and other compiler people
for consideration as an extension?
--
Taral
participants (3)
-
Bas van Dijk -
Ronny Wichers Schreur -
Taral