Talk About Network



Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Forth > Re: Type checki...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 49 of 71 Topic 3977 of 4053
Post > Topic >>

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

by "Stephan Becher" <stephan.remove-this.becher@[EMAIL PROTECTED] > Apr 10, 2008 at 06:53 PM

"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.




 71 Posts in Topic:
The strengths of FORTH
"Robert Miller"  2008-03-27 15:01:14 
Re: The strengths of FORTH
Jonah Thomas <jethomas  2008-03-27 18:47:44 
Re: The strengths of FORTH
Bruce McFarling <agila  2008-03-27 18:46:42 
Re: The strengths of FORTH
Bruce McFarling <agila  2008-03-28 09:30:44 
Re: The strengths of FORTH
mhx@[EMAIL PROTECTED] (M  2008-03-28 19:21:30 
Re: The strengths of FORTH
Bruce McFarling <agila  2008-03-28 12:06:51 
Re: The strengths of FORTH
"Paul E. Bennett&quo  2008-03-27 23:21:10 
Re: The strengths of FORTH
Brad Eckert <nospaambr  2008-03-27 19:03:48 
Re: The strengths of FORTH
Jonah Thomas <jethomas  2008-03-27 22:15:25 
Re: The strengths of FORTH
Benny Andersen <a.mail  2008-03-28 09:59:05 
Re: The strengths of FORTH
"dkelvey@[EMAIL PROT  2008-03-28 07:50:09 
Re: The strengths of FORTH
John Doty <jpd@[EMAIL   2008-03-28 09:25:07 
Type checking (was: The strengths of FORTH)
anton@[EMAIL PROTECTED]   2008-03-28 20:33:46 
Re: The strengths of FORTH
Bruce McFarling <agila  2008-03-28 09:42:22 
Re: The strengths of FORTH
Reinhold Straub <demar  2008-03-29 04:48:43 
Re: The strengths of FORTH
William James <w_a_x_m  2008-03-29 12:00:12 
Re: The strengths of FORTH
Reinhold Straub <demar  2008-03-30 05:59:03 
Re: Type checking (was: The strengths of FORTH)
m_l_g3@[EMAIL PROTECTED]   2008-04-02 01:04:50 
Re: Type checking (was: The strengths of FORTH)
"Stephan Becher"  2008-04-07 09:46:32 
Re: Type checking
"David N. Williams&q  2008-04-07 12:20:20 
Re: Type checking
"Stephan Becher"  2008-04-07 17:30:08 
Re: Type checking (was: The strengths of FORTH)
Trey Boudreau <trey@[E  2008-04-07 10:07:45 
Re: Type checking (was: The strengths of FORTH)
Bernd Paysan <bernd.pa  2008-04-07 18:32:48 
Re: Type checking (was: The strengths of FORTH)
Trey Boudreau <trey@[E  2008-04-07 16:46:00 
Re: Type checking (was: The strengths of FORTH)
"Stephan Becher"  2008-04-08 08:01:23 
Re: Type checking (was: The strengths of FORTH)
Bernd Paysan <bernd.pa  2008-04-08 10:16:55 
Re: Type checking (was: The strengths of FORTH)
kenney@[EMAIL PROTECTED]   2008-04-09 06:17:26 
Re: Type checking (was: The strengths of FORTH)
Bruce McFarling <agila  2008-04-09 07:39:32 
Re: Type checking (was: The strengths of FORTH)
"Mark W. Humphries&q  2008-04-09 09:08:39 
Re: Type checking (was: The strengths of FORTH)
Bernd Paysan <bernd.pa  2008-04-09 18:26:48 
Re: Type checking (was: The strengths of FORTH)
Doug Hoffman <no.spam&  2008-04-09 17:07:45 
Re: Type checking (was: The strengths of FORTH)
Albert van der Horst <  2008-04-10 03:49:42 
Re: Type checking (was: The strengths of FORTH)
Doug Hoffman <no.spam&  2008-04-10 06:01:45 
Re: Type checking (was: The strengths of FORTH)
Albert van der Horst <  2008-04-10 21:47:04 
Re: Type checking (was: The strengths of FORTH)
Bruce McFarling <agila  2008-04-09 09:19:33 
Re: Type checking (was: The strengths of FORTH)
John Doty <jpd@[EMAIL   2008-05-01 21:35:15 
Re: Type checking (was: The strengths of FORTH)
m_l_g3 <m_l_g3@[EMAIL   2008-04-17 17:27:21 
Re: Type checking (was: The strengths of FORTH)
anton@[EMAIL PROTECTED]   2008-04-08 14:14:30 
Re: Type checking (was: The strengths of FORTH)
Bruce McFarling <agila  2008-04-08 07:18:34 
Re: Type checking (was: The strengths of FORTH)
"Stephan Becher"  2008-04-09 08:49:44 
Re: Type checking (was: The strengths of FORTH)
Bruce McFarling <agila  2008-04-08 07:29:56 
Re: Type checking (was: The strengths of FORTH)
Bruce McFarling <agila  2008-04-09 07:37:06 
Re: Type checking (was: The strengths of FORTH)
"Stephan Becher"  2008-04-10 08:04:57 
Re: Type checking (was: The strengths of FORTH)
m_l_g3 <m_l_g3@[EMAIL   2008-04-09 17:48:14 
Re: Type checking (was: The strengths of FORTH)
"Stephan Becher"  2008-04-10 07:54:14 
Re: Type checking (was: The strengths of FORTH)
Albert van der Horst <  2008-04-10 21:27:21 
Re: Type checking (was: The strengths of FORTH)
Bruce McFarling <agila  2008-04-10 03:30:01 
Re: Type checking (was: The strengths of FORTH)
m_l_g3 <m_l_g3@[EMAIL   2008-04-10 04:16:59 
Re: Type checking (was: The strengths of FORTH)
"Stephan Becher"  2008-04-10 18:53:37 
Re: Type checking (was: The strengths of FORTH)
m_l_g3 <m_l_g3@[EMAIL   2008-04-10 04:48:57 
Re: Type checking (was: The strengths of FORTH)
m_l_g3 <m_l_g3@[EMAIL   2008-04-11 05:02:01 
Re: Type checking (was: The strengths of FORTH)
Bruce McFarling <agila  2008-04-11 08:37:46 
Re: The strengths of FORTH
Mikael Nordman <oh2aun  2008-03-28 19:41:15 
Re: The strengths of FORTH
Albert van der Horst <  2008-03-28 22:26:26 
Re: The strengths of FORTH
"Robert Miller"  2008-03-29 00:19:04 
Re: The strengths of FORTH
Mikael Nordman <oh2aun  2008-03-29 09:56:25 
Re: The strengths of FORTH
Aleksej Saushev <asau@  2008-04-01 23:35:18 
Re: The strengths of FORTH
Mikael Nordman <oh2aun  2008-04-02 18:39:30 
Re: The strengths of FORTH
Aleksej Saushev <asau@  2008-04-06 18:48:28 
Re: The strengths of FORTH
Brad Eckert <nospaambr  2008-04-04 09:29:12 
Re: The strengths of FORTH / OT: SMT soldering
"Robert Miller"  2008-04-04 15:28:47 
Re: The strengths of FORTH / OT: SMT soldering
John Doty <jpd@[EMAIL   2008-04-04 13:51:24 
Re: The strengths of FORTH / OT: SMT soldering
Brad Eckert <nospaambr  2008-04-04 16:46:08 
Re: The strengths of FORTH
William James <w_a_x_m  2008-03-29 11:42:17 
Re: The strengths of FORTH
"Robert Miller"  2008-03-29 17:56:46 
Re: The strengths of FORTH
Andrew Haley <andrew29  2008-03-30 10:03:42 
Re: The strengths of FORTH
Albert van der Horst <  2008-03-30 15:10:11 
Re: The strengths of FORTH
Guy Macon <http://www.  2008-03-30 09:54:09 
Re: The strengths of FORTH
Jonah Thomas <jethomas  2008-03-30 09:59:30 
Re: The strengths of FORTH / OT: SMT soldering
spam@[EMAIL PROTECTED]   2008-04-05 13:49:18 
Re: Type checking (was: The strengths of FORTH)
Jonah Thomas <jethomas  2008-04-08 07:22:41 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Fri May 16 2:04:53 CDT 2008.