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

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

1 /STRING vs SNIP

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

Contents

  1 /STRING vs SNIP foxaudioresearch@gmail.com - 2016-10-18 19:31 -0700
    Re: 1 /STRING vs SNIP Ron Aaron <rambamist@gmail.com> - 2016-10-19 07:24 +0300
    Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-19 07:52 +0000
      Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-19 16:58 -0700
        Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-21 16:01 +1000
          Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-21 00:51 -0700
            Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-21 00:57 -0700
          Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 05:20 -0700
            Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-22 00:25 +1000
              Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 09:13 -0700
                Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-21 16:24 +0000
                  Re: 1 /STRING vs SNIP albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-21 20:06 +0200
                    Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 14:19 -0700
                    Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-22 13:46 +1000
                    Re: 1 /STRING vs SNIP stephen@mpeforth.com (Stephen Pelc) - 2016-10-22 11:34 +0000
                      Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-22 13:49 +0000
                        Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-24 11:15 +1000
                          Re: 1 /STRING vs SNIP albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-24 03:01 +0200
                            Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-24 13:29 +1000
                          Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-24 11:15 +0000
                            Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-24 19:44 -0700
                            Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-29 11:17 +1000
                              Re: 1 /STRING vs SNIP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-29 04:09 -0500
                              Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-29 16:44 +0000
                                Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-29 17:11 -0700
                                Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-31 19:11 +1100
                                  Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 08:47 +0000
        Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 03:49 -0700
          Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-22 20:02 -0700
          Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-22 20:13 -0700
            Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-22 21:09 -0700
              Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-23 18:36 -0700
            Re: 1 /STRING vs SNIP alex <alex@rivadpm.com> - 2016-10-27 14:07 +0100
              Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-27 19:12 -0700
                Re: 1 /STRING vs SNIP alex <alex@rivadpm.com> - 2016-10-28 19:39 +0100
                  Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-28 20:26 -0700
      Re: 1 /STRING vs SNIP foxaudioresearch@gmail.com - 2016-10-26 19:52 -0700
        Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-27 09:42 +0000
          Re: 1 /STRING vs SNIP foxaudioresearch@gmail.com - 2016-10-27 06:46 -0700
          Re: 1 /STRING vs SNIP stephen@mpeforth.com (Stephen Pelc) - 2016-10-28 07:31 +0000
            Re: 1 /STRING vs SNIP jim <anon@example.com> - 2016-10-28 11:33 +0100
            Re: 1 /STRING vs SNIP jasmijn Bonting <tessa.bonting@gmail.com> - 2016-10-28 04:09 -0700
              Re: 1 /STRING vs SNIP stephen@mpeforth.com (Stephen Pelc) - 2016-10-28 12:41 +0000
              Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-28 16:50 +0000
                Re: 1 /STRING vs SNIP Chris Curl <ccurl609@gmail.com> - 2016-10-28 10:59 -0700
                  Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-29 10:17 +0000
    Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-19 20:19 +1000
      Re: 1 /STRING vs SNIP foxaudioresearch@gmail.com - 2016-10-19 05:12 -0700
    1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 04:07 -0700
      Re: 1 /STRING vs SNIP albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-21 15:50 +0200
      Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-25 16:38 -0700
        Re: 1 /STRING vs SNIP "David N. Williams" <williams@umich.edu> - 2016-10-26 10:50 -0400
          Re: 1 /STRING vs SNIP "David N. Williams" <williams@umich.edu> - 2016-10-26 10:53 -0400
          Re: 1 /STRING vs SNIP albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-26 17:33 +0200
            Re: 1 /STRING vs SNIP "David N. Williams" <williams@umich.edu> - 2016-10-27 10:16 -0400
              Re: 1 /STRING vs SNIP Doug Hoffman <glidedog@gmail.com> - 2016-10-27 17:01 -0400
            Re: 1 /STRING vs SNIP Coos Haak <htrofhc@gmail.com> - 2016-10-27 17:00 +0200
    Re: 1 /STRING vs SNIP Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-22 12:25 +0200

Page 1 of 3  [1] 2 3  Next page →

#52026 — 1 /STRING vs SNIP

I noticed a lot of code uses the phrase 1 /STRING so I made a word I call SNIP.

: snip      ( addr len -- addr' len' ) 1- swap 1+ swap ;

It's not rocket science but in my ITC system SNIP was 3 times faster than 
1 /STRING.  Seems like a Forthy thing to do if 1 /STRING is used a lot.

BF

(I was going to call it MOHEL, but thought better of it.)
 :-)

[toc] | [next] | [standalone]

#52028

On 19/10/2016 5:31, foxaudioresearch@gmail.com wrote:
> I noticed a lot of code uses the phrase 1 /STRING so I made a word I call SNIP.
> 
> : snip      ( addr len -- addr' len' ) 1- swap 1+ swap ;

Nice; I also have 'trim' etc for removing whitespace.

> 

> 
> (I was going to call it MOHEL, but thought better of it.)
>  :-)

Oy ;-)

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

#52035

foxaudioresearch@gmail.com writes:
>I noticed a lot of code uses the phrase 1 /STRING so I made a word I call SNIP.
>
>: snip      ( addr len -- addr' len' ) 1- swap 1+ swap ;

63 occurences "1 /string" in 62393 lines of code.  Too little IMO for
having to remember yet another word.

>It's not rocket science but in my ITC system SNIP was 3 times faster than 
>1 /STRING.

In VFX:

VFX Forth for Linux IA32 Version: 4.72 [build 0555]
: snip 1- swap 1+ swap ;  ok
: foo1 snip ;  ok
: foo2 1 /string ;  ok
see foo1 
FOO1 
( 080C0AB0    4B )                    DEC       EBX
( 080C0AB1    8B5500 )                MOV       EDX, [EBP]
( 080C0AB4    42 )                    INC       EDX
( 080C0AB5    895500 )                MOV       [EBP], EDX
( 080C0AB8    C3 )                    NEXT,
( 9 bytes, 5 instructions )
 ok
see foo2 
FOO2 
( 080C0AE0    83C3FF )                ADD       EBX, -01
( 080C0AE3    8B5500 )                MOV       EDX, [EBP]
( 080C0AE6    83C201 )                ADD       EDX, 01
( 080C0AE9    895500 )                MOV       [EBP], EDX
( 080C0AEC    C3 )                    NEXT,
( 13 bytes, 5 instructions )

Probably same speed as long as the code working set fits in the cache.

- 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 2016: http://www.euroforth.org/ef16/

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

#52058

On Wednesday, October 19, 2016 at 12:59:33 AM UTC-7, Anton Ertl wrote:
> foxaudioresearch@gmail.com writes:
> >I noticed a lot of code uses the phrase 1 /STRING so I made a word I call SNIP.
> >
> >: snip      ( addr len -- addr' len' ) 1- swap 1+ swap ;
> 
> 63 occurences "1 /string" in 62393 lines of code.  Too little IMO for
> having to remember yet another word.

If Anton Ertl is opposed to your SNIP because you have added another word for the user to remember, then he must absolutely hate my string-stack.4th package! I add about two dozen words for the user to remember! OMG! How would any human being ever learn all these words? It would take Anton Ertl a lifetime to learn how string-stack.4th works, even if he had Bernd Paysan helping him --- learning string-stack.4th is like learning rocket-science; it requires far more intelligence and perseverence than any ANS-Forth programmer could be expected to have! Even learning your SNIP is beyond the ability of most ANS-Forth programmers, and my string-stack.4th is at least an order of magnitude more complicated. Arg! ;-)

In this case, my DISCARD-LEFT$ would do the trick. I don't much like your SNIP because it is too specific in what it does. It only works with 1 char (by comparison; DISCARD-LEFT$ allows the programmer to specify any number of chars). Most importantly however, you don't have any way to manage your strings. You might have the original string still available, and also have the SNIP substring (I use the term "derivative" in my string-stack.4th) available, at the same time --- if you modify one of these strings, you will modify the other one also --- you are forcing the programmer to keep track of which strings are derivative of which other strings --- by comparison, in my string-stack.4th I have "unique" and "derivative" strings, but the system keeps track of which are which, so the programmer can write his code as if every string were unique and not worry about the optimization going on under the hood.

My string-stack.4th package is written entirely in ANS-Forth and should run on any ANS-Forth system. I'm not an ANS-Forth programmer however. Elizabeth Rather says:
-----------------------------------------------------------------------------
...in Forth it's so easy to build data structures that are exactly right for
the particular application at hand that worrying about what pre-built
structures you have and how to use them is just not worth the bother.
-----------------------------------------------------------------------------
She demands that every ANS-Forth program be written using only the raw ANS-Forth words, without any extensions at all. She demands that you use 
1 /STRING  
in your application program. Anton Ertl (appointed by Elizabeth Rather to be the chair-person of the Forth-200x committee) is parrotting Elizabeth Rather here. He is opposed to your SNIP because this causes a programmer of your system to have to worry about what pre-built words are available, which is just not worth the bother. Anton is worried that the reader of your code would encounter SNIP and think: 
"What the hell is that??? SNIP is not listed in the ANS-Forth document! Arg! Looking up this SNIP word in the programmer's own documentation is just not 
worth the bother --- I will forget about this program --- learning how it 
works is like rocket-science!"
In my string-stack.4th I'm treating strings as a "pre-built structure" and providing code that will work in any program that does text processing. In ANS-Forth, we have /STRING (and you have provided SNIP which is a slight upgrade), all of which treat the string as a kind of array, and require the user to directly access the chars in this array. By comparison, in my string-stack.4th, the programmer would never directly access the chars in the strings, and I don't actually provide any way to do so. I could easily upgrade my string-stack.4th to use UTF-8 or UTF-32 or whatever, rather than ascii, and all the code written that uses string-stack.4th would continue to work without modification because it doesn't access chars directly and hence doesn't assume that the chars are any particular format or size.

I'm all about writing general-purpose Forth code. This is why Elizabeth Rather and her committee appointees Anton Ertl and Bernd Paysan, and all of their sycophants, say that I'm not an ANS-Forth programmer.

The following is an excerpt from my documentation. These are just the words used for extracting sub-strings from strings. I also have a lot more words used for searching in strings. Oftentimes, you will search first to find your substring, then extract a substring or substrings based on that information.

Anyway, here is the excerpt:
-----------------------------------------------------------------------------

LEN$                        ( -- length )                       \ string: a --
This returns the length of the string on the data-stack. This consumes the 
string on the string-stack (Forth functions traditionally consume their 
arguments), so if this is used and you still need the string, then DUP$ or 
OVER$ or whatever should be used to keep a copy on the string-stack.

MID$                        ( start-index length -- )           \ string: a -- b
The B string is a substring in the middle of the A string.

ANTI-MID$                   ( start-index length -- )           \ string: a -- b
Returns the string with the middle part extracted (what MID$ would have 
returned is not returned, but instead the edge parts concatenated together are 
returned).

INNER$                      ( start-index limit-index -- )      \ string: a -- b
This is like MID$ except that it uses a LIMIT-INDEX rather than a LENGTH (this 
is somewhat like Mark Wills' MID$ and, to the best of my recollection, like 
the QBASIC MID$). Note that the LIMIT-INDEX is 1 beyond the middle-part that 
is kept (LIMIT-INDEX minus START-INDEX equals length).

ANTI-INNER$                 ( start-index limit-index -- )      \ string: a -- b
Returns the string with the middle part extracted (what INNER$ would have 
returned is not returned, but instead the edge parts concatenated together are 
returned). Note that the LIMIT-INDEX is 1 beyond the middle-part that is 
extracted (LIMIT-INDEX minus START-INDEX equals length).

LEFT$                       ( length -- )                       \ string: a -- b
This provides a substring of length LENGTH from the left side of the string.

RIGHT$                      ( length -- )                       \ string: a -- b
This provides a substring of length LENGTH from the right side of the string.

DISCARD-LEFT$               ( length -- )                       \ string: a -- b
This discards a substring of length LENGTH from the left side of the string.

DISCARD-RIGHT$              ( length -- )                       \ string: a -- b
This discards a substring of length LENGTH from the right side of the string.

FILL$                       ( length char -- )                  \ string: -- a
This produces a string filled with CHAR of length LENGTH.

BLANK$                      ( length -- )                       \ string: -- a
This produces a string filled with blanks of length LENGTH.

LPAD$                       ( length -- )                       \ string: a -- b
This pads the string with blanks on the left side so the total length is 
LENGTH --- if the length of A is less than LENGTH nothing is done.

RPAD$                       ( length -- )                       \ string: a -- b
This pads the string with blanks on the right side so the total length is 
LENGTH --- if the length of A is less than LENGTH nothing is done.

LTRIM$                      ( -- )                              \ string: a -- b
This trims the whitespace from the left side of the string.

RTRIM$                      ( -- )                              \ string: a -- b
This trims the whitespace from the right side of the string.

TRIM$                       ( -- )                              \ string: a -- b
This trims the whitespace from the left and right sides of the string.

BLACKEN$                    ( -- )                              \ string: a -- b
This removes all the whitespace from the entire string.

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

#52080

hughaguilar96@gmail.com wrote:
> On Wednesday, October 19, 2016 at 12:59:33 AM UTC-7, Anton Ertl wrote:
> > foxaudioresearch@gmail.com writes:
> > >I noticed a lot of code uses the phrase 1 /STRING so I made a word I call SNIP.
> > >
> > >: snip      ( addr len -- addr' len' ) 1- swap 1+ swap ;
> >
> > 63 occurences "1 /string" in 62393 lines of code.  Too little IMO for
> > having to remember yet another word.
>
> If Anton Ertl is opposed to your SNIP because you have added another word for the user
> to remember, then he must absolutely hate my string-stack.4th package! I add about two
> dozen words for the user to remember!
> ...
> In this case, my DISCARD-LEFT$ would do the trick. I don't much like your SNIP because
> it is too specific in what it does. It only works with 1 char (by comparison;
> DISCARD-LEFT$ allows the programmer to specify any number of chars). Most importantly
> however, you don't have any way to manage your strings.

/STRING isn't intended for that.  It's a low-level primitive whose scope and uses
extend beyond string packages.

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

#52084

On Thursday, October 20, 2016 at 10:02:41 PM UTC-7, HAA wrote:
> hughaguilar96@gmail.com wrote:
> > On Wednesday, October 19, 2016 at 12:59:33 AM UTC-7, Anton Ertl wrote:
> > > foxaudioresearch@gmail.com writes:
> > > >I noticed a lot of code uses the phrase 1 /STRING so I made a word I call SNIP.
> > > >
> > > >: snip      ( addr len -- addr' len' ) 1- swap 1+ swap ;
> > >
> > > 63 occurences "1 /string" in 62393 lines of code.  Too little IMO for
> > > having to remember yet another word.
> >
> > If Anton Ertl is opposed to your SNIP because you have added another word for the user
> > to remember, then he must absolutely hate my string-stack.4th package! I add about two
> > dozen words for the user to remember!
> > ...
> > In this case, my DISCARD-LEFT$ would do the trick. I don't much like your SNIP because
> > it is too specific in what it does. It only works with 1 char (by comparison;
> > DISCARD-LEFT$ allows the programmer to specify any number of chars). Most importantly
> > however, you don't have any way to manage your strings.
> 
> /STRING isn't intended for that.  It's a low-level primitive whose scope and uses
> extend beyond string packages.

Well, memory management is important --- this is why languages with GC are popular --- the memory-management in my string-stack.4th is simpler than GC, but it does relieve the programmer from the error-prone tedium of allocating and freeing memory for strings.

For Forth to be useful, we have to get past using low-level primitives directly in programs --- this makes our programs primitive --- it is extremely frustrating to me that ANS-Forth holds us at this 1970s level forever.

My string-stack.4th was written in ANS-Forth, but I knew that it would never be used by ANS-Forth programmers --- it was written mostly as something that would go into Straight Forth.

Because the string-stack is a standardized part of Straight Forth, I can dedicate a register to be the string-stack pointer; plus we have the PTR and CNT registers that can represent an array --- this should boost the efficiency of the string-stack a lot --- text-processing is a big part of what desktop computers do, so every language needs to provide support (lack of support for text processing is one reason why C has lost popularity).

Note that application programmers don't have to mess with PTR and CNT --- they can leave that low-level primitive stuff to systems programmers --- application programmers are strongly discouraged from accessing chars directly, but are encouraged to only work with strings on the string-stack.

Everybody criticizes me for taking a long time to write Straight Forth. I don't think that is fair. Now it is almost a quarter of a century since ANS-Forth became the standard, and ANS-Forth is still not useful --- the ANS-Forth programmers are still dinking around with /STRING and other low-level primitives --- it doesn't matter when I come out with Straight Forth, because it will be the first-ever useful Forth system when it does come out.

Forth-200x has no chance of being useful at all --- it lacks quotations, which are the basis for all general-purpose data-structures --- it is a complete waste of time.

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

#52085

On Friday, October 21, 2016 at 12:51:39 AM UTC-7, hughag...@gmail.com wrote:
> ...text-processing is a big part of what desktop computers do, so every language needs to provide support (lack of support for text processing is one reason why C has lost popularity).

Just as a fun experiment, I might rewrite string-stack.4th in C. It will never be used by ANS-Forth programmers, as they absolutely hate it --- it might be accepted by C programmers though --- how ironic would that be?

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

#52088

On Friday, October 21, 2016 at 1:02:41 AM UTC-4, HAA wrote:

> /STRING isn't intended for that.  It's a low-level primitive whose scope and uses
> extend beyond string packages.

Then why such a name?

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

#52089

trans wrote:
> On Friday, October 21, 2016 at 1:02:41 AM UTC-4, HAA wrote:
>
> > /STRING isn't intended for that.  It's a low-level primitive whose scope and uses
> > extend beyond string packages.
>
> Then why such a name?

Why not such a name?  The stack picture and specification makes clear it's dealing
with an arbitrary array of characters somewhere in memory.  The OTA project spec
has a string concatenation primitive +STRING similarly intended for general use.
I use these functions all the time.  The following example is from a previous posting.
The message it displays is, I think, particularly apt.

\ SKIP SCAN exist in most Forths as primitives
\ but can be coded from scratch

: +STRING ( a1 u1 a2 u2 -- a2 u3)
  2swap swap 2over + 2 pick cmove + ;

: SPLIT ( a u char -- a2 u2 a3 u3 )
  >r 2dup r> scan 2swap 2 pick - ;

: /WORD ( a u -- a1 u1 a2 u2 )
  bl skip  bl split  2swap ;

: +WORD ( a1 u1 a2 u2 -- a u )
  +string  s"  " 2swap +string ;

: REVERSE-WORDS ( src len dest -- dest len )
  >r  0 begin >r  dup while  /word  r> 1+ repeat 2drop
  2r> 0 tuck ?do  +word  loop -trailing ;

: .rvs ( a u -- )  pad reverse-words cr type ;

: plug ( -- ) cr
  s" words user-created few a with things do often can Forth" .rvs
  s" accomplish. to libraries require languages other that" .rvs ;

  plug

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

#52091

On Friday, October 21, 2016 at 9:26:48 AM UTC-4, HAA wrote:

> Why not such a name?  

B/c they day you finally come into modernity and use UTF-8, your word name isn't going to jive.

Although I suppose you could redefine the meaning of the word "string", the rest of the programming world be damned.

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

#52092

trans <transfire@gmail.com> writes:
>B/c they day you finally come into modernity and use UTF-8, your word name isn't going to jive.

/STRING works nicely for stepping by n bytes in an UTF-8 string.

And if you want to step by 1 code point in an UTF-8 string, there's
+X/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 2016: http://www.euroforth.org/ef16/

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

#52093

In article <2016Oct21.182415@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>trans <transfire@gmail.com> writes:
>>B/c they day you finally come into modernity and use UTF-8, your word name isn't going to jive.
>
>/STRING works nicely for stepping by n bytes in an UTF-8 string.
>
>And if you want to step by 1 code point in an UTF-8 string, there's
>+X/STRING.

C@ C! CMOVE /STRING COMPARE have all gradually moved from meaning strings
to meaning bytes. It would be weird if all implementations change
because of change in English language habits.

E.g. all operators in ciforth starting with $ means rows of bytes.
Normally in this primitive Forth you would have one ascii character
per byte, but you're in no way restricted as what you store in them.
A compact serial representation of a factorisation that accomodates
unrestricted precision big numbers comes to mind. (In a transputer
demonstration program.)

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#52096

On Friday, October 21, 2016 at 1:57:31 PM UTC-4, Albert van der Horst wrote:
> In article <2016Oct21.182415@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> >trans <transfire@gmail.com> writes:
> >>B/c they day you finally come into modernity and use UTF-8, your word name isn't going to jive.
> >
> >/STRING works nicely for stepping by n bytes in an UTF-8 string.
> >
> >And if you want to step by 1 code point in an UTF-8 string, there's
> >+X/STRING.
> 
> C@ C! CMOVE /STRING COMPARE have all gradually moved from meaning strings
> to meaning bytes. It would be weird if all implementations change
> because of change in English language habits.

Ah, I see. So that has already happened. I'm learning a lot about the history and culture of Forth. Thanks.

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

#52106

Albert van der Horst wrote:
> ...
> C@ C! CMOVE /STRING COMPARE have all gradually moved from meaning strings
> to meaning bytes.

They were 'bytes' from the very beginning.  From Forth-79 ...

C!             n addr --                     219          "c-store"
     Store the least significant 8-bits of n at addr.

C@             addr -- byte                  156          "c-fetch"
     Leave  on  the stack the contents of the byte  at  addr  (with
     higher bits zero, in a 16-bit field).

CMOVE          addr1 addr2 n --              153           "c-move"
     Move  n  bytes  beginning  at address  addr1  to  addr2.   The
     contents  of  addr1  is moved  first  proceeding  toward  high
     memory.  If n is zero nothing is moved.

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

#52113

On Fri, 21 Oct 2016 20:06:08 +0200 (CEST),
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:

>C@ C! CMOVE /STRING COMPARE have all gradually moved from meaning strings
>to meaning bytes. It would be weird if all implementations change
>because of change in English language habits.

This is formalised in the Forth 2012 standard. Unless otherwise
qualified in the text, the term 'character' means a 'primitive
character' (pchar), which can contain any value. On most CPUs,
a pchar is a byte.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#52114

stephen@mpeforth.com (Stephen Pelc) writes:
>On Fri, 21 Oct 2016 20:06:08 +0200 (CEST),
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:
>
>>C@ C! CMOVE /STRING COMPARE have all gradually moved from meaning strings
>>to meaning bytes. It would be weird if all implementations change
>>because of change in English language habits.
>
>This is formalised in the Forth 2012 standard. Unless otherwise
>qualified in the text, the term 'character' means a 'primitive
>character' (pchar), which can contain any value. On most CPUs,
>a pchar is a byte.

And at the last meeting we standardized "1 chars = 1".  So if the
address unit is a byte, /STRING works on bytes.

- 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 2016: http://www.euroforth.org/ef16/

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

#52139

Anton Ertl wrote:
> stephen@mpeforth.com (Stephen Pelc) writes:
> >On Fri, 21 Oct 2016 20:06:08 +0200 (CEST),
> >albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:
> >
> >>C@ C! CMOVE /STRING COMPARE have all gradually moved from meaning strings
> >>to meaning bytes. It would be weird if all implementations change
> >>because of change in English language habits.
> >
> >This is formalised in the Forth 2012 standard. Unless otherwise
> >qualified in the text, the term 'character' means a 'primitive
> >character' (pchar), which can contain any value. On most CPUs,
> >a pchar is a byte.
>
> And at the last meeting we standardized "1 chars = 1".  So if the
> address unit is a byte, /STRING works on bytes.
>
> - anton

That option already existed under Forth-94.  It was only necessary to
state the assumption.   All the 200x decision does is encourage
sloppiness - code that under Forth-94 would be considered poorly
written.  Presumably code that uses CHARS in some places and
not others, CHAR+ in some places and 1+ in others, in a willy-nilly
fashion is now perfectly legal under 200x ?

CHARS and CHAR+ are still there (and need to be) along with all the
operators that deal with chars.  Like 0= vs NOT they add clarity and
readability to code even if on most machines they're just synonyms.

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

#52140

In article <nujjrn$579$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote:
>Anton Ertl wrote:
>> stephen@mpeforth.com (Stephen Pelc) writes:
>> >On Fri, 21 Oct 2016 20:06:08 +0200 (CEST),
>> >albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:
>> >
>> >>C@ C! CMOVE /STRING COMPARE have all gradually moved from meaning strings
>> >>to meaning bytes. It would be weird if all implementations change
>> >>because of change in English language habits.
>> >
>> >This is formalised in the Forth 2012 standard. Unless otherwise
>> >qualified in the text, the term 'character' means a 'primitive
>> >character' (pchar), which can contain any value. On most CPUs,
>> >a pchar is a byte.
>>
>> And at the last meeting we standardized "1 chars = 1".  So if the
>> address unit is a byte, /STRING works on bytes.
>>
>> - anton
>
>That option already existed under Forth-94.  It was only necessary to
>state the assumption.   All the 200x decision does is encourage
>sloppiness - code that under Forth-94 would be considered poorly
>written.  Presumably code that uses CHARS in some places and
>not others, CHAR+ in some places and 1+ in others, in a willy-nilly
>fashion is now perfectly legal under 200x ?

If I use a byte array e.g. for the famous erathostenes sieve,
because it only need to contain a flag, I'm using C@ C!
These are byte operators to me. If I add CHARS here and there
at places that would suggest that we are dealing with characters.
Address units should be fundamental. Then you document how many
chars you can store in an address unit, or how many address units
it takes to store a character. (And how many address units is a cell.)

>
>CHARS and CHAR+ are still there (and need to be) along with all the
>operators that deal with chars.  Like 0= vs NOT they add clarity and
>readability to code even if on most machines they're just synonyms.

I never can tell MOVE and CMOVE apart.

NOT to invert a flag is better than 0= because that suggest
arithmetic not logic. Too bad we can't use it anymore, so
I have to start all my programs with
: NOT 0= ;

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#52143

Albert van der Horst wrote:
> ...
> I never can tell MOVE and CMOVE apart.

You should because they're very different functions.  MOVE handles
overlaps (an extra test) and on some implementations can actually
be faster.  CMOVE is one-directional and explicitly char-at-a-time.

And I didn't even need to look it up :)

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

#52146

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> And at the last meeting we standardized "1 chars = 1".  So if the
>> address unit is a byte, /STRING works on bytes.
...
>That option already existed under Forth-94.

Yes, it was an option, and all popular systems implemented this
option, and many programs rely on it.  I.e., it is common practice,
and that's why we standardized it.

>It was only necessary to
>state the assumption. All the 200x decision does is encourage
>sloppiness - code that under Forth-94 would be considered poorly
>written.

There are some people who consider such code poorly written, and many
that don't (as evidenced by the very common practice of writing such
code).  And that's pretty independent of the standard.  E.g., there
are people who consider code poorly written if it is not written to be
independent of the canonical flag representation, while every Forth
standard has specified a canonical flag representation.

>Presumably code that uses CHARS in some places and
>not others, CHAR+ in some places and 1+ in others, in a willy-nilly
>fashion is now perfectly legal under 200x ?

Not sure what you mean with willy-nilly.  Forth-94 and Forth-2012
programs can also use 1+, CHAR+, and CHARS in the same program.  In
the next standard a standard program can use 1+ where a Forth-2012
program should have used CHAR+ and use nothing where a Forth-2012 program
should have used CHARS or 1 CHARS /.

>CHARS and CHAR+ are still there (and need to be)

They need to be there for compatibility with standard Forth-2012
programs; they also allow people to use them who feel the urge to use
these words for whatever reasons.

- 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 2016: http://www.euroforth.org/ef16/

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web