Re: [q-lang-users] New stuff in cvs: multichar ops, views

[Albert G. <Dr....@t-...>]

Albert Graef wrote:
> I also have plans to turn 'lambda' into a virtual constructor for the
> builtin external <<Function>> type used to represent compiled lambdas,
> and, instead of having a builtin pretty-printing of <<Function>>
> objects, define an appropriate view for them.

Ok, this is now implemented as well. So you can now dissect a 'Function'
object (a.k.a. compiled lambda) simply as follows:

==> var fact = \N.if N>0 then N*fact(N-1) else 1; fact
\X1 . if X1>0 then X1*fact (X1-1) else 1

==> def \PAT.BODY = fact; PAT; BODY
X1
if X1>0 then X1*fact (X1-1) else 1

I think that this is quite neat. I also overhauled the definition of
equality on 'Function' objects in prelude.q so that it uses the
corresponding view instead of comparing string representations of the
objects.

There's one (last?) issue I want to work on for the current release,
namely the notion of syntactic equality for external types such as
'Function' which have an associated view. Right now external objects are
considered syntactically equal only if they are the same object (i.e.,
pointer equality). AFAICS, this is the only thing that makes sense if
there is no printable representation -- given that syntactical equality
must always be defined, for any kinds of objects.

But now that external types may have views, it makes sense to test
syntactic equality on such types by comparing the corresponding views.
This is consistent with the "two expressions are syntactically equal if
they print out the same in the interpreter" rule for normal objects.

I will also remove the current definition of (=) for Function objects,
as it's just syntactic equality, and there's no real notion of semantic
equality on functions which is also decidable, so it makes sense to
leave (=) undefined on these objects.

Is anyone fine with that? Will it break any of your existing code? Only
programs directly dealing with Function objects (comparing them with (=)
and (==)) might be affected.

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag