a compiler for perl

Francois-Rene Rideau fare@tunes.org
Fri, 19 May 2000 20:16:00 +0200


> I was talking about directly changing the list representation of
> functions, not the source (though they are equivalent).
I think the CommonLISP standard does not specify the effects
of modifying the body of functions
(e.g. by modifying interned strings or quoted material).
Citing the CLHS about QUOTE:

The consequences are undefined if literal objects (including quoted objects)
are destructively modified. 

Of course, depending on the implementation you use, and the safety
and optimization level, it might do what you think it will or not.

> You know, if Tunes was based on Logo it would start
> out with a very large number of users :-)
Alternatively, I could take Linux or *BSD, rename it "Tunes",
and have a large number of users... next thing, LinuxOne hires me.

> With runtime compilation (Self and Hotspot), we get the best of both
> worlds!
Sure.

>> If the system makes it possible to detect that eval won't be used in
>> a given program, then it might be stripped from a static binary output
>> (some LISP "tree-shakers" are known to do that).
> 
> Just "grep eval source.lisp" and if the result is empty you know you
> won't have to include the interpreter ;-)

It's not as easy as you say. What about the following?
(funcall (symbol-function (intern (concatenate 'string "EVA" "L")))
	"(+ 1 2)")


[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Love thy neighbor as thyself, but choose your neighborhood.
		-- Louise Beal