On 12/14/2015 07:49 AM, Sebastian Hanowski wrote:
> On Thu, Dec 10, 2015 at 10:53:00PM +0100, Michael Hanus wrote:
>> As I wrote before, the second argument of the non-strict unification
>> operator (=:<=) must be a pattern variable in order to stay in the=
>> well-understood framework of functional patterns. Since this is not th=
e
>> case in your definition, it might compute something as intended,
>> but the general declarative semantics is not clear (to me).
>
> Challenge accepted ;)
>
> fibaux fib xs | (1, (1, tail (tail fib))) =:<= xs = fib
>
> fibs = fibaux xs (head xs, (head (tail xs), zipWith (+) xs (tail xs))=
)
> where xs free
>
>
> And if non-linearity of patterns isn't an issue...
>
> fibaux fib (1, (1, tail (tail fib))) = fib
Unfortunately, non-linearity of patterns is a delicate point.
Non-linear patterns are translated into linear ones by adding
equational conditions, i.e., the last rule is interpreted as
fibaux fib0 (1, (1, tail (tail fib1))) | fib0=:=fib1 = fib0
This does not yield the result you desire and it also shows
that you cannot pass the values of other arguments into
a functional pattern (in order to obtain a declarative semantics
of functional patterns).
Hence, the challenge is open...
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Di Dez 15 2015 - 15:45:52 CET