Fwd: Meta-Interpreater

I am forwarding this message to the list, I guess the answer is interesting
for everybody but now I realized I was the only receiver.
Regards,

Edison <http://edisonm.com/>


---------- Forwarded message ----------
From: Richard A. O'Keefe <[email protected]>
Date: 2014-04-07 5:07 GMT+02:00
Subject: Re: [SWIPL] Meta-Interpreater
To: Edison Mera <[email protected]>



On 7/04/2014, at 10:44 AM, Edison Mera wrote:

> Meta interpreters for a production program are always a bad idea, not only
> for performance, but also for debugging, the debugger will show you the
> meta interpreter, but not the actual code being interpreted, and imagine
> that in a thousands line of code program.

I don't know that I'd go with the "always" part.

Let's get rid of the "meta-" prefix here, because
I don't think it's helpful.  (The original phrase
was "meta-CIRCULAR interpreters", as in interpreters
that could interpret themselves, which led in some
very interesting directions.)

Frankly, I am not at all sure where to draw the line
between "data structure" and "code", between "tree
walker" and "interpreter".  For example, I'm
currently reading "Effective strategic programming
for Java developers".  (Balland, Moreau, & Reilles,
Software Practice and Experience, 2014, v44 pp129-162.)
The things they call "strategies" would probably have
been called tactics (or possibly tacticals) in ML,
and would certainly have been native-compiled code.
They are, in effect, higher-order functions.
But in that paper, "strategies" are "terms".

If my sins were gross enough for me to suffer the
penalty of having to code in Java, would I want to
use SL?  Yes.  Would the fact (if it is a fact, I'll
have to read the paper another couple of times) that
this does some stuff at run time scare me off?  No!

Beginners are not told what the *real* point of writing
an interpreter is, namely to use very well understood
techniques for turning interpreters into compilers.

Pereira & Sheiber explain DCGs in their neat little book
by first exhibiting an interpreter for grammars.
In the case of grammar rules, everything is small enough
that you can apply the first Futamura projection by hand.

> However, because meta interpreters is a typical textbook Prolog exercise
to
> show its homoiconicity,

No, that's *NOT* the purpose.  The purpose is to show a basis
for *EXTENSION*.  For example, if you want to support Prolog-
like execution but with iterative deepening, it's easier to
start with an interpreter and then compile it away.  If you want
to apply meta-rules exploiting things like symmetry, or if you
want to apply the rule that if an attempt to prove a goal G
reaches an attempt to prove a goal G' that is an alphabetic
variant of G, you can immediately fail G' and still be sound,
these are easy things to mix into an interpreter.

A tracer, of course, just *is* an interpreter.
(Which should maybe be compiled away.)

The original poster's actual problem was solvable using
a DCG translator with a non-standard translation.
-------------- next part --------------
HTML attachment scrubbed and removed