

metacircularmetainterpreter

Author  Message 

metacircularmetainterpreter
Quote: >I have finally seen the "vanilla interpreter" one time too many: I appreciate O'Keefes very sophisticated solution utilizing difference > prove(true). > prove((A,B)) : > prove(A), > prove(B). > prove(H) : > clause(H, B), > prove(B). >It is time somebody told the truth about this: >Why is it disgusting? Because the third clause claims to be >A general rule for "defaulty" representations (such as here, where a lists. But one should not compare it directly with the vanilla meta interpreter. The latter is more towards a specification while the former is more towards an implementation. The handling of builtin predicates emphasizes this: Quote: >You can hook builtin predicates into this representation thus: (Somebody might have the idea to add a rule for the conjunction ','/2, > rule(p(X,..,Z), C, C) : p(X,...,Z). >e.g. > rule(rule(H,B0,B), C, C) : > rule(H, B0, B). as it is also a builtin). In fact, I will show that O'Keefes suggestion is a implementation Quote: >If you want to experiment with this, here is the definition of rule/3 I did experiments in AAISProlog on the Mac and  surprise!,surprise!  >for naive reverse and a metacircular version of prove_goal/1... both the vanilla (as defined just below) and metacircular version have about the same speed and adding cuts to either of them does not increase speed significantly ! For the specification of the metainterpeter I will use user defined prove(true). Now we derive the implementation. As it is the case with O'Keefes prove(true). Next we change the representation of the rules from prove([]). Now we fold the two recursive subgoals into one with help of append/3: prove([]). Then we use difference lists in rule/2 to get rid of append again by prove([]). We could have also choosen the transformation prove([]). Concluding, O'Keefes metacircularmetainterpreter is a 

Sun, 17 Jan 1993 17:50:00 GMT  
metacircularmetainterpreter
Quote: >I appreciate O'Keefe's very sophisticated solution utilizing difference >lists. But one should not compare it directly with the vanilla meta >interpreter. The latter is more towards a specification while the >former is more towards an implementation. it demands that clause(true, Body) and clause((X,Y), Body) *should* be called, and should fail. In a Prolog system which distinguishes between predicates you can change and predicates you can't, you are likely to get error messages when you run the "vanilla metainterpreter". If the V MI were written as prove(true). prove((X,Y)) : prove(X), prove(Y). prove(H) : H ~= true, H ~= (_,_), clause(H, B), prove(B). then the "it's only a specification" argument would go be valid. {I claim that clause((_,_), _) SHOULD report an error in every Prolog; (_,_) has a definition, it's just that the Prolog system refuses to show it do you.} Alternatively, the last clause of the V MI could be written as prove(H) : current_predicate(_, H), clause(H, B), prove(B). to make it explicit that clause/2 is only to be called on userdefined predicates. Quote: >In fact, I will show that O'Keefe's suggestion is an implementation The derivation in question does not preserve semantics. (The V MI can >version derivable from a specification based on the vanilla meta >interpreter. be talked into calling rule(true, _) and rule(_,_), _), the "derived" version can't.) When P and Q compute different functions, it is not clear that P can be regarded as an implementation of Q. 

Sun, 17 Jan 1993 08:49:00 GMT  
Page 1 of 1 
[ 2 post ] 