[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Woups! Typol bug
- Subject: Re: Woups! Typol bug
- From: td@babar.inria.fr (Thierry Despeyroux)
- Date: 25 Mar 92 10:44:10 GMT
In article <15723@sophia.inria.fr>, kuehne@pi.informatik.th-darmstadt.de (Thomas Kuehne) writes:
|> I was asked by the Typol type checker to report the following (bug?):
|>
|> export ANNOT_SPEC(penv[] |- spec)
|> as add_procdefs(spec)=_;
Thank you for your cooperation. This will be corrected.
|> The reason for calling the function add_procdefs is the side effect of
|> annotating the tree spec. Therefore i do not need any result of the
|> computation.
This is how the typol compiler works itself. The types are put as
annotations in the original tree. As the export clause builds
a lisp function, if you are not interested in a result, you can put ()
as result. However, it may be of interest to know in the lisp interface
when your typechecker fails. So I will suggest to put something else
as result, for example a string "ok". So the lisp function
#:file-name:add_procdefs will give "ok" when the type-checker succeeds
and () when it fails. And you may write something like
(ifn (#:file-name:add_procdefs ...)
(there is a bug in my type checker....))
|> By the way, is this how you do it ?
|> When interpreting a process call (like a procedure call) i need access
|> to the process defintion. My idea is to first annotate all nodes with
|> process calls with their corresponding process definition.
|> When arriving at a process call i simply 'getannot' the definition.
|> Is there another method ?
|> You might need to know that i am interpreting a tree with references to a
|> second tree. The second tree contains the process calls.
|> That is way working with an environment, that is updated during interpretation,
|> is not straightforward.
What I use to do is to build an environement with triples:
<name-of-proc, body, location> where location is the path to
the body of the procedure to allow the subject tracking.
So for declarations, I have a rule like
e |- proc_dec(ID, BODY) -> env[triple(ID, BODY, location(s(subject, int 2))).e] ;
(with location -> implemented as TREE in the abstract syntax definition)
and for calls
get_proc(e |- ID -> BODY, path) & withsubject(path: e |- BODY ...)
--------
e |- call(ID) ...
and
env[triple(ID, BODY, location path).e] |- ID -> BODY, path ;
somewhere in get_proc.
I see some advantages doing this: efficiency (no need to get annotations
somewhere in the Lisp world, sharing thanks to the prolog implementation)
and I understand it better from a logical point of view (in particular
annotations are not undone when backtracking).
Thierry.
--
Send contributions to centaur@sophia.inria.fr. Registration and
administrative matters should be sent to centaur-request@sophia.inria.fr.
+---------------------------------------------------------------------------+
| Thierry Despeyroux | email: Thierry.Despeyroux@sophia.inria.fr |
| I.N.R.I.A. Sophia-Antipolis | phone: +33 93 65 77 07 fax: +33 93 65 77 66 |
+---------------------------------------------------------------------------+