[RPL/2] self compiling ?

[BERTRAND Joël]

DEMAINE Benoit-Pierre wrote:
> BERTRAND Joël wrote:
>> Adrian Blake wrote:
>>> Would you gibe me a simple example of eval()
>> 	An example of EVAL ?
>>
>> TEST
>> <<
>> 	<< 1 10 for I I disp next >> eval
>>  >>
>>
>> 	But today, you cannot modify evaluated expression. Maybe you look for 
>> OBGET, EXSUB, EXGET to modify an expression ? These intrinsic functions 
>> have to be written...
> 
> If you did not implement yet the obj/list functions, then, I expect at
> least string to object functions should exist in RPL/2.

	Yes, of course. STR-> and ->STR. But don't forget that STR-> requires a 
lot of cpu time. RPL/2 must analyze coherence and syntax of expression 
before trying to assign a type of each component of initial string.

> In critical
> cases, on HP48, I used to use ->srt and str->, that allow to alter
> program objects in the "string" way ...
> 
> Of course, an equivalent to obj->list (proposed in the Metakernel for
> HP48GX) would be much more convenient :) (and it's complement in our
> cas: list->prog, or some generic wraper: list->type that would take as
> argument and the number of the object type the list should be converted
> to. ). These were trivial to implement on HP48, since the only
> difference between a program and a list was the prolog :) (from memory,
> the 1st bunch of 5 quartets).
> 
> Bertrand, did you keep in RPL/2 this kind of memory oganisation where
> the first word of the object is the adress of the routine that
> implements it's content ?

	Nope. An RPL/2 is a compound type that contains a void pointer and a 
type (3 characters). The only difference between a list and an 
expression (algebraic or RPN expression) is this type : "RPN" for RPN 
expression, "ALG" for algebraic and "LST" for list. But there is a 
fondamental difference between an expression and a list. You cannot use 
all intrinsic functions in an expression. Thus, RPL/2 has to analyze 
expression syntax _before_ conversion to avoid all syntax errors. It has 
to analyze semantic of expression too (you can use loops, conditional 
statement and these code structures have to be well written. For 
example, you cannot start your expression with THEN or END...). I think 
it is better to modify by approprate functions a preexistant expression 
than trying to transform a list in expression (that requires a lot of 
cpu time in validation process).

> Once you get a wrapper to alter the prolog, and convert a program into a
> list, you just manipulate the list like any other one :)

	I'm really not sure it's the better method.

	JKB