On 3/12/21 5:21 AM, Anton Ertl wrote:
> Ben Hoyt <benhoyt@gmail.com> writes:
>> Thanks for the help, folks. Updated version:
>> https://gist.github.com/benhoyt/770a6ce13e307b8cd2e7f1e7c4731c70
>>
>> (Merge sort taken from Rosetta Code.)
>>
>> I decided to just build the latest version of Gforth so I could have TRAVERSE-WORDLIST.
>>
>> dxforth, thanks a lot for the pointers to SKIP and SCAN -- very helpful.
>>
>> It's actually quite fast -- not much slower than the Python
>> solution! (Python takes ~2.2 seconds for my large 43MB input file,
>> this Gforth solution takes 3.7s).

ISTM that even this non-optimized "Forth" solution contains enough
non-standard words to make it difficult or impossible for the casual
reader of Hoyt's article to run it on anything but the latest Gforth. It
won't run on VFX and, I suspect, SwiftForth. Two very mainstream and
easily obtained Forths. I still can't get the latest Gforth to run on my
Mac (Catalina OS). The optimized version is hopeless.

Undefined words:
rdrop
execute-parsing
skip and scan are not in ANS (are they?), though VFX has them

Hoyt had to search "in the wild" for a cell array sort routine and he
found one in Rosetta Code. That's a shoddy way to have to find "library
code".

He lamented having to write his own ascii lower case routine.

Strangely, he also laments "I used to love the idea of no local
variables, but in practice it just means a lot of dup over swap rot".
But ANS Forth is chock full of local variables. Two different flavors
are in the standard. I don't understand his comment here.

Bottom line, I think anyone reading Hoyt's article will come away with a
very bad impression of what it takes to write programs in Forth. It
didn't have to be that way. Steering Hoyt to only standard ANS solutions
that would run as-is on Gforth, VFX, and SwiftForth would have been far
better IMO. Of course that would not have solved the problem of finding
"library" routines like merge-sort, lowercase, and perhaps a hash table.
The solution to that seems simple but I'm not volunteering.

Sorry this is coming so late. I have been unavoidably busy with other
things for most of the year.

-Doug

> Slower than Python does not sound fast to me:-)
>
> Is the benchmark input publically available?
>
> - anton
>

On Friday, 13 August 2021 at 14:51:55 UTC+1, Doug Hoffman wrote:
> On 3/12/21 5:21 AM, Anton Ertl wrote:
> > Ben Hoyt <ben...@gmail.com> writes:
> >> Thanks for the help, folks. Updated version:
> >> https://gist.github.com/benhoyt/770a6ce13e307b8cd2e7f1e7c4731c70
> >>
> >> (Merge sort taken from Rosetta Code.)
> >>
> >> I decided to just build the latest version of Gforth so I could have TRAVERSE-WORDLIST.
> >>
> >> dxforth, thanks a lot for the pointers to SKIP and SCAN -- very helpful.
> >>
> >> It's actually quite fast -- not much slower than the Python
> >> solution! (Python takes ~2.2 seconds for my large 43MB input file,
> >> this Gforth solution takes 3.7s).
>
> ISTM that even this non-optimized "Forth" solution contains enough
> non-standard words to make it difficult or impossible for the casual
> reader of Hoyt's article to run it on anything but the latest Gforth. It
> won't run on VFX and, I suspect, SwiftForth. Two very mainstream and
> easily obtained Forths. I still can't get the latest Gforth to run on my
> Mac (Catalina OS). The optimized version is hopeless.
>
> Undefined words:
> rdrop
> execute-parsing
> skip and scan are not in ANS (are they?), though VFX has them
>
>
> Hoyt had to search "in the wild" for a cell array sort routine and he
> found one in Rosetta Code. That's a shoddy way to have to find "library
> code".
>
> He lamented having to write his own ascii lower case routine.
>
> Strangely, he also laments "I used to love the idea of no local
> variables, but in practice it just means a lot of dup over swap rot".
> But ANS Forth is chock full of local variables. Two different flavors
> are in the standard. I don't understand his comment here.
>
> Bottom line, I think anyone reading Hoyt's article will come away with a
> very bad impression of what it takes to write programs in Forth. It
> didn't have to be that way. Steering Hoyt to only standard ANS solutions
> that would run as-is on Gforth, VFX, and SwiftForth would have been far
> better IMO. Of course that would not have solved the problem of finding
> "library" routines like merge-sort, lowercase, and perhaps a hash table.
> The solution to that seems simple but I'm not volunteering.
>
> Sorry this is coming so late. I have been unavoidably busy with other
> things for most of the year.
>
> -Doug
>
> > Slower than Python does not sound fast to me:-)
> >
> > Is the benchmark input publically available?
> >
> > - anton
> >

""

I think, if you read the earlier posts, you will find that Ben states "I want to keep
it "mostly standard" but I'm fine using a couple of Gforth-specific features if
needed. " .

As for the undefined words, I assume rdrop is simply

: rdrop ( -- ) r> drop ;

Skip and scan are :-

: scan ( a u c -- a1 u1 )
over 0= if drop exit then
>r over c@ r@ = if r> drop else 1 /string r> recurse then ;

: skip ( a u c -- a1 u1 )
over 0= if drop exit then
>r over c@ r@ = if 1 /string r> recurse else r> drop then ;

Execute-parsing is :-

https://git.savannah.gnu.org/cgit/gforth.git/tree/compat/execute-parsing.fs

As someone who tried his hand at the exercise, I did come away with the impression
that for a problem that sounded simple it was not easy to solve in forth. ( I didnt need
to read Ben's article to come to that conclusion. )

I also realised the need to build a library and that's going to be a slow work-in-progress.

NN

Doug Hoffman <dhoffman888@gmail.com> writes:
>ISTM that even this non-optimized "Forth" solution contains enough
>non-standard words to make it difficult or impossible for the casual
>reader of Hoyt's article to run it on anything but the latest Gforth. It
>won't run on VFX and, I suspect, SwiftForth. Two very mainstream and
>easily obtained Forths. I still can't get the latest Gforth to run on my
>Mac (Catalina OS). The optimized version is hopeless.
>
>Undefined words:
>rdrop
>execute-parsing
>skip and scan are not in ANS (are they?), though VFX has them

RDROP is indeed not necessary and can be replaced with R> DROP.

Concerning EXECUTE-PARSING, he did the right thing and used a capable
Forth instead of trying to work around the deplorable fact that VFX
and SwiftForth still have not implemented this word. Shame on them!

It's not as if EXECUTE-PARSING is a secret of Gforth. EXECUTE-PARSING
has been discussed here repeatedly since November 2000, it has been
brought up in the standardization committee, where typical tabling
tactics have been used successfully (ask for more functionality, and
when that request is satisfied, everybody dislikes the result because
of complexity). And of course, they have the classical defense that
nobody uses EXECUTE-PARSING. Ben Hoyt's program is a counterexample
to that claim. If you want to run Ben Hoyt's program on VFX, ask
Stephen Pelc for EXECUTE-PARSING.

SKIP and SCAN exist in Gforth, SwiftForth, and VFX.

>Hoyt had to search "in the wild" for a cell array sort routine and he
>found one in Rosetta Code. That's a shoddy way to have to find "library
>code".

So what? The result worked. Sure, it would be better if Forth had a
library culture like, say, Python, but for various reasons it has not.

>He lamented having to write his own ascii lower case routine.

Gforth only has TOUPPER:-).

>Strangely, he also laments "I used to love the idea of no local
>variables, but in practice it just means a lot of dup over swap rot".
>But ANS Forth is chock full of local variables. Two different flavors
>are in the standard. I don't understand his comment here.

Lot's of people here claim that proper Forth code does not need
locals, and that real Forthers do not use them. Apparently Ben Hoyt
followed this dogma in this program, then looked at the result, and
made this comment.

>Bottom line, I think anyone reading Hoyt's article will come away with a
>very bad impression of what it takes to write programs in Forth. It
>didn't have to be that way. Steering Hoyt to only standard ANS solutions
>that would run as-is on Gforth, VFX, and SwiftForth would have been far
>better IMO.

My impression is that he was not interested in being steered. A
number of people (me included) presented alternative solutions.

In what sense would a pure-standard solution have been better? It
would have been even longer, portraying Forth as a very long-winded
language.

You can find a short version (25 lines including empty lines and
comments) in <2021Mar12.090140@mips.complang.tuwien.ac.at>.

You can also find a version that runs on lxf, SwiftForth, and VFX on
<http://www.complang.tuwien.ac.at/anton/count-unique-portable.fs>,
with results in <2021Mar19.172724@mips.complang.tuwien.ac.at> and
<2021Mar20.095626@mips.complang.tuwien.ac.at>. And finally I did a
very Gforth-performance-oriented version
<2021Mar20.152840@mips.complang.tuwien.ac.at>.

- 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 2021: https://euro.theforth.net/2021

NN <november.nihal@gmail.com> writes:
>: rdrop ( -- ) r> drop ;

Unfortunately, that does not work in general, because there is a
colon-sys on the top of return stack at the start of this colon
definition.

- 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 2021: https://euro.theforth.net/2021

On Friday, 13 August 2021 at 17:14:23 UTC+1, Anton Ertl wrote:
> NN <novembe...@gmail.com> writes:
> >: rdrop ( -- ) r> drop ;
> Unfortunately, that does not work in general, because there is a
> colon-sys on the top of return stack at the start of this colon
> definition.
> - 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 2021: https://euro.theforth.net/2021

My bad :-(

Would this work ?

: rdrop postpone >r postpone drop ; immediate

NN <november.nihal@gmail.com> writes:
>Would this work ?
>
>: rdrop postpone >r postpone drop ; immediate

As used by Ben Hoyt, yes.

Interpreting it does not work like Gforth's RDROP (but then, other
Forth systems generally don't support interpretive return stack access
anyway), and ticking it does not work like Gforth's RDROP, either.

- 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 2021: https://euro.theforth.net/2021

On 8/13/21 11:02 AM, Anton Ertl wrote:
> Doug Hoffman <dhoffman888@gmail.com> writes:
>> ISTM that even this non-optimized "Forth" solution contains enough
>> non-standard words to make it difficult or impossible for the casual
>> reader of Hoyt's article to run it on anything but the latest Gforth. It
>> won't run on VFX and, I suspect, SwiftForth. Two very mainstream and
>> easily obtained Forths. I still can't get the latest Gforth to run on my
>> Mac (Catalina OS). The optimized version is hopeless.
>>
>> Undefined words:
>> rdrop
>> execute-parsing
>> skip and scan are not in ANS (are they?), though VFX has them
>
> RDROP is indeed not necessary and can be replaced with R> DROP.
>
> Concerning EXECUTE-PARSING, he did the right thing and used a capable
> Forth instead of trying to work around the deplorable fact that VFX
> and SwiftForth still have not implemented this word. Shame on them!
>
> It's not as if EXECUTE-PARSING is a secret of Gforth. EXECUTE-PARSING
> has been discussed here repeatedly since November 2000, it has been
> brought up in the standardization committee, where typical tabling
> tactics have been used successfully (ask for more functionality, and
> when that request is satisfied, everybody dislikes the result because
> of complexity). And of course, they have the classical defense that
> nobody uses EXECUTE-PARSING. Ben Hoyt's program is a counterexample
> to that claim. If you want to run Ben Hoyt's program on VFX, ask
> Stephen Pelc for EXECUTE-PARSING.
>
> SKIP and SCAN exist in Gforth, SwiftForth, and VFX.

Do they all behave the same?

>> Hoyt had to search "in the wild" for a cell array sort routine and he
>> found one in Rosetta Code. That's a shoddy way to have to find "library
>> code".
>
> So what? The result worked. Sure, it would be better if Forth had a
> library culture

That is an understatement.

> like, say, Python, but for various reasons it has not.
>
>> He lamented having to write his own ascii lower case routine.
>
> Gforth only has TOUPPER:-).
>
>> Strangely, he also laments "I used to love the idea of no local
>> variables, but in practice it just means a lot of dup over swap rot".
>> But ANS Forth is chock full of local variables. Two different flavors
>> are in the standard. I don't understand his comment here.
>
> Lot's of people here claim that proper Forth code does not need
> locals, and that real Forthers do not use them. Apparently Ben Hoyt
> followed this dogma in this program, then looked at the result, and
> made this comment.
>
>> Bottom line, I think anyone reading Hoyt's article will come away with a
>> very bad impression of what it takes to write programs in Forth. It
>> didn't have to be that way. Steering Hoyt to only standard ANS solutions
>> that would run as-is on Gforth, VFX, and SwiftForth would have been far
>> better IMO.
>
> My impression is that he was not interested in being steered. A
> number of people (me included) presented alternative solutions.
>
> In what sense would a pure-standard solution have been better?

Anyone wanting to run the code could easily have done so on any
of VFX, SwiftForth, or Gforth (and maybe some other Forths).

> It
> would have been even longer, portraying Forth as a very long-winded
> language.
>
> You can find a short version (25 lines including empty lines and
> comments) in <2021Mar12.090140@mips.complang.tuwien.ac.at>.
>
> You can also find a version that runs on lxf, SwiftForth, and VFX on
> <http://www.complang.tuwien.ac.at/anton/count-unique-portable.fs>,
> with results in <2021Mar19.172724@mips.complang.tuwien.ac.at> and
> <2021Mar20.095626@mips.complang.tuwien.ac.at>. And finally I did a
> very Gforth-performance-oriented version
> <2021Mar20.152840@mips.complang.tuwien.ac.at>.
>
> - anton

So regardless of what you or I think, he concludes the following
about Forth:

"(though I’m not sure it’s valid to call this simple!):"

"It’s not for nothing that Forth has a reputation for being write-only."

"in practice it just means a lot of dup over swap rot"

"even Gforth (which has a lot more than ANS standard Forth) doesn’t have
fairly basic tools like to-lower or sort, so we have to roll those
ourselves (the in-place merge sort was taken from Rosetta Code)"

"I might still consider using Forth for fun or on tiny embedded systems,
but I don’t think it has the ergonomics or the libraries to write
programs for general use. For a much richer, more modern take on a
Forth-like language, check out Factor."

-Doug

p.s., I worry about using the dictionary trick to get a hash table. One
could not do this for shipping a turnkey production program. A
dedicated hash table is needed, like Marcel did it.

Doug Hoffman <dhoffman888@gmail.com> writes:
>On 8/13/21 11:02 AM, Anton Ertl wrote:
>> SKIP and SCAN exist in Gforth, SwiftForth, and VFX.
>
>Do they all behave the same?

Who knows? In my portable version I used the standardized PARSE-NAME
instead, but found that SwiftForth and VFX do not treat line feed as
white space in PARSE-NAME, and so instead used the reference
implementation of PARSE-NAME.

>> In what sense would a pure-standard solution have been better?
>
>Anyone wanting to run the code could easily have done so on any
>of VFX, SwiftForth, or Gforth (and maybe some other Forths).

Yes, but the program would have been even longer, which would have
made Forth look even worse. And the vendors would be reinforced in
their stance than nobody needs EXECUTE-PARSING.

>p.s., I worry about using the dictionary trick to get a hash table. One
>could not do this for shipping a turnkey production program.

Sure one can. A turnkey program just starts a different word instead
of the text interpreter.

>A
>dedicated hash table is needed, like Marcel did it.

I see no reason not to use Forth features just because some vendors
don't support them for turnkey programs. Better ask these vendors for
providing the full power of Forth, including wordlists, in turnkey
programs.

- 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 2021: https://euro.theforth.net/2021

On 13 Aug 2021 at 16:02:39 BST, "Anton Ertl" <Anton Ertl> wrote:

> Concerning EXECUTE-PARSING, he did the right thing and used a capable
> Forth instead of trying to work around the deplorable fact that VFX
> and SwiftForth still have not implemented this word. Shame on them!

There's an old proverb "People in glass houses shouldn't throw stones".

>> Bottom line, I think anyone reading Hoyt's article will come away with a
>> very bad impression of what it takes to write programs in Forth. It
>> didn't have to be that way. Steering Hoyt to only standard ANS solutions
>> that would run as-is on Gforth, VFX, and SwiftForth would have been far
>> better IMO.

If you want a new word adopted, it is a good idea to implement it for more
than one system. I look forward to Anton's contribution of EXECUTE-PARSING
for VFX.

Stephen

>
> If you want a new word adopted, it is a good idea to implement it for more
> than one system. I look forward to Anton's contribution of EXECUTE-PARSING
> for VFX.

Bernd actually implemented (thanks) EXECUTE-PARSING for VFX many
years ago. See the VfxForth harness in the Minos sources.

In my ample spare time I'll make a file of gForth-isms.

Stephen

Stephen Pelc <stephen@vfxforth.com> writes:
>On 13 Aug 2021 at 16:02:39 BST, "Anton Ertl" <Anton Ertl> wrote:
>
>> Concerning EXECUTE-PARSING, he did the right thing and used a capable
>> Forth instead of trying to work around the deplorable fact that VFX
>> and SwiftForth still have not implemented this word. Shame on them!
>
>There's an old proverb "People in glass houses shouldn't throw stones".

Gforth has provided EXECUTE-PARSING since Gforth-0.6 in 2003.

>>> Bottom line, I think anyone reading Hoyt's article will come away with a
>>> very bad impression of what it takes to write programs in Forth. It
>>> didn't have to be that way. Steering Hoyt to only standard ANS solutions
>>> that would run as-is on Gforth, VFX, and SwiftForth would have been far
>>> better IMO.
>
>If you want a new word adopted, it is a good idea to implement it for more
>than one system. I look forward to Anton's contribution of EXECUTE-PARSING
>for VFX.

I posted an implementation in Forth-94 (should work on VFX) here
in on February 12, 2006 <2006Feb12.174921@mips.complang.tuwien.ac.at>,
and added it to

http://www.complang.tuwien.ac.at/forth/compat.zip

shortly after. In the meantime you can find it also on

http://theforth.net/package/compat

in particular in

http://theforth.net/package/compat/current-view/execute-parsing.fs

And I mentioned both EXECUTE-PARSING and its implementation here
repeatedly.

You have only yourself to blame for not including it in VFX earlier.

- 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 2021: https://euro.theforth.net/2021

On 13/08/2021 23:51, Doug Hoffman wrote:
> ...
> Bottom line, I think anyone reading Hoyt's article will come away with a
> very bad impression of what it takes to write programs in Forth.

First impressions of Forth are typically bad. I was no different. But
if others were able to use it successfully - why not me?

> It
> didn't have to be that way. Steering Hoyt to only standard ANS solutions
> that would run as-is on Gforth, VFX, and SwiftForth would have been far
> better IMO.

Agreed. I wouldn't have used the forth compiler/dictionary which then
relies on oddities such as:

search-wordlist
name>string
name>interpret
execute-parsing

A mundane approach as might be done in C is preferable to 'showing off'
Forth, which then backfires.

to-lower

I might agree with because functions like this have universal appeal -
just don't expect it to come from 200x.

On 8/16/21 12:24 AM, dxforth wrote:
> On 13/08/2021 23:51, Doug Hoffman wrote:
>> ... Bottom line, I think anyone reading Hoyt's article will come away
>> with a
>> very bad impression of what it takes to write programs in Forth.
>
> First impressions of Forth are typically bad.  I was no different.  But
> if others were able to use it successfully - why not me?
>
>> It
>> didn't have to be that way. Steering Hoyt to only standard ANS solutions
>> that would run as-is on Gforth, VFX, and SwiftForth would have been far
>> better IMO.
>
> Agreed.  I wouldn't have used the forth compiler/dictionary which then
> relies on oddities such as:

These 3 words are now in the standard, and Gforth, VFX, and SwiftForth
all have them:

> search-wordlist
> name>string
> name>interpret

execute-parsing and the sort (in place) and rdrop used are non-standard.
Finding them in-the-wild is non-trivial but can be done. Standard Forth
could benefit greatly by having a Standard Library. The problem would of
course be agreeing on what should be in a Standard Library and, more
difficult yet, what code to use. The Forth community would never agree
on even a simple Standard Library. It's just not part of the culture.
I'm amazed that we have the ANS Standard as it is.

I didn't have a problem with showing the code for to-lower because that
"showed off" how easily such functions can be written in Forth. Though
it is likely a candidate for a Standard Library.

-Doug

> A mundane approach as might be done in C is preferable to 'showing off'
> Forth, which then backfires.
>
> to-lower
>
> I might agree with because functions like this have universal appeal -
> just don't expect it to come from 200x.

On 15 Aug 2021 at 16:31:29 BST, "Anton Ertl" <Anton Ertl> wrote:

> Stephen Pelc <stephen@vfxforth.com> writes:
>> On 13 Aug 2021 at 16:02:39 BST, "Anton Ertl" <Anton Ertl> wrote:
>>
>>> Concerning EXECUTE-PARSING, he did the right thing and used a capable
>>> Forth instead of trying to work around the deplorable fact that VFX
>>> and SwiftForth still have not implemented this word. Shame on them!
>>
>> There's an old proverb "People in glass houses shouldn't throw stones".
>
> Gforth has provided EXECUTE-PARSING since Gforth-0.6 in 2003.

Jolly good. But the point I was making is that VFX contains many words
(features) that I find far more useful than EXECUTE-PARSING. You will
argue the same for gForth. Having hissy-fits about a favourite word is
unproductive.

Stephen

Stephen Pelc <stephen@vfxforth.com> writes:
>Jolly good. But the point I was making is that VFX contains many words
>(features) that I find far more useful than EXECUTE-PARSING. You will
>argue the same for gForth.

The original point was not what you or I find useful, but what Ben
Hoyt found useful, and whether, as Doug Hoffman argued, Ben Hoyt
should have refrained from using it because you did not supply this
word with VFX. I don't think he should.

- 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 2021: https://euro.theforth.net/2021

On Monday, 16 August 2021 at 11:11:29 UTC+2, Doug Hoffman wrote:
> On 8/16/21 12:24 AM, dxforth wrote:
> > On 13/08/2021 23:51, Doug Hoffman wrote:
> >> ... Bottom line, I think anyone reading Hoyt's article will come away
> >> with a
> >> very bad impression of what it takes to write programs in Forth.
> >
> > First impressions of Forth are typically bad. I was no different. But
> > if others were able to use it successfully - why not me?
> >
> >> It
> >> didn't have to be that way. Steering Hoyt to only standard ANS solutions
> >> that would run as-is on Gforth, VFX, and SwiftForth would have been far
> >> better IMO.
> >
> > Agreed. I wouldn't have used the forth compiler/dictionary which then
> > relies on oddities such as:
> These 3 words are now in the standard, and Gforth, VFX, and SwiftForth
> all have them:
> > search-wordlist
> > name>string
> > name>interpret
> execute-parsing and the sort (in place) and rdrop used are non-standard.
> Finding them in-the-wild is non-trivial but can be done. Standard Forth
> could benefit greatly by having a Standard Library. The problem would of
> course be agreeing on what should be in a Standard Library and, more
> difficult yet, what code to use. The Forth community would never agree
> on even a simple Standard Library. It's just not part of the culture.
> I'm amazed that we have the ANS Standard as it is.
>
> I didn't have a problem with showing the code for to-lower because that
> "showed off" how easily such functions can be written in Forth. Though
> it is likely a candidate for a Standard Library.

A to-lower (and to-upper) that handles unicode codepoints is not that easy to write!

Peter

> -Doug
> > A mundane approach as might be done in C is preferable to 'showing off'
> > Forth, which then backfires.
> >
> > to-lower
> >
> > I might agree with because functions like this have universal appeal -
> > just don't expect it to come from 200x.

P Falth <peter.m.falth@gmail.com> writes:
>A to-lower (and to-upper) that handles unicode codepoints is not that easy to write!

What it should produce also depends on the locale. E.g., in most locales

'I' to-lower xemit

should output 'i', but in some locales (e.g., tr_TR.utf8) it should
output a similar, but dotless letter.

- 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 2021: https://euro.theforth.net/2021

On 8/16/21 6:05 PM, P Falth wrote:

> A to-lower (and to-upper) that handles unicode codepoints is not that easy to write!

Yes. So it appears.

-Doug

On 8/14/21 5:59 AM, Doug Hoffman wrote:

>>> Hoyt had to search "in the wild" for a cell array sort routine and he
>>> found one in Rosetta Code. That's a shoddy way to have to find "library
>>> code".

>>> He lamented having to write his own ascii lower case routine.

>> (In what sense would a pure-standard solution have been better?)
>
> Anyone wanting to run the code could easily have done so on any
> of VFX, SwiftForth, or Gforth (and maybe some other Forths).

Having said that, I should provide an alternative. The following is
based on library code, which is fair because most all of Hoyt's other
examples used library code. The difference is that Forth has no standard
library code. It is my library code, been using it for years, but
anyone's generic code should do.

include FMS2LL.f
include ptr.f
include array.f
include string.f
include file.f
include hash-table.f

hash-table t \ make a dynamically resizable hash table
s" kjvbiblex10.txt" file f

: process-line-array {: array -- :}
array :size 0
?do i array :at ( str-obj )
dup :lower :@ ( key-addr key-len) 2dup t :@
if ( key-addr key-len val ) 1+
else ( key-addr key-len ) 1
then -rot t :insert
loop array <free ;

: read-file->hash-table
begin
f :read-line ( str-obj)
while
dup :size
if bl swap :split ( array)
process-line-array
else drop
then
repeat ;

>array value a \ make a dynamically resizable array

read-file->hash-table \ populate the hash table
t :uneach
[: a :add ;] t :apply \ load the array with nodes from the hashtable
[: :val@ swap :val@ < ;] a :sortWith \ sort the array on #ofUniques
[: cr dup :key@ :. space :val@ . ;] a :apply \ print the array
a :size . \ #of unique words

The above solution is correct and runs as is on any ANS Forth. But it is
slow, taking about 15 seconds using VFX 32-bit(Hoyt's Ruby non-optimised
solution ran 40% slower on my machine than on his, for a rough
comparison). The bottlenecks are in my library code. It takes most all
of the 15 seconds just to :split each line into an array of strings and
then to populate the hash-table. I can see where my library code could
easily be made much faster for this specific problem just by tweaking
those two functions and allotting instead of allocating. But why bother?
It's a fictitious problem.

Is it better in the sense that it is easier to read, fully ANS
compatible, and memory can be reclaimed without restarting? I don't
know. Others surely can't read it as easily as I can. Would Hoyt have
lamented that this is write-only code? I don't know.

-Doug

On 8/19/21 8:49 AM, Doug Hoffman wrote:

If anyone is interested:

https://github.com/DouglasBHoffman/FMS2
> include FMS2LL.f
> include ptr.f
> include array.f
> include string.f
> include file.f
> include hash-table.f

-Doug

> Is it better in the sense that it is easier to read, fully ANS
> compatible, and memory can be reclaimed without restarting? I don't
> know. Others surely can't read it as easily as I can. Would Hoyt have
> lamented that this is write-only code? I don't know.

Hoyt is here, quietly fascinated that this thread has lasted 5 months and has 138 messages. :-)

I don't think this is particularly write-only code; on the contrary, it seems fairly straight-forward -- nice! With the hash-table and split helpers it's a lot more similar to how you'd do it in other languages that have more full-fledged standard libraries. I'm not familiar with that [: ... ;] syntax, but I can see what it's trying to do easily enough.

-Ben

On 8/19/21 5:17 PM, Ben Hoyt wrote:
>
>> Is it better in the sense that it is easier to read, fully ANS
>> compatible, and memory can be reclaimed without restarting? I don't
>> know. Others surely can't read it as easily as I can. Would Hoyt have
>> lamented that this is write-only code? I don't know.
>
> Hoyt is here, quietly fascinated that this thread has lasted 5 months and has 138 messages. :-)

Greetings! That would be partly because of me, I suppose. I came in
late and basically restarted the discussion. :-)

> I don't think this is particularly write-only code; on the contrary,
> it seems fairly straight-forward -- nice! With the hash-table and
> split helpers it's a lot more similar to how you'd do it in other
> languages that have more full-fledged standard libraries.
That's good to hear. I try to code in a straightforward style and
re-use code whenever it makes sense. Though there are differing views on
this among Forthers.

> I'm not familiar with that [: ... ;] syntax, but I can see what it's
> trying to do easily enough.
That is a relatively new "quotation" (2018?) Forth 200x syntax. It
simply allows for defining a block of nameless code and obtaining its
XT. It can be convenient.

As a strong supporter of writing Standard Forth code, doing so is my
goal. Though I think it's good for Forthers to push the envelope with
new ideas.

I found your article to be informative and well written. As you can see
it has generated a fair amount of discussion here. Anton Ertl wrote a
solution in a clever and efficient way. Marcel Hendrix, and a few
others, wrote some slightly non-standard code that runs quite fast.

Thanks for writing the article and for the feedback above.

-Doug

> -Ben