Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #37601 > unrolled thread

Decoding Roman numerals

Back to article view | Back to comp.lang.forth

Contents

  Decoding Roman numerals "WJ" <w_a_x_man@yahoo.com> - 2015-03-23 20:20 +0000
    Re: Decoding Roman numerals foxaudioresearch@gmail.com - 2015-03-25 20:01 -0700
      Re: Decoding Roman numerals hughaguilar96@gmail.com - 2015-03-29 14:21 -0700
        Re: Decoding Roman numerals foxaudioresearch@gmail.com - 2015-03-30 21:20 -0700
          Re: Decoding Roman numerals hughaguilar96@gmail.com - 2015-03-30 22:00 -0700
            Re: Decoding Roman numerals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-31 07:05 +0000
              Re: Decoding Roman numerals hughaguilar96@gmail.com - 2015-03-31 16:29 -0700
                Re: Decoding Roman numerals Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-01 11:43 +0200
                Re: Decoding Roman numerals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 10:04 +0000
                  Re: Decoding Roman numerals hughaguilar96@gmail.com - 2015-04-01 19:27 -0700
                    Re: Decoding Roman numerals "Alex McDonald" <blog@rivadpm.com> - 2015-04-02 11:39 +0100
            Re: Decoding Roman numerals foxaudioresearch@gmail.com - 2015-03-31 06:43 -0700
              Re: Decoding Roman numerals Coos Haak <chforth@hccnet.nl> - 2015-04-02 12:56 +0200
        Re: Decoding Roman numerals Hans Bezemer <the.beez.speaks@gmail.com> - 2015-04-17 09:41 +0200
          Re: Decoding Roman numerals "Alex McDonald" <blog@rivadpm.com> - 2015-04-17 11:05 +0100
          Re: Decoding Roman numerals hughaguilar96@gmail.com - 2015-04-17 09:53 -0700
            Re: Decoding Roman numerals Hans Bezemer <the.beez.speaks@gmail.com> - 2015-04-18 12:48 +0200
          Re: Decoding Roman numerals Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 02:13 +0200
            Re: Decoding Roman numerals hughaguilar96@gmail.com - 2015-04-24 13:21 -0700

#37601 — Decoding Roman numerals

Oforth:

func: char-val {| i |
  toUpper "IVXLCDM" indexOf --  -> i
  5 i 2 rem pow  10 i 2 / pow  * }

func: sign(n, prev) { n prev - ++ sgn  n * }

func: think( n, prev, total ) { prev n sign   total +   n prev max }

func: decode {
  reverse map( #char-val )
  0 0 rot apply( #think )
  drop }


  >"i" decode println
  1
  ok
  >"ii" decode println
  2
  ok
  >"iv" decode println
  4
  ok
  >"iiiiv" decode println
  1
  ok
  >"mdclxvi" decode println
  1666
  ok
  >"mm" decode println
  2000
  ok
  >"mcmxxc" decode println
  1980
  ok
  >"mcmxxciv" decode println
  1984
  ok

[toc] | [next] | [standalone]

#37664

On Monday, March 23, 2015 at 4:21:49 PM UTC-4, WJ wrote:
> Oforth:
> 
> func: char-val {| i |
>   toUpper "IVXLCDM" indexOf --  -> i
>   5 i 2 rem pow  10 i 2 / pow  * }
> 
> func: sign(n, prev) { n prev - ++ sgn  n * }
> 
> func: think( n, prev, total ) { prev n sign   total +   n prev max }
> 
> func: decode {
>   reverse map( #char-val )
>   0 0 rot apply( #think )
>   drop }
> 
><snip>

It's pretty impressive what oForth can do.  I looked at the Forth example on 
Rosetta code and I could not understand it with all the stack juggling.

I took a run at this in a crude Forth manner using factoring and my old version
of HsForth for DOS which I have harnessed up to be as standard as something that
weird could be. Forgive the non-standard word(s), they are comprehensible in context I believe.

I also discovered that some of the strings converted in the oForth example are
 illegal formats for Roman Numerals so I put in a crude test for that.

Fun.

HEX
: toUpper ( char -- char ) 05F and ;

DECIMAL

variable oldndx
variable curndx
variable negcnt

create numerals  ," IVXLCDM"
create values    0 , 1 , 5 , 10 , 50 , 100 , 500 , 1000 ,

: init     ( -- )           curndx off  oldndx off  negcnt off ;
: toindex  ( char -- indx)  toUpper numerals count rot SCAN dup 0= abort" invalid numeral" ;
: tovalue  ( ndx -- n )     cell * values + @ ;
: remember ( ndx -- ndx )   curndx @ oldndx !  dup curndx !  ;
: memory@   ( -- n1 n2 )    curndx @ oldndx @ ;
: numval   ( char -- n )    toindex remember tovalue ;
: ?illegal ( ndx --  )      memory@ =  negcnt @ and abort" illegal subtraction" ;

: negate?  ( n -- +/- n )
           memory@  <
           if   negcnt on
                negate

           else
                ?illegal
                negcnt off
           then ;

: decode   ( c-addr -- n )
           init
           0              \ accumulator on the stack
           swap
           count 1- bounds swap
           do   i c@ numval negate? +    -1 +loop ;

c" i"        decode . 1  ok
c" ii"       decode . 2  ok
c" iv"       decode . 4  ok
c" mdclxvi"  decode . 1666  ok
c" mm"       decode . 2000  ok
c" mmm"      decode . 3000  ok
c" mcmliv"   decode . 1954  ok
c" mcmxlvi"  decode . 1946  ok
c" md"       decode . 1500  ok
c" mdc"      decode . 1600  ok
c" mdcl"     decode . 1650  ok
c" mdclxvi"  decode . 1666  ok
c" mcmlxxxiv" decode . 1984  ok

c" iiiiv"    decode .
             ^^^^^^
illegal subtraction

c" mcmxxc"   decode .
             ^^^^^^
illegal subtraction

c" mcmxxciv" decode .
             ^^^^^^
illegal subtraction

[toc] | [prev] | [next] | [standalone]

#37740

On Wednesday, March 25, 2015 at 8:01:42 PM UTC-7, foxaudio...@gmail.com wrote:
> On Monday, March 23, 2015 at 4:21:49 PM UTC-4, WJ wrote:
> > Oforth:
> > 
> > func: char-val {| i |
> >   toUpper "IVXLCDM" indexOf --  -> i
> >   5 i 2 rem pow  10 i 2 / pow  * }
> > 
> > func: sign(n, prev) { n prev - ++ sgn  n * }
> > 
> > func: think( n, prev, total ) { prev n sign   total +   n prev max }
> > 
> > func: decode {
> >   reverse map( #char-val )
> >   0 0 rot apply( #think )
> >   drop }
> > 
> ><snip>
> 
> It's pretty impressive what oForth can do.  I looked at the Forth example on 
> Rosetta code and I could not understand it with all the stack juggling.
> 
> I took a run at this in a crude Forth manner using factoring and my old version
> of HsForth for DOS which I have harnessed up to be as standard as something that
> weird could be. Forgive the non-standard word(s), they are comprehensible in context I believe.
> 
> I also discovered that some of the strings converted in the oForth example are
>  illegal formats for Roman Numerals so I put in a crude test for that.
> 
> Fun.
> 
> HEX
> : toUpper ( char -- char ) 05F and ;
> 
> DECIMAL
> 
> variable oldndx
> variable curndx
> variable negcnt
> 
> create numerals  ," IVXLCDM"
> create values    0 , 1 , 5 , 10 , 50 , 100 , 500 , 1000 ,
> 
> : init     ( -- )           curndx off  oldndx off  negcnt off ;
> : toindex  ( char -- indx)  toUpper numerals count rot SCAN dup 0= abort" invalid numeral" ;
> : tovalue  ( ndx -- n )     cell * values + @ ;
> : remember ( ndx -- ndx )   curndx @ oldndx !  dup curndx !  ;
> : memory@   ( -- n1 n2 )    curndx @ oldndx @ ;
> : numval   ( char -- n )    toindex remember tovalue ;
> : ?illegal ( ndx --  )      memory@ =  negcnt @ and abort" illegal subtraction" ;
> 
> : negate?  ( n -- +/- n )
>            memory@  <
>            if   negcnt on
>                 negate
> 
>            else
>                 ?illegal
>                 negcnt off
>            then ;
> 
> : decode   ( c-addr -- n )
>            init
>            0              \ accumulator on the stack
>            swap
>            count 1- bounds swap
>            do   i c@ numval negate? +    -1 +loop ;
> 
> c" i"        decode . 1  ok
> c" ii"       decode . 2  ok
> c" iv"       decode . 4  ok
> c" mdclxvi"  decode . 1666  ok
> c" mm"       decode . 2000  ok
> c" mmm"      decode . 3000  ok
> c" mcmliv"   decode . 1954  ok
> c" mcmxlvi"  decode . 1946  ok
> c" md"       decode . 1500  ok
> c" mdc"      decode . 1600  ok
> c" mdcl"     decode . 1650  ok
> c" mdclxvi"  decode . 1666  ok
> c" mcmlxxxiv" decode . 1984  ok
> 
> c" iiiiv"    decode .
>              ^^^^^^
> illegal subtraction
> 
> c" mcmxxc"   decode .
>              ^^^^^^
> illegal subtraction
> 
> c" mcmxxciv" decode .
>              ^^^^^^
> illegal subtraction

The other Forth example used DOES> in interpretive mode, which is not ANS-Forth. I don't know of any Forth that does allow this. Also, it is totally pointless --- why not just define the array as <ARABIC> and then write the function (ARABIC) that explicitly works with that array?

I looked over your code and I found these words that are not ANS-Forth:
."
ON
OFF
SCAN

I already have the first three in my novice-package. I don't know what SCAN does, but I can pretty much guess (I think UR/Forth had SCAN, but I don't recall for sure) --- if you explain this one to me exactly, I could put it in my next release of the novice-package --- then you could be ANS-Forth, although you would have to specify that the novice-package is required (as I did in my own RosettaCode programs).

BTW: Some comments as to what your variables are for would help the reader.

[toc] | [prev] | [next] | [standalone]

#37770

On Sunday, March 29, 2015 at 5:21:55 PM UTC-4, hughag...@gmail.com wrote:
> On Wednesday, March 25, 2015 at 8:01:42 PM UTC-7, foxaudio...@gmail.com wrote:
> > On Monday, March 23, 2015 at 4:21:49 PM UTC-4, WJ wrote:
> > > Oforth:
> > > 
> > > func: char-val {| i |
> > >   toUpper "IVXLCDM" indexOf --  -> i
> > >   5 i 2 rem pow  10 i 2 / pow  * }
> > > 
> > > func: sign(n, prev) { n prev - ++ sgn  n * }
> > > 
> > > func: think( n, prev, total ) { prev n sign   total +   n prev max }
> > > 
> > > func: decode {
> > >   reverse map( #char-val )
> > >   0 0 rot apply( #think )
> > >   drop }
> > > 
> > ><snip>
> > 
> > It's pretty impressive what oForth can do.  I looked at the Forth example on 
> > Rosetta code and I could not understand it with all the stack juggling.
> > 
> > I took a run at this in a crude Forth manner using factoring and my old version
> > of HsForth for DOS which I have harnessed up to be as standard as something that
> > weird could be. Forgive the non-standard word(s), they are comprehensible in context I believe.
> > 
> > I also discovered that some of the strings converted in the oForth example are
> >  illegal formats for Roman Numerals so I put in a crude test for that.
> > 
> > Fun.
> > 
> > HEX
> > : toUpper ( char -- char ) 05F and ;
> > 
> > DECIMAL
> > 
> > variable oldndx
> > variable curndx
> > variable negcnt
> > 
> > create numerals  ," IVXLCDM"
> > create values    0 , 1 , 5 , 10 , 50 , 100 , 500 , 1000 ,
> > 
> > : init     ( -- )           curndx off  oldndx off  negcnt off ;
> > : toindex  ( char -- indx)  toUpper numerals count rot SCAN dup 0= abort" invalid numeral" ;
> > : tovalue  ( ndx -- n )     cell * values + @ ;
> > : remember ( ndx -- ndx )   curndx @ oldndx !  dup curndx !  ;
> > : memory@   ( -- n1 n2 )    curndx @ oldndx @ ;
> > : numval   ( char -- n )    toindex remember tovalue ;
> > : ?illegal ( ndx --  )      memory@ =  negcnt @ and abort" illegal subtraction" ;
> > 
> > : negate?  ( n -- +/- n )
> >            memory@  <
> >            if   negcnt on
> >                 negate
> > 
> >            else
> >                 ?illegal
> >                 negcnt off
> >            then ;
> > 
> > : decode   ( c-addr -- n )
> >            init
> >            0              \ accumulator on the stack
> >            swap
> >            count 1- bounds swap
> >            do   i c@ numval negate? +    -1 +loop ;
> > 
> > c" i"        decode . 1  ok
> > c" ii"       decode . 2  ok
> > c" iv"       decode . 4  ok
> > c" mdclxvi"  decode . 1666  ok
> > c" mm"       decode . 2000  ok
> > c" mmm"      decode . 3000  ok
> > c" mcmliv"   decode . 1954  ok
> > c" mcmxlvi"  decode . 1946  ok
> > c" md"       decode . 1500  ok
> > c" mdc"      decode . 1600  ok
> > c" mdcl"     decode . 1650  ok
> > c" mdclxvi"  decode . 1666  ok
> > c" mcmlxxxiv" decode . 1984  ok
> > 
> > c" iiiiv"    decode .
> >              ^^^^^^
> > illegal subtraction
> > 
> > c" mcmxxc"   decode .
> >              ^^^^^^
> > illegal subtraction
> > 
> > c" mcmxxciv" decode .
> >              ^^^^^^
> > illegal subtraction
> 
> The other Forth example used DOES> in interpretive mode, which is not ANS-Forth. I don't know of any Forth that does allow this. Also, it is totally pointless --- why not just define the array as <ARABIC> and then write the function (ARABIC) that explicitly works with that array?
> 
> I looked over your code and I found these words that are not ANS-Forth:
> ."
> ON
> OFF
> SCAN
> 
> I already have the first three in my novice-package. I don't know what SCAN does, but I can pretty much guess (I think UR/Forth had SCAN, but I don't recall for sure) --- if you explain this one to me exactly, I could put it in my next release of the novice-package --- then you could be ANS-Forth, although you would have to specify that the novice-package is required (as I did in my own RosettaCode programs).
> 
> BTW: Some comments as to what your variables are for would help the reader.

SCAN comes from the tool belt of Neil Bawd.  Although it is normally coded in assembler here the high level definition.

: SCAN           ( str len char -- str+i len-i )
    >R  BEGIN  DUP WHILE  OVER C@ R@ -
        WHILE  1 /STRING  REPEAT THEN
    R> DROP ;

The entire body of work can be found here:
http://forth.sourceforge.net/mirror/toolbelt-ext/index.html

It really is some excellent Forth.

Some comments to add for the variables:

variable oldndx  \ the index of the numeral on the previous scan
variable curndx  \ the index of the numeral on this current scan
variable negcnt  \ a flag to store if we did a subtraction on the last scan

I didn't know it was in the toolbelt, but an ISO/ANS version of ," is also on source forge.


: PLACE               ( str len addr -- )
    2DUP 2>R  1+  SWAP  MOVE  2R> C! ;

: STRING,             ( str len -- )
    HERE  OVER 1+  ALLOT  PLACE ;

: ," [CHAR] " PARSE  STRING, ; IMMEDIATE


Thanks for the comments Hugh.

BF

[toc] | [prev] | [next] | [standalone]

#37771

On Monday, March 30, 2015 at 9:20:20 PM UTC-7, foxaudio...@gmail.com wrote:
> I didn't know it was in the toolbelt, but an ISO/ANS version of ," is also on source forge.
> 
> : PLACE               ( str len addr -- )
>     2DUP 2>R  1+  SWAP  MOVE  2R> C! ;
> 
> : STRING,             ( str len -- )
>     HERE  OVER 1+  ALLOT  PLACE ;
> 
> : ," [CHAR] " PARSE  STRING, ; IMMEDIATE

Why is ," immediate?

BTW: There is a weirdity in Gforth that prevents this from working:

: ,"  postpone s"  string, ;

[toc] | [prev] | [next] | [standalone]

#37772

hughaguilar96@gmail.com writes:
>BTW: There is a weirdity in Gforth that prevents this from working:
>
>: ,"  postpone s"  string, ;

POSTPONE S" gives you the compilation semantics of S".  I think you
want the interpretation semantics here.  That would be:

: ," ['] S" execute string, ;

But why not just use

: ," '"' parse string, ;

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#37790

On Tuesday, March 31, 2015 at 12:07:24 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >BTW: There is a weirdity in Gforth that prevents this from working:
> >
> >: ,"  postpone s"  string, ;
> 
> POSTPONE S" gives you the compilation semantics of S".  I think you
> want the interpretation semantics here.  That would be:
> 
> : ," ['] S" execute string, ;
> 
> But why not just use
> 
> : ," '"' parse string, ;

Perhaps later, a doctor with a flashlight can show us where the interpretation semantics for S" come from.

According to the ANS-Forth document (6.1.2165):
"Interpretation semantics for this word are undefined."

[toc] | [prev] | [next] | [standalone]

#37801

hughaguilar96@gmail.com writes:
> Perhaps later, a doctor with a flashlight can show us where the
> interpretation semantics for S" come from.

I'm not a doctor, but I can point you to the File-Acces wrod set, in
particular 11.6.1.2165.

[toc] | [prev] | [next] | [standalone]

#37802

hughaguilar96@gmail.com writes:
>Perhaps later, a doctor with a flashlight can show us where the interpretation semantics for S" come from.
>
>According to the ANS-Forth document (6.1.2165):
>"Interpretation semantics for this word are undefined."

|11.6.1.2165 S" s-quote FILE
|
|Extend the semantics of 6.1.2165 S" to be:
|
|Interpretation: ( "ccc<quote>" -- c-addr u )
|
|Parse ccc delimited by " (double quote). Store the resulting string
|c-addr u at a temporary location. The maximum length of the temporary
|buffer is implementation-dependent but shall be no less than 80
|characters. Subsequent uses of S" may overwrite the temporary
|buffer. At least one such buffer shall be provided.

Hmm, if you were unaware of the interpretation semantics, what did you
expect

: ,"  postpone s"  string, ;

to do?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#37826

On Wednesday, April 1, 2015 at 3:31:09 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >Perhaps later, a doctor with a flashlight can show us where the interpretation semantics for S" come from.
> >
> >According to the ANS-Forth document (6.1.2165):
> >"Interpretation semantics for this word are undefined."
> 
> |11.6.1.2165 S" s-quote FILE
> |
> |Extend the semantics of 6.1.2165 S" to be:
> |
> |Interpretation: ( "ccc<quote>" -- c-addr u )
> |
> |Parse ccc delimited by " (double quote). Store the resulting string
> |c-addr u at a temporary location. The maximum length of the temporary
> |buffer is implementation-dependent but shall be no less than 80
> |characters. Subsequent uses of S" may overwrite the temporary
> |buffer. At least one such buffer shall be provided.
> 
> Hmm, if you were unaware of the interpretation semantics, what did you
> expect
> 
> : ,"  postpone s"  string, ;
> 
> to do?

I tried that originally, but it didn't work, and so I read the ANS-Forth document and found that it is not supposed to work.

I later on rewrote S" and C" so that they will work correctly --- in the REPL, in a file, or in a colon word --- and there can be multiple ones in use simultaneously.

I noticed that Stephen Pelc also rewrote them so they will work correctly --- the difference is that he doesn't provide the source-code, and it is most likely not ANS-Forth --- by comparison, everything in the novice-package is ANS-Forth open-source.

VFX contains a lot of work-arounds for the bugs in ANS-Forth design, but most of this is proprietary code --- I think Pelc is okay with ANS-Forth being bug-ridden, because he hopes to achieve vendor lock-in by providing proprietary work-arounds that the users get hooked on using --- now he's on the Forth-200x committee, and he is letting Forth Inc. run the show, presumably with the same plan for MPE this time as last time.

Why didn't ANS-Forth define S" and C" correctly in 1994? Is it possible that our self-proclaimed "leading expert" doesn't know what a circular-buffer is? Could this be the same reason why PAD was put in ANS-Forth? Am I the only Forther who thinks that this makes the Forth community look dumb? 

I'll shine a spotlight on the dumb part:
"Subsequent uses of S" may overwrite the temporary buffer. At least one such buffer shall be provided."

[toc] | [prev] | [next] | [standalone]

#37832

on 02/04/2015 03:27:21, hugh & his alter-ego wrote:
> I noticed that Stephen Pelc also rewrote them so they will work correctly -
> -- the difference is that he doesn't provide the source-code, and it is mos
> t likely not ANS-Forth --- by comparison, everything in the novice-package 
> is ANS-Forth open-source.

> VFX contains a lot of work-arounds for the bugs in ANS-Forth design,
> but mo st of this is proprietary code --- I think Pelc is okay with
> ANS-Forth bein g bug-ridden, because he hopes to achieve vendor
> lock-in by providing propr ietary work-arounds that the users get
> hooked on using --- now he's on the Forth-200x committee, and he is
> letting Forth Inc. run the show, presumably with the same plan for MPE
> this time as last time.

I'm beginning to wonder if you're actually two people that tag-team the
same email account. First it's the commies making your life a misery with
their free software, now it's the capitalists when they lock you up to
their standard's based Ponzi schemes. I'm adding economics to the list of
subjects the two of you don't have a clue about.

[toc] | [prev] | [next] | [standalone]

#37776

On Tuesday, March 31, 2015 at 1:00:03 AM UTC-4, hughag...@gmail.com wrote:
> On Monday, March 30, 2015 at 9:20:20 PM UTC-7, foxaudio...@gmail.com wrote:
> > I didn't know it was in the toolbelt, but an ISO/ANS version of ," is also on source forge.
> > 
> > : PLACE               ( str len addr -- )
> >     2DUP 2>R  1+  SWAP  MOVE  2R> C! ;
> > 
> > : STRING,             ( str len -- )
> >     HERE  OVER 1+  ALLOT  PLACE ;
> > 
> > : ," [CHAR] " PARSE  STRING, ; IMMEDIATE
> 
> Why is ," immediate?
> 
> BTW: There is a weirdity in Gforth that prevents this from working:
> 
> : ,"  postpone s"  string, ;

Well that's what I get for copying code from a web site.
I saw your questions late and was at a computer that didn't have my code on it.
So of course there is no reason to have ," be immediate in this context.

Here in fact is the code in my old "almost ISO/ANS" DOS system:

: ,"   ( -- )  [char] " word C@ 1+ allot ;

This definition is used in immediate mode only (interpreted)

It seems to me that the Neil Bawd version is meant to be used inside a colon definition and so is immediate and uses PLACE to compile the string into memory.

Apology for the confusion.  

BF

[toc] | [prev] | [next] | [standalone]

#37835

Op Tue, 31 Mar 2015 06:43:39 -0700 (PDT) schreef
foxaudioresearch@gmail.com:

> On Tuesday, March 31, 2015 at 1:00:03 AM UTC-4, hughag...@gmail.com wrote:
>> On Monday, March 30, 2015 at 9:20:20 PM UTC-7, foxaudio...@gmail.com wrote:
>>> I didn't know it was in the toolbelt, but an ISO/ANS version of ," is also on source forge.
>>> 
>>> : PLACE               ( str len addr -- )
>>>     2DUP 2>R  1+  SWAP  MOVE  2R> C! ;
>>> 
>>> : STRING,             ( str len -- )
>>>     HERE  OVER 1+  ALLOT  PLACE ;
>>> 
>>> : ," [CHAR] " PARSE  STRING, ; IMMEDIATE
>> 
>> Why is ," immediate?
>> 
>> BTW: There is a weirdity in Gforth that prevents this from working:
>> 
>>: ,"  postpone s"  string, ;
> 
> Well that's what I get for copying code from a web site.
> I saw your questions late and was at a computer that didn't have my code on it.
> So of course there is no reason to have ," be immediate in this context.
> 
> Here in fact is the code in my old "almost ISO/ANS" DOS system:
> 
>: ,"   ( -- )  [char] " word C@ 1+ allot ;
> 
> This definition is used in immediate mode only (interpreted)
> 
> It seems to me that the Neil Bawd version is meant to be used inside a colon definition and so is immediate and uses PLACE to compile the string into memory.
> 
> Apology for the confusion.  
> 
> BF

I've looked a some more implementations, but all have non-immediate
versions: F83 F-PC SwiftForth Win32Forth Gforth.
A usage of ," is inside definitions like ." that are immediate.
It would be a nuisance to write every time <postpone ,"> instead of
simply <,"> .

I suppose that this is a misprint at the page of Neal Bawd.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

#38258

hughaguilar96@gmail.com wrote:
> The other Forth example used DOES> in interpretive mode, which is not
> ANS-Forth. I don't know of any Forth that does allow this. 
Like gForth?

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#38263

on 17/04/2015 08:41:42, Hans Bezemer wrote:
> hughaguilar96@gmail.com wrote:
>> The other Forth example used DOES> in interpretive mode, which is not
>> ANS-Forth. I don't know of any Forth that does allow this.
> Like gForth?
> 
> Hans Bezemer
> 

Mine does too, and I believe iForth allows this as well (but that's from
memory so check).

[toc] | [prev] | [next] | [standalone]

#38283

On Friday, April 17, 2015 at 12:42:32 AM UTC-7, The Beez wrote:
> hughaguilar96@gmail.com wrote:
> > The other Forth example used DOES> in interpretive mode, which is not
> > ANS-Forth. I don't know of any Forth that does allow this. 
> Like gForth?
> 
> Hans Bezemer

Well, I never did RTFM the gForth manual. Stephen Pelc has also criticized me several times for not RTFMing the VFX manual. I didn't RTFM the iForth manual either --- I have no interest in iForth after my experience with Marcel Hendrix posting my encryption-cracking program on comp.lang.forth with my name removed from the copyright notice.

So, what exactly did the ANS-Forth standard accomplish? Nothing was standardized! All of the ANS-Forth compliant compilers do whatever they want to do, but not all in the same way --- being ANS-Forth compliant mostly involves brown-nosing Elizabeth Rather --- she says who is ANS-Forth compliant and who isn't.

And, if the ANS-Forth standard didn't standardize, then why is the chairperson of the ANS-Forth committee considered to be anything except a failure?

With my novice-package I am one of only a very few people who have written non-trivial code that is ANS-Forth and works on multiple ANS-Forth compilers --- but, ironically, Elizabeth Rather says that I'm not an ANS-Forth programmer and never will be.

[toc] | [prev] | [next] | [standalone]

#38334

hughaguilar96@gmail.com wrote:
> Well, I never did RTFM the gForth manual. Stephen Pelc has also criticized
> me several times for not RTFMing the VFX manual. I didn't RTFM the iForth
> manual either --- I have no interest in iForth after my experience with
> Marcel Hendrix posting my encryption-cracking program on comp.lang.forth
> with my name removed from the copyright notice.
Well, you should if you want to pose the statement "I don't know of any
Forth that does allow this", which at least IMPLIES you know your Forth's.
 
> So, what exactly did the ANS-Forth standard accomplish? Nothing was
> standardized! All of the ANS-Forth compliant compilers do whatever they
> want to do, but not all in the same way --- being ANS-Forth compliant
> mostly involves brown-nosing Elizabeth Rather --- she says who is
> ANS-Forth compliant and who isn't.
I'm not the greatest fan of ANS-Forth, since it is a SYSTEM standard and not
a language standard. BUT - having that said - it standardized something
more and in a better way than the abysmal Forth-83 did. It allows me:

- to write words with standardized behavior which will work as advertised
and can be considered "black boxes" when used;
- to interpret (as a programmer, not a compiler) a well written Forth
program, see what words sets are required to make it behave as advertised;
- to write well behaved Forth programs on my own compiler, knowing they will
work on well behaved Forth compilers;
- to make my own compiler as well behaved as possible and to document the
places where it doesn't.

I think that's great. It's that that Wil Baden tried to make me understand
and I see his point now - after years of reaping the benefits.

> With my novice-package I am one of only a very few people who have written
> non-trivial code that is ANS-Forth and works on multiple ANS-Forth
> compilers --- but, ironically, Elizabeth Rather says that I'm not an
> ANS-Forth programmer and never will be.
I don't think there aren't loads of non-trivial code out there - but that is
open to discussion, given we don't have a common definition of
what "non-trivial" is. E.g. I've been using Brad Eckerts FLOAT library for
year - with great pleasure. Shame he doesn't want to do anything with it
nowadays, because it's pretty neat. I've been using Ed's ANS libraries.
I've been using Zen float for years - and extended it significantly. On the
other hand, I've supplied FSL libs as well - and used some of it myself.
I've ported several FFL libs.

But obviously, it's all "non-trivial" and "badly written" and NOVICE is the
best thing since sliced bread. BTW, I wouldn't be too worried what anyone
says or thinks of you. It doesn't change what you are.

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#38468

Hans Bezemer wrote:

> hughaguilar96@gmail.com wrote:
>> The other Forth example used DOES> in interpretive mode, which is not
>> ANS-Forth. I don't know of any Forth that does allow this.
> Like gForth?

Well, you know a Forth that does this.  Hugh is entitled to be an idiot, and 
he always brags about his lack of knowledge, as if not knowing something was 
an achievement ;-).  Something like the Alzheimer way to enlightenment or 
so.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38582

On Tuesday, April 21, 2015 at 5:13:25 PM UTC-7, Bernd Paysan wrote:
> Hans Bezemer wrote:
> 
> > hughaguilar96@gmail.com wrote:
> >> The other Forth example used DOES> in interpretive mode, which is not
> >> ANS-Forth. I don't know of any Forth that does allow this.
> > Like gForth?
> 
> Well, you know a Forth that does this.  Hugh is entitled to be an idiot, and 
> he always brags about his lack of knowledge, as if not knowing something was 
> an achievement ;-).  Something like the Alzheimer way to enlightenment or 
> so.

Why am I an idiot because I don't know about the non-standard quirks of gForth? Why are the readers of RosettaCode expected to know about the non-standard quirks of gForth? Why are they expected to know that the Forth code shown is gForth rather than ANS-Forth, when there is no comment indicating which Forth it was written in?

I think that you are over-stating the importance of gForth --- gForth is useless because it is written in C and hence is abysmally slow --- gForth is not important; it has never been used for writing commercial software and it never will be.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web