"m_l_g3" <m_l_g3@[EMAIL PROTECTED]
> schrieb im Newsbeitrag
news:6cd0431b-5ff2-45e6-b4cd-9d48acd679cc@[EMAIL PROTECTED]
> On Apr 10, 9:54 am, "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
> online.de> 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:
>> > 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?
StrongForth's version of CATCH is slightly different from the ANS Forth
specification. In ANS Forth, the stack pointer remains unchanged if CATCH
fails. In StrongForth, data type consistency requires that the stack
pointer
has the same value after a successful return and after an exception. This
means that the compiler has to calculate the value of the stack pointer
before the runtime code of CATCH is compiled. But this is impossible if
the
stack diagram of the catched word contains a tuple in its input or output
parameter list. Solving this problem would be possible by implementing a
very clever runtime code for CATCH, bit I don't think the effort pays off.
> =====
>
> One more nice feature of the StrongForth is that it can cope with
> return address manipulations.
I don't think I understand what you mean by that. StrongForth does not
encourage return stack manipulations. The examples you provide below are
all
implemented as code definitions. Since StrongForth does not have separate
data type heaps for the return stack, it cannot determine the data type of
an item on the return stack. R@[EMAIL PROTECTED]
is actually implemented as a local that is
created by >R and removed by R>, because locals can have data types.
> : (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.
Address arithmetic in StrongForth involves 1+, 1-, +, -, +! (LOOP) and
(+LOOP). I took over this feature from C because I like it very much. 1+
means "next", no matter whether you deal with integers, character
addresses,
cell addresses or double cell addresses. For a Forth programmer this might
look strange, but for a C programmer I'm sure it is quite natural.
> By the way, what does 1+ do for a string?
StrongForth does not have a data type for counted strings. In fact, there
are no words that directly operate with counted strings. Strings are
always
represented in the address-and-count format, which has the data type
representation CDATA -> CHARACTER UNSIGNED.
> : 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.


|