Yet another draw of rectangle

[humptydumpty]

Hi all!

Hope to enjoy the reader :)


: hypotenuse->cathetis ( xy XY -- xy xY XY xY ;decomposition )

2over drop over ( xy XY xY )
2swap 2over \ 2tuck
;

: rectangle ( x0y0 x1y1 -- )

2over ( x0y0 x1y1 x0y0 )
hypotenuse->cathetis ( x0y0 x1y1 x1y0 x0y0 x1y0 )
LINE ( x0y0 x1y1 x1y0 )
2over ( x0y0 x1y1 x1y0 x1y1 )
LINE ( x0y0 x1y1 )
hypotenuse->cathetis ( x0y0 x0y1 x1y1 x0y1 )
LINE ( x0y0 x0y1 )
LINE
;



Have a nice day,
humptydumpty

[Robert L.]

On 11/19/2016, humptydumpty wrote:

> : hypotenuse->cathetis ( xy XY -- xy xY XY xY ;decomposition )
>
> 2over drop over ( xy XY xY )
> 2swap 2over \ 2tuck
> ;
>
> : rectangle ( x0y0 x1y1 -- )
>
> 2over ( x0y0 x1y1 x0y0 )
> hypotenuse->cathetis ( x0y0 x1y1 x1y0 x0y0 x1y0 )
> LINE ( x0y0 x1y1 x1y0 )
> 2over ( x0y0 x1y1 x1y0 x1y1 )
> LINE ( x0y0 x1y1 )
> hypotenuse->cathetis ( x0y0 x0y1 x1y1 x0y1 )
> LINE ( x0y0 x0y1 )
> LINE
> ;

Ruby:

def betwixt a,b; [b[0],a[1]]; end

def rectangle( a, b )
[a, betwixt(a,b), b, betwixt(b,a), a].
each_cons(2){|c,d| line c,d}
end

Testing:

def line a,b; puts "#{a} - #{b}";end

rectangle [8,0],[640,480]
===>
[8, 0] - [640, 0]
[640, 0] - [640, 480]
[640, 480] - [8, 480]
[8, 480] - [8, 0]

--
General Mills ... aired a television commercial for ... Cheerios ... promoting
Aryan hybridization with blacks (depicting, as usual, a white woman and a black
man). ... The ad agency responsible for the campaign was ... [Jewish] Saatchi &
Saatchi.... www.counter-currents.com/2013/08/behind-anti-white-advertising

[HAA]

Nice but return stack version posted by Gerry circa 1/2015 gets my tick -
13 instructions (excluding initial move) in one definition compared to 16
split over two here. No tick for appealing to sensibilities of non-Forthers
as they will never be pleased viz. WJ :)

[Paul Rubin]

"HAA" <som...@microsoft.com> writes:
> Nice but return stack version posted by Gerry circa 1/2015 gets my tick -
> 13 instructions (excluding initial move) in one definition compared to 16
> split over two here. No tick for appealing to sensibilities of non-Forthers
> as they will never be pleased viz. WJ :)

Is this ok?

: LINE swap . . cr ;

: rect ( x0 y0 x1 y1 )
2over 2over ( x0 y0 x1 y1 x0 y0 x1 y1 )
-rot swap ( x0 y0 x1 y1 x0 y1 x1 y0 )
LINE ( x0 y0 x1 y1 x0 y1 )
2over LINE ( x0 y0 x1 y1 x0 y1 )
LINE ( x0 y0 x1 y1 )
2drop LINE ;

: test 0 10 1 11 rect ;

Looks like 10 instructions? Test parameters are 0 and 1 for x
coordinates, 10 and 11 for y coordinates.

[hughag...@gmail.com]

I don't recommend passing X and Y on the stack like you do. Use structs such as these:

0
w field pt.x
w field pt.y
constant pt

0
pt field line.a
pt field line.b
constant line

I didn't actually look at your code. Ahhhh --- difficult to get interested --- not my style of Forth.

[HAA]

I believe so. Add the initial MOVETO (2 instructions) and you have a
practical function!

[Paul Rubin]

Paul Rubin <no.e...@nospam.invalid> writes:
> : rect ( x0 y0 x1 y1 ) ...
> 2drop LINE ;


I didn't try hard enough to get rid of some stack motion earlier. Of
course this is shorter:

: rect ( x0 y0 x1 y1 )
2over 2over ( x0 y0 x1 y1 x0 y0 x1 y1 )
-rot swap ( x0 y0 x1 y1 x0 y1 x1 y0 )
LINE ( x0 y0 x1 y1 x0 y1 )

2swap LINE ( x0 y0 x0 y1 )
LINE ( x0 y0 )
LINE ;

Maybe a little more rearrangement is possible.

[humptydumpty]

On Sunday, November 20, 2016 at 11:18:50 AM UTC+2, Paul Rubin wrote:

Hi!

First ( x0y1 x1y0 ) LINE draws a diagonal, not an edge ...

[humptydumpty]

Hi!

Thank you for appreciation !

I founded Gerry version:

: draw-rectangle ( x0 y0 x1 y1 -- )
2over move rot >r >r ( -- x0 x1 ) ( R: -- y0 y1 )
over r@ draw dup r> draw r@ draw r> draw
;

Is nice too!
Remarks: Is based on concept of current-point variable.
DRAW also is relative to current-point variable, and then
updates current-point position to input-point.
For number of operations,
DRAW ( xy -- ) should be based on LINE ( xy XY -- ),
and must update XY with xy.

... but I like factored version more: no variables, no locals,
no return-stack temporaries, just factoring by knowledge.

[Paul Rubin]

humptydumpty <oua...@gmail.com> writes:
> First ( x0y1 x1y0 ) LINE draws a diagonal, not an edge ...

The output I get from "test" is

test 1 10
1 11
0 11
0 10
ok

which corresponds to:

x1y0 LINE x1y1 LINE x0y1 LINE x0y0 LINE

I assumed x0y0 was the starting point. Since only one coordinate
changes before each LINE, they are all edges and not diagonals, unless I
missed something.

[humptydumpty]

On Sunday, November 20, 2016 at 12:16:05 PM UTC+2, Paul Rubin wrote:

Oops, your LINE is relative, based on current-point position,
and takes 2 parameters.
I reasoned that your LINE is LINE ( xy XY -- ), with 4 parameters.
As 2-parameters version is based on that with 4-parameters, should be counted
and current-point update to number of operations.

[HAA]

humptydumpty wrote:
> ...

> Remarks: Is based on concept of current-point variable.
> DRAW also is relative to current-point variable, and then
> updates current-point position to input-point.
> For number of operations,
> DRAW ( xy -- ) should be based on LINE ( xy XY -- ),
> and must update XY with xy.

Given GetX GetY MoveTo Draw it's possible to define

: LINE ( x1 y1 x2 y2 -- )
getx gety 2>r 2swap moveto draw 2r> moveto ;

It should work the same?

[humptydumpty]

Challenge is to draw a rectangle using a 'draw-line'
that takes 4 parameters from data stack: x1 y1 x2 y2.

It was much debated here on c.l.f.

[Rod Pemberton]

Humpty's LINE seems to be consuming 2 x-y pairs per LINE. Unless I'm
mistaken, your LINE seems to be consuming 1 x-y pair per LINE.


Rod Pemberton

[Paul Rubin]

humptydumpty <oua...@gmail.com> writes:
> Challenge is to draw a rectangle using a 'draw-line'
> that takes 4 parameters from data stack: x1 y1 x2 y2.

Oh ok, thanks, I'll make another try later.

[Andrew Haley]

humptydumpty <oua...@gmail.com> wrote:
>
> Challenge is to draw a rectangle using a 'draw-line'
> that takes 4 parameters from data stack: x1 y1 x2 y2.
>
> It was much debated here on c.l.f.

It was, on at least three occasions and the right answer IMO is "don't
do that". Instead keep a current position and it's trivial. That's
Forth: get the design right, the coding falls away. The first time I
remember discussing this on c.l.f was 1995/04/18, twenty-two years
ago.

Message-ID: <3mml5a$q...@usenetw1.news.prodigy.com>
https://groups.google.com/d/msg/comp.lang.forth/igSsORB_CDQ/KWU_XTphpGgJ
https://groups.google.com/forum/#!searchin/comp.lang.forth/subject$3Astack$20AND$20subject$3Amanipulation$20AND$20authorname$3A%22Andrew$20Haley%22|sort:relevance/comp.lang.forth/igSsORB_CDQ/XKLnSqpa0_AJ

Andrew.

[Ilya Tarasov]

: BOX // X1, Y1, X2, Y2, COLOR
4 PICK 4 PICK 4 PICK 7 PICK - 3 PICK HLINE
4 PICK 4 PICK 3 PICK 6 PICK - 3 PICK VLINE
4 PICK 2 PICK 4 PICK 7 PICK - 3 PICK HLINE
2 PICK 4 PICK 3 PICK 6 PICK - 3 PICK VLINE
DROP DROP DROP DROP DROP
;

100 150 200 180 0xFFFF BOX

: BOX // X1, Y1, X2, Y2, COLOR
// 4 3 2 1 0
FRAME{
ARG4 @ ARG3 @ ARG2 @ ARG4 @ - ARG0 @ HLINE
ARG4 @ ARG3 @ ARG1 @ ARG3 @ - ARG0 @ VLINE
ARG4 @ ARG1 @ ARG2 @ ARG4 @ - ARG0 @ HLINE
ARG2 @ ARG3 @ ARG1 @ ARG3 @ - ARG0 @ VLINE
}FRAME
;

300 150 400 180 0xFF00 BOX

: BOX
LOC[
QUAN X1 QUAN X2 QUAN Y1 QUAN Y2 QUAN COLOR
]LOC
TO COLOR TO Y2 TO X2 TO Y1 TO X1

X1 Y1 X2 X1 - COLOR HLINE
X1 Y1 Y2 Y1 - COLOR VLINE
X1 Y2 X2 X1 - COLOR HLINE
X2 Y1 Y2 Y1 - COLOR VLINE
;

500 150 600 180 0xFF0000 BOX

[HAA]

I missed that debate. If RECTANGLE can be created in fewer steps
using DRAW (below) does it not suggest DRAW not LINE is the preferred
primitive? It was the case in a commercial graphics pack I saw.

\ Paul's code with MOVETO
: rect ( x0 y0 x1 y1 )
2over 2dup MOVETO 2over SWAP ROT DRAW
2swap DRAW DRAW DRAW ;

[Paul Rubin]

"HAA" <som...@microsoft.com> writes:
> \ Paul's code with MOVETO
> : rect ( x0 y0 x1 y1 )
> 2over 2dup MOVETO 2over SWAP ROT DRAW
> 2swap DRAW DRAW DRAW ;

Nice, but I think you don't want the 2DUP after the initial 2OVER :

: draw ( x1 y1 -- ) ." draw " swap . . cr ;
: moveto ( x y -- x y ) ." moveto " 2dup swap . . cr ;

: rect ( x0 y0 x1 y1 )

2over MOVETO

2over SWAP ROT DRAW
2swap DRAW DRAW DRAW ;

: test cr clearstack 0 10 1 11 rect ;

giving:

test
moveto 0 10
draw 1 10
draw 1 11
draw 0 11
draw 0 10
ok

[HAA]

MOVETO ( x y -- ) is a general-purpose function in the graphics package and
requires the 2DUP here. I think you have hit on the definitive Forth definition
for RECT. My original was 14 instructions, yours would make it 11.

[Paul Rubin]

"HAA" <som...@microsoft.com> writes:
> MOVETO ( x y -- ) is a general-purpose function in the graphics
> package and requires the 2DUP here. I think you have hit on the
> definitive Forth definition for RECT. My original was 14
> instructions, yours would make it 11.

Heh, I'm sure others have done it better. And the LINE version is still
a pretty annoying challenge. I wrote a "brute force" version with the
idea of refactoring it for fewer operations after writing it; but
getting it working was time consuming and tiring enough that I put it
aside after it worked:

: 4dup 2over 2over ;

: LINE ( x0 y0 x1 y1 -- ) 2>r swap . . 2r> swap . . cr ;

\ & in stack comment means duplicate the input parameters
: r1 ( x0 y0 x1 y1 -- & x0 y0 x1 y0 ) 4dup drop over ;

: r2 ( x0 y0 x1 y1 -- & x1 y0 x1 y1 )
4dup >r -rot nip over r> ;

: r3 ( x0 y0 x1 y1 -- & x1 y1 x1 y0 )
4dup 2swap drop over ;

: r4 ( x0 y0 x1 y1 -- x0 y1 x0 y0 )
nip ( x0 y0 y1 )
>r over r> ( x0 y0 x0 y1 )
-rot swap ;

: rect r1 LINE r2 LINE r3 LINE r4 LINE ;

: test cr clearstack 0 10 1 11 rect ;

Is this really the language we want to entice schoolkids into
programming with?! :)

[Mark Wills]

Guys,

Just use locals and quit with the stack thrashing s**t!

WTF guys???!!!!! <SLAP!>

:-)

[Paul Rubin]

Mark Wills <markwi...@gmail.com> writes:
> Just use locals and quit with the stack thrashing s**t!
> WTF guys???!!!!! <SLAP!>

Heh, what kind of challenge would that be? It's also easy with PICK.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
>
> Is this really the language we want to entice schoolkids into
> programming with?! :)

There's nothing wrong with the language. It's being used
inappropriately.

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> There's nothing wrong with the language. It's being used
> inappropriately.

Aww, I bet you said the same thing about the C++ template
metaprogramming implementation. ;-)

[Robert L.]

I thought that purpose of a programming language was to make
programming as easy as possible.

It seems that the purpose of Forth is to make programming
as hard as possible. It achieves that goal.

--
I do know that Jews are G-d's Chosen People (we say that in Kiddush every
Friday nite). Does that make us different from Gentiles? Clearly. If that's a
problem, deal with it.
web.archive.org/web/20101020044210/http://www.jpost.com/JewishWorld/JewishNews/Article.aspx?id=191782

[HAA]

Mark Wills wrote:
> On Tuesday, 22 November 2016 08:03:00 UTC, Paul Rubin wrote:
> > "HAA" <som...@microsoft.com> writes:
> > > MOVETO ( x y -- ) is a general-purpose function in the graphics
> > > package and requires the 2DUP here. I think you have hit on the
> > > definitive Forth definition for RECT. My original was 14
> > > instructions, yours would make it 11.
> >
> > Heh, I'm sure others have done it better.

Paul, do you really think so? The rect problem has been floating around
since Leo Brodie posed it as a 'worst case scenario' in Thinking Forth.
You should drop him a line with your solution :)

> > Is this really the language we want to entice schoolkids into
> > programming with?! :)

Chuck claimed Forth was the only language that's fun. What other
language entertains children of all ages?

> Guys,
>
> Just use locals and quit with the stack thrashing s**t!
>
> WTF guys???!!!!! <SLAP!>
>
> :-)

Yes but locals double the code size and are no fun at all :)

[rickman]

Which means it needs a MOVE_TO to set a starting point.

--

Rick C

[Paul Rubin]

"HAA" <som...@microsoft.com> writes:
> The rect problem has been floating around since Leo Brodie posed it as
> a 'worst case scenario' in Thinking Forth. You should drop him a line
> with your solution :)

I found the rectangle discussion (called [BOX] in the book) in the local
variables section of chapter 7. He calls them local variables but
they're actually globals since I guess Forth back then didn't have what
we now call locals. Also, he starts with the 4-parameter line drawing
primitive that takes both endpoints, then suggests some alternatives.

Basically he doesn't even try for a stack juggling solution. He
suggests using variables and also suggests reorganizing the API in a few
different ways.

So, I doubt the stuff in this thread would interest him much, especially
after all these years, and with him no longer involved with Forth
afaict.

I remember enjoying the book a lot and thinking it was way ahead of its
time, so I may re-read it. Thanks for the reminder!

[Albert van der Horst]

In article <8737iia...@nightsong.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>"HAA" <som...@microsoft.com> writes:
>> The rect problem has been floating around since Leo Brodie posed it as
>> a 'worst case scenario' in Thinking Forth. You should drop him a line
>> with your solution :)
>
>I found the rectangle discussion (called [BOX] in the book) in the local
>variables section of chapter 7. He calls them local variables but
>they're actually globals since I guess Forth back then didn't have what
>we now call locals. Also, he starts with the 4-parameter line drawing
>primitive that takes both endpoints, then suggests some alternatives.

They may have a lifetime of the program, and they may be accessible
from everywhere, but they are logically locals.
Because in Forth visibility may be manipulated separately from other
aspects, e.g. hiding them can be accomplished by manipulating the
headers in the wordlists, links or some such.

>
>Basically he doesn't even try for a stack juggling solution. He
>suggests using variables and also suggests reorganizing the API in a few
>different ways.

This way of using VARIABLE's is idiomatic Forth, as Elizabeth Rather
has pointed out, time and again.
There is school of dogmatic abhorrence of "global" parameters.
In order to be a good programmer it suffices to be aware of the
this advantages of global data.

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

[foxaudio...@gmail.com]

I dimly remember reading something about that in Thinking Forth. It was challenging what bad thing was going to come along and accidentally clobber your global variable. It's your code so it is your responsibility to to not clobber the variable.

It's very true that after using variables in a definition you could "behead" them in some systems so they are no longer accessible by the compiler.

BF

[Paul Rubin]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> They may have a lifetime of the program, and they may be accessible
> from everywhere, but they are logically locals.

Yeah I understood that and was just mentioning that Forth back then
didn't have locals like now. I don't remember if the Thinking Forth
dialect had wordlists.

> This way of using VARIABLE's is idiomatic Forth, as Elizabeth Rather
> has pointed out, time and again.

Thinking Forth quoted Chuck saying to allocate true globals in the
initialization screen, and pseudo-locals in the same screen where they
were used. Back then the program and data were both held in ram, so if
you had a chunk of code that needed a temp variable, you could probably
afford a permanent ram cell since its ram consumption was much smaller
than the code's.

These days on MCU's, ram is often considerably more scarce than program
memory. So allocating permanent ram for variables needed only
temporarily is even less pleasant than before.

> There is school of dogmatic abhorrence of "global" parameters.
> In order to be a good programmer it suffices to be aware of the
> this advantages of global data.

With today's larger programs things get out of control more easily, but
when the program is small enough, using globals like that is manageable.

[humptydumpty]

On Tuesday, November 22, 2016 at 10:03:00 AM UTC+2, Paul Rubin wrote:

Hi!

What a nightmare! :)

That is because you try to factor using knowledge from programming domain.
But before that, maybe you should factor using knowledge from problem domain,
in this case geometry.

'hypotenuse->cathetis' is such a factor that transform a hypotenuse to cathetis. In our case, rectangle diagonal is the hypotenuse and cathetis are
the 2 concurrent edges of rectangle.

That 'hypotenuse->cathetis' is stack reordering with meaning, that it is.

[rickman]

Funny that you say "no variables, no locals". By using MOVE you have
pushed the use of variables into a lower word that then has to use
global storage to save the coordinates for a later DRAW command.
Likewise the DRAW command has to save those coordinates for the next
command.

If DRAW is given the start and end coordinates the storage in the lower
words is not required. But then you have to work harder to juggle the
stack.

No panacea here.

--

Rick C

[humptydumpty]

Hi!

You misunderstand posts. My solution is pair 'hypotenuse->cathetis' 'rectangle' words. That is factored version.

'draw-rectangle' is Gerry solution, not mine.

[Ron Aaron]

On 22/11/2016 10:02, Paul Rubin wrote:
...

> Is this really the language we want to entice schoolkids into
> programming with?! :)

Maybe! It encourages lateral thinking.

For example, rephrasing the problem so that you have:

: rect \ wide high x y --
... ;

makes it much easier to program in Forth.

It's a good thing to encourage (especially, young) minds to restate
problems in more practical ways. Just because we have been taught to
think of a rectangle as (x0,y0),(x1,y1) does not mean that's the most
appropriate way to think of it in any particular situation.

[Paul Rubin]

Ron Aaron <ramb...@gmail.com> writes:
> For example, rephrasing the problem so that you have:
> : rect \ wide high x y --
> ... ;
> makes it much easier to program in Forth.

Yep. Thinking Forth suggested something like that. Here's my
implementation using the interface it described:

: MOVETO ( x y ) swap . . ." MOVETO" cr ;

: (dm) ( x caddr u -- ) 2>r . 2r> type cr ;
: DOWN ( x -- ) s" DOWN" (dm) ;
: UP ( x -- ) s" UP" (dm) ;
: RIGHT ( x -- ) s" RIGHT" (dm) ;
: LEFT ( x -- ) s" LEFT" (dm) ;

: rec ( x0 y0 x1 y1 -- )
2dup MOVETO
rot - -rot -
2dup RIGHT DOWN LEFT UP ;

: test cr 1 1 5 8 rec ;

[rickman]

I'm not addressing your post vs. anyone else's, I'm commenting on the
trade off between burying the storage in variables in lower words which
will require global variables, vs. juggling the stack. Call it
factoring if you like. It doesn't matter if you encapsulate the stack
juggling in a word "hypotenuse->cathetis" or not. It is still messy
stack juggling. Try writing hypotenuse->cathetis, it's a PITA. BTW,
don't you need *two* hypotenuse->cathetis words, one for each pair of
adjacent sides?

--

Rick C

[Ron Aaron]

On 24/11/2016 7:59, Paul Rubin wrote:
> Ron Aaron <ramb...@gmail.com> writes:
>> For example, rephrasing the problem so that you have:
>> : rect \ wide high x y --
>> ... ;
>> makes it much easier to program in Forth.
>
> Yep. Thinking Forth suggested something like that. Here's my
> implementation using the interface it described:

...

Here's mine: http://8th-dev.com/forum/index.php/topic,1118.0.html

:)

[Elizabeth D. Rather]

On 11/23/16 8:51 AM, foxaudio...@gmail.com wrote:
> I dimly remember reading something about that in Thinking Forth. It was challenging what bad thing was going to come along and accidentally clobber your global variable. It's your code so it is your responsibility to to not clobber the variable.
>
> It's very true that after using variables in a definition you could "behead" them in some systems so they are no longer accessible by the compiler.
>

Any half-way civilized Forth compiler will give you a message if it's
redefining something, so you can examine and fix it if needed. It's
really pretty low-risk.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[hughag...@gmail.com]

Using global variables is idiotic --- this will not be idiomatic Straight Forth.

Elizabeth Rather says:
-----------------------------------------------------------------------
Truly, I don't see the point of all this paranoia about reentrancy,
particularly in systems without a multitasker. VARIABLE was *designed*
for things that would be used in multiple definitions. I remember the horror
of (*gasp*) global variables back in the 1960's in Fortran.
But, frankly, in 30+ years of programming in Forth I never found them a
problem. I think this is all about mythical dragons.
-----------------------------------------------------------------------

Everybody is ignorant on a wide variety of subject. An ignoramus however, is proud of being ignorant, and consequently will never learn.

Here is another quote:
-----------------------------------------------------------------------
I hate locals :-)
-----------------------------------------------------------------------

Elizabeth Rather is an ignoramus --- ANS-Forth was informed by ignorance and driven by arrogance --- ANS-Forth made the entire Forth community appear to be ignorant of even the most rudimentary computer-science concepts, such as reentrancy, that every first-year programmer should be aware of (concepts that I was familiar with when I was still in high-school).

[HAA]

humptydumpty wrote:
> ...

> You misunderstand posts. My solution is pair 'hypotenuse->cathetis' 'rectangle' words.
> That is factored version.
>
> 'draw-rectangle' is Gerry solution, not mine.
>
> Have a nice day,
> humptydumpty

I understand you want to solve the RECT problem as originally
presented but its use of ( x1 y1 x2 y2 ) LINE was flawed from
the beginning.

In a reasonably comprehensive graphics package MOVETO
is essential. The next step is ( x y ) DRAW which then allows
( x1 y1 x2 y2 ) LINE. Using LINE to define RECT is what you
do when there is no other choice. That your factor needs DROP
immediately tells me there is something not optimum about
the use of LINE.

[hughag...@gmail.com]

On Sunday, November 20, 2016 at 12:14:07 AM UTC-7, hughag...@gmail.com wrote:
> I don't recommend passing X and Y on the stack like you do. Use structs such as these:
>
> 0
> w field pt.x
> w field pt.y
> constant pt
>
> 0
> pt field line.a
> pt field line.b
> constant line

I still think that it is best to use structs like this.

Theoretically, a rectangle could be defined like this:

0
pt field rec.a
pt field rec.b \ opposite corner from REC.A
constant rec

As a practical matter however, when would you ever have opposite corners of a rectangle? That is very awkward!

Here is a better definition:

line
w field rec.width \ the line goes down the middle of the rectangle and isn't drawn
constant rec

This would be a lot more useful for drawing pictures! The goal here is that you can write a Forth function that draws a picture, and it will be reasonably readable. Wasn't that pretty much the point of PostScript? How does PostScript represent a rectangle? I don't know PostScript very well (my only PostScript program was for the slide-rule) --- I'm not much interested in graphics --- if I were to get interested, I would start by learning PostScript, as those guys have already put some thought into the subject.

I doubt that the use of structs would be any less efficient or less readable than the use of local variables. Local variables are extremely inefficient in SwiftForth (the local-frame pointer is not in a register; it is in a user-variable) --- so the use of structs would likely be more efficient.

Even if structs are less efficient, who cares? In a graphical package, the OS calls that draw on the screen are going to be the most time-consuming part of the code.

[luser droog]

On Thursday, November 24, 2016 at 8:11:10 PM UTC-6, hughag...@gmail.com wrote:
> On Sunday, November 20, 2016 at 12:14:07 AM UTC-7, hughag...@gmail.com wrote:
> > I don't recommend passing X and Y on the stack like you do. Use structs such as these:
> >
> > 0
> > w field pt.x
> > w field pt.y
> > constant pt
> >
> > 0
> > pt field line.a
> > pt field line.b
> > constant line
>
> I still think that it is best to use structs like this.
>
> Theoretically, a rectangle could be defined like this:
>
> 0
> pt field rec.a
> pt field rec.b \ opposite corner from REC.A
> constant rec
>
> As a practical matter however, when would you ever have opposite corners of a rectangle? That is very awkward!
>
> Here is a better definition:
>
> line
> w field rec.width \ the line goes down the middle of the rectangle and isn't drawn
> constant rec
>
> This would be a lot more useful for drawing pictures! The goal here is that you can write a Forth function that draws a picture, and it will be reasonably readable. Wasn't that pretty much the point of PostScript? How does PostScript represent a rectangle? I don't know PostScript very well (my only PostScript program was for the slide-rule) --- I'm not much interested in graphics --- if I were to get interested, I would start by learning PostScript, as those guys have already put some thought into the subject.

Thanks for the hook! I was looking for a spot to jump in to this thread.

PostScript deals with rectangles a few different ways. In the original
Level 1 standard, the best way is probably with the *relative* operators

dx dy rmoveto -
dx dy rlineto -

So I'd write something like (I'm sure this can be improved:

% w h x y rect -
/rect {
gsave
translate % w h
0 1 index rlineto % w h
exch 0 rlineto % h
0 exch neg rlineto %
closepath
stroke
grestore
} def

Arranging the order of arguments and relative moves let me
get rid of the x y vars right away. Then the stack juggling
is much simpler.

Level 2 has builtin:

x y width height [matrix] rectstroke -
x y width height [matrix] rectfill -

where the matrix is optional.

PostScript organizes its dynamic namespace as a stack of dict
objects. The normal execution model guarantees that each
program starts with a "clean" system, just 3 dicts on the
dictstack

systemdict (read-only, contains all operators)
globaldict (writeable, for data that must persist across
save/restore boundaries)
userdict (writeable)

And it's fine to just put everything in userdict. More
complicated setups are required if you try to make a
postscript-driver (part of your graphics application
that produces ps output) that is DSC-compliant, that
is conforming to the Document Structuring Conventions.
Or when you're trying to make a re-usable component,
then you start to worry about name conflicts and putting
things in their proper little boxes.

[luser droog]

On Thursday, November 24, 2016 at 8:59:00 PM UTC-6, luser droog wrote:
> % w h x y rect -
> /rect {
> gsave
> translate % w h

0 0 moveto

[rickman]

On 11/24/2016 7:54 PM, hughag...@gmail.com wrote:
>
> Elizabeth Rather is an ignoramus --- ANS-Forth was informed by ignorance and driven by arrogance --- ANS-Forth made the entire Forth community appear to be ignorant of even the most rudimentary computer-science concepts, such as reentrancy, that every first-year programmer should be aware of (concepts that I was familiar with when I was still in high-school).

The only ignoramus is someone who can't just get on with their life, but
rather has to obsess over imagined slights and at every opportunity
attack people who have done nothing to you. You are a sick individual.
I don't know how you can keep a job or how you can even function in
society if you display these same behaviors in the rest of your life.

Will you never get over this and get on with your life?

--

Rick C

[Albert van der Horst]

In article <44bc2a65-afbe-4822...@googlegroups.com>,
<hughag...@gmail.com> wrote:
>On Wednesday, November 23, 2016 at 5:38:34 AM UTC-7, Albert van der Horst w=

>rote:
>> In article <8737iia...@nightsong.com>,
>> Paul Rubin <no.e...@nospam.invalid> wrote:
>> >"HAA" <som...@microsoft.com> writes:
>> >> The rect problem has been floating around since Leo Brodie posed it as
>> >> a 'worst case scenario' in Thinking Forth. You should drop him a line
>> >> with your solution :)
>> >
>> >I found the rectangle discussion (called [BOX] in the book) in the local
>> >variables section of chapter 7. He calls them local variables but
>> >they're actually globals since I guess Forth back then didn't have what
>> >we now call locals. Also, he starts with the 4-parameter line drawing
>> >primitive that takes both endpoints, then suggests some alternatives.

>>=20

>> They may have a lifetime of the program, and they may be accessible
>> from everywhere, but they are logically locals.
>> Because in Forth visibility may be manipulated separately from other
>> aspects, e.g. hiding them can be accomplished by manipulating the
>> headers in the wordlists, links or some such.

>>=20

>> >
>> >Basically he doesn't even try for a stack juggling solution. He
>> >suggests using variables and also suggests reorganizing the API in a few
>> >different ways.

>>=20

>> This way of using VARIABLE's is idiomatic Forth, as Elizabeth Rather
>> has pointed out, time and again.
>> There is school of dogmatic abhorrence of "global" parameters.
>> In order to be a good programmer it suffices to be aware of the
>> this advantages of global data.

This must be of course:

"
In order to be a good programmer it suffices to be aware of the

disadvantages of global data.
"

>
>Using global variables is idiotic --- this will not be idiomatic Straight F=
>orth.

I wouldn't put it that strongly but yes.

[HAA]

Robert L. wrote:
> ...

> I thought that purpose of a programming language was to make
> programming as easy as possible.

A programming language is an interface between man and machine.
As needs vary so do programming languages and what is "easy".

> It seems that the purpose of Forth is to make programming
> as hard as possible. It achieves that goal.

Assembler is a programming language. Its goal is to offer the best
flexibility and best speed. It's not the fault of assembler that some
programmers have neither the interest, need, nor capacity to use it.

Offering features no other programming language has, assembler
continues to exist. The same has been true of Forth. That there
are those who want to make Forth compete with other languages
and in doing so draw comparison as you do is not the fault of
Forth's creator who continues to see it as a unique tool.

[hughag...@gmail.com]

On Saturday, November 26, 2016 at 7:32:23 PM UTC-7, HAA wrote:
> Assembler is a programming language. Its goal is to offer the best
> flexibility and best speed. It's not the fault of assembler that some
> programmers have neither the interest, need, nor capacity to use it.
>
> Offering features no other programming language has, assembler
> continues to exist. The same has been true of Forth. That there
> are those who want to make Forth compete with other languages
> and in doing so draw comparison as you do is not the fault of
> Forth's creator who continues to see it as a unique tool.

I want Straight Forth to be competitive with other languages --- maybe Forth's creator will hate it --- or maybe he will just ignore it the same way that he ignored ANS-Forth in the last century and ignores Forth-200x in this century.

I think that Forth is a "unique tool" --- I wouldn't program in Forth if I didn't think so --- but this doesn't mean that Forth programmers have to do without general-purpose data-structures (there should be a distinction between "unique" and "stupid," although some people believe that the words are synonyms).

BTW: You do know that "Robert L." is a sock-puppet for WJ, don't you? I just mark all of his posts as spam without bothering to read them --- most likely Google cancelled his WJ account because everybody marks his posts as spam --- that is why he had to invent a new name for himself.

[HAA]

hughag...@gmail.com wrote:
> ...

> I want Straight Forth to be competitive with other languages --- maybe Forth's creator
> will hate it --- or maybe he will just ignore it the same way that he ignored ANS-Forth
> in the last century and ignores Forth-200x in this century.

Chuck's interviews make it clear he wrote Forth for himself and his views haven't
altered substantially since the 70's. It's an image promoters of Forth would prefer
to avoid.

> BTW: You do know that "Robert L." is a sock-puppet for WJ, don't you?

Content and sig unmistakeable. Using assembler as my example was deliberate.
If I were going to compare Forth with another language it would be asm - same
building-block approach, emphasis on code generation, and low-level access to
everything. Comparing Forth with little-in-common languages like Ruby doesn't
work for me, and I doubt anyone else.

[Elizabeth D. Rather]

On 11/27/16 6:00 PM, HAA wrote:
> hughag...@gmail.com wrote:
>> ...
>> I want Straight Forth to be competitive with other languages --- maybe Forth's creator
>> will hate it --- or maybe he will just ignore it the same way that he ignored ANS-Forth
>> in the last century and ignores Forth-200x in this century.
>
> Chuck's interviews make it clear he wrote Forth for himself and his views haven't
> altered substantially since the 70's. It's an image promoters of Forth would prefer
> to avoid.

Chuck probably hasn't changed much, it's true. But Forth had outgrown
Chuck by 1980, and has been extended and used on virtually every CPU on
the market since then, by thousands of programmers and in thousands of
successful projects. There are standards, and they have evolved. Forth
may have begun as Chuck's personal productivity tool, but like many
technologies, it outgrew its inventor.

>> BTW: You do know that "Robert L." is a sock-puppet for WJ, don't you?
>
> Content and sig unmistakeable. Using assembler as my example was deliberate.
> If I were going to compare Forth with another language it would be asm - same
> building-block approach, emphasis on code generation, and low-level access to
> everything. Comparing Forth with little-in-common languages like Ruby doesn't
> work for me, and I doubt anyone else.

Yes, quite recognizable, and quite useless.

[hughag...@gmail.com]

On Sunday, November 27, 2016 at 9:00:45 PM UTC-7, HAA wrote:
> hughag...@gmail.com wrote:
> > ...
> > I want Straight Forth to be competitive with other languages --- maybe Forth's creator
> > will hate it --- or maybe he will just ignore it the same way that he ignored ANS-Forth
> > in the last century and ignores Forth-200x in this century.
>
> Chuck's interviews make it clear he wrote Forth for himself and his views haven't
> altered substantially since the 70's. It's an image promoters of Forth would prefer
> to avoid.

Well, yes and no.

According to Jeff Fox, the cause of him leaving Forth Inc. was that Elizabeth Rather wanted to sue FIG for pirating Forth Inc.'s MicroForth and releasing it into the public-domain as FIGforth. She wanted the Forth language to be proprietary to Forth Inc.. She would have also liked to sue Laboratory MicroSystems Inc. (LMI) for selling PC/Forth and UR/Forth in competition with Forth Inc. (their products weren't pirated directly from Forth Inc.'s PolyForth, but they did have the same "look and feel"). Charles Moore refused to support these lawsuits and this was the irreconcialiable difference that forced him to leave Forth Inc. in 1982. He contacted FIG and told them they could continue distributing FIGforth, but they couldn't pirate any of his more recent Forth systems which were better, and they agreed. As for LMI, they didn't pirate his code so he didn't think they were his concern --- same with the variety of other Forth systems available, from public-domain to shareware to commercial --- he seemed to be friends with C.H.Ting, and was at least friendly toward the other Forth developers.

So, no, he didn't want Forth to only for himself --- he was okay with other people writing their own Forth systems and/or writing application programs in Forth --- he didn't demand money from them.

But, yes, he declined to take a leadership role and tell people what they can and cannot do with Forth --- he wasn't involved in ANS-Forth that is all about telling people what they can't do with Forth --- he seemed to be content with letting people do what they want with Forth, and he seemed to even expect that some of them would do something intelligent that he hadn't thought of himself.

Despite what the ANS-Forth and Forth-200x proponents say, he doesn't support them, and he isn't opposed to my Straight Forth either --- he is still waiting for somebody to do something intelligent --- it has been 40 years now, which is a pretty long wait.

> > BTW: You do know that "Robert L." is a sock-puppet for WJ, don't you?
>
> Content and sig unmistakeable. Using assembler as my example was deliberate.
> If I were going to compare Forth with another language it would be asm - same
> building-block approach, emphasis on code generation, and low-level access to
> everything. Comparing Forth with little-in-common languages like Ruby doesn't
> work for me, and I doubt anyone else.

It would make more sense to compare Forth to C than to assembler --- Forth and C have similar uses --- of course, C has been described as a portable assembly-language, and for a long time I thought of Forth as being an over-grown macro-assembler, so comparing both of them to assembler is reasonable.

As for Ruby, Python, etc., they are very different from both Forth and C and comparisons don't make much sense. My Straight Forth does have quotations, which ANS-Forth and Forth-200x lack (although my rquotations are an easy upgrade) --- so I'm closer to these Lisp-derived languages than either C or Forth-200x --- my Straight Forth is still a low-level language though (it doesn't have tagged data), so comparing it to languages with tagged data (Ruby, Python, Oforth, Factor, etc.) is comparing apples to oranges.

I'm not opposed to Ruby, Python etc.. If I were to get into web-development, I would go with one of these because they have web-frameworks available --- Rails was Ruby's killer-application; it would still be largely unknown if Rails hadn't been developed --- all of these languages produce code that is slow as molasses though, so they aren't good choices for CAM which is my own interest.

[HAA]

hughag...@gmail.com wrote:
> ...

> It would make more sense to compare Forth to C than to assembler --- Forth and C have
> similar uses --- of course, C has been described as a portable assembly-language, and
> for a long time I thought of Forth as being an over-grown macro-assembler, so comparing
> both of them to assembler is reasonable.

Interesting C being described that way. It's low level in a sense but users are still at
the mercy of compiler, presupplied libraries and standards. Forth is one of the few
languages that's truly 'grass roots' - where users could create from ground up. No
reliance on anybody or thing. Anyone that's used MASM has probably discovered
there are things which can't be done, except perhaps awkwardly. So Forth gets a
tick over asm :)

[Rod Pemberton]

On Tue, 29 Nov 2016 15:22:40 +1100
"HAA" <som...@microsoft.com> wrote:

"... where users could create from [the] ground up."

I'd argue that statement describes the failing of Forth, not it's
merit. That's part of the reason why Forth is called a "write-once"
language. The others being that it's simple syntax can be
exceptionally cryptic, the code can be untraceable or difficult to
understand, and Forth requires the user to juggle stack items. Without
a large, standardized, and ubiquitous set of functionality, every Forth
application has to develop it's own solution to the same basic
programming problems and situations. This requires extra work, time or
man-hours, on the part of the programmer, and interferes with
portability, as the resulting code is non-standard. The code is unique
to that application, when every application could've used the same
functionality. It also means that any bad solutions or poor designs
will be passed along forever with that application. It also means that
numerous programs will most assuredly have bad, buggy, or limited
implementations of functionality which is commonly used. A programmer
needs to have a certain set of standard tools or components which are
widely available and easy to use.


Rod Pemberton

[Elizabeth D. Rather]

On 11/28/16 7:42 PM, Rod Pemberton wrote:
> On Tue, 29 Nov 2016 15:22:40 +1100
> "HAA" <som...@microsoft.com> wrote:
>
>> hughag...@gmail.com wrote:
>
>>> It would make more sense to compare Forth to C than to assembler
>>> --- Forth and C have similar uses --- of course, C has been
>>> described as a portable assembly-language, and for a long time I
>>> thought of Forth as being an over-grown macro-assembler, so
>>> comparing both of them to assembler is reasonable.
>>
>> Interesting C being described that way. It's low level in a sense
>> but users are still at the mercy of compiler, presupplied libraries
>> and standards. Forth is one of the few languages that's truly 'grass
>> roots' - where users could create from ground up. No reliance on
>> anybody or thing. Anyone that's used MASM has probably discovered
>> there are things which can't be done, except perhaps awkwardly. So
>> Forth gets a tick over asm :)
>>
>
> "... where users could create from [the] ground up."
>
> I'd argue that statement describes the failing of Forth, not it's
> merit. That's part of the reason why Forth is called a "write-once"
> language.

Typical complaints of Forth newbies, contrary to the experience of
people who have experience via a course, good tutorials, or the chance
to work alongside experienced Forth programmers.

> The others being that it's simple syntax can be
> exceptionally cryptic, the code can be untraceable or difficult to
> understand, and Forth requires the user to juggle stack items.

Again, not the experience of those who have actually written one or more
Forth applications. Yes, Forth doesn't "look like" C or the
algol-derivatives or Fortran-derivatives. But it's really simpler than
any of the others, and quite easy to pick up if you can resist trying to
program "the way you always do".

> Without
> a large, standardized, and ubiquitous set of functionality, every Forth
> application has to develop it's own solution to the same basic
> programming problems and situations. This requires extra work, time or
> man-hours, on the part of the programmer, and interferes with
> portability, as the resulting code is non-standard. The code is unique
> to that application, when every application could've used the same
> functionality.

Chuck first described Forth as an "application-oriented language." The
fact is, not all applications require the same functionality, and even
consecutive applications in similar application domains have different
constraints and requirements. I worked with Chuck on ~8 image-processing
applications, for example. He quickly developed an approach very much
like later OOP systems, in which an "image" was a basic object and
possessed characteristic methods, etc. But they were all very different
in detail, and although they shared a common overall paradigm, the code
differed a lot. But each one was developed to completion in 2-3 weeks,
despite estimates from our customers of months of development, even
using "standard libraries".

Chuck kept for many years a microfilm cache of his past applications,
from which he extracted math functions, graphics capabilities, device
drivers, and much more... and re-wrote them every time to adapt to the
situation at hand. And every time he had his code up and running far
faster than our customer has expected of programmers using "standard
libraries". And they were usually faster, smaller, and more accurate.
And I have seen similar results from a long line of outstanding Forth
progrmmers I've worked with over the years. It's really hard to
understand the power of Forth as a "dabbler" or even from implementing a
DIY Forth. It's power is in developing real-world applications.

It also means that any bad solutions or poor designs
> will be passed along forever with that application. It also means that
> numerous programs will most assuredly have bad, buggy, or limited
> implementations of functionality which is commonly used. A programmer
> needs to have a certain set of standard tools or components which are
> widely available and easy to use.

That is only true for incompetent programmers, and incompetent
programmers can produce awful results in any language.

[john]

> In article <20161129004209.27f63172@_>, NeedNotR...@xrsevnneqk.cem says...
>
. . .

This is a good point. The problem is - in whose interest is it to solve it?

The forth world is so fragmented that everyone wants to take credit for
writing their own forth and almost none ever have any real use.
Its a tunnel vision thing I think.

It doesn't just apply to forth. You can say the same about various other
languages or products. Especially the OOP based ones.
Look at the number of OOP designed games the creators just dump
rather than release new levels - there's more money in releasing
a "new" product than expanding an existing one
In the pascal/Delphi/lazarus world everyone seems to want credit
for creating yet another slightly modified copy of the same package and seldom
tries to build or really create anything more complete that solves anything.

While doing some research about a month ago we found a couple of
really good Forth scientific libraries online - but they really were
well hidden (not purposefully I don't think)

I told jim at the time we could spare some bandwidth and offer a forth
library online if he wanted. He made the suggestion here and was
promptly ignored. So perhaps no one really cares enough to bother?
No enough kudos perhaps.

There are forth FTP and other sites out there but they are more
like unmanaged "code dumps" than libraries. It's hard
to know if their creators tried and lost interest because of
everyone elses apathy about forth. People don't seem to
want to actually use "forth" as much as they want to be known
as a "creator" of "A" forth.

Code dumps and link pages are easy - libraries take work.
It all comes down to money and time and enthusiasm though.

--
john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/

=========================

[Albert van der Horst]

In article <20161129004209.27f63172@_>,

Rod Pemberton <NeedNotR...@xrsevnneqk.cem> wrote:
>On Tue, 29 Nov 2016 15:22:40 +1100

>I'd argue that statement describes the failing of Forth, not it's
>merit. That's part of the reason why Forth is called a "write-once"
>language. The others being that it's simple syntax can be
>exceptionally cryptic, the code can be untraceable or difficult to
>understand, and Forth requires the user to juggle stack items. Without
>a large, standardized, and ubiquitous set of functionality, every Forth
>application has to develop it's own solution to the same basic
>programming problems and situations. This requires extra work, time or
>man-hours, on the part of the programmer, and interferes with
>portability, as the resulting code is non-standard. The code is unique
>to that application, when every application could've used the same
>functionality. It also means that any bad solutions or poor designs
>will be passed along forever with that application. It also means that

My experience is that by using a previous design for a slightly
different application exposes the flaws of the design.
Very often when I discovered that I couldn't make a required change
to a program, after redesigning it a bit, the change became trivial,
sometimes even a one line changes.
So reuse of code results in reusable code.

>numerous programs will most assuredly have bad, buggy, or limited
>implementations of functionality which is commonly used. A programmer
>needs to have a certain set of standard tools or components which are
>widely available and easy to use.

They must be based on abstractions and most abstractions are leaky.
So as long as you stay on the highway all goes smooth.
Now try to make terminal program that works through USB with
most of the single board computers on Windows, like I did.

>
>
>Rod Pemberton

[Stephen Pelc]

On Tue, 29 Nov 2016 11:48:18 -0000, john <an...@example.com> wrote:

>There are forth FTP and other sites out there but they are more
>like unmanaged "code dumps" than libraries.

Gerald Wodni has put a lot of effort into the package manager
and site at
http://theforth.net/
Because it already has a package manager and support from several
people in the Forth community, it is to be encouraged rather than
copied.

Stephen

--
Stephen Pelc, steph...@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

[john]

> In article <583d8e51....@news.eternal-september.org>, ste...@mpeforth.com says...

>
> On Tue, 29 Nov 2016 11:48:18 -0000, john <an...@example.com> wrote:
>
> >There are forth FTP and other sites out there but they are more
> >like unmanaged "code dumps" than libraries.
>
> Gerald Wodni has put a lot of effort into the package manager
> and site at
> http://theforth.net/
> Because it already has a package manager and support from several
> people in the Forth community, it is to be encouraged rather than
> copied.
>
> Stephen

Now that's more like it Stephen.
Absolutely this should be used.

But needs more promotion maybe?
(It didnt show up on our lists and a site that useful really needs to be
found easier... )

If Gerold wants an ad on our site he'd be very welcome
(I don't charge - anyone else welcome too within reason)

[Elizabeth D. Rather]

It's also a property of comp.lang.forth. There's a whole world of
professional Forth programmers working on major projects. That community
is in touch with suppliers such as FORTH, Inc. and MPE and a few of the
professionals here, but most of the people on comp.lang.forth are here
out of intellectual curiosity or other motivations and either do their
professional work in other languages or aren't professional programmers.

> It doesn't just apply to forth. You can say the same about various other
> languages or products. Especially the OOP based ones.
> Look at the number of OOP designed games the creators just dump
> rather than release new levels - there's more money in releasing
> a "new" product than expanding an existing one
> In the pascal/Delphi/lazarus world everyone seems to want credit
> for creating yet another slightly modified copy of the same package and seldom
> tries to build or really create anything more complete that solves anything.

Again, that may be an indication of what brings people to
comp.lang.<whatever>.

> While doing some research about a month ago we found a couple of
> really good Forth scientific libraries online - but they really were
> well hidden (not purposefully I don't think)
>
> I told jim at the time we could spare some bandwidth and offer a forth
> library online if he wanted. He made the suggestion here and was
> promptly ignored. So perhaps no one really cares enough to bother?
> No enough kudos perhaps.
>
> There are forth FTP and other sites out there but they are more
> like unmanaged "code dumps" than libraries. It's hard
> to know if their creators tried and lost interest because of
> everyone elses apathy about forth. People don't seem to
> want to actually use "forth" as much as they want to be known
> as a "creator" of "A" forth.
>
> Code dumps and link pages are easy - libraries take work.
> It all comes down to money and time and enthusiasm though.

As I said above, that's typical of some online communities. Professional
Forthers are generally pretty busy working on some project under
deadline. In their spare time hanging out on a hobbyist board is the
last thing they want to do. I am grateful to the few professionals here
who provide that point of view.

[Paul Rubin]

humptydumpty <oua...@gmail.com> writes:
> 'hypotenuse->cathetis' is such a factor that transform a hypotenuse to
> cathetis. In our case, rectangle diagonal is the hypotenuse and
> cathetis are the 2 concurrent edges of rectangle.

Thanks, I didn't know that word before. Wikipedia spells it differently
but I think this is what you meant:

https://en.wikipedia.org/wiki/Cathetus

Meanwhile I ran an exhaustive search program and found there is no 10
word solution. That search took about 13 hours on my i7-3770.
Searching for 11 word solutions would take between 1 and 2 weeks. I'd
rather try a better algorithm.

[hughag...@gmail.com]

On Tuesday, November 29, 2016 at 1:20:53 AM UTC-7, Elizabeth D. Rather wrote:
> On 11/28/16 7:42 PM, Rod Pemberton wrote:
> > "... where users could create from [the] ground up."
> >
> > I'd argue that statement describes the failing of Forth, not it's
> > merit. That's part of the reason why Forth is called a "write-once"
> > language.

I marked Rod Pemberton's post as spam so it won't appear under Google Groups.

Rod Pemberton is a troll promoting C on comp.lang.forth (also comp.lang.asm.x86 and alt.lang.asm) and likely other forums --- he is no different than WJ (aka Robert L.) who promotes Ruby (used to promote Gauche Scheme but apparently got told to stop by the Gauche Scheme developers, and who used to promote Oforth but got told to stop by Franck).

Only an idiot would respond to a Rod Pemberton post.

> Again, not the experience of those who have actually written one or more
> Forth applications.

And here we have our idiot responding to the Rod Pemberton post.

Elizabeth Rather has never written even one Forth application. All of the Forth code she has posted on comp.lang.forth was copied directly out of the "Starting Forth" book. She also knows almost nothing about computer programming. There is no evidence to indicate that she knows about any data-structure other than the array. There is no evidence to indicate that she knows what structs are. There is no evidence to indicate that she knows what a circular buffer is or how an ISR works.

> Chuck kept for many years a microfilm cache of his past applications,
> from which he extracted math functions, graphics capabilities, device
> drivers, and much more... and re-wrote them every time to adapt to the
> situation at hand. And every time he had his code up and running far
> faster than our customer has expected of programmers using "standard
> libraries". And they were usually faster, smaller, and more accurate.
> And I have seen similar results from a long line of outstanding Forth
> progrmmers I've worked with over the years. It's really hard to
> understand the power of Forth as a "dabbler" or even from implementing a
> DIY Forth. It's power is in developing real-world applications.

You are describing writing new programs by cut-and-paste-and-tweak of old programs. This is stupid:

1.) Tweaking old code is very error-prone and usually introduces bugs --- with code-libraries that were tested, you can be sure that they will continue to work, because the code isn't being modified and so bugs can't be introduced.

2.) Tweaking old code results in bloated hard-to-read source-code because the low-level iteration-code is mixed together with the application code. It is better to hide the iteration-code inside of HOFs.

We have much better software now than we did in the 1970s. Part of the reason is that computers are bigger and more powerful and hence can support bigger programs that do more. More important though, is that we have code-libraries and better languages now --- if we were still using 1970s programming techniques (cut-and-paste-and-tweak) today, our programs would still be at the 1970s level in what they could do --- we would not have the internet; we would be programming in C; we would consider WordStar to be the ultimate in what a computer is capable of.

[hughag...@gmail.com]

On Tuesday, November 29, 2016 at 7:24:02 AM UTC-7, Stephen Pelc wrote:
> On Tue, 29 Nov 2016 11:48:18 -0000, john <an...@example.com> wrote:
>
> >There are forth FTP and other sites out there but they are more
> >like unmanaged "code dumps" than libraries.
>
> Gerald Wodni has put a lot of effort into the package manager
> and site at
> http://theforth.net/
> Because it already has a package manager and support from several
> people in the Forth community, it is to be encouraged rather than
> copied.

I haven't looked at that, and I won't bother. I can't contribute to it, so I have no interest in using it.

I did glance over FFL (Forth Foundation Library) and it was terrible. I looked at the singly-linked-list implementation and their EACH (or whatever they called it) held its own data on the data-stack when executing the xt, so it couldn't access the data on the data-stack that the parent function had left there. That is utterly stupid! I pointed this out, and the problem got fixed. Here is the new function:

: scl-execute ( i*x xt scl -- j*x = Execute xt for every cell data in list )
snl-first@ \ walk = first
BEGIN
nil<>? \ while walk<>nil do
WHILE
dup >r scn-cell@
swap
dup >r execute \ execute xt with cell
r> r>
snn-next@ \ walk = walk->next
REPEAT
drop
;

Notice how it is holding the internal data on the return-stack so it is not sitting on top of the data left by the calling function. I was the one who pointed out the need for this, but notice that Stephen Pelc doesn't give me credit for this.

Notice that scl-execute still has a bug in it. It is obtaining the next node after executing the xt. This is a bug because the current node may get destroyed by the xt's code, in which case the link to the next node is no longer valid. A typical example would be if the xt removes the node from the list and appends it to another list, in which case the link would be set to NIL because the node is now the tail node of the other list.

This is my EACH in the novice-package (working correctly since 2010):

: each ( i*x head 'toucher -- j*x ) \ toucher: i*x node -- j*x
>r
begin dup while \ -- node \r: -- 'toucher
r@ over .fore @ >r \ -- node 'toucher \r: -- 'toucher next
execute r> repeat drop
rdrop ;

Notice how my EACH is more efficient than scl-execute because I'm only doing one >R and one R> inside of the loop, whereas scl-execute is doing two >R and two R> inside of the loop. Also notice how my EACH is short and readable --- all of the FFL code is over-complicated and hard-to-read.

I haven't bothered to look at the rest of FFL. The fact that I had to point out the need for their scl-execute to hold its own data on the return-stack was not a confidence builder. And, scl-execute still has the bug in which it obtains the next node after doing the EXECUTE rather than before, which is pretty dumb. All in all, FFL looks worthless to me --- I'm not going to waste any further time in debugging it --- FFL certainly does have a grandiloquent name though!

I have my novice package: http://www.forth.org/novice.html

It is not an "unmanaged code dump" --- it is a code-library with documentation --- I have general-purpose data-structures in which you give an xt to a HOF in the usual way of modern languages.

In a few days I will release a new version with my string-stack.4th package, my OOP package, my disambiguifiers, and various other code. I have all this new code, so I might as well release it. This will likely be the last release of the novice package though --- it is pointless --- the only result has been flames such as these:

John Passaniti:
crap

Elizabeth Rather:
Does "*every* application" you write use exactly the same kind of data
arranged in the same way? If so, having written it once you can reuse it
often. If not, you either have to rearrange your data to make it work or
modify your "general-purpose" structure.

Stephen Pelc:
RTFM!

Alex McDonald:
You have serious misunderstanding of how pointers work.
You really don't understand how CREATE DOES> works.

etc., etc..

[Rod Pemberton]

On Tue, 29 Nov 2016 17:18:28 -0800 (PST)
hughag...@gmail.com wrote:

[OT, yet another attempt to infuse Hugh with some reason]

> I marked Rod Pemberton's post as spam so it won't appear under Google
> Groups.
>

Well, it seems that a few someones did me a favor then, as you'll need
to remark it as spam, yet again ... I guess we won't be hearing from
you for a few days, since you'll be involved in "spam" flag war on
Google Groups? LOL.

Hugh, I truly don't care if you mark it as spam on Google Groups, as
someone only needs to click on GG "spam" messages to read them. But, I
really don't know why you'd be marking Usenet messages as spam on
Google Groups. That seems like a pointless waste of your time, much
like your incessant rants and personal attacks on the most active of
those who post to comp.lang.forth. But, only you can decide to keep
on attacking windmills. Most who read c.l.f. are likely actually
reading and posting to Usenet from Usenet, not Google Groups. FYI, for
the past few years, someone was marking _ALL_ of your posts as spam on
Google Groups. No, it wasn't me.

Personally, I still think that you're still "butt hurt" that no
serious Forth programmers here happen to like your "novice" Forth
package, or that they keep pointing out the flaws it has. I don't
think you should take this personally, as I assume they would "help" to
"fix" my Forth as well, should it ever be released. Someone has to
keep Forth standards high, you just happened to be earlier in line ...

> Rod Pemberton is a troll promoting C on comp.lang.forth (also
> comp.lang.asm.x86 and alt.lang.asm) and likely other forums

FYI, a troll would not be skilled in x86 assembly and C, nor would
said troll be implementing a Forth interpreter, which passes much of
Hayes Core. I'm just expressing my perspective and programming
experience in full, so as to share it with others. I think it has
value, just a others here do about their experiences. This is no
different than many who post here, including Ms. Rather, Rick "rickman"
C., Paul Rubin, Anton Ertl, Bernd Paysan, Hugh Aguilar (yes, even
you...), and many others, but to a far lesser extent. Yes, I know that
not everyone will accept my experience as theirs. Yes, I understand
that they share competing perspectives, which can only be rebutted via
alternate experiences of their own. Does that mean such perspectives
shouldn't be shared? Some would call that censorship or suppression.
Who gave you that right? c.l.f. is not moderated. Of course, you could
call all of those people above whom I mentioned trolls too, as Bernd
goes off on microprocessors and history, rickman on micro-processors,
Rubin on C, Ms. Rather on Forth history, etc. So, who are you really
barking at on this troll thing, Hugh? Are you preaching to the
choir ... of trolls?

> > Again, not the experience of those who have actually written one or
> > more Forth applications.
>
> And here we have our idiot responding to the Rod Pemberton post.

Well, we apparently have more than one, whom you would classify as
such. Perhaps, they don't give a damn anymore about your perspective,
given that you incessantly attack them, or won't stop with your rather
hostile variant of pro-Forth, yet anti-Forth establishment, rants?
Since no one seems to share your perspectives, I'm assuming that you
truly appear to be insane to almost everyone here.

> Elizabeth Rather has never written even one Forth application.

> [...]

I'm sure you'd argue that your statement is or was the truth. But, how
is that even remotely related to Forth programming? Does simply
mentioning "Forth" in a sentence while attacking someone now constitute
"on-topic" behavior for c.l.f.? If a troll is defined as one who posts
"off-topic" stuff with an attempt to incite others into arguments for
their amusement, then your rants, personal attacks, and demonification
of Forth standards, are Troll behavior. How could they be received as
anything but that? IIRC, there have been about half a dozen people
who've called you out as such.


Rod Pemberton

[Ron Aaron]

On 29/11/2016 10:20, Elizabeth D. Rather wrote:
> On 11/28/16 7:42 PM, Rod Pemberton wrote:
>> Without a large, standardized, and ubiquitous set of functionality, every Forth
>> application has to develop it's own solution to the same basic
>> programming problems and situations. This requires extra work, time or
>> man-hours, on the part of the programmer, and interferes with
>> portability, as the resulting code is non-standard. The code is unique
>> to that application, when every application could've used the same
>> functionality.

> Chuck first described Forth as an "application-oriented language." The
> fact is, not all applications require the same functionality, and even
> consecutive applications in similar application domains have different

> constraints and requirements...

> It also means that any bad solutions or poor designs
> will be passed along forever with that application. It also means that
> numerous programs will most assuredly have bad, buggy, or limited
> implementations of functionality which is commonly used.

Elizabeth, I fail to understand the objection to a standardized library
of working code. Most application code uses and re-uses various
building-blocks, and those can be profitably put into a common library.
Witness the extreme success of the lowly C standard library.

What you don't mention is that while a bad solution or a poor design may
be propagated, in general that is not the case. The community of users
makes fixes, improvements and suggestions, and these get rolled into the
standard libraries.

A "standard library" does not mean an immutable implementation.

Furthermore, by pushing the need to create, e.g. an "array"
implementation every time one needs an array, you guarantee that *more*
mistakes will be made.

[Elizabeth D. Rather]

On 11/29/16 7:08 PM, Ron Aaron wrote:
>
>
> On 29/11/2016 10:20, Elizabeth D. Rather wrote:
>> On 11/28/16 7:42 PM, Rod Pemberton wrote:
>>> Without a large, standardized, and ubiquitous set of functionality, every Forth
>>> application has to develop it's own solution to the same basic
>>> programming problems and situations. This requires extra work, time or
>>> man-hours, on the part of the programmer, and interferes with
>>> portability, as the resulting code is non-standard. The code is unique
>>> to that application, when every application could've used the same
>>> functionality.
>
>> Chuck first described Forth as an "application-oriented language." The
>> fact is, not all applications require the same functionality, and even
>> consecutive applications in similar application domains have different
>> constraints and requirements...
>
>> It also means that any bad solutions or poor designs
>> will be passed along forever with that application. It also means that
>> numerous programs will most assuredly have bad, buggy, or limited
>> implementations of functionality which is commonly used.
>
> Elizabeth, I fail to understand the objection to a standardized library
> of working code. Most application code uses and re-uses various
> building-blocks, and those can be profitably put into a common library.
> Witness the extreme success of the lowly C standard library.

I have no objection whatever to a standardized library of Forth code. I
have supported the Forth Math Library by including it with FORTH, Inc.
products since the '90's even though many people criticize it for
containing a lot of really bad code and few widely useful functions. It
would be wonderful if more people directed their efforts toward useful
library functions rather the "Yet another Forth implementation". I
merely offer my view as to why this hasn't happened much.

> What you don't mention is that while a bad solution or a poor design may
> be propagated, in general that is not the case. The community of users
> makes fixes, improvements and suggestions, and these get rolled into the
> standard libraries.
>
> A "standard library" does not mean an immutable implementation.

A "standard library" would be wonderful. I invite you do propose one.

> Furthermore, by pushing the need to create, e.g. an "array"
> implementation every time one needs an array, you guarantee that *more*
> mistakes will be made.

Many implementations and virtually all manuals include an array, like:

: ARRAY ( n ) CELLS ALLOT
DOES> ( i - a ) SWAP CELLS + ;

On the other hand, this took me less than a minute to type. What's the
big deal? I suggest that the real reason Forth libraries haven't caught
on is that it's easier to write the words than to search the internet
for versions someone else wrote that don't do exactly what you want.

[Alex]

On 11/30/2016 02:15, hughag...@gmail.com wrote:

>
> Notice how it is holding the internal data on the return-stack so it
> is not sitting on top of the data left by the calling function. I was
> the one who pointed out the need for this, but notice that Stephen
> Pelc doesn't give me credit for this.
>

Hahahaha! No credit...

> This is my EACH in the novice-package (working correctly since
> 2010):
>
> : each ( i*x head 'toucher -- j*x ) \ toucher: i*x
> node -- j*x
>> r
> begin dup while \ -- node
> \r: -- 'toucher r@ over .fore @ >r \ -- node
> 'toucher \r: -- 'toucher next execute r> repeat drop
> rdrop ;
>
> Notice how my EACH is more efficient than scl-execute because I'm
> only doing one >R and one R> inside of the loop, whereas scl-execute
> is doing two >R and two R> inside of the loop. Also notice how my
> EACH is short and readable --- all of the FFL code is
> over-complicated and hard-to-read.
>

I wrote that EACH for you, helped you eliminate a lot of rstack and
stack juggling, and you haven't given me credit for it.

https://groups.google.com/forum/#!original/comp.lang.forth/kH8lPSKdW30/_NzkfGsgnbkJ

I asked you to remove it from your distribution here:

https://groups.google.com/forum/#!original/comp.lang.forth/S59nQGxoUt0/dWhF1RSwgVAJ

Now it's Hugh's brilliant code.

--
Alex

[Ron Aaron]

On 11/30/2016 09:51, Elizabeth D. Rather wrote:
> On 11/29/16 7:08 PM, Ron Aaron wrote:

>> Elizabeth, I fail to understand the objection to a standardized library

>> of working code...

> I have no objection whatever to a standardized library of Forth code. I
> have supported the Forth Math Library by including it with FORTH, Inc.
> products since the '90's even though many people criticize it for
> containing a lot of really bad code and few widely useful functions. It
> would be wonderful if more people directed their efforts toward useful
> library functions rather the "Yet another Forth implementation". I
> merely offer my view as to why this hasn't happened much.

OK. I would posit that a Forth Math Library only scratches a very
particular itch (I have no opinion on the quality of the code, never
having looked at it).

>> A "standard library" does not mean an immutable implementation.
>
> A "standard library" would be wonderful. I invite you do propose one.

As you well know, I'm not an ANS Forth user, so my input on a standard
ANS-compatible library would not be particularly useful.

> Many implementations and virtually all manuals include an array, like:

Yes, yes I know that. But (as has been pointed out by others), in just
about every language, the user is not expected to "roll his own"
fundamental data structures. Even C has built-in arrays (though not
higher-level constructs like trees etc; those you have to make yourself).

> On the other hand, this took me less than a minute to type. What's the
> big deal?

The big deal, IMO, is that this should "come for free" with the
language. Indeed, that's why 8th has arrays and maps and other
generally useful containers. Because when it comes to real-world
applications (outside of embedded systems, that is), the "time to
market" is drastically reduced when one doesn't have to cobble together
basic building blocks. Likewise, the reliability of the overall system
is enhanced when using well-tested building blocks.

So yes, in your very narrow problem domain (of whatever your problem
domain was), it's acceptable to re-invent and copy-and-paste or
whatever. I've not yet worked on a project (in any language) where the
people paying the bill were willing to pay me to re-invent things which
already existed (or should have existed).

I suggest that the real reason Forth libraries haven't caught
> on is that it's easier to write the words than to search the internet
> for versions someone else wrote that don't do exactly what you want.

I challenge that assertion, but YMMV.

[john]

> In article <VMadnb2EDIODGKPF...@supernews.com>, era...@forth.com says...

>
> I suggest that the real reason Forth libraries haven't caught
> on is that it's easier to write the words than to search the internet
> for versions someone else wrote that don't do exactly what you want.
>
> Cheers,
> Elizabeth
>
> --

Trust me Elizabeth - that's not the case.
as an example - If I wanted an FFT I couldn't just sit down and code
it today (some years ago maybe but not these days - hence jim) . I might still
know what an FFT is (or a sobel edge detector or whatever is) and have
a need for it without having the time to re-acquaint myself fully to recreate one.
A proven library or package or whatever you call it is ideal in such cases.
It happens at all levels.

To keep it practical how about making it a function of the standards
committe to review and approve a list of packages based for example
on the repeated use and refinement from a single source such as Geralds
library or another if he was unable or unwilling to do that side of things.

Forth users would be encouraged to use the packages and report back any
issue to the author and when a concensus arises that one is a stable
item that resolves a problem or provides a "product"
the standards comittee marks it as the authorised solution.

Anyone can then "include" it in applications the same as any C library or
whatever.

The mechanisms are there without too much work provided there
are enough actual users of forth to drive it.

[Stephen Pelc]

On Wed, 30 Nov 2016 13:41:50 -0000, john <an...@example.com> wrote:

>Trust me Elizabeth - that's not the case.
>as an example - If I wanted an FFT I couldn't just sit down and code
>it today (some years ago maybe but not these days - hence jim) . I might still
>know what an FFT is (or a sobel edge detector or whatever is) and have
>a need for it without having the time to re-acquaint myself fully to recreate one.
>A proven library or package or whatever you call it is ideal in such cases.
>It happens at all levels.

Libraries appeal as application complexity increases. Especially for
desktop apps, consideration of application size is increasingly
irrelevant. Running a 32 Mb Forth app on a PC with 4Gb (base) of RAM
is using less than 1% of RAM for the application. Embedded apps are
also much larger than they used to be. Memory constraints don't get
any easier. There may be more memory but it's still in demand -
especially RAM.

I have been banging on about libraries for years. FLAG is a personal
project hosted by MPE.
http://soton.mpeforth.com/flag/

Successful library repositories need to be supplier-neutral and appeal
to modernists as well as us old farts. Gerald's site succeeds in both
ways.

>To keep it practical how about making it a function of the standards
>committe to review and approve a list of packages based for example
>on the repeated use and refinement from a single source such as Geralds
>library or another if he was unable or unwilling to do that side of things.

See
http://forth-standard.org/

At the last standard meeting in September, the topic was discussed.
Currently libraries are on
http://theforth.net
but after some evaluation process has been defined and set up, some
will emerge on the standard site.

Would you like to volunteer to help?

[Elizabeth D. Rather]

On 11/30/16 12:09 AM, Ron Aaron wrote:
>
>
> On 11/30/2016 09:51, Elizabeth D. Rather wrote:
>> On 11/29/16 7:08 PM, Ron Aaron wrote:
>
>>> Elizabeth, I fail to understand the objection to a standardized library
>>> of working code...
>
>
>> I have no objection whatever to a standardized library of Forth code. I
>> have supported the Forth Math Library by including it with FORTH, Inc.
>> products since the '90's even though many people criticize it for
>> containing a lot of really bad code and few widely useful functions. It
>> would be wonderful if more people directed their efforts toward useful
>> library functions rather the "Yet another Forth implementation". I
>> merely offer my view as to why this hasn't happened much.
>
> OK. I would posit that a Forth Math Library only scratches a very
> particular itch (I have no opinion on the quality of the code, never
> having looked at it).
>
>>> A "standard library" does not mean an immutable implementation.
>>
>> A "standard library" would be wonderful. I invite you do propose one.
>
> As you well know, I'm not an ANS Forth user, so my input on a standard
> ANS-compatible library would not be particularly useful.

I'm merely pointing out the hypocrisy of decrying the lack of libraries
while making no efforts to contribute to one.

>> Many implementations and virtually all manuals include an array, like:
>
> Yes, yes I know that. But (as has been pointed out by others), in just
> about every language, the user is not expected to "roll his own"
> fundamental data structures. Even C has built-in arrays (though not
> higher-level constructs like trees etc; those you have to make yourself).

If you are selecting an implementation to use, surely you would pick one
that comes with the added facilities you require for your projects, yes?

>> On the other hand, this took me less than a minute to type. What's the
>> big deal?
>
> The big deal, IMO, is that this should "come for free" with the
> language. Indeed, that's why 8th has arrays and maps and other
> generally useful containers. Because when it comes to real-world
> applications (outside of embedded systems, that is), the "time to
> market" is drastically reduced when one doesn't have to cobble together
> basic building blocks. Likewise, the reliability of the overall system
> is enhanced when using well-tested building blocks.

Well, Forth2012 has:

6.2.0825 BUFFER: “buffer-colon” CORE EXT
( u “hspacesiname” – – )
Skip leading space delimiters. Parse name delimited by a space. Create a
definition for name, with the execution semantics defined below. Reserve
u address units at an aligned address. Contiguity of this region with
any other region is undefined.

name Execution: ( – – a-addr )
a-addr is the address of the space reserved by BUFFER: when it defined
name. The program is responsible for initializing the contents.

So that, at least, is standardized. It's a bit-wise array. The Forth20xx
committee is perfectly capable of adding others, should they wish to. I
don't in any sense argue against doing so, I merely observe the reason
why it hasn't happened: it's too easy to do.

> So yes, in your very narrow problem domain (of whatever your problem
> domain was), it's acceptable to re-invent and copy-and-paste or
> whatever. I've not yet worked on a project (in any language) where the
> people paying the bill were willing to pay me to re-invent things which
> already existed (or should have existed).
>
>
>> I suggest that the real reason Forth libraries haven't caught
>> on is that it's easier to write the words than to search the internet
>> for versions someone else wrote that don't do exactly what you want.
>
> I challenge that assertion, but YMMV.
>

[Cecil Bayona]

On 11/30/2016 1:43 PM, Elizabeth D. Rather wrote:
> On 11/30/16 12:09 AM, Ron Aaron wrote:
>> As you well know, I'm not an ANS Forth user, so my input on a standard
>> ANS-compatible library would not be particularly useful.
>
> I'm merely pointing out the hypocrisy of decrying the lack of libraries
> while making no efforts to contribute to one.
>
>

> Cheers,
> Elizabeth
>
Not supporting a product you don't believe in is not hypocrisy, and it's
obvious he supports libraries since his product has a varied selection
of libraries.

What is hypocrisy is selling a product full of libraries yet
discouraging others from making their own libraries.

Cut and paste, what a joke, the most primitive form of having a library,
I understand why it was done to begin with when personal computers were
not available so having a print out was necessary but we have moved way
beyond that point many decades ago.

--
Cecil - k5nwa

[Elizabeth D. Rather]

On 11/30/16 1:36 PM, Cecil Bayona wrote:
> On 11/30/2016 1:43 PM, Elizabeth D. Rather wrote:
>> On 11/30/16 12:09 AM, Ron Aaron wrote:
>>> As you well know, I'm not an ANS Forth user, so my input on a standard
>>> ANS-compatible library would not be particularly useful.
>>
>> I'm merely pointing out the hypocrisy of decrying the lack of libraries
>> while making no efforts to contribute to one.
>>

> Not supporting a product you don't believe in is not hypocrisy, and it's
> obvious he supports libraries since his product has a varied selection
> of libraries.
>
> What is hypocrisy is selling a product full of libraries yet
> discouraging others from making their own libraries.

What?? I was just *encouraging* those desiring a standard library to
contribute to one, rather than just carping on the sidelines.

> Cut and paste, what a joke, the most primitive form of having a library,
> I understand why it was done to begin with when personal computers were
> not available so having a print out was necessary but we have moved way
> beyond that point many decades ago.

No idea what that remark is in reference to.

[Ron Aaron]

On 30/11/2016 21:43, Elizabeth D. Rather wrote:
> On 11/30/16 12:09 AM, Ron Aaron wrote:

>> As you well know, I'm not an ANS Forth user, so my input on a standard
>> ANS-compatible library would not be particularly useful.
>
> I'm merely pointing out the hypocrisy of decrying the lack of libraries
> while making no efforts to contribute to one.

"Hypocrisy", really?

As Cecil pointed out in another reply, 8th has a lot of libraries and
more are added with each release, whether because of user-requests or my
own reasons.

So better rethink the use of that term, it doesn't apply in any manner.

> Well, Forth2012 has:
>
> 6.2.0825 BUFFER: “buffer-colon” CORE EXT
> ( u “hspacesiname” – – )

...

> So that, at least, is standardized. It's a bit-wise array.

If that is what an 'array' is in your mind, then I'm not sure what
profit there is in further discussion on this topic. It's even named
'BUFFER:' -- to indicate that it holds a bunch of bytes. Yes, it
*could* be used as an array. So could a simple CREATE 100 ALLOT.

And while an 'array' of this nature is certainly simple to implement,
one which accommodates increasing amounts of data is not. Nor is a
"map" simple to implement correctly, let alone other common data structures.

By all means, continue thinking that rolling your own array (or
whatever) every single time you need one is a profitable use of your
programmers' time and your money.

[john]

> In article <583ee1a8....@news.eternal-september.org>, ste...@mpeforth.com says...

>

> See
> http://forth-standard.org/
>
> At the last standard meeting in September, the topic was discussed.
> Currently libraries are on
> http://theforth.net
> but after some evaluation process has been defined and set up, some
> will emerge on the standard site.
>
> Would you like to volunteer to help?
>
> Stephen

What I would like is is about another 20 hours in a day.
There's only so much 2 men and a dog can do.

I'm just suprised all this stuff wasn't done long ago.
I've offered space on the web site to contribute what I can
but time is the enemy as always.

My real interest in forth at the moment is to prototype
my OS and processor design but all I need for that is a minimal
kernel and it wont look at all like forth very soon after anyway.
I think this is something worth doing - especially as Intel have
just signalled the beginning of the end of the X86 family...

If you get specific issues you need help with by all means
poke me with a sharp stick at any time -- that's where I live.

[Andrew Haley]

john <an...@example.com> wrote:
>> In article <VMadnb2EDIODGKPF...@supernews.com>, era...@forth.com says...
>>
>> I suggest that the real reason Forth libraries haven't caught
>> on is that it's easier to write the words than to search the internet
>> for versions someone else wrote that don't do exactly what you want.
>

> Trust me Elizabeth - that's not the case.

:-)

> as an example - If I wanted an FFT I couldn't just sit down and code
> it today (some years ago maybe but not these days - hence jim) . I
> might still know what an FFT is (or a sobel edge detector or
> whatever is) and have a need for it without having the time to
> re-acquaint myself fully to recreate one.

Wee-eell, yabbut. I've coded FFTs a few times, and they were
different. Sure, if you happen to have a fast floating-point unit
then you don't have to worry much about scaling and whatnot, and if
you can use double precision you probably don't have to worry much
about rounding errors. But there's still the matter of whether your
data just happens to fit in an array a power of two in length, and
whether it's convenient to use DIT or DIF. Sure, if you need
something *now* and your CPU is significantly more capable than the
problem actually requires, a library routine will suffice. And if
your cost is domintated by developer time, then a library routine is
indeed optimal.

> A proven library or package or whatever you call it is ideal in such
> cases. It happens at all levels.

Not necessarily ideal: adequate.

Andrew.

[Elizabeth D. Rather]

On 11/30/16 7:02 PM, Ron Aaron wrote:
> On 30/11/2016 21:43, Elizabeth D. Rather wrote:
>> On 11/30/16 12:09 AM, Ron Aaron wrote:
>
>>> As you well know, I'm not an ANS Forth user, so my input on a standard
>>> ANS-compatible library would not be particularly useful.
>>
>> I'm merely pointing out the hypocrisy of decrying the lack of libraries
>> while making no efforts to contribute to one.
>
> "Hypocrisy", really?
>
> As Cecil pointed out in another reply, 8th has a lot of libraries and
> more are added with each release, whether because of user-requests or my
> own reasons.
>
> So better rethink the use of that term, it doesn't apply in any manner.

It isn't intended to apply to those who are actively working to provide
Forth libraries, but to those who complain about the lack of
standardized libraries and take no steps toward defining them.

>> Well, Forth2012 has:
>>
>> 6.2.0825 BUFFER: “buffer-colon” CORE EXT
>> ( u “hspacesiname” – – )
> ...
>> So that, at least, is standardized. It's a bit-wise array.
>
> If that is what an 'array' is in your mind, then I'm not sure what
> profit there is in further discussion on this topic. It's even named
> 'BUFFER:' -- to indicate that it holds a bunch of bytes. Yes, it
> *could* be used as an array. So could a simple CREATE 100 ALLOT.
>
> And while an 'array' of this nature is certainly simple to implement,
> one which accommodates increasing amounts of data is not. Nor is a
> "map" simple to implement correctly, let alone other common data structures.
>
> By all means, continue thinking that rolling your own array (or
> whatever) every single time you need one is a profitable use of your
> programmers' time and your money.

If you prefer a cell-wise array, Forth2012 provides this:

D.2.3 Addressing memory

A related problem is that of addressing an array of cells in an
arbitrary order. This standard provides a portable scaling operator
named CELLS. Given a number n, CELLS returns the number of address units
needed to hold n cells. Using CELLS, we can make a portable definition
of an ARRAY defining word:

: ARRAY ( u -- ) CREATE CELLS ALLOT
DOES> ( u -- addr ) SWAP CELLS + ;

Would it make you happy for the next release of the standard made this
definition of ARRAY required?

Clearly one of the first steps is for a number of Forth programmers and
system providers to agree on a definition of "array", because to many of
us, it's just a dedicated region of data storage that is index-able.

[hughag...@gmail.com]

On Wednesday, November 30, 2016 at 3:03:13 AM UTC-7, Alex wrote:
> On 11/30/2016 02:15, hughag...@gmail.com wrote:
>
> >
> > Notice how it is holding the internal data on the return-stack so it
> > is not sitting on top of the data left by the calling function. I was
> > the one who pointed out the need for this, but notice that Stephen
> > Pelc doesn't give me credit for this.
> >
>
> Hahahaha! No credit...

This is scl-execute in FFL now.

: scl-execute ( i*x xt scl -- j*x = Execute xt for every cell data in list )
snl-first@ \ walk = first
BEGIN
nil<>? \ while walk<>nil do
WHILE
dup >r scn-cell@
swap
dup >r execute \ execute xt with cell
r> r>
snn-next@ \ walk = walk->next
REPEAT
drop
;

Prior to me pointing out that scl-execute should not hold its internal data on the data-stack, scl-execute was holding its internal data on the data-stack --- so why shouldn't I get credit for pointing out the bug?

scl-execute still has a bug in it. It is fetching the next-node from the link after doing EXECUTE --- the xt being executed, however, may clobber that link so it is no longer valid afterward --- for example, the node may get moved to another list.

My novice-package has been working correctly since 2010 --- FFL is still not working correctly --- I pointed out the first gigantic bug, and it got fixed, but I pointed out this second bug back in 2010 also, and it hasn't gotten fixed.

I would not use FFL --- it has bugs --- I don't think Stephen Pelc tests this code, and he doesn't use it for his own programs either.

> > This is my EACH in the novice-package (working correctly since
> > 2010):
> >
> > : each ( i*x head 'toucher -- j*x ) \ toucher: i*x
> > node -- j*x
> >> r
> > begin dup while \ -- node
> > \r: -- 'toucher r@ over .fore @ >r \ -- node
> > 'toucher \r: -- 'toucher next execute r> repeat drop
> > rdrop ;
> >
> > Notice how my EACH is more efficient than scl-execute because I'm
> > only doing one >R and one R> inside of the loop, whereas scl-execute
> > is doing two >R and two R> inside of the loop. Also notice how my
> > EACH is short and readable --- all of the FFL code is
> > over-complicated and hard-to-read.
> >
>
>
> I wrote that EACH for you, helped you eliminate a lot of rstack and
> stack juggling, and you haven't given me credit for it.
> https://groups.google.com/forum/#!original/comp.lang.forth/kH8lPSKdW30/_NzkfGsgnbkJ

Okay, I will give you credit for the optimization that reduced the number of >R and R> inside of the loop from two to one.

> I asked you to remove it from your distribution here:
> https://groups.google.com/forum/#!original/comp.lang.forth/S59nQGxoUt0/dWhF1RSwgVAJ

Trying to take credit for my LIST.4TH package is not going to work. You made a minor contribution.

You have also been telling a lot of lies about the novice-package. You said that my SORT doesn't work and that I "have a serious misunderstanding of how pointers work" --- you were lying --- my SORT works fine.

[hughag...@gmail.com]

On Thursday, December 1, 2016 at 11:58:11 AM UTC-7, Elizabeth D. Rather wrote:
> On 11/30/16 7:02 PM, Ron Aaron wrote:
> >> Well, Forth2012 has:
> >>
> >> 6.2.0825 BUFFER: “buffer-colon” CORE EXT
> >> ( u “hspacesiname” – – )
> > ...
> >> So that, at least, is standardized. It's a bit-wise array.
> >
> > If that is what an 'array' is in your mind, then I'm not sure what
> > profit there is in further discussion on this topic. It's even named
> > 'BUFFER:' -- to indicate that it holds a bunch of bytes. Yes, it
> > *could* be used as an array. So could a simple CREATE 100 ALLOT.
> >
> > And while an 'array' of this nature is certainly simple to implement,
> > one which accommodates increasing amounts of data is not. Nor is a
> > "map" simple to implement correctly, let alone other common data structures.

BUFFER is useless. It doesn't do anything for you that
CREATE 100 ALLOT
doesn't do.

As for data-structures that accomodates increasing amounts of data, my novice package has: LIST.4TH and ASSOCIATION.4TH

> > By all means, continue thinking that rolling your own array (or
> > whatever) every single time you need one is a profitable use of your
> > programmers' time and your money.
>
> If you prefer a cell-wise array, Forth2012 provides this:
>
> D.2.3 Addressing memory
>
> A related problem is that of addressing an array of cells in an
> arbitrary order. This standard provides a portable scaling operator
> named CELLS. Given a number n, CELLS returns the number of address units
> needed to hold n cells. Using CELLS, we can make a portable definition
> of an ARRAY defining word:
>
> : ARRAY ( u -- ) CREATE CELLS ALLOT
> DOES> ( u -- addr ) SWAP CELLS + ;
>
> Would it make you happy for the next release of the standard made this
> definition of ARRAY required?
>
> Clearly one of the first steps is for a number of Forth programmers and
> system providers to agree on a definition of "array", because to many of
> us, it's just a dedicated region of data storage that is index-able.

Your ARRAY is copied directly out of "Starting Forth" --- all of the code that you have posted on comp.lang.forth has been copied directly out of "Starting Forth" --- every Forth programmer has read that book; the cartoons were cute; it was pretty light on technical information though.

What is the point of having an ARRAY definer that is limited to one dimension and is limited to cell-sized elements? That is not a general-purpose data-structure.

This has been discussed at length previously:
https://groups.google.com/forum/#!topic/comp.lang.forth/kH8lPSKdW30%5B26-50%5D

Here Andrew Haley wrote an array definer using CREATE DOES> that did allow any number of dimensions, but was restricted to cell-sized elements. I upgraded this so that it didn't use CREATE DOES> and hence was faster (because it doesn't have to fetch constant values out of memory at run-time, but compiles them as literals at compile-time) --- my upgrade also allows the elements to be any size, so you can have arrays of structs.

It is pointless to limit the users to only having cell-sized elements in the array. With my arrays, the user can have an array of pointers if that is what he needs, but can also have an array of structs --- the user is in full control --- a general-purpose data-structure should allow the user to get whatever he wants.

This is from the novice-package:
----------------------------------------------------------------------------

macro: [] ( adr index - element-adr )
cells + ;

macro: -> ( adr index -- element )
[] @ ;

: ,rows ( size 0 dims... -- size 0 dims... ) \ size is the size of the element; all elements get zero'd out
here locals| array dim | \ ARRAY is the adr and DIM is the largest dimension
dup if w else over then \ -- element-size \ all but the last level are pointers (size W)
dim * zallot
dup if
dim 0 do here array I [] ! dup >r recurse r> loop
then ;

\ Any alignment to the dictionary pointer should be done *before* ,ROWS is called.
\ This is in <ARY> prior to the DIMENSIONS.
\ This isn't necessary in ,ROWS prior to the RECURSE because we have only been compiling words.
\ Don't align the HERE at the beginning of ,ROWS as this has to be the same HERE that was obtained prior to calling ,ROWS.

: dimensions ( size 0 dims... size ) \ size is the size of the element
,rows
begin 0= until ; \ discard the dimensions and the zero terminator

: <ary> ( size 0 dims... name -- )
>r
non-zeros >r r@ 0 = abort" *** ARY needs some dimensions ***"
align here >r dimensions >r
r> r> r> r> { siz adr cnt name -- }
name get-current :name \ runtime: indices... -- element-adr
adr lit,
cnt 1 ?do swap, postpone -> loop
swap, siz lit*, +, ;,
c" <" name get-current :2name \ runtime: -- base-adr
adr lit, ;,
name c" >" get-current :2name \ runtime: adr index -- element-adr
siz lit*, +, ;,
;

: ary ( size 0 dims... -- )
bl word hstr dup >r <ary> r> dealloc ;

\ You can define a two-dimensional array of words in either of these ways:
\ W 0 3 5 C" TEST" <ARY>
\ W 0 3 5 ARY TEST

\ Assuming that I and J are indexes, an element can be accessed like this:
\ I J TEST \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the same order as the dimensions were.

\ It is also possible to access the element like this:
\ <TEST J -> I TEST> \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the opposite order as the dimensions were.

\ The [] only works for word-sized elements.
\ You should always use the xxx> word (even for words) because it takes into account the size of the element.

\ Arrays of dimensions other than two are defined the same --- you can have as many dimensions as you want.
\ <ARY> figures out how many dimensions there are by looking for the 0 under the non-zero dimensions.

\ This is a classic example of the problem with CREATE DOES> words being limited to *one* action per data type.
\ The CREATE DOES> version of the Iliff vectors relied on [] for resolving the final level, which had to be word elements.
\ There is no way to do this with CREATE DOES> because you can't have a type-specific version of [] (such as my xxx> word).

[HAA]

Rod Pemberton wrote:
> On Tue, 29 Nov 2016 15:22:40 +1100
> "HAA" <som...@microsoft.com> wrote:
>
> > hughag...@gmail.com wrote:
>

> > > It would make more sense to compare Forth to C than to assembler
> > > --- Forth and C have similar uses --- of course, C has been
> > > described as a portable assembly-language, and for a long time I
> > > thought of Forth as being an over-grown macro-assembler, so
> > > comparing both of them to assembler is reasonable.
> >
> > Interesting C being described that way. It's low level in a sense
> > but users are still at the mercy of compiler, presupplied libraries
> > and standards. Forth is one of the few languages that's truly 'grass
> > roots' - where users could create from ground up. No reliance on
> > anybody or thing. Anyone that's used MASM has probably discovered
> > there are things which can't be done, except perhaps awkwardly. So
> > Forth gets a tick over asm :)
> >
>

> "... where users could create from [the] ground up."
>
> I'd argue that statement describes the failing of Forth, not it's
> merit. That's part of the reason why Forth is called a "write-once"

> language. The others being that it's simple syntax can be
> exceptionally cryptic, the code can be untraceable or difficult to

> understand, and Forth requires the user to juggle stack items. Without

> a large, standardized, and ubiquitous set of functionality, every Forth
> application has to develop it's own solution to the same basic
> programming problems and situations. This requires extra work, time or
> man-hours, on the part of the programmer, and interferes with
> portability, as the resulting code is non-standard. The code is unique
> to that application, when every application could've used the same

> functionality. It also means that any bad solutions or poor designs

> will be passed along forever with that application. It also means that
> numerous programs will most assuredly have bad, buggy, or limited

> implementations of functionality which is commonly used. A programmer
> needs to have a certain set of standard tools or components which are
> widely available and easy to use.
>
>
> Rod Pemberton

Elsewhere you mention x86 assembly. You appear to acknowledge the
skill of asm programmers who work in environments largely devoid of
standards and libraries. Yet when Forth programmers do the same,
it's seen as a "failing" of the language?

[Rod Pemberton]

> Elsewhere you mention x86 assembly. You appear to acknowledge the
> skill of asm programmers who work in environments largely devoid of
> standards and libraries. Yet when Forth programmers do the same,
> it's seen as a "failing" of the language?
>

It's a general failing of assembly too. There are various assembly
libraries, but they don't generally come with the assembler. The
failing is that you have to do much more work to do if coding in
assembly, when you aren't using a library. If you are using an
assembly library, you have to learn the intricacies of a non-standard,
non-portable library. Assembly can be harder to test too, as you have
to code your own print routines and other code pieces to help you debug
it. Of course, the assembly code isn't portable like a high-level
language. C and Forth are the two most ubiquitous languages, but one
is still quite popular and the other almost dead. One has libraries
and structured syntax, and one doesn't.

It can be a failing of C too, if you don't fully use the C libraries, or
if you restrict usage of C to C itself and just a portion of the C
library, as some do. E.g., if you want the C code to compile with a
less-developed, more primitive, or simpler C compiler, you don't want to
make heavy use of the C libraries. You might restrict C library usage
to just <stdio.h>. The libraries for the less-developed C compiler
won't be as developed or, will have bugs. A number of well known C
compilers have had various long-term non-compliance issues with the C
standards too.

Assembly is generally harder to work with, less forgiving, usually
doesn't come with a code optimizer, and requires register juggling.
This is much like Forth needing stack juggling. If the assembler
doesn't have a good preprocessor, then you won't be able to use named
variables in the assembly code either. This is a huge drawback. So,
the best way to use assembly, IMO, is to extend or enhance or
complement a high-level language. I.e., I don't recommend using
assembly, unless it's for something small or trivial or something which
simply can't be easily done in a high-level language without it, e.g.,
special file format, interfacing with the operating system, special
processor instructions, high-speed math or graphics routine, etc.

If you look at all the publicly available C code which has been produced
over the decades, much of it is still available and many projects are
still used or recycled. You can't say that about the huge quantity of
MS-DOS programs which were released with assembly code. The vast
majority of these programs are dead. When x86 PCs migrated from 16-bit
to 32-bit, they couldn't be recompiled easily 32-bit. C code could. C
code didn't need a rewrite.


Rod Pemberton

[HAA]

Rod Pemberton wrote:
> ...

> If you look at all the publicly available C code which has been produced
> over the decades, much of it is still available and many projects are
> still used or recycled. You can't say that about the huge quantity of
> MS-DOS programs which were released with assembly code. The vast
> majority of these programs are dead. When x86 PCs migrated from 16-bit
> to 32-bit, they couldn't be recompiled easily 32-bit. C code could. C
> code didn't need a rewrite.

The picture isn't as rosy as you make out. C itself has undergone changes
starting with K&R. Code written on one compiler would often produce errors
when compiled on another. It may be the original programmer's fault but it
falls to you to sort it out. The same for programs with OS specific code.
No language is a panacea. All expect you to deal with issues and all are
subject to change. If your program relies on certain user-created libraries
it may become invalid with the next release of the language. If you didn't write
the library yourself you may not be in a position to update it, or it's impossible,
and the life of your program ends there.

Is Forth dead? Only for those not using it :)

[HAA]

hughag...@gmail.com wrote:
> ...

> Here Andrew Haley wrote an array definer using CREATE DOES> that did allow any number
> of dimensions, but was restricted to cell-sized elements. I upgraded this so that it
> didn't use CREATE DOES> and hence was faster (because it doesn't have to fetch constant
> values out of memory at run-time, but compiles them as literals at compile-time) --- my
> upgrade also allows the elements to be any size, so you can have arrays of structs.

Fetching is relatively fast. It's the multiply used in simple multidim arrays that slows
it down. An array that lays down pointers need only execute CELLS + @ for each
index. Nothing comes free and memory is traded for speed. Each case on its merits.

[hughag...@gmail.com]

You don't know what you are talking about. This is my code from the novice package:

[Andrew Haley]

HAA <som...@microsoft.com> wrote:

> Fetching is relatively fast. It's the multiply used in simple
> multidim arrays that slows it down. An array that lays down
> pointers need only execute CELLS + @ for each index. Nothing comes
> free and memory is traded for speed. Each case on its merits.

Kinda sorta, but on today's processors multiplies and fetches both
take about four or five cycles of latency. The difference is that you
if you're multiplying you have to load the constant to multiply by as
well as actually doing the multiplication. This constant might be in
an immediate field, but probably isn't; if you're careful or lucky
it's just a shift.

Andrew.

[hughag...@gmail.com]

I think it was an honest mistake for HAA to assume that I'm multiplying --- that is how 1ARRAY 2ARRAY etc. work (although if the dimension is a power of two then it is just a shift because LIT*, optimizes internally) --- by ARY doesn't use multiply.

I don't think it is an honest mistake for Andrew Haley to assume that I'm multiplying. He knows that my ARY was derived from his code. He also knows that my ARY is better than his code because I allow the array element to be any size, so you can have an array of structs, whereas he forces the array element to be cell size so you can only have an array of integers or an array of pointers. Andrew Haley is an employee of Elizabeth Rather and so he has to pretend that it is not possible to write an array definer that allows the array element to be any size --- also, as a practical matter, he is using CREATE DOES> which only allows one action to be associated with the array, and so he has no way to support generality in the element size.

It is a good point though that multiply on a modern processor is pretty fast (division continues to be a speed sink though). I never considered 1ARRAY 2ARRAY etc. to be inefficient. I switched over to ARY because it is a lot more convenient, and there is a lot less code generated (which could be an issue if there are a lot of arrays defined). I still have 1ARRAY 2ARRAY etc. in the novice-package --- I just encourage the use of ARY instead --- in Straight Forth I will only have ARY because I don't want redundancy; I want all the programs to look similar so code maintainers can learn how any particular program works quickly (this is more important to me than allowing everybody to be a cowboy and consequently have every program look different, like in ANS-Forth).

This is LIT*, that is used internally by 1ARRAY 2ARRAY etc..:
---------------------------------------------------------------------------
: lg ( u -- val|-1 ) \ -1 if not a power of 2
dup 0= if drop -1 exit then
0 begin \ -- u val
over 1 and 0= while 1+ >r 1 rshift r> repeat
over 1 xor if 2drop -1 exit then \ not a power of 2
nip ;

: lit*, ( mult -- ) \ runtime: n -- n*mult
dup 0 = if drop drop, 0 lit, exit then
dup 1 = if drop exit then
dup lg \ -- mult lg(mult)
dup 0< if drop lit, *,
else nip lit, lshift, then ;
---------------------------------------------------------------------------

[Alex]

On 12/5/2016 18:39, hughag...@gmail.com wrote:

> Andrew Haley is an
> employee of Elizabeth Rather

Really?

--
Alex

[hughag...@gmail.com]

Yes, of course. Why else would he have been appointed to the Forth-200x committee? He says this:

On Saturday, June 25, 2016 at 3:09:53 AM UTC-7, Andrew Haley wrote:
> Brad Eckert <hwf...@gmail.com> wrote:
> >
> > Forth is a language best taught by experts. You can teach yourself,
> > but it's going to take a while if you're learning by doing. Using a
> > commercial Forth is a good way to learn from an expert.
>
> I was fortunate enough to work for COMSOL and attend (and later teach)
> some training courses and then even do some things with Forth, Inc.
> I'm not sure that I would ever have really got the idea of Forth
> without being taught by experts.

This is the COMSOL he is referring to:
http://www.computer-solutions.co.uk/chipdev/forth.htm

[Alex]

Ah, so he knows what he's talking about. That's why you're jealous.

--
Alex

[HAA]

hughag...@gmail.com wrote:
> ...

> I think it was an honest mistake for HAA to assume that I'm multiplying --- that is how
> 1ARRAY 2ARRAY etc. work (although if the dimension is a power of two then it is just a
> shift because LIT*, optimizes internally) --- by ARY doesn't use multiply.

Perhaps you misread. The "multiply used in simple multidim arrays" was referencing
the CREATE DOES> arrays generally promoted by Forth. An example from
'Programming Forth':

: 2Array \ n1 n2 -- ; [child] n1 n2 -- addr ; 2-D array
Create \ create data word
Over , \ save width for run-time
cell * * \ calculate size
Here over erase \ clear memory
allot \ reserve n cells
Does> \ run time gives address of data
Dup @ Rot * Rot + 1+
cell *
+
;

Ignoring the CELL * in the run-time (use CELLS), it still leaves a multiply that needs
to be performed for each dimension in the array. Multidim arrays based on multiply
aren't always bad (I've used them myself) but they seem to be the only thing offered
when newbies ask 'Why doesn't Forth have arrays?'. Array run-time in other
languages I've seen go to length to avoid the multiply. It wouldn't hurt for Forth to
have more than CREATE DOES> up its sleeve when newbies come calling.

[Elizabeth D. Rather]

Fine. What did you have in mind? Got a spec?

[hughag...@gmail.com]

On Tuesday, December 6, 2016 at 12:36:45 AM UTC-7, Elizabeth D. Rather wrote:
> On 12/5/16 9:13 PM, HAA wrote:
> > Multidim arrays based on multiply
> > aren't always bad (I've used them myself) but they seem to be the only thing offered
> > when newbies ask 'Why doesn't Forth have arrays?'. Array run-time in other
> > languages I've seen go to length to avoid the multiply. It wouldn't hurt for Forth to
> > have more than CREATE DOES> up its sleeve when newbies come calling.
>
> Fine. What did you have in mind? Got a spec?

I already posted code for <ARY> and ARY --- I wrote that in 2010.

I've written quite a lot of code, most of which will go into Straight Forth --- I can't contribute to FFL or any other code-library managed by Stephen Pelc --- that is why I'm now designing Straight Forth as my "spec."

[hughag...@gmail.com]

On Tuesday, December 6, 2016 at 12:12:56 AM UTC-7, HAA wrote:
> hughag...@gmail.com wrote:
> > ...
> > I think it was an honest mistake for HAA to assume that I'm multiplying --- that is how
> > 1ARRAY 2ARRAY etc. work (although if the dimension is a power of two then it is just a
> > shift because LIT*, optimizes internally) --- by ARY doesn't use multiply.
>
> Perhaps you misread. The "multiply used in simple multidim arrays" was referencing
> the CREATE DOES> arrays generally promoted by Forth. An example from
> 'Programming Forth':
>
> : 2Array \ n1 n2 -- ; [child] n1 n2 -- addr ; 2-D array
> Create \ create data word
> Over , \ save width for run-time
> cell * * \ calculate size
> Here over erase \ clear memory
> allot \ reserve n cells
> Does> \ run time gives address of data
> Dup @ Rot * Rot + 1+
> cell *
> +
> ;

Sorry that I assumed that you were attacking me --- you were replying to my post, which is why I assumed that you were referring to my code.

IIRC, all of the code in "Programming Forth" was derived directly from the "Starting Forth" book.

The biggest problem with this code is not efficiency issues involving multiply --- the biggest problem is that it is not general-purpose (here restricted to 2-dimensional arrays with cell elements) --- I think that is what turns off the newbies the most (assuming that they are already familiar with any language other than line-number BASIC, they are going to be unimpressed by "Starting Forth"/"Programming Forth")

[Andrew Haley]

No, of course not. I am Java Platform Engineering Lead at Red Hat.

Andrew.

[Andrew Haley]

Alex <al...@rivadpm.com> wrote:
>
> Ah, so he knows what he's talking about. That's why you're jealous.

Yep.

Andrew.

[Stephen Pelc]

On Tue, 6 Dec 2016 00:14:43 -0800 (PST), hughag...@gmail.com
wrote:

>IIRC, all of the code in "Programming Forth" was derived directly from the =
>"Starting Forth" book.

You do not remember correctly.

Stephen

--
Stephen Pelc, steph...@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

[hughag...@gmail.com]

On Tuesday, December 6, 2016 at 5:01:12 AM UTC-7, Stephen Pelc wrote:
> On Tue, 6 Dec 2016 00:14:43 -0800 (PST), hughag...@gmail.com
> wrote:
>
> >IIRC, all of the code in "Programming Forth" was derived directly from the =
> >"Starting Forth" book.
>
> You do not remember correctly.
>
> Stephen

Show me any code written by Elizabeth Rather, in "Programming Forth" or posted on comp.lang.forth or anywhere else, that was not copied directly out of the "Starting Forth" book --- I don't think there is any --- I think she is a total fake!

[hughag...@gmail.com]

You have worked for Forth Inc. in the past --- this stain can never be washed off --- she appointed you to the Forth-200x committee because she still considers you to be her tool, and you are.

[hughag...@gmail.com]

A bit arrogant, aren't you Andrew? Has your appointment to the Forth-200x committee gone to your head? Does everybody that Elizabeth Rather appoints to the Forth-200x committee need to buy a new hat one size larger?

Alex McDonald is already at the maximum hat size due to the prodigious quantity of b.s. that he packs in his head --- if he gets promoted to be a voting member of the Forth-200x committee, which I expect to happen soon, there won't be any hat that will fit him --- he'll need to overturn a five-gallon bucket and use that for his hat, which will be the only thing that will fit!

Remember this thead?
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B1-25%5D

Here we have an example of Andrew Haley completely failing to understand what a quotation is. And, btw, whatever happened to that issue? Have the Paysan-faked quotations been accepted into Forth-200x yet? This was another example of when I wrote code that worked (the rquotations) and the Forth-200x committee remained focused on a fantasy that doesn't work in the sense that there is no working code, and also doesn't work in the sense that it fails to provide the features that my code provides.

On Saturday, July 9, 2016 at 11:24:11 AM UTC-7, hughag...@gmail.com wrote:
> On Saturday, July 9, 2016 at 10:27:31 AM UTC-7, Andrew Haley wrote:
> > JennyB <jenny...@googlemail.com> wrote:
> > > Outside its parent, the quotation could only be meaningfully be
> > > executed from within another definition that provided a suitable
> > > local frame. How you would manage that, or why you would want to, I
> > > leave up to you.
> >
> > Quite. I think that idea isn't going to fly.
> >
> > Andrew.
>
> LOL! Jennifer Brien has already figured out that this statement of her's is nonsense --- Andrew Haley (employee of Forth Inc.) had to go back to a post where she still didn't understand how quotations worked so he could agree with that. Quite (funny).
>
> The HOF doesn't have to "provide a suitable local frame" --- this was Jennifer's confused idea that the HOF had to have a look-alike local-frame as the parent function's --- actually, the HOF just has to have a local-frame so that its local-frame pointer can be held aside by REX (on the return-stack), but it doesn't matter to the quotation what the HOF's local-frame looks like because it is going to be ignored.

[HAA]

No spec but don't you think the topic of arrays in Forth has been underwhelming?
We've touched on issues of speed and multidimension arrays. In every language
but Forth a programmer knows how to create an array of any dimension. Here,
if lucky, you're told how to build a two-dimension array. But what if you needed
three or four? I'm in favor of Forth programmers working things out for themselves
when there's gain to be had but for common things like this? Arrays-of-arrays
offer speedup through simple shifts and fetches instead of multiply, or irregular
shaped arrays, but would you know how to create them or where to find code?
Simple one dimension arrays may be the basis of everything but unfortunately
that's where the journey stops in Forth literature.