Re: Curry syntax

From: Wolfgang Lux <>
Date: Sat, 11 Mar 2017 16:38:36 +0100

Hi Andy,

> Is there some difference between let bindings and where bindings in this regard?


> It seems if the functional pattern you show could work in a "let" context, then it should also work in a "where" context. Is this an MCC extension?

Sort of. Trying it in PAKCS will give you an internal compiler error, but there's really not much magic behind it, it's just the usual rewrite of function patterns into a set of variable declarations plus some carefully placed extra constraints to solve the function pattern.

> I see your points and take them well. I think the nub of my suggestion (which I now see more clearly) is to interpret an expression in a binding context as a constraint. So, something like:
> let length x == 3 in x
> OR
> x where length x == 3
> There's no use for this in a functional setting, but in Curry it has meaning. I don't know how much the syntax would be disturbed, but it seems possible that ambiguities could be introduced by allowing this.

It would make parsing a bit more difficult, but I think it would be possible. A different question is the semantics of such expressions in a binding context. Bindings are lazy, so a local binding x = True == False has no effect until the variable x is actually used in the program. What about an expression True == False in a binding context? IMHO, it should be ignored because there is no free variable in the expression, but is that obvious for the user? I wouldn't make the semantics of expressions in binding context strict, because that is already achieved by guards (and the &> operator when a plain expression is required).

> I think my intuition comes from the "let x free in ..." and "... where x free" constructs. Those already don't bind x, but establish a property regarding it.

Technically these constructs do introduce the variable and bind it to itself, but that's my perspective as an implementor. But if by property you mean the scope of x, I can agree with that.


curry mailing list

Received on So Mär 12 2017 - 18:44:15 CET

This archive was generated by hypermail 2.3.0 : Mo Dez 04 2023 - 07:15:14 CET