Strange behaviour in yall [v2]

General
1

Hi, I want to ease the use of the {}/() operator by predefining some variables in a term and putting it into the {} part of the {}/() operator.

All these operations work on the console:

(ins)?- A=m , X=(A, B) , {X,H}/( H= t(_), A:assertz( H) ) .
A = m,
X =  (m, B),
H = t(_).

(ins)?- A=m , X={A, B} , {X,H}/( H= t(_), A:assertz( H) ) .
A = m,
X = {m, B},
H = t(_).

So I think after some tests that this flexibility is intended. And it would make sense.

But when I load these statements after putting it into a file like this:

:- use_module(library(yall)). % {}/()

test004 :- A=m , X=(A, B) , {X,H}/( H= t(_), A:assertz( H) ) .

test005 :- A=m , X={A, B} , {X,H}/( H= t(_), A:assertz( H) ) .

then I get errors:

test004:

(ins)[debug]  ?- make.
Warning: /home/ox/tmp/2022_03_21_prolog_yall_slash/001.pl:5:
Warning:    Singleton variables: [B]
ERROR: /home/ox/tmp/2022_03_21_prolog_yall_slash/001.pl:5:
ERROR:    Arguments are not sufficiently instantiated
% /home/ox/tmp/2022_03_21_prolog_yall_slash/001 compiled 0.00 sec, 0 clauses
ERROR: Arguments are not sufficiently instantiated
ERROR: In:
ERROR:   [11] notrace(make_no_trace)
ERROR:   [10] make:make at /usr/local/lib/swipl/library/make.pl:79
ERROR:    [9] toplevel_call(user:user:make) at /usr/local/lib/swipl/boot/toplevel.pl:1117

test005:

(ins)[debug]  ?- make.
Warning: /home/ox/tmp/2022_03_21_prolog_yall_slash/001.pl:7:
Warning:    Singleton variables: [B]
ERROR: /home/ox/tmp/2022_03_21_prolog_yall_slash/001.pl:7:
ERROR:    Arguments are not sufficiently instantiated
% /home/ox/tmp/2022_03_21_prolog_yall_slash/001 compiled 0.00 sec, 0 clauses
ERROR: Arguments are not sufficiently instantiated
ERROR: In:
ERROR:   [11] notrace(make_no_trace)
ERROR:   [10] make:make at /usr/local/lib/swipl/library/make.pl:79
ERROR:    [9] toplevel_call(user:user:make) at /usr/local/lib/swipl/boot/toplevel.pl:1117

Unfortunately this is my usecase. Simpler statements are working.

The Documentation in

https://logtalk.org/manuals/refman/grammar.html#lambda-expressions

which the swi documentation referes to makes no statements about that.



lambda_expression ::=

lambda_free_variables “ `/` ” lambda_parameters “ `>>` ” *callable* |

lambda_free_variables “ `/` ” *callable* |

lambda_parameters “ `>>` ” *callable*

lambda_free_variables ::=

“ `{` ” *conjunction of variables* “ `}` ” |

“ `{` ” *variable* “ `}` ” |

“ `{}` ”

It can be, that it is not intended.

But maybe I am wrong.

How can I fix this?

Regards,
Frank

2

Yall compiles lambda expressions in the source code when possible. The goal expansion hook available to compile this only sees {X,H}/( H= t(_), A:assertz( H) ) and has no clue that X will be bound a runtime (let alone to what it will be bound).

At the toplevel it works as now the lambda is handled at runtime and the unification already happened.

As is, that is unlikely to improve anytime soon. Eventually translation of code should IMO be handled using partial evaluation and such differences should vanish.

2 Likes