Tue Feb 6 03:43:13 GMT 2007
((dup cons) dup cons)
just added 'compose', then i found out the quine in the title doesnt
work any more. it does work in joy, so what's up? the problem here of
course is that consing 2 quoted programs does not give a quoted
program: these are abstract data types and not lists.. manfred must be
using some explicit definition of cons on quoted programs somewhere,
or i don't really understand his list semantics.
the problem with mine is that quoted programs are in fact lists, but
they have a header containing a link to the symbol resolver.
so, am i missing something about Joy? is the: "quoted program is list"
necessary? have to check that.
in the mean time, i can get to quines by defining 'qons'.
there is a possibility of embedding lex information inside the list,
so instead of
(lex a b c) -> ((lex a) (lex b) (lex c))
which might even be better, since it allows for mixing of dicts. this
also makes it possible to use a simpler interpreter, since the lex
state doesn't need to be maintained.
hmm.. tried, but to tired. but something is rather important. having
lists and programs on the same level as in joy is nice, but requires a
single semantics. since i already almost automaticly introduced 3
kinds of sematics for symbolic code (cat, forth rewriter and forth
compiler) this is not really feasible.
so lists and programs should probably be separate entities, where
programs are abstract and not dissectable, but compose and qons are
defined to do run-time composition.
concat compose (qoncat)
where quons will take 2 quoted programs, and concatenate the quotation
of the first with the second, or (a) (b) -> ((a) b)
however, if i change the interpreter as mentioned above, the two
columns will be identical, and programs can be manipulated just as
lists, without giving up any other functionality.
so, good to learn, CAT not really Joy because
- i'm using fully quoted lists instead of quoted programs to represent
data lists: there is a clear separation between code and data.
- joy probably uses numbers directly in the lists, which i can't due
to different number semantics for cat and purrr. for me, they have
to be incapsulated in numbers.
- parsing from symbolic -> code is explicit because of different
semantics: this allows reuse of interpreter for different mini