Re: Meta-Interpreater

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.
However, because meta interpreters is a typical textbook Prolog exercise to
show its homoiconicity, beginners think that is a nice programming pattern
and are not aware of those problems.
If you really need to keep track of the goals executed to reach an answer
without to modify your program, you need a tracer, which is like a debugger
but without user-interaction.
Just to illustrate the idea, this is a simple one that print the typical
Prolog ports, implemented using the goal_expansion/2 hook:

:- module(tr, [p/1]).
> write_port(Port, Goal) :-
>     format(user_error, '~a: ~q~n', [Port, Goal]).
> do_trace(Goal) :-
>     write_port(call, Goal),
>     ( true
>     ; write_port(fail, Goal),
>       fail
>     ),
>     prolog_current_choice(C0),
>     Goal,
>     prolog_current_choice(C1),
>     write_port(exit, Goal),
>     ( C0==C1
>     ->!
>     ; ( true
>       ; write_port(redo, Goal),
> fail
>       )
>     ).
> goal_expansion(Goal0, Goal) :-
>     trace(Goal0),
>     Goal = do_trace(Goal0).



trace(p(_)).
> trace(a(_)).
> trace(b(_)).


> p(X) :-
>     a(X),
>     b(X).
> a(a).
> a(b).
> a(c).
> b(b).
> b(c).
> b(d).



Example:

?- p(A).
> call: a(_G1413)
> exit: a(a)
> call: b(a)
> fail: b(a)
> redo: a(a)
> exit: a(b)
> call: b(b)
> exit: b(b)
> A = b ;
> redo: a(b)
> exit: a(c)
> call: b(c)
> exit: b(c)
> A = c.
> ?-


From there it can be improved to show or store more information, etc...
Hope this help,

Edison <http://edisonm.com/>


2014-04-01 17:28 GMT+02:00 Martin Riener <[email protected]>:

> Hi,
>
> It's certainly possible to write the grammar and use a metainterpreter
> afterwards to get the parse tree. For that two things have to work:
>
> a) the evaluation of the dcg works directly intepreted
> b) you run the dcg on a meta-interpreter to extract the tree
>
> it seems, you are still stuck with a), so step b) can not give better
> results. In fact, a meta-interpreter has a high performance cost, so
> depending on what your prof says, it might be better to replace b with
> the step
>
> c) extend your grammar to carry on the parse tree (perhaps have a look
> at [1] to find a small tutorial about how to do parsing with dcgs, they
> can build parse trees without using a meta-interpreter)
>
> if path c) is viable or not is up to your prof.
>
> hope this clears stuff up a bit,
> cheers Martin
>
>
> [1] http://www.pathwayslms.com/swipltuts/dcg/
>
>
> On 04/01/2014 03:51 PM, [email protected] wrote:
> > Thanks for your response.
> > Actually the assignment spect says:- The aim of this assignment is to
> develop a computer program that inputs a protein sequence, determines
> weather that sequence can be parsed by a given biological grammer and if
> so, shows how the sequence can be broken down into gramatical constructs.
> And aim is also to develop a prolog meta interpreater that not only
> determines wheather a sentence can be parsed by a grammer but also generate
> a parse tree.
> >  I have made an interpreater which reads the grammer and the sequennce
> but it continue reading forever. I know this is because I am new to this
> programing language. So I will be glad if you can be of help.
> > thanks
> >
> > _____________________________________
> > Sent from http://swi-prolog.996271.n3.nabble.com
> >
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>
-------------- next part --------------
HTML attachment scrubbed and removed