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

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

Reducing C,

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

Contents

  Reducing C, josv@planet.nl - 2015-01-28 04:07 -0800
    Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-01-28 05:02 -0800
    Re: Reducing C, Howerd <howerdo@yahoo.co.uk> - 2015-01-28 07:42 -0800
      Re: Reducing C, josv@planet.nl - 2015-01-28 08:17 -0800
    Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-01-29 03:37 +1100
    Re: Reducing C, visualforth@rocketmail.com - 2015-01-28 12:53 -0800
    Re: Reducing C, humptydumpty <ouatubi@gmail.com> - 2015-01-28 14:03 -0800
    Re: Reducing C, humptydumpty <ouatubi@gmail.com> - 2015-01-28 20:39 -0800
      Re: Reducing C, humptydumpty <ouatubi@gmail.com> - 2015-01-28 20:51 -0800
        Re: Reducing C, josv@planet.nl - 2015-01-29 06:28 -0800
    Re: Reducing C, hughaguilar96@gmail.com - 2015-01-29 21:18 -0800
      Re: Reducing C, josv@planet.nl - 2015-01-30 05:38 -0800
        Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-01-30 15:11 +0000
          Re: Reducing C, josv@planet.nl - 2015-01-30 08:34 -0800
        Re: Reducing C, hughaguilar96@gmail.com - 2015-01-31 20:26 -0800
          Re: Reducing C, josv@planet.nl - 2015-02-01 11:16 -0800
            Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-02 11:03 +1100
              Re: Reducing C, "Elizabeth D. Rather" <erather@forth.com> - 2015-02-01 14:13 -1000
                Re: Reducing C, hughaguilar96@gmail.com - 2015-02-01 17:22 -0800
                Re: Reducing C, hughaguilar96@gmail.com - 2015-02-01 17:36 -0800
                  Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-02 11:40 +0000
                    Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-02-02 05:24 -0800
                      Netiquette was: Re: Reducing C, albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-02 13:40 +0000
                      Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-02 15:08 +0000
                        Politeness, was Re: Reducing C, "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-02 19:30 -0500
                          Re: Politeness, was Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-03 01:57 +0100
                          Re: Politeness, was Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-03 11:59 +0000
                        Re: Reducing C, josv@planet.nl - 2015-02-03 02:31 -0800
                          Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-03 12:06 +0000
                            Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-03 19:47 +0000
                              Re: Reducing C, josv@planet.nl - 2015-02-03 14:06 -0800
                                Re: Reducing C, hughaguilar96@gmail.com - 2015-02-03 21:19 -0800
                                  Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-04 12:10 +0000
                                    Re: Reducing C, hughaguilar96@gmail.com - 2015-02-04 18:22 -0800
                                      Re: Reducing C, hughaguilar96@gmail.com - 2015-02-04 19:04 -0800
                                        Re: Reducing C, stephen@mpeforth.com (Stephen Pelc) - 2015-02-05 11:33 +0000
                                          Re: Reducing C, hughaguilar96@gmail.com - 2015-02-05 19:39 -0800
                                            Re: Reducing C, stephen@mpeforth.com (Stephen Pelc) - 2015-02-06 11:50 +0000
                                              Re: Reducing C, hughaguilar96@gmail.com - 2015-02-06 11:28 -0800
                                        Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-02-05 04:37 -0800
                                          Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-06 21:47 +1100
                                          Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-13 09:45 +1100
                                            Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-02-13 05:24 -0800
                                              Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-15 13:53 +1100
                                                Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-02-16 01:07 -0800
                                                  Re: Reducing C, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-16 15:02 +0000
                                                  Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-19 14:22 +1100
                                        Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-05 13:18 +0000
                                        Re: Reducing C, josv@planet.nl - 2015-02-05 07:02 -0800
                                          Re: Reducing C, josv@planet.nl - 2015-02-05 07:14 -0800
                                      Re: Reducing C, josv@planet.nl - 2015-02-07 07:12 -0800
                                  Re: Reducing C, josv@planet.nl - 2015-02-04 07:12 -0800
                                    Re: Reducing C, november.nihal@gmail.com - 2015-02-04 09:38 -0800
                                    Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-04 21:08 +0000
                                      Re: Reducing C, josv@planet.nl - 2015-02-05 06:45 -0800
                                        Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-06 13:21 +0000
                                  Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-05 17:36 +0100
                                    Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-05 17:06 +0000
                                      Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-05 18:17 +0100
                                      Re: Reducing C, "Elizabeth D. Rather" <erather@forth.com> - 2015-02-05 10:40 -1000
                                        Re: Reducing C, hughaguilar96@gmail.com - 2015-02-05 20:25 -0800
                                          Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-06 11:39 +0000
                                          Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-06 12:48 +0100
                                            Re: Reducing C, hughaguilar96@gmail.com - 2015-02-06 17:28 -0800
                                              Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-07 12:38 +0100
                                          Re: Reducing C, albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-06 14:40 +0000
                                            Re: Reducing C, hughaguilar96@gmail.com - 2015-02-06 18:33 -0800
                                      Re: Reducing C, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-06 13:49 +0000
                                        Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-06 14:15 +0000
                              Re: Reducing C, hughaguilar96@gmail.com - 2015-02-03 21:23 -0800
                                Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-04 12:41 +0000
                              Re: Reducing C, "WJ" <w_a_x_man@yahoo.com> - 2015-02-04 18:19 +0000
                                Re: Reducing C, "WJ" <w_a_x_man@yahoo.com> - 2015-02-04 20:54 +0000
                  Re: Reducing C, "WJ" <w_a_x_man@yahoo.com> - 2015-02-04 09:41 +0000
                    Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-04 12:54 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#36215

on 02/02/2015 01:36:46,  wrote:
> On Sunday, February 1, 2015 at 5:13:34 PM UTC-7, Elizabeth D. Rather
> > wrote:
>> On 2/1/15 2:03 PM, HAA wrote:
> > wrote:
>> > Storing a few raw numbers is most easily achieved by typing C,
> > wrote:
>>
> > wrote:
>> Yes, the OP noted that, but thought it was "boring" and was looking for
> wrote:
> 
>> syntactic sugar. IMO none of the offered solutions contribute much
>> except more code.
> 
> You have never posted any code on comp.lang.forth except for code
> examples copied directly out of "Starting Forth" (and you get those
> wrong most of th e time, because you try to do it from memory) --- the
> reason why you are op posed to "more code" is because you can't write
> it.
> 
> This is a trivial coding challenge --- I was going to let the OP do it
> hims elf, but since you have spoken out against the writing of Forth
> code, I wil l write it myself:
> 
> variable original-depth
> 
>: string[ ( -- )
> depth original-depth ! ;
> 
>: numbers-count ( -- count )
> depth original-depth @ - ;
> 
>: reverse-numbers ( numbers... count -- numbers... )
> 0 ?do  I roll  loop ;
> 
>: good-char? ( n -- flag )
> 256 u< ;
> 
>: ]string ( numbers... -- )
> numbers-count >r
> r@ reverse-numbers
> r@ c,
> r> 0 ?do
> dup good-char? 0= abort" *** ]STRING given a bad char ***
> c,  loop ;
> 
> 
> This is a test of the code under VFX:
> 
> create hey  ok
> string[ char H char E char Y char ! ]string  ok
> hey count type HEY! ok
> 

What an awful solution. How long have you been writing Forth? 

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

#36216

On Monday, 2 February 2015 11:40:37 UTC, Alex McDonald  wrote:
> What an awful solution. How long have you been writing Forth?

Nice bit of drive-by trolling there, Alex. Could you not be a bit
more specific? What specifically is so awful about it?

Mark

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

#36217 — Netiquette was: Re: Reducing C,

In article <98faaf9b-74c0-4d5a-b8f8-3c99211580af@googlegroups.com>,
Mark Wills  <markwills1970@gmail.com> wrote:
>On Monday, 2 February 2015 11:40:37 UTC, Alex McDonald  wrote:
>> What an awful solution. How long have you been writing Forth?
>
>Nice bit of drive-by trolling there, Alex. Could you not be a bit
>more specific? What specifically is so awful about it?

What are you guys talking about?

Hint: this is usenet.Articles should
be self contained. They must contain enough material of the original
post to be understandable, even if e.g. Hugh decides to delete
his article.

[It is not just you. It is becoming a habit, so I decided to
say something about it.]
>
>Mark
-- 
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]

#36218

on 02/02/2015 13:24:14, Mark Wills wrote:
> On Monday, 2 February 2015 11:40:37 UTC, Alex McDonald  wrote:
>> What an awful solution. How long have you been writing Forth?
> 
> Nice bit of drive-by trolling there, Alex. Could you not be a bit
> more specific? What specifically is so awful about it?

As Albert points out, please stop over-trimming your posts. The entire
sense is in danger of being lost. I quote it below. 


> You have never posted any code on comp.lang.forth except for code
> examples copied directly out of "Starting Forth" (and you get those
> wrong most of th e time, because you try to do it from memory) --- the
> reason why you are op posed to "more code" is because you can't write
> it.
> 
> This is a trivial coding challenge --- I was going to let the OP do it
> hims elf, but since you have spoken out against the writing of Forth
> code, I wil l write it myself:
> 
> variable original-depth
> 
>: string[ ( -- )
> depth original-depth ! ;
> 
>: numbers-count ( -- count )
> depth original-depth @ - ;
> 
>: reverse-numbers ( numbers... count -- numbers... )
> 0 ?do  I roll  loop ;
> 
>: good-char? ( n -- flag )
> 256 u< ;
> 
>: ]string ( numbers... -- )
> numbers-count >r
> r@ reverse-numbers
> r@ c,
> r> 0 ?do
> dup good-char? 0= abort" *** ]STRING given a bad char ***
> c,  loop ;
> 
> 
> This is a test of the code under VFX:
> 
> create hey  ok
> string[ char H char E char Y char ! ]string  ok
> hey count type HEY! ok
> 

"Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity."

Questions you might want to ask yourself.

1. Why are there two DO LOOPs for each string generated? 
2. Why is there a ROLL on the stack for every character before it is
stored? 3. Is REVERSE-NUMBERS really needed? Could it be removed?
4. Why test for "invalid" characters; but no test for a negative result
in NUMBERS-COUNT; and no test for a STRING[ ]STRING in excess of 255
CHARs? 5. Why the test for a GOOD-CHAR? rather than a "bad char" as it
needs 0= for the ABORT" ?

No-one can teach you how to create beautiful code, but ugliness is pretty
easy to spot. It's generally because the algorithm is bad in the first
place, as is the case here. So this was not a drive-by troll; I assumed
(wrongly in your case) that most people would look at the code with a
critical eye and come to the same conclusion. Elizabeth is right, btw;
unless there's a large amount of this data it's syntactic sugar. None of
the offered solutions contribute much except more (ugly) code.

As Albert points out, please stop over-trimming your posts. The entire
sense is in danger of being lost.

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

#36240 — Politeness, was Re: Reducing C,

On Mon, 02 Feb 2015 10:08:35 -0500, Alex McDonald <blog@rivadpm.com> wrote:

> "Beauty is more important in computing than anywhere else in technology
> because software is so complicated. Beauty is the ultimate defence
> against complexity."

While we're on the topic of "politeness", if you quote someone as
obscure and unknown as a computer professor from Yale which the world
only knows of his name because he was a victim of a mad math genius
and bomber, himself a victim/agent of the CIA's MK ULTRA program, at
least mention the guy's name ...  I'd swear your only point in quoting
him was to indirectly introduced MK ULTRA into the conversation.  That
seems to be a topic du jour of trolls.


Rod Pemberton

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

#36243 — Re: Politeness, was Re: Reducing C,

Rod Pemberton <buzz@notnotnontnooatno.cmm> wrote:

> I'd swear your only point in quoting
> him was to indirectly introduced MK ULTRA into the conversation.

That's a real slimy way of saying "he made me do it"!

BTW: What happened to your spelling lately?

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

#36245 — Re: Politeness, was Re: Reducing C,

on 03/02/2015 00:30:05, "Rod Pemberton" wrote:
> On Mon, 02 Feb 2015 10:08:35 -0500, Alex McDonald <blog@rivadpm.com>
> wrote:
> 
>> "Beauty is more important in computing than anywhere else in technology
>> because software is so complicated. Beauty is the ultimate defence
>> against complexity."
> 
> While we're on the topic of "politeness", if you quote someone as

Good point, I should have attributed. David Hillel Gelernter,
http://cpsc.yale.edu/people/david-gelernter

> obscure and unknown as a computer professor from Yale which the world

Gelernter is not obscure and unknown. His work on parallelism, tuple
spaces and Linda is very interesting; it has application to object
storage systems being developed today.

> only knows of his name because he was a victim of a mad math genius
> and bomber, himself a victim/agent of the CIA's MK ULTRA program, at
> least mention the guy's name ... I'd swear your only point in quoting
> him was to indirectly introduced MK ULTRA into the conversation. That
> seems to be a topic du jour of trolls.
> 

I hope my mentioning him a second time doesn't feed your paranoia.

> 
> Rod Pemberton
> 

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

#36244

Hi Alex,
Your comment and the code of Hugh made me change the code as follows:

: ;bytes   ( numbers... -- )
    depth last @ name> >body @ - dup 1- locals| from |
    dup>r 0  ?do  sp@ from i - cells+ @ c,  loop
    sp@ r@ cells+ sp!  r> swap ! ;

: long$:  \ compiletime: ( "name" - ) runtime: ( - adr n )
   create here depth ,   \ map: n...
   does>  lcount ;

long$: &test2 ( - adr #bytes )  char H char E char Y char !  ;bytes

&test2 type cr

Jos

On 2 february 2015 16:08:35 UTC+1 Alex McDonald wrote:
> on 02/02/2015 13:24:14, Mark Wills wrote:
> > On Monday, 2 February 2015 11:40:37 UTC, Alex McDonald  wrote:
> >> What an awful solution. How long have you been writing Forth?
> > 
> > Nice bit of drive-by trolling there, Alex. Could you not be a bit
> > more specific? What specifically is so awful about it?
> 
> As Albert points out, please stop over-trimming your posts. The entire
> sense is in danger of being lost. I quote it below. 
> 
> 
> > You have never posted any code on comp.lang.forth except for code
> > examples copied directly out of "Starting Forth" (and you get those
> > wrong most of th e time, because you try to do it from memory) --- the
> > reason why you are op posed to "more code" is because you can't write
> > it.
> > 
> > This is a trivial coding challenge --- I was going to let the OP do it
> > hims elf, but since you have spoken out against the writing of Forth
> > code, I wil l write it myself:
> > 
> > variable original-depth
> > 
> >: string[ ( -- )
> > depth original-depth ! ;
> > 
> >: numbers-count ( -- count )
> > depth original-depth @ - ;
> > 
> >: reverse-numbers ( numbers... count -- numbers... )
> > 0 ?do  I roll  loop ;
> > 
> >: good-char? ( n -- flag )
> > 256 u< ;
> > 
> >: ]string ( numbers... -- )
> > numbers-count >r
> > r@ reverse-numbers
> > r@ c,
> > r> 0 ?do
> > dup good-char? 0= abort" *** ]STRING given a bad char ***
> > c,  loop ;
> > 
> > 
> > This is a test of the code under VFX:
> > 
> > create hey  ok
> > string[ char H char E char Y char ! ]string  ok
> > hey count type HEY! ok
> > 
> 
> "Beauty is more important in computing than anywhere else in technology
> because software is so complicated. Beauty is the ultimate defence
> against complexity."
> 
> Questions you might want to ask yourself.
> 
> 1. Why are there two DO LOOPs for each string generated? 
> 2. Why is there a ROLL on the stack for every character before it is
> stored? 3. Is REVERSE-NUMBERS really needed? Could it be removed?
> 4. Why test for "invalid" characters; but no test for a negative result
> in NUMBERS-COUNT; and no test for a STRING[ ]STRING in excess of 255
> CHARs? 5. Why the test for a GOOD-CHAR? rather than a "bad char" as it
> needs 0= for the ABORT" ?
> 
> No-one can teach you how to create beautiful code, but ugliness is pretty
> easy to spot. It's generally because the algorithm is bad in the first
> place, as is the case here. So this was not a drive-by troll; I assumed
> (wrongly in your case) that most people would look at the code with a
> critical eye and come to the same conclusion. Elizabeth is right, btw;
> unless there's a large amount of this data it's syntactic sugar. None of
> the offered solutions contribute much except more (ugly) code.
> 
> As Albert points out, please stop over-trimming your posts. The entire
> sense is in danger of being lost.

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

#36246

on 03/02/2015 10:31:26, JosvdVen  wrote:
> Hi Alex,
> Your comment and the code of Hugh made me change the code as follows:
> 
>: ;bytes   ( numbers... -- )
> depth last @ name> >body @ - dup 1- locals| from |
> dup>r 0  ?do  sp@ from i - cells+ @ c,  loop
> sp@ r@ cells+ sp!  r> swap ! ;
> 
>: long$:  \ compiletime: ( "name" - ) runtime: ( - adr n )
> create here depth ,   \ map: n...
> does>  lcount ;
> 
> long$: &test2 ( - adr #bytes )  char H char E char Y char !  ;bytes
> 
> &test2 type cr
> 
> Jos
> 

It's very Win32Forth specific. 

Reversing items on the stack, or PICKing them off as you have done with
Win32forth's SP@, isn't required. The bytes can be ALLOTed and
initialised with C! from last byte to first, rather than using C, and
going from first byte to last.

 
> On 2 february 2015 16:08:35 UTC+1 Alex McDonald wrote:
>> on 02/02/2015 13:24:14, Mark Wills wrote:
>> > On Monday, 2 February 2015 11:40:37 UTC, Alex McDonald  wrote:
>> >> What an awful solution. How long have you been writing Forth?
>> >
>> > Nice bit of drive-by trolling there, Alex. Could you not be a bit
>> > more specific? What specifically is so awful about it?
>>
>> As Albert points out, please stop over-trimming your posts. The entire
>> sense is in danger of being lost. I quote it below.
>>
>>
>> > You have never posted any code on comp.lang.forth except for code
>> > examples copied directly out of "Starting Forth" (and you get those
>> > wrong most of th e time, because you try to do it from memory) --- the
>> > reason why you are op posed to "more code" is because you can't write
>> > it.
>> >
>> > This is a trivial coding challenge --- I was going to let the OP do it
>> > hims elf, but since you have spoken out against the writing of Forth
>> > code, I wil l write it myself:
>> >
>> > variable original-depth
>> >
>> >: string[ ( -- )
>> > depth original-depth ! ;
>> >
>> >: numbers-count ( -- count )
>> > depth original-depth @ - ;
>> >
>> >: reverse-numbers ( numbers... count -- numbers... )
>> > 0 ?do  I roll  loop ;
>> >
>> >: good-char? ( n -- flag )
>> > 256 u< ;
>> >
>> >: ]string ( numbers... -- )
>> > numbers-count >r
>> > r@ reverse-numbers
>> > r@ c,
>> > r> 0 ?do
>> > dup good-char? 0= abort" *** ]STRING given a bad char ***
>> > c,  loop ;
>> >
>> >
>> > This is a test of the code under VFX:
>> >
>> > create hey  ok
>> > string[ char H char E char Y char ! ]string  ok
>> > hey count type HEY! ok
>> >
>>
>> "Beauty is more important in computing than anywhere else in technology
>> because software is so complicated. Beauty is the ultimate defence
>> against complexity."
>>
>> Questions you might want to ask yourself.
>>
>> 1. Why are there two DO LOOPs for each string generated?
>> 2. Why is there a ROLL on the stack for every character before it is
>> stored? 3. Is REVERSE-NUMBERS really needed? Could it be removed?
>> 4. Why test for "invalid" characters; but no test for a negative result
>> in NUMBERS-COUNT; and no test for a STRING[ ]STRING in excess of 255
>> CHARs? 5. Why the test for a GOOD-CHAR? rather than a "bad char" as it
>> needs 0= for the ABORT" ?
>>
>> No-one can teach you how to create beautiful code, but ugliness is pretty
>> easy to spot. It's generally because the algorithm is bad in the first
>> place, as is the case here. So this was not a drive-by troll; I assumed
>> (wrongly in your case) that most people would look at the code with a
>> critical eye and come to the same conclusion. Elizabeth is right, btw;
>> unless there's a large amount of this data it's syntactic sugar. None of
>> the offered solutions contribute much except more (ugly) code.
>>
>> As Albert points out, please stop over-trimming your posts. The entire
>> sense is in danger of being lost.
> 
> 

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

#36256

on 03/02/2015 12:06:11, "Alex McDonald" wrote:
> on 03/02/2015 10:31:26, JosvdVen  wrote:
>> Hi Alex,
>> Your comment and the code of Hugh made me change the code as follows:
>>
>>: ;bytes   ( numbers... -- )
>> depth last @ name> >body @ - dup 1- locals| from |
>> dup>r 0  ?do  sp@ from i - cells+ @ c,  loop
>> sp@ r@ cells+ sp!  r> swap ! ;
>>
>>: long$:  \ compiletime: ( "name" - ) runtime: ( - adr n )
>> create here depth ,   \ map: n...
>> does>  lcount ;
>>
>> long$: &test2 ( - adr #bytes )  char H char E char Y char !  ;bytes
>>
>> &test2 type cr
>>
>> Jos
>>
> 
> It's very Win32Forth specific.
> 
> Reversing items on the stack, or PICKing them off as you have done
> with Win32forth's SP@, isn't required. The bytes can be ALLOTed and
> initialised with C! from last byte to first, rather than using C, and
> going from first byte to last.
> 

Here's my attempt at something a bit more ANS for getting the characters
off the stack. The assumption is ASCII; supporting extended chars in the
latest Forth standard would require more work and perhaps a different
approach.

: n2str ( cn ... c1 n -- \ for 0 <= n <= MAX-CHAR )
\ build string |c1|...|cn| at HERE
  ?dup if
    here swap allot here 1-
    do i c! -1 +loop
  then ;   

: n2cstring ( cn ... c1 n -- \ for 0 <= n <= MAX-CHAR )
  dup c, n2str ;

: n2lstring ( cn ... c1 n -- \ for 0 <= n )
  dup , n2str ;

here 0 n2cstring count type 
here 'a' 'b' 'c' '!' 4 n2cstring count type 

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

#36257

\ Hi Alex,
\ I agree with you after seeing your code.
\ My code has been changed as follows:

: ;bytes   ( numbers... -- )
    depth last @ name> >body tuck @ - dup>r
    swap ! here r@ allot
    dup r> + 1-
      do   i c! -1  +loop ;

: long$:  \ compiletime: ( "name" - ) runtime: ( - Adr #items )
   create depth ,   \ map: n...
   does>  lcount ;

long$: &test2 ( - adr #bytes )  char H char E char Y char !  ;bytes

cr &test2 type cr
\s

On 3 februari 2015 20:47:02 UTC+1 Alex McDonald wrote:
> on 03/02/2015 12:06:11, "Alex McDonald" wrote:
> > on 03/02/2015 10:31:26, JosvdVen  wrote:
> >> Hi Alex,
> >> Your comment and the code of Hugh made me change the code as follows:
> >>
> >>: ;bytes   ( numbers... -- )
> >> depth last @ name> >body @ - dup 1- locals| from |
> >> dup>r 0  ?do  sp@ from i - cells+ @ c,  loop
> >> sp@ r@ cells+ sp!  r> swap ! ;
> >>
> >>: long$:  \ compiletime: ( "name" - ) runtime: ( - adr n )
> >> create here depth ,   \ map: n...
> >> does>  lcount ;
> >>
> >> long$: &test2 ( - adr #bytes )  char H char E char Y char !  ;bytes
> >>
> >> &test2 type cr
> >>
> >> Jos
> >>
> > 
> > It's very Win32Forth specific.
> > 
> > Reversing items on the stack, or PICKing them off as you have done
> > with Win32forth's SP@, isn't required. The bytes can be ALLOTed and
> > initialised with C! from last byte to first, rather than using C, and
> > going from first byte to last.
> > 
> 
> Here's my attempt at something a bit more ANS for getting the characters
> off the stack. The assumption is ASCII; supporting extended chars in the
> latest Forth standard would require more work and perhaps a different
> approach.
> 
> : n2str ( cn ... c1 n -- \ for 0 <= n <= MAX-CHAR )
> \ build string |c1|...|cn| at HERE
>   ?dup if
>     here swap allot here 1-
>     do i c! -1 +loop
>   then ;   
> 
> : n2cstring ( cn ... c1 n -- \ for 0 <= n <= MAX-CHAR )
>   dup c, n2str ;
> 
> : n2lstring ( cn ... c1 n -- \ for 0 <= n )
>   dup , n2str ;
> 
> here 0 n2cstring count type 
> here 'a' 'b' 'c' '!' 4 n2cstring count type

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

#36259

On Tuesday, February 3, 2015 at 3:06:35 PM UTC-7, jo...@planet.nl wrote:
> \ Hi Alex,
> \ I agree with you after seeing your code.
> \ My code has been changed as follows:
> 
> : ;bytes   ( numbers... -- )
>     depth last @ name> >body tuck @ - dup>r
>     swap ! here r@ allot
>     dup r> + 1-
>       do   i c! -1  +loop ;
> 
> : long$:  \ compiletime: ( "name" - ) runtime: ( - Adr #items )
>    create depth ,   \ map: n...
>    does>  lcount ;
> 
> long$: &test2 ( - adr #bytes )  char H char E char Y char !  ;bytes
> 
> cr &test2 type cr
> \s

Your code is not ANS-Forth. Neither LAST or NAME> are ANS-Forth. In Forth-83 we had NAME> and LATEST, so I know what NAME> does and I can assume that LAST is a Win32Forth version of LATEST. Some of the other stuff such as DUP>R and LCOUNT most likely are Win32Forth, but I can guess what they do --- apparently Win32Forth doesn't do any optimization, so it has DUP>R that is the same as DUP >R but more efficient --- apparently LCOUNT is like COUNT except with a cell rather than a byte.

The big problem is that you are assuming that the data and code are separate, which is not required in ANS-Forth (it should have been, but wasn't). The effect of this is that the ALLOT in ;BYTES is not necessarily going to provide memory immediately after the count value that is comma'd after the CREATE (the >BODY address) --- on many Forth systems, the DOES> will put its code there.

What you are doing is not possible in ANS-Forth, which is why I didn't do anything like that --- it is sad, but even a trivial programming challenge for a novice requires work-arounds to the failures of ANS-Forth.

My novice package is entirely ANS-Forth. Getting any code  to work under ANS-Forth is not easy! Elizabeth Rather should give me a medal! I could have done better if I had NAME> and LAST available, but they weren't available and they can't be written in ANS-Forth, so I did without. Similarly, I could have done better if I had been able to assume that code and data were separate, but I couldn't assume this, so I did without. Writing in ANS-Forth is an ascetic practice, as it involves doing without quite a lot --- programming in ANS-Forth is like riding a pig instead of a horse, just to prove that it can be done (and claiming that Elizabeth Rather is a real programmer, is like kissing the pig) --- but if you are going to accept ANS-Forth, then you have to do this.

Anyway, in regards to style, you should factor more. Your ;BYTES is too long --- factor out distinctive activities.

P.S. In my Forth I'm not going to have ROLL because it is so inefficient. Also, allowing PICK and ROLL to have a run-time-determined index is problematic for stack-machines that don't have an indexed addressing-mode into the parameter-stack --- this is actually a difficult addressing-mode in implement on a custom processor (the MiniForth didn't have it). ANS-Forth does have ROLL with a run-time-determined index though, so my code is ANS-Forth.

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

#36270

on 04/02/2015 05:19:32,  wrote:
> On Tuesday, February 3, 2015 at 3:06:35 PM UTC-7, jo...@planet.nl
> > wrote:
>> \ Hi Alex,
>> \ I agree with you after seeing your code.
>> \ My code has been changed as follows:
>>
>> : ;bytes   ( numbers... -- )
>>     depth last @ name> >body tuck @ - dup>r
>>     swap ! here r@ allot
>>     dup r> + 1-
>>       do   i c! -1  +loop ;
>>
>> : long$:  \ compiletime: ( "name" - ) runtime: ( - Adr #items )
>>    create depth ,   \ map: n...
>>    does>  lcount ;
>>
>> long$: &test2 ( - adr #bytes )  char H char E char Y char !  ;bytes
>>
>> cr &test2 type cr
>> \s
> 
[snip]

> 
> The big problem is that you are assuming that the data and code are
> separat e, which is not required in ANS-Forth (it should have been,
> but wasn't). Th e effect of this is that the ALLOT in ;BYTES is not
> necessarily going to pr ovide memory immediately after the count value
> that is comma'd after the CR EATE (the >BODY address) --- on many
> Forth systems, the DOES> will put its code there.
> 
> What you are doing is not possible in ANS-Forth, which is why I didn't
> do a nything like that --- it is sad, but even a trivial programming
> challenge f or a novice requires work-arounds to the failures of
> ANS-Forth.

That's a good point re code & data space, but contrary to your assertion,
is possible in ANS; just move the DOES> out into ;BYTES.

: ;bytes   ( numbers... -- )
    depth last @ name> >body tuck @ - dup>r
    swap ! here r@ allot
    dup r> + 1-
      do   i c! -1  +loop 
   does> lcount ;

: long$:  \ compiletime: ( "name" - ) runtime: ( - Adr #items )
   create depth , ;  \ map: n...

long$: &test2 ( - adr #bytes )  char H char E char Y char !  ;bytes

[snip]

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

#36288

On Wednesday, February 4, 2015 at 5:10:44 AM UTC-7, Alex McDonald wrote:
> > The big problem is that you are assuming that the data and code are
> > separat e, which is not required in ANS-Forth (it should have been,
> > but wasn't). Th e effect of this is that the ALLOT in ;BYTES is not
> > necessarily going to pr ovide memory immediately after the count value
> > that is comma'd after the CR EATE (the >BODY address) --- on many
> > Forth systems, the DOES> will put its code there.
> 
> That's a good point re code & data space, but contrary to your assertion,
> is possible in ANS; just move the DOES> out into ;BYTES.

Doing this would still be considered a work-around for the bad design of ANS-Forth.

Here is my upgraded version, that corresponds to the OP's syntax pretty much. Note that W is a constant for 1 CELLS in the novice package.

: drops ( numbers... count -- )
    0 ?do  drop  loop ;    

: long$: ( -- )             \ stream: name
    create  depth , ;       \ the body will be the count, but temporarily holds the depth
    
: <;long$> ( numbers... 'comma -- )    
    locals| 'comma |
    depth  here w - @  - >r     \ count of numbers...
    r@  here w - !              \ store count in the body
    r@ if  0  r@ 1-  do  I pick  'comma execute  -1 +loop  then
    r> drops  
    does>  ( body -- adr cnt )
        dup w +  swap @ ;
        
: ;chars ( numbers... -- )        
    ['] c,  <;long$> ;
    
: ;words ( numbers... -- )    
    ['] ,  <;long$> ;

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

#36292

On Wednesday, February 4, 2015 at 7:22:55 PM UTC-7, hughag...@gmail.com wrote:
> Here is my upgraded version, that corresponds to the OP's syntax pretty much. Note that W is a constant for 1 CELLS in the novice package.
> 
> : drops ( numbers... count -- )
>     0 ?do  drop  loop ;    
> 
> : long$: ( -- )             \ stream: name
>     create  depth , ;       \ the body will be the count, but temporarily holds the depth
>     
> : <;long$> ( numbers... 'comma -- )    
>     locals| 'comma |
>     depth  here w - @  - >r     \ count of numbers...
>     r@  here w - !              \ store count in the body
>     r@ if  0  r@ 1-  do  I pick  'comma execute  -1 +loop  then
>     r> drops  
>     does>  ( body -- adr cnt )
>         dup w +  swap @ ;
>         
> : ;chars ( numbers... -- )        
>     ['] c,  <;long$> ;
>     
> : ;words ( numbers... -- )    
>     ['] ,  <;long$> ;

I messed up! My code is not ANS-Forth because it fails to consider (13.3.3):
"After a definition's locals have been declared, a program may place data on the return stack. However, if this is done, locals shall not be accessed until those values have been removed from the return stack"
My program worked because I tested under VFX that does not use the return-stack for locals --- which just goes to show that testing a program under an ANS-Forth compliant system is no guarantee that the program is ANS-Forth compliant --- riding a pig is possible, but it is not easy!

Here is a new version (note that { is available in the novice package):

: drops ( numbers... count -- )
    0 ?do  drop  loop ;    

: long$: ( -- )                     \ stream: name
    create  depth , ;               \ the body will hold the count, but temporarily holds the depth
    
: <;long$> ( numbers... 'comma -- )    
    >r
    depth  here w - @  - 
    r>  { how-many 'comma -- }
    how-many .
    how-many  here w - !            \ store count in the body
    how-many if  0  how-many 1-  do  I pick  'comma execute  -1 +loop  then
    how-many drops  
    does>  ( body -- adr cnt )
        dup w +  swap @ ;
        
: ;chars ( numbers... -- )        
    ['] c,  <;long$> ;
    
: ;words ( numbers... -- )    
    ['] ,  <;long$> ;

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

#36299

On Wed, 4 Feb 2015 19:04:40 -0800 (PST), hughaguilar96@gmail.com
wrote:

>My program worked because I tested under VFX that does not use the return-s=
>tack for locals

VFX does use the return stack for locals.

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]

#36317

On Thursday, February 5, 2015 at 4:33:21 AM UTC-7, Stephen Pelc wrote:
> On Wed, 4 Feb 2015 19:04:40 -0800 (PST), hughaguilar96@gmail.com
> wrote:
> 
> >My program worked because I tested under VFX that does not use the return-s=
> >tack for locals
> 
> VFX does use the return stack for locals.

You must be using another register (other than ESP) as a frame-pointer to where the locals are stored in the return-stack --- this allows >R and R> to move the return-stack pointer down and up without losing track of where the local frame is.

In my language, I'm using a register as a local-frame pointer into the return stack; this helps boost the speed because the >R data is near the local variables in memory, and may share the same cache line, so data-cache thrashing is reduced. By comparison, if you have a locals stack that is separate from the return-stack, they aren't going to share cache lines because they are going to be widely separated in memory. The downside of my design, is that all the local variables have to be defined early in the colon word prior to >R being used. I require the local variables to all be defined at the very beginning of the colon word. In section (13.3.3) of the ANS-Forth document, we have this restriction:
"Locals shall not be declared until values previously placed on the return stack within the definition have been removed"
This is to ensure that there is no >R data on the return-stack at the time that the local variables get defined and room for them is allotted on the return-stack.

I quoted this from the ANS-Forth document (13.3.3): 
"After a definition's locals have been declared, a program may place data on the return stack. However, if this is done, locals shall not be accessed until those values have been removed from the return stack" 
This was put in the ANS-Forth document to allow an ANS-Forth compiler to use the return-stack pointer as the local-frame pointer, which means that >R and R> can't be used because the location of the local frame will be lost --- it is possible to keep track of >R and R> at compile-time and adjust the offset of from the return-stack pointer to where the local frame is, but this won't work if >R or R> are inside of a BEGIN loop as there is no way to know at compile-time how many of them there will be.

The problem with the ANS-Forth standard, is that the worst-case scenario becomes the standard. In all likelihood, there hasn't been any Forth compiler written in 25 years that has used the return-stack pointer as the local-frame pointer --- this would only be done on a processor with an extreme shortage of registers, which hasn't been an issue since the 1980s --- but it is possible, so a programmer has to assume the worst-case to make his program standard-compliant. I think SwiftForth-v2 does use the return-stack pointer as the local-frame pointer, although I'm not sure if this is still true in v3 or not.

A big problem with Forth-83, was that it standardized implementation --- ANS-Forth was supposed to standardize behavior, rather than implementation. Unfortunately, Elizabeth Rather failed badly at this goal. ANS-Forth has a lot of weird restrictions that allow for specific implementations to be standard (many of these implementations have been obsolete for decades). The implementation in which the return-stack pointer is used as the local-frame pointer, is one example. Another example is how >R and R> use the return-stack, and DO loops use the return-stack also, so >R data can't be carried into DO loops. That bit me in this program, as I originally put the 'COMMA datum on the return stack with >R, but then my program crashed when I used RR@ EXECUTE inside of the DO loop --- so I had to make 'COMMA a local variable --- but then I posted that program not realizing that once I had introduced one local variable, I couldn't continue to use R@ for the other value (what is now the HOW-MANY local variable) --- so I had to change everything around again and convert completely from >R to locals. Programming in ANS-Forth is a major hassle because I have to always keep in mind all of these weird implementation issues, and work around all of the seemingly arbitrary restrictions that ANS-Forth puts in the way --- it is like riding a pig through an obstacle course.

As a fun experiment, try explaining to a novice why >R data can't be accessed inside of a DO loop. You will get to feel stupid! The novice will point out that modern processors have 16 registers, so it is not necessary to use one register for multiple unrelated purposes. The novice will also point out that ANS-Forth shouldn't standardize implementation (the use of the same stack for both >R data and DO loop data), but should only standardize behavior. All in all, ANS-Forth is a complete failure --- the work of an idiot! --- anybody with a modicum of programming experience can see this on their first reading of the ANS-Forth document, which is why nobody wants to become an ANS-Forth programmer.

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

#36325

On Thu, 5 Feb 2015 19:39:14 -0800 (PST), hughaguilar96@gmail.com
wrote:

>On Thursday, February 5, 2015 at 4:33:21 AM UTC-7, Stephen Pelc wrote:
>> On Wed, 4 Feb 2015 19:04:40 -0800 (PST), hughaguilar96@gmail.com
>> wrote:
>>=20
>> >My program worked because I tested under VFX that does not use the retur=
>n-s=3D
>> >tack for locals
>>=20
>> VFX does use the return stack for locals.
>
>You must be using another register (other than ESP) as a frame-pointer to w=
>here the locals are stored in the return-stack --- this allows >R and R> to=
> move the return-stack pointer down and up without losing track of where th=
>e local frame is.

And? Note that the VFX disassembler is very good for inspecting your
code.

[remaining boasts and diatribes snipped]

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]

#36336

On Friday, February 6, 2015 at 4:50:09 AM UTC-7, Stephen Pelc wrote:
> On Thu, 5 Feb 2015 19:39:14 -0800 (PST), hughaguilar96@gmail.com
> wrote:
> 
> >On Thursday, February 5, 2015 at 4:33:21 AM UTC-7, Stephen Pelc wrote:
> >> On Wed, 4 Feb 2015 19:04:40 -0800 (PST), hughaguilar96@gmail.com
> >> wrote:
> >>=20
> >> >My program worked because I tested under VFX that does not use the retur=
> >n-s=3D
> >> >tack for locals
> >>=20
> >> VFX does use the return stack for locals.
> >
> >You must be using another register (other than ESP) as a frame-pointer to w=
> >here the locals are stored in the return-stack --- this allows >R and R> to=
> > move the return-stack pointer down and up without losing track of where th=
> >e local frame is.
> 
> And? Note that the VFX disassembler is very good for inspecting your
> code.

I don't care enough about how VFX works internally to disassemble it --- I just want to write ANS-Forth code and know that it will work on any ANS-Forth compiler --- telling me to disassemble the generated code from VFX is nonsense.

The point I was making, is that you are not using the return-stack pointer as the local-frame pointer --- because of this, it is possible in VFX to use local variables and >R in the same colon word without all the restrictions imposed by section 13.3.3 of the ANS-Forth document --- if I depend upon this however, then I get locked into using VFX because my code is no longer ANS-Forth.

To write ANS-Forth code, it is necessary to assume the worst-case scenario --- in this example, that the return-stack pointer is used as the local-frame pointer, and that all of the restrictions of section 13.3.3 must be adhered to or the program won't work --- but if the worst-case scenario effectively becomes the standard, then what was the point of allowing any other scenario?

The problem with ANS-Forth, is that most of the features clash with each other and can't be used together. Some examples are:
1.) >R data clashes with local variables and they can't be used together (although VFX works around this problem, causing VFX to be non-standard).
2.) >R data clashes with DO loops and they can't be used together (VFX doesn't work around this problem).
3.) >R data clashes with return-addresses and can't be carried between functions.
4.) Code and data clash, because they are both being compiled at HERE --- this problem would be solved if there were two versions of HERE, one for code and one for data (VFX can do this, but this makes VFX non-standard, and VFX doesn't do this as a default).
5.) The control-flow stack clashes with the parameter stack, so they can't be used together (at compile-time, there may be control-flow data on top of the user's data on the parameter-stack, making his data inaccessible).
6.) The floating-point stack clashes with the parameter stack, so they can't be used together (the size of a float is not defined, so if a float is on top of other data on the parameter stack, that other data becomes inaccessible).
7.) Two-cell data is on the same stack as one-cell data --- this is the primary reason why stack-juggling in ANS-Forth becomes so complicated.

There are a couple of explanations for why we have features clashing in ANS-Forth:
1.) The only assembly-language that Elizabeth Rather knows, is PDP-11. The PDP-11 has very few registers, and so it makes sense to use one register for multiple unrelated uses, and just be careful to avoid using these features at the same time (for example, using the return-stack for return-addresses, and for >R data, and for local variables, and for DO loops). Also, the PDP-11 doesn't have a separate cache for code and data (afaik, it didn't have any cache at all), so intermingling code and data in memory doesn't kill the speed as it does on modern processors (also, memory on the PDP-11 was so limited that any trick for saving memory was worthwhile). Elizabeth Rather was still projecting the PDP-11 limitations onto ANS-Forth in 1994, over a decade after the PDP-11 became obsolete.
2.) ANS-Forth was designed, and written in stone, without any reference compiler being implemented. Nobody on the ANS-Forth committee noticed that the features clashed, because they had no compiler to test ANS-Forth on. If they did notice that the features clashed (whoever wrote section 13.3.3 must have), they either didn't realize that this would cause programming in ANS-Forth to be like riding a pig through an obstacle course, or they hoped that this would baffle the riff-raff leaving themselves as an elite priesthood --- this is pretty much the case today, as there is no good way to determine if a program is ANS-Forth or not, so you just have to get a blessing from one of the ANS-Forth compiler vendors (Pelc, Rather or Payson/Ertl) to claim that your program is ANS-Forth (note that our OP is using Win32Forth, so he can't claim that his program is ANS-Forth).

Anyway, the result is that ANS-Forth was a convoluted mess lacking in self-consistency --- the work of an idiot! --- ANS-Forth needs to be flushed, and the ANS-Forth "leading expert" needs to be sacked, if Forth is ever going to be taken seriously.

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

#36300

On Thursday, 5 February 2015 03:04:42 UTC, hughag...@gmail.com  wrote:
> I messed up! My code is not ANS-Forth because it fails to consider (13.3.3):
> "After a definition's locals have been declared, a program may place data on the return stack. However, if this is done, locals shall not be accessed until those values have been removed from the return stack"
> My program worked because I tested under VFX that does not use the return-stack for locals --- which just goes to show that testing a program under an ANS-Forth compliant system is no guarantee that the program is ANS-Forth compliant --- riding a pig is possible, but it is not easy!

Hmmm... Perhaps you could have used a local to hold the thing you are
putting on the return stack! Irony!

The only problem with that is that in ANS Forth locals are initialised 
from the stack, so you'd have to include a dummy 0 at the top of the 
definition to have something for the local to receive. That's one
particular feature of ANS locals that I don't really like. It's not a
show-stopper, but maybe I don't *want* to hold the data-stack parameters
on the stack as locals. I prefer my own system in this regard. On my
system, locals are declared and are initialised to zero. It's up to you
to set them to whatever you want from wherever.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web