Weird Language Features

[Johann Hibschman]

Dave Cross writes:

> 1/ The programmer calls a function that doesn't actually exist within
> the application (or libraries).

It's easy to trap this error in Common Lisp, but it's hard to set up a
"general replacement" routine.  You can, generally, trap the error for
a given block of code, then attempt to guess a replacement function,
but I don't think you can then resume the calculation.

However, if you're reading in user/scripting code, it's an easy thing
to pre-process it, looking for unknown functions, then replace those
symbols with your guess.  It just has to be a pre-processing step, not
a run-time step.  i.e. you have to do (eval (process (read-all
"file"))), rather than just (load "file").

If the program's not making an error, the package system should be
able to handle it.

> 2/ Can ou filter the input source code before compilation (or
> interpretation) in some way so that language keywords could be changed
> for other strings?

Pathetically easy in any of the lisp-derivative languages.  This is
where having a code form that looks like data really shines; you just
read the code in, manipulate it at will, then execute it afterwards.
Use the same (eval (process (read-all "file"))).

> If you're wondering why I'm inventing these bizarre scenarios, it's
> for a paper I'm writing for this year's Perl Conference.

Have fun.  I do suspect that Common Lisp whups Perl in this respect,
though.  :-)

-- 
Johann Hibschman                           johann at physics.berkeley.edu