[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about Centaur
- Subject: Re: Question about Centaur
- From: td@almeria.inria.fr (Thierry Despeyroux)
- Date: 10 Feb 1994 10:50:45 +0100
In article <1994Feb10.012452.22449@sophia.inria.fr>, ychen@ISI.EDU writes:
|> Sisal2
|> ------
|> The Exp program evaluation is a simple case because it needs only
|> the information contained in an Exp PROGRAM.
|> I am currently working on evaluating the Sisal2 program. To evaluate
|> a Sisal2 program, an evaluator needs the following information:
|>
|> (A) the Sisal2 PROGRAM
|> (B) the entry-point FUNCTION NAME and
|> (C) the INPUT DATA for the arguments of that function.
|>
|> Questions
|> ---------
|> I can construct the typol-object for (A) by (STEP 1)~(STEP 3)
|> without any problem.
|>
|> My question is: Do I have to construct a typol-object for
|> the FUNCTION NAME and a typol-object for the INPUT DATA?
|>
|> If this is true, does that means I have to define a language
|> (by FUNCTION_NAME.metal) for reading the function name in (STEP 2)
|> and to define a language (by INPUT_DATA.metal) for reading
|> the input data in (STEP 2)?
It depends on the type of FUNCTION NAME and INPUT DATA.
If it is a string or an integer, you do not need to provide a typol-object. If
it is a tree, you must provide it. In the last case, you have the
choice to extend your formalism Sisal2 to contain your data, or
to define it in a different formalism (The same thing applies for
environments). The problem here is that most of the time environments,
data, etc. share some objets with the language itself, but metal does
not allow modular definitions. So the choice is
1) Extend the initial formalism with environments and data. This
pollutes the initial definition but allows sharing any part of the
abstract syntax (e.g. a Sisal2 Exp may be found some where in the data).
2) Define a new formalism. It seams cleaner because the initial
formalism and the constructs that are needed for execution are separated.
But only the atomic values (strings and integers) are shared. And sometime
you will have to translate a expression in the environment into an expression
in the environment (for example).
In the following example, func_name is a string that is immediatly used
to construct a tree. This is easier than passing a tree, saving a typol-object.
program sisal2_evaluator is
use sisal2;
judgement ENV, PROG |- ID, DATA -> DATA;
export env[], prog |- id func_name, data
as eval(prog, func_name, data) = result;
...
I hope this will help you.
Thierry.
--
Send contributions and compliments 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 |
+---------------------------------------------------------------------------+