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

On Apr 10, 9:54 am, "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
> wrote:
> "m_l_g3" <m_l...@[EMAIL PROTECTED]
> schrieb im
Newsbeitragnews:b6409894-74ed-4089-a21a-3451cd458581@[EMAIL PROTECTED]
>
On Apr 8, 3:22 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> >> "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
> wrote:
> >> > "Bernd Paysan" <bernd.pay...@[EMAIL PROTECTED]
> schrieb
>
> ...
>
> >> > Furthermore, some words like ?DUP and FIND are simply incompatible
> >> > with strong static type checking, because their stack effects are
not
> >> > known at compile time.
>
> > In fact, ?DUP has the stack effect ( x -- x/xx ), and
> > IF can be described as ( x/xx -- x ; no jump ) ( x/xx -- ; jump )
> > so ?DUP IF would work...
>
> Yes. In the utilities of StrongForth 1.3, three words are provided that
> implement the semantics of
> ?DUP IF, ?DUP WHILE and ?DUP UNTIL. They are called ?IF, ?WHILE and
> ?UNTIL, respectively.
>

Probably, it is Forth that should have ?IF ?WHILE ?UNTIL...

> > Another awful ANS Forth data type is ( xn ... x1 n ), but it also can
> > be resolved.
> > IIRC, pointers are parametrized with the data type they point to;
> > the same thing may be dome for { x }*n.
>
> That's indeed an awful data type. In order to be able to include
SAVE-INPUT,
> RESTORE-INPUT,
> GET-ORDER and SET-ORDER (which all use this data type), I added a
special
> data type called
> TUPLE that covers a variable number of cells. It is usually used in a
> qualified form like TUPLE -> WID. Operations on TUPLE are NULL TUPLE
(create
> an empty tuple), >T (add a cell), T> (remove a cell), SIZE and DROP.
This is
> sufficent to implement the above mentioned words and it works very well.
The
> only yet unresolved issue is that CATCH cannot be applied to words whose
> stack diagrams contain a tuple, because the size of the tuple cannot be
> evaluated at compile time.

Can you please explain?
In Forth, CATCH is done via SP@[EMAIL PROTECTED]
 .. SP! and RP@[EMAIL PROTECTED]
 ... RP!

I do not see any problems with a TUPLE, provided that it is a whole
TUPLE.

The nature of CATCH requires that the values before SP@[EMAIL PROTECTED]
 can be only
read, but not changed or removed. Do you restrict access rights?


=====

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.