Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Reforth - A forth which fixes problematic aspects of Forth without sacrificing its simplicity.
567 views
Skip to first unread message
andreas...@lowfatcomputing.org
May 16, 2013, 12:18:59 PM5/16/13
to
I found this rethink of FORTH and I like what I see, but I would need to try coding with it.
http://aerosuidae.net/reforth/
Thoughts?
http://aerosuidae.net/reforth/
Thoughts?
Clyde W. Phillips Jr.
May 16, 2013, 12:51:24 PM5/16/13
to
On Thursday, May 16, 2013 11:18:59 AM UTC-5, andreas...@lowfatcomputing.org wrote:
> I found this rethink of FORTH and I like what I see, but I would need to try coding with it.
Yes Sir. I like it soo much so far, and you want to know why?
> I found this rethink of FORTH and I like what I see, but I would need to try coding with it.
I already feel I've coded in it, somehow after simply reading it.
I had my code inserting itself into it.
I like it so far.
Elizabeth D. Rather
May 16, 2013, 3:46:51 PM5/16/13
to
Virtually all the gripes deal with things that good programming style
can address. He says this is his 4th Forth (auspicious?) but doesn't say
how much actual application experience he has. I believe that in order
to write a really good Forth system it's necessary to have developed
good skills in *using* Forth.
I particularly disagree with his preference for null-terminated strings,
because of the implication of run-time length determination. Yes,
they're necessary for interacting with C, but not for internal Forth use.
I'd be interested to see how his loop ideas work out in practice.
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."
==================================================
Paul Rubin
May 17, 2013, 5:34:05 AM5/17/13
to
andreas...@lowfatcomputing.org writes:
> http://aerosuidae.net/reforth/
> Thoughts?
1. I agree with Elizabeth that the null-terminated strings are a dumb
idea. They might help for interoperation with C, but they were a dumb
idea in C as well. Hate on C++ as much as you want, at least it fixed
this issue with its string type.
2. I do like most of the language stuff, like the nested functions. It
looks like real consideration went into it. It took a while for the
Colorforth influence to become apparent, but when I recognized that, it
made me smile.
3. I do think the meaning
BEGIN foo bar END
is a little bit surprising (it's an infinite loop)
4. The implementation is cute too, though not in anything like the
classic Forth spirit. The editor (written in Forth) apparently
compiles your program into lower level primitives while you type.
These primitives then get handed off to the low level compiler
(written in C) which expands them into C code. This is actually
something like Colorforth, though Colorforth generates machine
code directly.
Anyway, it's intriguing and I may play with it sometime (I only looked
at the code for now, didn't try building or running it).
> http://aerosuidae.net/reforth/
> Thoughts?
1. I agree with Elizabeth that the null-terminated strings are a dumb
idea. They might help for interoperation with C, but they were a dumb
idea in C as well. Hate on C++ as much as you want, at least it fixed
this issue with its string type.
2. I do like most of the language stuff, like the nested functions. It
looks like real consideration went into it. It took a while for the
Colorforth influence to become apparent, but when I recognized that, it
made me smile.
3. I do think the meaning
BEGIN foo bar END
is a little bit surprising (it's an infinite loop)
4. The implementation is cute too, though not in anything like the
classic Forth spirit. The editor (written in Forth) apparently
compiles your program into lower level primitives while you type.
These primitives then get handed off to the low level compiler
(written in C) which expands them into C code. This is actually
something like Colorforth, though Colorforth generates machine
code directly.
Anyway, it's intriguing and I may play with it sometime (I only looked
at the code for now, didn't try building or running it).
Gerry Jackson
May 17, 2013, 6:21:24 AM5/17/13
to
On 17/05/2013 10:34, Paul Rubin wrote:
> andreas...@lowfatcomputing.org writes:
>> http://aerosuidae.net/reforth/
>> Thoughts?
>
> andreas...@lowfatcomputing.org writes:
>> http://aerosuidae.net/reforth/
>> Thoughts?
>
2. I do like most of the language stuff, like the nested functions.
I agree, I implemented nested definitions in my Forth some 2 or 3 months
ago for much the same reason as the ReForth author.
My ANS Forth gripe list overlaps his as well.
--
Gerry
Anton Ertl
May 17, 2013, 8:05:45 AM5/17/13
to
Null-terminated strings are a bad idea.
The control-flow ideas are not a significant improvement over standard
Forth.
State-smart control structures are a bad idea, but probably not worse
than other ideas for interpretable control flow.
Named nested definitions seem unnecessary to me.
The idea of two fixed local variables is interesting. The difference
from machineForth's registers is that you had to manage the registers
yourself, while the compiler does it for you for the locals. This
means that machineForth code is harder to reuse (like other code using
global state), but ReForth code is harder to factor (like other
locals).
The HIPHIP:CHEER idea has been under low-intensity discussion in the
Forth200x committee; it will probably take several more years until we
reach a consensus on such a thing; I believe it is an improvement over
the current way to deal with name spaces, so something like this
should be available.
"Sub-words as objects": The earlier ideas come together nicely. The
whole thing still does not quite convince me, but a part of that may
be the NIH syndrom:-).
String literals: The escape sequences are supported in Forth 200x S\".
Understanding the strings in the Forth parser (instead of through
words like S\") is implemented in the development branch of Gforth,
where it is based on a more general concept called recognizers (which
can also be used for implementing HIPHIP:CHEER).
String formatting: >STRING-EXECUTE is more flexible, and easier to
remember, but less terse.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
The control-flow ideas are not a significant improvement over standard
Forth.
State-smart control structures are a bad idea, but probably not worse
than other ideas for interpretable control flow.
Named nested definitions seem unnecessary to me.
The idea of two fixed local variables is interesting. The difference
from machineForth's registers is that you had to manage the registers
yourself, while the compiler does it for you for the locals. This
means that machineForth code is harder to reuse (like other code using
global state), but ReForth code is harder to factor (like other
locals).
The HIPHIP:CHEER idea has been under low-intensity discussion in the
Forth200x committee; it will probably take several more years until we
reach a consensus on such a thing; I believe it is an improvement over
the current way to deal with name spaces, so something like this
should be available.
"Sub-words as objects": The earlier ideas come together nicely. The
whole thing still does not quite convince me, but a part of that may
be the NIH syndrom:-).
String literals: The escape sequences are supported in Forth 200x S\".
Understanding the strings in the Forth parser (instead of through
words like S\") is implemented in the development branch of Gforth,
where it is based on a more general concept called recognizers (which
can also be used for implementing HIPHIP:CHEER).
String formatting: >STRING-EXECUTE is more flexible, and easier to
remember, but less terse.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
Paul Rubin
May 17, 2013, 9:00:17 AM5/17/13
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> The idea of two fixed local variables is interesting.
Oh yes I forgot to remark on that. It triples the amount of stuff
> The idea of two fixed local variables is interesting.
pushed on the R stack at each call, and it's not clear to me how you're
supposed to get at the locals if you also use >R to store stuff in the
traditional way. Maybe that's taken care of: I didn't check closely.
But that would require some bookkeeping, and it sounded like he wanted
the simplest possible compiler. So overall it's either very
constraining or else not much than the more flexible gforth-style
locals.
I do remember the TI-99 Forth Alex(?) posts about here has something
like that, with 4 slots instead of 2.
Alex McDonald
May 17, 2013, 9:00:30 AM5/17/13
to
On May 17, 1:05 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
shenanigans) if the code space and the dictionary space are distinct.
I suppose [: ;] is the nameless variety.
>
> The idea of two fixed local variables is interesting. The difference
> from machineForth's registers is that you had to manage the registers
> yourself, while the compiler does it for you for the locals. This
> means that machineForth code is harder to reuse (like other code using
> global state), but ReForth code is harder to factor (like other
> locals).
>
> The HIPHIP:CHEER idea has been under low-intensity discussion in the
> Forth200x committee; it will probably take several more years until we
> reach a consensus on such a thing; I believe it is an improvement over
> the current way to deal with name spaces, so something like this
> should be available.
I suspect that there will be complaints that namespace:word is too
noisy, especially if there are several namespaces or the same
namespace repeated several times. Then we will have a proposal for
ALSO <namespace> and hence no change.
>
> "Sub-words as objects": The earlier ideas come together nicely. The
> whole thing still does not quite convince me, but a part of that may
> be the NIH syndrom:-).
The steps the parser takes in the example given appear to be wrong.
wrote:
> andreas.wag...@lowfatcomputing.org writes:
> >http://aerosuidae.net/reforth/
>
> >Thoughts?
>
> Null-terminated strings are a bad idea.
>
> The control-flow ideas are not a significant improvement over standard
> Forth.
>
> State-smart control structures are a bad idea, but probably not worse
> than other ideas for interpretable control flow.
>
> Named nested definitions seem unnecessary to me.
They can only be implemented (at least, implemented without a lot of
> >http://aerosuidae.net/reforth/
>
> >Thoughts?
>
> Null-terminated strings are a bad idea.
>
> The control-flow ideas are not a significant improvement over standard
> Forth.
>
> State-smart control structures are a bad idea, but probably not worse
> than other ideas for interpretable control flow.
>
> Named nested definitions seem unnecessary to me.
shenanigans) if the code space and the dictionary space are distinct.
I suppose [: ;] is the nameless variety.
>
> The idea of two fixed local variables is interesting. The difference
> from machineForth's registers is that you had to manage the registers
> yourself, while the compiler does it for you for the locals. This
> means that machineForth code is harder to reuse (like other code using
> global state), but ReForth code is harder to factor (like other
> locals).
>
> The HIPHIP:CHEER idea has been under low-intensity discussion in the
> Forth200x committee; it will probably take several more years until we
> reach a consensus on such a thing; I believe it is an improvement over
> the current way to deal with name spaces, so something like this
> should be available.
noisy, especially if there are several namespaces or the same
namespace repeated several times. Then we will have a proposal for
ALSO <namespace> and hence no change.
>
> "Sub-words as objects": The earlier ideas come together nicely. The
> whole thing still does not quite convince me, but a part of that may
> be the NIH syndrom:-).
Ron Aaron
May 17, 2013, 9:09:55 AM5/17/13
to
On 05/17/2013 03:05 PM, Anton Ertl wrote:
> andreas...@lowfatcomputing.org writes:
>> http://aerosuidae.net/reforth/
>>
>> Thoughts?
>
> Null-terminated strings are a bad idea.
glibc or system libraries. That's why in Reva strings are
nul-terminated behind the scenes, so they can be passed as-is (well, the
address part can) to external functions.
Paul Rubin
May 17, 2013, 10:33:29 AM5/17/13
to
Paul Rubin <no.e...@nospam.invalid> writes:
> I do remember the TI-99 Forth Alex(?) posts about here
I'm probably thinking of Mark Wills. I don't remember any others who
> I do remember the TI-99 Forth Alex(?) posts about here
post 9900 stuff.
Albert van der Horst
May 17, 2013, 11:27:06 AM5/17/13
to
In article <hKKdnWwtUtExqgjM...@supernews.com>,
strings make me shudder.
I've been thinking about local anythings, instead of local values too.
My idea's go in the direction of explicit scoping
: do-something { : a x y z ; } ... a ... a ... ;
I can't stand the idea of do-something:a . The ':' destroys everything
Forth stands for. With explicit scoping it would look like
'do-something s's a ( pronounced " do-something ssss a " )
where s's sets of the dictionary
search from do-something. Here the ' is used more as a dictionary entry address
than an execution token. Without the scoping `` a '' would not be found.
>
>I'd be interested to see how his loop ideas work out in practice.
Certainly worth studying. Interpreting Control words are nothing new,
and easily implemented (two screens in a simple Forth like ciforth.),
but other aspects are new.
>
>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."
>==================================================
--
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
Elizabeth D. Rather <era...@forth.com> wrote:
>On 5/16/13 6:18 AM, andreas...@lowfatcomputing.org wrote:
>> I found this rethink of FORTH and I like what I see, but I would need
>to try coding with it.
>>
>> http://aerosuidae.net/reforth/
>>
>> Thoughts?
>>
>
>I disagree with most of his "gripes", but some of his ideas are interesting.
>
>Virtually all the gripes deal with things that good programming style
>can address. He says this is his 4th Forth (auspicious?) but doesn't say
>how much actual application experience he has. I believe that in order
>to write a really good Forth system it's necessary to have developed
>good skills in *using* Forth.
>
>I particularly disagree with his preference for null-terminated strings,
>because of the implication of run-time length determination. Yes,
>they're necessary for interacting with C, but not for internal Forth use.
Indeed most of the idea's are at least worth considering, but null-terminated
>On 5/16/13 6:18 AM, andreas...@lowfatcomputing.org wrote:
>> I found this rethink of FORTH and I like what I see, but I would need
>to try coding with it.
>>
>> http://aerosuidae.net/reforth/
>>
>> Thoughts?
>>
>
>I disagree with most of his "gripes", but some of his ideas are interesting.
>
>Virtually all the gripes deal with things that good programming style
>can address. He says this is his 4th Forth (auspicious?) but doesn't say
>how much actual application experience he has. I believe that in order
>to write a really good Forth system it's necessary to have developed
>good skills in *using* Forth.
>
>I particularly disagree with his preference for null-terminated strings,
>because of the implication of run-time length determination. Yes,
>they're necessary for interacting with C, but not for internal Forth use.
strings make me shudder.
I've been thinking about local anythings, instead of local values too.
My idea's go in the direction of explicit scoping
: do-something { : a x y z ; } ... a ... a ... ;
I can't stand the idea of do-something:a . The ':' destroys everything
Forth stands for. With explicit scoping it would look like
'do-something s's a ( pronounced " do-something ssss a " )
where s's sets of the dictionary
search from do-something. Here the ' is used more as a dictionary entry address
than an execution token. Without the scoping `` a '' would not be found.
>
>I'd be interested to see how his loop ideas work out in practice.
and easily implemented (two screens in a simple Forth like ciforth.),
but other aspects are new.
>
>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."
>==================================================
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
Albert van der Horst
May 17, 2013, 11:41:03 AM5/17/13
to
In article <9d5eae25-6916-4864...@a6g2000vbf.googlegroups.com>,
scoping.
I don't see that nested definitions are particularly difficult with
a single dictionary space. I'm almost inclined to take that as a challenge
for ciforth. ciforth had the forsight to implement inline strings
as a memory area that is jumped over (the word SKIP ,an alias for BRANCH)
Now I can SKIP anything. ( Doing away with S" C" (.") ." )
>
>
>>
>> The idea of two fixed local variables is interesting. �The difference
>> from machineForth's registers is that you had to manage the registers
>> yourself, while the compiler does it for you for the locals. �This
>> means that machineForth code is harder to reuse (like other code using
>> global state), but ReForth code is harder to factor (like other
>> locals).
>>
>> The HIPHIP:CHEER idea has been under low-intensity discussion in the
>> Forth200x committee; it will probably take several more years until we
>> reach a consensus on such a thing; I believe it is an improvement over
>> the current way to deal with name spaces, so something like this
>> should be available.
>
>I suspect that there will be complaints that namespace:word is too
>noisy, especially if there are several namespaces or the same
>namespace repeated several times. Then we will have a proposal for
>ALSO <namespace> and hence no change.
Too noisy? It requires a whole new interpreter/find mechanism.
>
Groetjes Albert
Alex McDonald <bl...@rivadpm.com> wrote:
>On May 17, 1:05�pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> andreas.wag...@lowfatcomputing.org writes:
>> >http://aerosuidae.net/reforth/
>>
>> >Thoughts?
>>
<SNIP>
>On May 17, 1:05�pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> andreas.wag...@lowfatcomputing.org writes:
>> >http://aerosuidae.net/reforth/
>>
>> >Thoughts?
>>
>> Named nested definitions seem unnecessary to me.
>
>
>They can only be implemented (at least, implemented without a lot of
>shenanigans) if the code space and the dictionary space are distinct.
>I suppose [: ;] is the nameless variety.
In his syntax the redefiniton of : is impossible, so I would prefer { } for
>
>
>They can only be implemented (at least, implemented without a lot of
>shenanigans) if the code space and the dictionary space are distinct.
>I suppose [: ;] is the nameless variety.
scoping.
I don't see that nested definitions are particularly difficult with
a single dictionary space. I'm almost inclined to take that as a challenge
for ciforth. ciforth had the forsight to implement inline strings
as a memory area that is jumped over (the word SKIP ,an alias for BRANCH)
Now I can SKIP anything. ( Doing away with S" C" (.") ." )
>
>
>>
>> The idea of two fixed local variables is interesting. �The difference
>> from machineForth's registers is that you had to manage the registers
>> yourself, while the compiler does it for you for the locals. �This
>> means that machineForth code is harder to reuse (like other code using
>> global state), but ReForth code is harder to factor (like other
>> locals).
>>
>> The HIPHIP:CHEER idea has been under low-intensity discussion in the
>> Forth200x committee; it will probably take several more years until we
>> reach a consensus on such a thing; I believe it is an improvement over
>> the current way to deal with name spaces, so something like this
>> should be available.
>
>I suspect that there will be complaints that namespace:word is too
>noisy, especially if there are several namespaces or the same
>namespace repeated several times. Then we will have a proposal for
>ALSO <namespace> and hence no change.
>
Groetjes Albert
Alex McDonald
May 17, 2013, 12:01:50 PM5/17/13
to
On May 17, 2:09 pm, Ron Aaron <rambam...@gmail.com> wrote:
> On 05/17/2013 03:05 PM, Anton Ertl wrote:
>
> On 05/17/2013 03:05 PM, Anton Ertl wrote:
>
> > andreas.wag...@lowfatcomputing.org writes:
> >>http://aerosuidae.net/reforth/
>
> >> Thoughts?
>
> > Null-terminated strings are a bad idea.
>
> They're an excellent idea when you want to pass your strings to e.g.
> glibc or system libraries. That's why in Reva strings are
> nul-terminated behind the scenes, so they can be passed as-is (well, the
> address part can) to external functions.
I made later versions of Win32Forth do that too. All strings terminate
> >>http://aerosuidae.net/reforth/
>
> >> Thoughts?
>
> > Null-terminated strings are a bad idea.
>
> They're an excellent idea when you want to pass your strings to e.g.
> glibc or system libraries. That's why in Reva strings are
> nul-terminated behind the scenes, so they can be passed as-is (well, the
> address part can) to external functions.
in a null, and all string operations maintain a terminating null.
Alex McDonald
May 17, 2013, 12:13:59 PM5/17/13
to
On May 17, 4:41 pm, alb...@spenarnc.xs4all.nl (Albert van der Horst)
wrote:
> In article <9d5eae25-6916-4864-8c3b-bd622d3cc...@a6g2000vbf.googlegroups.com>,
here's a -13 throw" from the currently defined parser. I've abandoned
FIND completely anyhow, and use the gforth inspired equivalent FIND-
NAME.
wrote:
> In article <9d5eae25-6916-4864-8c3b-bd622d3cc...@a6g2000vbf.googlegroups.com>,
> Alex McDonald <b...@rivadpm.com> wrote:
>
> >On May 17, 1:05 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
>
>
>
> >On May 17, 1:05 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
>
>
> >> The HIPHIP:CHEER idea has been under low-intensity discussion in the
> >> Forth200x committee; it will probably take several more years until we
> >> reach a consensus on such a thing; I believe it is an improvement over
> >> the current way to deal with name spaces, so something like this
> >> should be available.
>
> >I suspect that there will be complaints that namespace:word is too
> >noisy, especially if there are several namespaces or the same
> >namespace repeated several times. Then we will have a proposal for
> >ALSO <namespace> and hence no change.
>
> Too noisy? It requires a whole new interpreter/find mechanism.
Not really. All it needs is an escape hatch out of a "bad parse,
> >> Forth200x committee; it will probably take several more years until we
> >> reach a consensus on such a thing; I believe it is an improvement over
> >> the current way to deal with name spaces, so something like this
> >> should be available.
>
> >I suspect that there will be complaints that namespace:word is too
> >noisy, especially if there are several namespaces or the same
> >namespace repeated several times. Then we will have a proposal for
> >ALSO <namespace> and hence no change.
>
> Too noisy? It requires a whole new interpreter/find mechanism.
here's a -13 throw" from the currently defined parser. I've abandoned
FIND completely anyhow, and use the gforth inspired equivalent FIND-
NAME.
Elizabeth D. Rather
May 17, 2013, 2:13:56 PM5/17/13
to
internal use, they're grossly inefficient. If you need to pass an
internal string outside, it's an easy conversion.
Paul Rubin
May 17, 2013, 3:16:24 PM5/17/13
to
Alex McDonald <bl...@rivadpm.com> writes:
> I made later versions of Win32Forth do that too. All strings terminate
> in a null, and all string operations maintain a terminating null.
I've done stuff like that too (not for Forth) but there are
> I made later versions of Win32Forth do that too. All strings terminate
> in a null, and all string operations maintain a terminating null.
disadvantages, like if you want to write an in-situ parser or otherwise
have objects representing substrings of some big string, that just point
into the memory used by the big string.
rickman
May 17, 2013, 4:25:16 PM5/17/13
to
would other uses be precluded? As long at you don't try to use the
interstitial strings as null terminated all should be fine.
--
Rick
Ed
May 17, 2013, 11:23:44 PM5/17/13
to
to hide names of words no longer needed.
Control structures employ less words. Is it less confusing
to use the same names for different controls - or more?
Doug Hoffman
May 18, 2013, 6:05:07 AM5/18/13
to
On 5/17/13 11:23 PM, Ed wrote:
> Control structures employ less words. Is it less confusing
> to use the same names for different controls - or more?
We already have the same names for some different control flow, like
> Control structures employ less words. Is it less confusing
> to use the same names for different controls - or more?
begin and if:
begin
again
begin
until
begin
while
repeat
(multiwhiles not shown)
I sometimes get again and repeat confused because in English they convey
essentially the same meaning.
-Doug
Ed
May 18, 2013, 8:33:24 AM5/18/13
to
Doug Hoffman wrote:
> ...
Programming isn't English. Correct use of Again/Repeat is covered in
Forth101. Should a newbie confuse them they'll keep getting an error
message until the difference registers.
> ...
> I sometimes get again and repeat confused because in English they convey
> essentially the same meaning.
Like End; and End. in Pascal?
> essentially the same meaning.
Programming isn't English. Correct use of Again/Repeat is covered in
Forth101. Should a newbie confuse them they'll keep getting an error
message until the difference registers.
Albert van der Horst
May 18, 2013, 8:45:25 AM5/18/13
to
In article <kn6s65$ari$1...@speranza.aioe.org>, Ed <inv...@nospam.com> wrote:
>andreas...@lowfatcomputing.org wrote:
>> I found this rethink of FORTH and I like what I see, but I would need
>to try coding
>> with it.
>>
>> http://aerosuidae.net/reforth/
>>
>> Thoughts?
>
>Nested definitions - long and painful. There are easier ways
>to hide names of words no longer needed.
There is not an easier way to document that words are local facilities.
>andreas...@lowfatcomputing.org wrote:
>> I found this rethink of FORTH and I like what I see, but I would need
>to try coding
>> with it.
>>
>> http://aerosuidae.net/reforth/
>>
>> Thoughts?
>
>Nested definitions - long and painful. There are easier ways
>to hide names of words no longer needed.
On the other hand a word that contains other words is long.
Add an other level of nesting like classes and you're in for a mess.
There seems to be no solution ...
Maybe a good program is an art form of compromise ...
Elegance leading to parsimony may be the key.
>
>Control structures employ less words. Is it less confusing
>to use the same names for different controls - or more?
and at least solved the problem that some loops go on for a definite
time, but sometimes need a LEAVE. In Forth that invariably leads to ugly
code in my experience.
Maybe iterators and exceptions is a solution.
Doug Hoffman
May 18, 2013, 8:50:05 AM5/18/13
to
On 5/18/13 8:33 AM, Ed wrote:
> Doug Hoffman wrote:
>> ...
>> I sometimes get again and repeat confused because in English they convey
>> essentially the same meaning.
> Doug Hoffman wrote:
>> ...
>> I sometimes get again and repeat confused because in English they convey
>> essentially the same meaning.
> Programming isn't English. Correct use of Again/Repeat is covered in
> Forth101.
You are right. It is my failing/weakness.
> Forth101.
-Doug
Ron Aaron
May 18, 2013, 2:01:30 PM5/18/13
to
On 05/17/2013 09:13 PM, Elizabeth D. Rather wrote:
> Sure. That's what they're good for. Pretty much nothing else. For
> internal use, they're grossly inefficient. If you need to pass an
> internal string outside, it's an easy conversion.
This seems to be a dividing line to some extent between the 'hosted'
Forths and the native ones. Those of us who work 'hosted', rely on the
underlying OS for services ... and the API calls, pretty much without
exception, require NUL terminated strings. A native Forth doesn't need
them at all for any reason.
The reason I eliminated the "zt" word (zero-terminate) from Reva in
practice was that it was annoying to have to intersperse it all the time
when calling an external library, and even more annoying when forgotten!
Doug Hoffman
May 19, 2013, 5:44:41 AM5/19/13
to
On 5/18/13 8:33 AM, Ed wrote:
> Programming isn't English.
Choosing meaningful names is generally best. One could do this:
synonym ever again
begin
ever \ as in forever
begin
repeat \ meaningful but wrong
begin
while
again \ meaningful but wrong
Looking at the definitions of the the three words in a dictionary (ever
repeat again), two of them are defined in terms of the other: again and
repeat. A dictionary defines ever as forever.
*Not* suggesting any changes.
-Doug
Gerry Jackson
May 19, 2013, 6:00:37 AM5/19/13
to
On 17/05/2013 16:41, Albert van der Horst wrote:
> In article <9d5eae25-6916-4864...@a6g2000vbf.googlegroups.com>,
> Alex McDonald <bl...@rivadpm.com> wrote:
>> On May 17, 1:05 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>> wrote:
>>> andreas.wag...@lowfatcomputing.org writes:
>>>> http://aerosuidae.net/reforth/
>>>
>>>> Thoughts?
>>>
> <SNIP>
>>> Named nested definitions seem unnecessary to me.
>>
>>
>> They can only be implemented (at least, implemented without a lot of
>> shenanigans) if the code space and the dictionary space are distinct.
>> I suppose [: ;] is the nameless variety.
>
> In his syntax the redefiniton of : is impossible,
Why? Surely his version of : is effectively an immediate word and can be
> In article <9d5eae25-6916-4864...@a6g2000vbf.googlegroups.com>,
> Alex McDonald <bl...@rivadpm.com> wrote:
>> On May 17, 1:05 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>> wrote:
>>> andreas.wag...@lowfatcomputing.org writes:
>>>> http://aerosuidae.net/reforth/
>>>
>>>> Thoughts?
>>>
> <SNIP>
>>> Named nested definitions seem unnecessary to me.
>>
>>
>> They can only be implemented (at least, implemented without a lot of
>> shenanigans) if the code space and the dictionary space are distinct.
>> I suppose [: ;] is the nameless variety.
>
> In his syntax the redefiniton of : is impossible,
redefined with a call to the original : (like any other immediate word)
by postponing it.
[...]
--
Gerry
Steve
May 19, 2013, 8:49:21 AM5/19/13
to
Steve.
Albert van der Horst
May 19, 2013, 2:39:47 PM5/19/13
to
In article <kna7kn$r45$1...@dont-email.me>,
I stand corrected. It can be done in a way similar to haven an
interpreted IF. We have to rethink : as a word that belongs
to the compilations system and hence should be immediate ...
>
>[...]
>
>--
>Gerry
interpreted IF. We have to rethink : as a word that belongs
to the compilations system and hence should be immediate ...
>
>[...]
>
>--
>Gerry
Mark Wills
May 20, 2013, 6:25:56 AM5/20/13
to
There were 8 words:
!A !B !C !D and @A @B @C @D.
That was it. Super mega simple and took minutes to implement. It took me a lot longer to document it.
I eventually replaced it with a more 'traditional' locals implementation:
http://turboforth.net/locals.html
FWIW.
Mark Wills
May 20, 2013, 6:27:13 AM5/20/13
to
Null-terminated strings in Forth should be an anathema IMHO.
The Beez
May 25, 2013, 9:45:02 AM5/25/13
to
On 17 mei, 11:34, Paul Rubin <no.em...@nospam.invalid> wrote:
> 1. I agree with Elizabeth that the null-terminated strings are a dumb
> idea. They might help for interoperation with C, but they were a dumb
> idea in C as well. Hate on C++ as much as you want, at least it fixed
> this issue with its string type.
Well, I don't. The "speed" advantage of counted strings is barely
noticeable in practice because if you (a) reduce the amount of string
variables, you will (b) be using addr/count strings 99% percent of the
time. Proof: the lack of COUNT's, especially within control
constructs. And most people conveniently forget the DISadvantages of
counted strings.
> 2. I do like most of the language stuff, like the nested functions. It
> looks like real consideration went into it. It took a while for the
> Colorforth influence to become apparent, but when I recognized that, it
> made me smile.
Well, most of those concepts also are part of 4tH - for the last
TWENTY years, like nested functions, multi-WHILE control structures,
state-smart control structures, immediate structures and circular
string buffers. Even his (most elegant) object orientation resembles
4tH's FOOS implementation on certain aspects. However, 4tH maintains a
much higher compatibility with standard ANS Forth, mostly because it
is more explicit, e.g. you can make a nested function private, but it
isn't done automatically.
His BREAK and CONTINUE are very nice from the user side, but when you
have to implement it with stack-based control structures, it isn't
very nice - I don't digging through a stack to find the nearest loop
construct. Note the original LEAVE did neither: it just set the LOOP
index to the LOOP limit (and that's still how 4tH does it). It
resembles a BASIC interpreter I once wrote, so I suspect LOOP
constructs have their own private control stack.
> 4. The implementation is cute too, though not in anything like the
> classic Forth spirit. The editor (written in Forth) apparently
> compiles your program into lower level primitives while you type.
> These primitives then get handed off to the low level compiler
> (written in C) which expands them into C code. This is actually
> something like Colorforth, though Colorforth generates machine
> code directly.
Again, it resembles 4tH. But 4tH compiles the source not while typing,
but in one go. Technically, there isn't too much difference. 4tH also
provides the C-code generator, but as one separate step.
In short, I can understand why this thing was written, since I agree
with most of his "gripes". However, while his "outside" constructs are
pretty clean, I expect (some of them) them not to be so clean in the
implementation. His MY and AT I think are just ugly kludges.
Hans Bezemer
> 1. I agree with Elizabeth that the null-terminated strings are a dumb
> idea. They might help for interoperation with C, but they were a dumb
> idea in C as well. Hate on C++ as much as you want, at least it fixed
> this issue with its string type.
Well, I don't. The "speed" advantage of counted strings is barely
noticeable in practice because if you (a) reduce the amount of string
variables, you will (b) be using addr/count strings 99% percent of the
time. Proof: the lack of COUNT's, especially within control
constructs. And most people conveniently forget the DISadvantages of
counted strings.
> 2. I do like most of the language stuff, like the nested functions. It
> looks like real consideration went into it. It took a while for the
> Colorforth influence to become apparent, but when I recognized that, it
> made me smile.
Well, most of those concepts also are part of 4tH - for the last
TWENTY years, like nested functions, multi-WHILE control structures,
state-smart control structures, immediate structures and circular
string buffers. Even his (most elegant) object orientation resembles
4tH's FOOS implementation on certain aspects. However, 4tH maintains a
much higher compatibility with standard ANS Forth, mostly because it
is more explicit, e.g. you can make a nested function private, but it
isn't done automatically.
His BREAK and CONTINUE are very nice from the user side, but when you
have to implement it with stack-based control structures, it isn't
very nice - I don't digging through a stack to find the nearest loop
construct. Note the original LEAVE did neither: it just set the LOOP
index to the LOOP limit (and that's still how 4tH does it). It
resembles a BASIC interpreter I once wrote, so I suspect LOOP
constructs have their own private control stack.
> 4. The implementation is cute too, though not in anything like the
> classic Forth spirit. The editor (written in Forth) apparently
> compiles your program into lower level primitives while you type.
> These primitives then get handed off to the low level compiler
> (written in C) which expands them into C code. This is actually
> something like Colorforth, though Colorforth generates machine
> code directly.
Again, it resembles 4tH. But 4tH compiles the source not while typing,
but in one go. Technically, there isn't too much difference. 4tH also
provides the C-code generator, but as one separate step.
In short, I can understand why this thing was written, since I agree
with most of his "gripes". However, while his "outside" constructs are
pretty clean, I expect (some of them) them not to be so clean in the
implementation. His MY and AT I think are just ugly kludges.
Hans Bezemer
m...@iae.nl
May 25, 2013, 10:41:00 AM5/25/13
to
On Saturday, May 25, 2013 3:45:02 PM UTC+2, The Beez wrote:
> On 17 mei, 11:34, Paul Rubin <no.em...@nospam.invalid> wrote:
[..]
> On 17 mei, 11:34, Paul Rubin <no.em...@nospam.invalid> wrote:
> In short, I can understand why this thing was written, since I agree
^^^^^^^^^^^^^
> with most of his "gripes".
^^^^^^^^^^^^^^^^^^^^^^^^^
:-))
> However, while his "outside" constructs are
> pretty clean, I expect (some of them) them not to be so clean in the
> implementation. His MY and AT I think are just ugly kludges.
-marcel
0 new messages