Re: Functional syntax

On 12/05/2013 05:47 PM, Alan Baljeu wrote:

>>> Can you elaborate what sort of issues need be resolved?
>> One is still on the radar: how to interact with DSLs that do not
>> wish to use this as functional notation.  Also the interaction
>> with meta-calls is quite delicate.
> 
> 
> The LISP way is to do one of these:
> with_functional_expansion(stuff), other_stuff
> 
> 
> and any A.B found in stuff gets expanded.  Or
> 
> 
> without_functional_expansion(stuff), other_stuff 
> any A.B found in other_stuff gets expanded

I know.  I don't really like it though.

> Note that if expansion is compile-time, and can be 
> disabled, it's easy for a programmer to structure 
> code so the data elements are not subject to unwanted
> rewrites.

I don't think (but I might be wrong; too much in my head)
that you didn't answer my question whether you could solve
./2 being expanded into functional notation in your DSL by
term/goal expanding it into something else than a ./2
term.  ./2 expansion happens after all user and other
system expansion, just before the stuff is compiled into
VM codes.

> As for meta-calls, I think these two points cover most issues:
> 1) any term rewrite produces a comma-list

If you mean by `term' `goal', I agree.  That is how it works.
There is however code like this:

d(d{x:1}).
d(d{x:2}).

	forall(d(D), writeln(D.x)).

which should compile into

	forall(d(D), (.(D,x,X), writeln(X))).

and not

	.(D,x,X),
	forall(d(D), writeln(X)).

This is fine for meta-arguments that are annotated as
`0'.  However, we have a problem with demand loading, were
we do not have the meta-information available before the
code is loaded.  That needs some solution.  It isn't really
a new problem; it just gets really important to so.

Worse are things annotated as e.g., 1.  What does this
mean?  At the moment it is reported as an error.

	maplist(f(D.x), List)

> 2) ./2 is callable

I guess you mean ./3?  It is.  It is a system predicate.

	Cheers --- Jan