Re: Type checking (was: The strengths of FORTH)

On Apr 10, 3:16 pm, m_l_g3 <m_l...@[EMAIL PROTECTED]
> wrote:
> On Apr 10, 9:54 am, "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
>
> One more nice feature of the StrongForth is that it can cope with
> return address manipulations.
>
> : (call) r> dup ref+ >r ref@[EMAIL PROTECTED]
 >r ;
> ( interpretation-stack: ra -> ref  -- ra ra )
> : (call) r> dup 1+ >r @[EMAIL PROTECTED]
 >r ;
>
> where interpretation stack is the return stack + ip (instruction
> pointer, the register that changes each time a primitive is executed).
> The rule of thumb is that when you call a colon definition, the
> interpretation stack state becomes the return stack state; when a
> colon definition is exited, the return stack state becomes the
> interpretation stack state.
>
> : lit ( interpretatins-stack: ra -> single -- ra )  ( -- single )
>   r@[EMAIL PROTECTED]
 @[EMAIL PROTECTED]
 r> 1+ >r ;
>
> where 1+ adds the size of a single.
>
> By the way, I would leave 1+ for arithmetic and have size+ for ptr ->
> something..
> 1+ for "one-plus", where "one" means "of that type" is a pun, but I
> would not like to have it built-in into language.
>
> By the way, what does 1+ do for a string?
>
> : slit ( interpretatins-stack: ra -> string -- ra )  ( -- string )
>   r@[EMAIL PROTECTED]
 @[EMAIL PROTECTED]
 r> size+ ALIGNED >r ;
>
> Note: ra points to run-time tokens; ra -> something points to
> something followed by run-time tokens.

What's even more interesting,
is that the *implementation* of R> ( r: ra -- )  ( -- ra )
will not be portable (it will require system knowledge,
for example, R> ABS>REL on Win32Forth and 2R> on F-PC) but the
code that *uses* return address manipulations in StrongForth
will be portable (with the dependency on that the ra support
code has been ported).


And now the non-typechecked area is the code generation.
: literal compile lit , ; IMMEDIATE
The type of LIT must be chosen based on the type of constant compiled
after it...

(The issues like "data and code are in different address spaces" are
no problem here: the system may have the type "code space pointer" and
have corresponding versions of memory access words. And if the
hardware, say, provides no access to the call stack at all,
StrongForth may report a "feature not suported by hardware" error at
compile-time. But anyway, at the moment the problem is that there's no
StrongForth for common platforms, not porting StrongForth to exotic
architectures.)