|
|
 Up |
|
|
  |
Author: wertywerty Date: Oct 11, 2006 23:38
J Thomas wrote:
How many existing Forth compilers would run
> code that has the first three environmental dependencies? Separate user
> return stack, separate loop stack, harvard architecture.
Give it up , its the Titanic , it deserves to sink ......
The lowest levels of Forth code is always dependent on invirons
....
There is no need to "save" the older Forth applications .
We have easier hardware and need to trash all that old stuff .
NewForth has no STACK , no STATE flag , no compiler , no
interpreter , no loader , and no manual .... uh ? say what ?
.
There is nothing to learn in NewForth , you simply clic G.U.I.
icons/images and it runs .....
Wanna rewrite it ?
You can do low level using built in symbolic asm/disasm .
It manages and links all objects , so there are no FOLDERS/FILES .
Give it up !! Its dead , get on with higher level programming
in NewForth ! Quit arguing low level stuff ....
|
| |
|
| | no comments |
|
|
Author: kenneykenney Date: Oct 12, 2006 03:14
> Mostly, you shouldn't have more ways to make a loop than you
> need.
Well originally Basic only gave you For-Next any other loop
structure had to be derived using If-Then and Goto. This was
actually easier for me to use than the multiple loop structures
available in some modern languages.
Ken Young
|
| |
|
| | no comments |
|
|
Author: J ThomasJ Thomas Date: Oct 10, 2006 00:52
Forth -- including 94 standard Forth -- has a collection of quirks that
make it harder for newbies to learn the language. They all have a sound
basis, they make minimal systems efficient. But people who are learning
Forth who aren't planning to use it on minimal systems might learn a
dialect that's easier. Here are some suggestions.
Dummy return stack. We used the return stack because it was there. It
was useful. There are restrictions. You can't put something on the
return stack before you enter a DO loop and use R@ inside the loop.
Etc. These are extra trouble for programmers to remember. Use a dummy
return stack that isn't used for anything else, and you can do what you
want with it, interpreting or compiling. I would suggest that
programmers not pass parameters across routines on the rack, because it
makes the documentation harder. But people will try that out and find
out whether it works for them.
|
| Show full article (2.22Kb) |
| 139 Comments |
|
|
Author: Bernd PaysanBernd Paysan Date: Oct 10, 2006 05:58
J Thomas wrote:
> Dummy return stack. We used the return stack because it was there. It
> was useful. There are restrictions. You can't put something on the
> return stack before you enter a DO loop and use R@ inside the loop.
> Etc. These are extra trouble for programmers to remember. Use a dummy
> return stack that isn't used for anything else, and you can do what you
> want with it, interpreting or compiling. I would suggest that
> programmers not pass parameters across routines on the rack, because it
> makes the documentation harder. But people will try that out and find
> out whether it works for them.
Yes, sounds a good way to shoot in your foot even further. Please *don't*
juggle too many things on too many stacks, it will bite you one way or the
other. Use locals, if you can't factor properly, and get lost in the wood
of too many variables (and always remember the circus artist in the
hospital in TF, with the "too many variables" comment below).
We have a separate locals stack in Gforth, we could open that up to users,
but IMHO, it doesn't make sense to have anonymous locals.
|
| Show full article (3.29Kb) |
| 32 Comments |
|
|
Author: Aleksejj SaushevAleksejj Saushev Date: Oct 10, 2006 07:47
Bernd Paysan writes:
> J Thomas wrote:
> We have a separate locals stack in Gforth, we could open that up to users,
> but IMHO, it doesn't make sense to have anonymous locals.
>
>> Harvard architecture. With code and data and headers all at HERE they
>> can get in each others' way. Can't compile while there's an incomplete
>> data structure, can't allot data with an incomplete definition, who
>> needs it?
>
> There's another reason for doing that: Native code compilers shouldn't put
> data and code too close together on recent architectures (though the
> Pentium 4, which was the worst offender, now is starting to become legacy).
In addition you may have code space better protected.
Not all may afford ignorance of operating system.
|
| Show full article (2.44Kb) |
| 2 Comments |
|
|
Author: Aleksejj SaushevAleksejj Saushev Date: Oct 10, 2006 07:52
"J Thomas" gmail.com> writes:
> Get rid of ?DUP and SEARCH-WORDLIST . Words that return a conditional
> number of stack items are a snare and a delusion.
I disagree with you in respect to ?DUP and similar words.
It is very convenient to have such words, because you have good
idioms of their usage:
begin get-line while ( c-addr u ) 2drop repeat
begin get-char while ( char ) drop repeat
|
| |
| no comments |
|
|
Author: J ThomasJ Thomas Date: Oct 10, 2006 07:59
Bernd Paysan wrote:
> J Thomas wrote:
>> Get rid of DO LOOP . It's beautifully efficient. Sometimes it does N
>> items and sometimes it does N+1 items. How many of us got bit by that
>> before we learned what to expect?
>
> The problem is more +LOOP. It gives you N+1 items when you count downwards.
> That's why we have -LOOP in Gforth. DO LOOP (no +LOOP) is fine.
You use +LOOP to count up and -LOOP to count down? I'd rather have a
replacement for +LOOP that just worked, with a new name. Still, it only
matters for newbies.
>> There are probably other examples that I don't think of immediately
>> because I'm used to them. How many existing Forth compilers would run
>> code that has the first three environmental dependencies? Separate user
>> return stack, separate loop stack, harvard architecture.
>
> The list is probably empty.
|
| Show full article (2.10Kb) |
| 28 Comments |
|
|
Author: Gary ChansonGary Chanson Date: Oct 10, 2006 08:15
> Forth -- including 94 standard Forth -- has a collection of quirks that
> make it harder for newbies to learn the language. They all have a sound
> basis, they make minimal systems efficient. But people who are learning
> Forth who aren't planning to use it on minimal systems might learn a
> dialect that's easier. Here are some suggestions.
>
> Dummy return stack. We used the return stack because it was there. It
> was useful. There are restrictions. You can't put something on the
> return stack before you enter a DO loop and use R@ inside the loop.
> Etc. These are extra trouble for programmers to remember. Use a dummy
> return stack that isn't used for anything else, and you can do what you
> want with it, interpreting or compiling. I would suggest that
> programmers not pass parameters across routines on the rack, because it
> makes the documentation harder. But people will try that out and find
> out whether it works for them.
>
> Separate loop stack. We used the return stack to hold loop indices
> because it was there. We still could, but why should we? If people do ...
|
| Show full article (2.79Kb) |
| no comments |
|
|
Author: Frank BussFrank Buss Date: Oct 10, 2006 08:34
J Thomas wrote:
> Get rid of ?DUP and SEARCH-WORDLIST . Words that return a conditional
> number of stack items are a snare and a delusion.
I'm new to Forth, but I like ?dup, because it helps you to write less code.
Without it you have to write this:
: foo dup if do-something-with-x else drop then ;
With ?dup you can write it like this:
: foo ?dup if do-something-with-x then ;
Maybe a "?if" would be better?
|
| |
| 4 Comments |
|
|
|
|
|
Author: J ThomasJ Thomas Date: Oct 10, 2006 09:07
Frank Buss wrote:
> I'm new to Forth, but I like ?dup, because it helps you to write less code.
> Without it you have to write this:
>
> : foo dup if do-something-with-x else drop then ;
>
> With ?dup you can write it like this:
>
> : foo ?dup if do-something-with-x then ;
>
> Maybe a "?if" would be better?
Chuck Moore has switched to something like that. A nondestructive IF
particularly. I could imagine the inefficiency would even out.
The following has less overhead than ELSE on many systems :
: foo dup if do-something-with-x dup then drop ;
?DUP usually has to implement a branch itself, although it can be done
in assembly or something to be efficient.
: ?DUP ( 0|x -- 0 | x x )
dup if dup then ;
|
| Show full article (0.81Kb) |
| 3 Comments |
|
|
|
|
