"Forth is Sudoku for programmers"

[foxaudio...@gmail.com]

*Don't shoot the messenger please**

I was doing some research on Lisp internals having found some old code
by Martin Tracy on my drive. I went looking around and found this discussion:

http://forums.parallax.com/discussion/160027/lisp-technically-scheme-written-in-forth


<quote>"Dave Hein Posts: 4,831
February 2015 edited February 2015 0
I found a lisp interpreter written in C at http://www.umcs.maine.edu/~chaitin
/lisp.c . I was able to get it to run on the Prop in a matter of minutes by
changing the #define for SIZE from 1000000 to 400, and using the CMM model. The
program is 950 lines of C code. I don't know lisp, but the program seems to do
the right thing when I type in (+ 1 2).

I've officially given up trying to port lisp.fs to pfth. I could probably get it to work in another day or so, but it seems a bit pointless. This exercise has reinforced my belief that Forth is just not a good language for writing large programs. It's fine for peeking and poking and dinking around. However, serious programming should really have library support and standards and compilers that assist the developer. Forth is fine if you want a challenge, but if you want to get something done use something else.

As I've said before, Forth is Sudoku for programmers."
</quote>

The Scheme they were trying to port was for Gforth.
(http://www.complang.tuwien.ac.at/schani/oldstuff/#lisp)

And of course moving it to the little Parallax board was not possible.
The Forth on the board is not quite standard.

It seems a shame that we don't have code examples like the 'C' Scheme
example that are as easily configured for different hardware.

The comments in the posts mentioned the fact the the C code used arrays
and the Forth code used Structs (and locals). Maybe simpler is better?

Now where have I heard that before?

It looks like a good project for my spare time.


BF

So much code so little time.

[WJ]

Forth is a toy language. The only ones who attempt to use
it outside of embedded controllers are those so bone-headed
that they cannot learn a real language. Gavino thinks that
it is awe-inspiring.

Speaking of Lisp:

> But if you're going to allow LOOP, then why use FORMAT at all?!?
> Since FORMAT probably uses WITH-OUTPUT-TO-STRING "under the hood",
> just do so directly:
>
> > (let ((list '(a b c))
> (delim #\,))
> (with-output-to-string (s)
> (loop for tail on list
> do (princ (first tail) s)
> (when (rest tail)
> (princ delim s)))))
>
> "A,B,C"

MatzLisp (Ruby):

[:a,:b,:c].join ", "
==>"a, b, c"

--
Africans gang-rape and clitorectomize Finnish girl; government arrests Finn whom
they accuse of complaining: http://www.wvwnews.net/story.php?id=6746

[Paul Rubin]

foxaudio...@gmail.com writes:
> As I've said before, Forth is Sudoku for programmers." </quote>

Chuck Moore said something similar:

I write Forth code every day. It is a joy to write a few simple words
and solve a problem. As brain exercise it far surpasses cards,
crosswords or Sudoku.

Quote is from James Hague article "Understanding What It's Like to
Program in Forth", http://prog21.dadgum.com/33.html .

[foxaudio...@gmail.com]

Touche!

That being said, it makes me wonder if a some programs should be added to the standard test suite to show more than functionality for Standard Forth but demonstrate some utility as well.

A suite a demonstration programs might catch some the gotchas that don't show
up in a word by word test approach as well.

Are there any favourite candidate APPs that could be bundled with compilers to demonstrate that they will compile and run on "standard" systems?

BF

[Julian Fondren]

On Wednesday, August 10, 2016 at 3:06:23 PM UTC-5, foxaudio...@gmail.com wrote:
> I've officially given up trying to port lisp.fs to pfth.

Not write code. Port code.

> The Scheme they were trying to port was for Gforth.
> (http://www.complang.tuwien.ac.at/schani/oldstuff/#lisp)

From gforth to pfth: https://github.com/parallaxinc/spinsim/tree/master/pfth103_p2

Which "implements all 133 of the ANS Forth core words, and 38 of the
45 core ext words."

> The comments in the posts mentioned the fact the the C code used arrays
> and the Forth code used Structs (and locals). Maybe simpler is better?

Simpler is better if you plan to port the code to a very simple Forth.

I can imagine this guy's frustration.

Step 1. reimplement { ... } locals syntax.

Step 2. reimplement structures.fs, not the most bare-bones of
structures libraries.

Step 3?. reimplement ALLOCATE

Step 4. reimplement NUMBER ,and any other unnoticed non-ANS words

.... well that's it. And there isn't much that's non-ANS there. And
the structures and {} stuff is so simply used that you could just
drop-in replace them with something bare-bones.

Hm. No, looking at lisp.fs, this guy's problem is that he was only
pretending to be a Forth programmer.

> > I could probably get it to work in another day or so, but it seems a bit
> > pointless. This exercise has reinforced my belief that Forth is just not a
> > good language for writing large programs.

lisp.fs is 500 lines long. It stops being interesting (from a Forth
perspective) at less than 150 lines in. The rest is all just putting
the lisp together

> > It's fine for peeking and poking and dinking around.

This guy has never written anything in Forth. He's used it like RPL
on a HP calculator, just to peek and poke and dink around.

> > However, serious programming should really have library
> > support and standards and compilers that assist the developer.

"pfth should be a richer implementation."

That's a fair desire I guess, but it shouldn't be cast as a
complaint about Forth.


-- Julian

[lehs]

Some prefer languages where "everything" is built in and rather use their time searching in manuals than being more creative and use Forth. Sometimes because of their personality and sometimes because it is more efficient to use libraries.

Making really nice code is a kind of sudoku in what ever language.

[Julian Fondren]

On Wednesday, August 10, 2016 at 10:28:06 PM UTC-5, Julian Fondren wrote:
> On Wednesday, August 10, 2016 at 3:06:23 PM UTC-5, foxaudio...@gmail.com wrote:
> > The comments in the posts mentioned the fact the the C code used arrays
> > and the Forth code used Structs (and locals). Maybe simpler is better?
>
> Simpler is better if you plan to port the code to a very simple Forth.
>
> I can imagine this guy's frustration.
>

pfth also doesn't have DOES> or THROW

A bigger language can't be a defense against slimmer implementations
when the already slim language isn't fully implemented.

Even so, it's appreciated:

> So when we are discussing Forth vs other "languages" in this forum
> surely it is always in respect to the Propeller, not the PC (where
> rarely I would use Forth anyway), and Forth on the Propeller is
> actually a dynamic interactive language and O/S whereas the PC
> compiled binary blobs are not "languages" anymore, just a hard-coded
> black box.

[hughag...@gmail.com]

On Wednesday, August 10, 2016 at 11:26:27 PM UTC-7, lehs wrote:
> Some prefer languages where "everything" is built in and rather use their time searching in manuals than being more creative and use Forth. Sometimes because of their personality and sometimes because it is more efficient to use libraries.
>
> Making really nice code is a kind of sudoku in what ever language.

People program computers for many reasons, one of which is that they get paid to do it --- nobody gets paid to solve sudoku problems --- if programming is like sudoku then you aren't going to get paid.

All programmers are creative. You can't really be a programmer if you aren't at least somewhat creative. It is possible to waste your creativity however. If you are writing a program that needs to store data (every program needs to store data) then you need a general-purpose data-structure. There is going to be plenty of opportunity for creativity in regard to the design of your program. If you have to write your own self-balancing binary-tree however, then this is just a distraction. By the time that you have this figured out, you will have forgotten what the purpose of the program was. Also, your creativity is wasted because the subject has been done to death already. Implementing a self-balancing binary-tree is not really what programming is about --- there are no programmers getting paid to do this --- programmers get paid to write programs.

[lehs]

Yes there should be libraries for a lot of things in Forth, built upon some standard.

But what can you do with self-balancing trees that could be done better with some kind of stack?

[humptydumpty]

Hi!

Tested and not working. One definition is wrong.

Originally:

: symtab-lookup { namea nameu -- }
symtab-first @
begin
dup 0<>
while
>r
r@ symtab-namea @ r@ symtab-nameu @ namea nameu compare
0= if
r> symtab-lisp @ unloop exit
endif
r> symtab-next @
repeat
drop 0 ;

'unloop' shouldn't be there. Also 'drop 0'. Also stack comments are wrong.
I would write:

: symtab-lookup ( namea nameu -- lisp|0 )
2>R symtab-first @
BEGIN
dup
WHILE
dup symtab-namea @ over symtab-nameu @ 2R@ compare
IF
symtab-next @
ELSE
symtab-lisp @ 2RDROP EXIT
THEN
REPEAT
2RDROP
;

Testing:
~/src/lisp> gforth lisp.fs -e 'S" test.scm" lisp-load-from-file cr .s cr bye'

lisp.fs:173: warning: redefined number4 120
<1> 0


Other things looks strange, like:

0 variable symtab-first
drop

Wow! Better write comment that "Gforth initializes variables with 0",
or write it as should be:

0 variable symtab-first 0 symtab-first !

Partially I understand complaints of porter.

Have a nice day,
humptydumpty

[humptydumpty]

excuse me for typo:

> 0 variable symtab-first 0 symtab-first !

variable symtab-first 0 symtab-first !

--
humptydumpty

[Anton Ertl]

Julian Fondren <julian....@gmail.com> writes:
>On Wednesday, August 10, 2016 at 3:06:23 PM UTC-5, foxaudio...@gmail.com wrote:
>> I've officially given up trying to port lisp.fs to pfth.
>
>Not write code. Port code.
>
>> The Scheme they were trying to port was for Gforth.
>> (http://www.complang.tuwien.ac.at/schani/oldstuff/#lisp)
>
>From gforth to pfth: https://github.com/parallaxinc/spinsim/tree/master/pfth103_p2
>
>Which "implements all 133 of the ANS Forth core words, and 38 of the
>45 core ext words."
>
>> The comments in the posts mentioned the fact the the C code used arrays
>> and the Forth code used Structs (and locals). Maybe simpler is better?
>
>Simpler is better if you plan to port the code to a very simple Forth.
>
>I can imagine this guy's frustration.
>
>Step 1. reimplement { ... } locals syntax.

If it's just the syntax, you can find an implementation of this syntax
based on Forth-94 (LOCAL) in
<https://www.complang.tuwien.ac.at/forth/compat.zip>. However,
(LOCAL) is not in CORE or CORE EXT.

>Step 2. reimplement structures.fs, not the most bare-bones of
>structures libraries.

That's also in the compat library. It uses some words outside CORE
and CORE EXT, but, e.g., FLOAT words only for defining FP fields,
which you won't need if you don't have the FLOAT wordset, so just
comment these words out.

>Step 3?. reimplement ALLOCATE

That's a harder one, if you want the full functionality.

>Step 4. reimplement NUMBER ,and any other unnoticed non-ANS words

You can check for non-ANS words with Gforth's ansreport.fs.

>Hm. No, looking at lisp.fs, this guy's problem is that he was only
>pretending to be a Forth programmer.

Who? Schani? As he writes in
<http://www.complang.tuwien.ac.at/schani/oldstuff/#lisp>:

|When I learn a new programming language, the first program I write in
|that language is usually an interpreter for a small subset of Lisp or
|Scheme. I have found that to be a good way to quickly familiarize
|myself with most aspects of a new language. These are some of the
|results of my efforts.

So yes, this was his first Forth program.

- 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 2016: http://www.euroforth.org/ef16/

[Anton Ertl]

foxaudio...@gmail.com writes:
>That being said, it makes me wonder if a some programs should be added to the standard test suite to show more than functionality for Standard Forth but demonstrate some utility as well.
>
>A suite a demonstration programs might catch some the gotchas that don't show
>up in a word by word test approach as well.

Yes, it might, but if the test suite is any good, it's unlikely.
Application programmers often avoid the murky corners where
implementation bugs hide; that's why the bugs hide there, and are not
caught earlier. Of course, once in a while an application programmer
strays in one of those corners, and is then bitten by such a bug, but
all the other murky corners may still be infested by bugs.

By contrast, when a test programmer writes test cases, he purposely go
into those corners, and he does it with short test cases so that one
does not have to understand a huge application to understand the bug.

I think one Forth implementor complained about the test cases that I
produce, because my test cases uncover bugs in his Forth system that
don't show up at his client with a huge application. Of course, the
question is: If you are an application programmer, do you want a
system that just stands the test of being able to run some
applications, even if one of them is huge, without knowing what
programming practices the programmers of these applications use, or do
you prefer a system that has also removed the bugs uncovered by
contrived tests?

>Are there any favourite candidate APPs that could be bundled with compilers to demonstrate that they will compile and run on "standard" systems?

<https://www.complang.tuwien.ac.at/forth/appbench.zip> is an
application benchmark that is intended to run on many systems; it's
not a test suite, though.

[humptydumpty]

On Thursday, August 11, 2016 at 2:37:29 PM UTC+3, Anton Ertl wrote:

As a first Forth program is impressive. But maybe more
feedback at right time could helped that 'lisp.fs' be
well done as a forth program.

--

[Julian Fondren]

On Thursday, August 11, 2016 at 6:37:29 AM UTC-5, Anton Ertl wrote:
> Who? Schani?

No, I mean the porter. The guy who took his failure to port
Schani's program as an affirmation that Forth is a toy language.

> As he writes in
> <http://www.complang.tuwien.ac.at/schani/oldstuff/#lisp>:
>
> |When I learn a new programming language, the first program I write in
> |that language is usually an interpreter for a small subset of Lisp or
> |Scheme. I have found that to be a good way to quickly familiarize
> |myself with most aspects of a new language. These are some of the
> |results of my efforts.
>
> So yes, this was his first Forth program.
>

OK, that explains the odd stuff that humptydumpty noted. I'd
wondered if maybe "0 variable ..." were a rewrite from code that had
used an initializing variant of VARIABLE like "0 var ..."


-- Julian

[lawren...@gmail.com]

On Thursday, August 11, 2016 at 6:26:27 PM UTC+12, lehs wrote:

> Some prefer languages where "everything" is built in and rather use their
> time searching in manuals than being more creative and use Forth. Sometimes
> because of their personality and sometimes because it is more efficient to
> use libraries.

As Isaac Newton said, “if I have seen farther, it is by standing on the shoulders of giants”.

A language that lets you leverage the power of prewritten libraries is a much more productive language than one that does not.

[Cecil Bayona]

But that is against the spirit of Forth, in case you are not aware, and
is a great sin, I am being sarcastic, troglodytes can be applied to many
Forth programmers, well maybe not programmers, but people that claim to
be. The funny thing, ANS Forth uses libraries but very primitive
versions called word sets.

--
Cecil - k5nwa

[HAA]

I don't claim to be a programmer but it would take a lot before I'd trust a pre-written
library. If it was a 'portable' library written by an ANS-programmer, I definitely wouldn't
touch it. Forth was never aimed at the masses. It was intended for those who can
exploit a given situation - and that can't be done by using a library of which you have
no idea how it works, or what's contained therein. More thought and less code is
what Forth is about.

[rickman]

What's primitive about word sets? How is that different from a Forth
library?

--

Rick C

[lawren...@gmail.com]

On Friday, August 12, 2016 at 2:22:38 PM UTC+12, HAA wrote:

> I don't claim to be a programmer but it would take a lot before I'd trust a
> pre-written library.

You trust the browser and the OS it’s running on when you read and post to this group, do you not? And all the servers between you and me that are relaying your words to me, and mine to you.

The time is long past when you could do any serious computing without putting a lot of “trust” in pre-written code.

[lawren...@gmail.com]

On Friday, August 12, 2016 at 2:59:06 PM UTC+12, rickman wrote:

> What's primitive about word sets?

Do they define separate namespaces? How about managing dependencies?

[Elizabeth D. Rather]

There's a big difference between using a completed, production program
and using a body of code that is intended to be a component of a program
that you're writing. Most libraries that I've aren't totally black
boxes, but have many options and things that can be included or not,
etc. To be useful it would have to be provided in source, be both
readable and well-documented, and fully compatible with the Forth system
I'm using. This is certainly not impossible; polyFORTH came with
extensive database and graphics libraries, for example, and SwiftForth
and SwiftX include a number of smaller application-oriented bodies of
code. But we were disappointed in the math library that was circulated
many years ago, due to issues both with code quality and documentation.

Good libraries could in theory be a great asset to Forth, but every time
this subject comes up it's always structured as "somebody [else] should
write more libraries," not "here's a great library I have written."
People on clf would rather write a DIY Forth system than a library.

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."
==================================================

[HAA]

lawren...@gmail.com wrote:
> On Friday, August 12, 2016 at 2:22:38 PM UTC+12, HAA wrote:
>
> > I don't claim to be a programmer but it would take a lot before I'd trust a
> > pre-written library.
>
> You trust the browser and the OS it's running on when you read and post to this group,
> do you not? And all the servers between you and me that are relaying your words to me,
> and mine to you.

My browser regularly crashes. I use it because it does the job most of the time
and there is enough redundancy (wasted resources) in the internet for users not
to notice the failures.

> The time is long past when you could do any serious computing without putting a lot of
> "trust" in pre-written code.

I have little doubt there exists pre-written code in Forth but it will be proprietary
material that's been written by the companies concerned and adapted as needed.
It's what I do for my projects. I don't hear Forth Inc, MPE, other vendor/consultants
calling for portable general-purpose Forth libraries so they can use them in their
projects. What they do seem to want is capable programmers.

[lawren...@gmail.com]

On Friday, August 12, 2016 at 4:23:05 PM UTC+12, Elizabeth D. Rather wrote:
> There's a big difference between using a completed, production program
> and using a body of code that is intended to be a component of a program
> that you're writing.

No there isn’t really. On my Debian system:

ldo@theon:~> dpkg-query --showformat $'${Package} ${Depends}\n' --show firefox-esr
firefox-esr libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.17), libcairo2 (>= 1.2.4), libdbus-1-3 (>= 1.9.14), libdbus-glib-1-2 (>= 0.78), libevent-2.0-5 (>= 2.0.10-stable), libffi6 (>= 3.0.4), libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.20.0), libgtk2.0-0 (>= 2.24.0), libhunspell-1.4-0, libnspr4 (>= 2:4.10.3), libnss3 (>= 2:3.19), libpango-1.0-0 (>= 1.14.0), libsqlite3-0 (>= 3.7.12-1~), libstartup-notification0 (>= 0.8), libstdc++6 (>= 5.2), libvpx3 (>= 1.5.0), libx11-6, libxcomposite1 (>= 1:0.3-1), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxrender1, libxt6, zlib1g (>= 1:1.2.0), fontconfig, procps, debianutils (>= 1.16)

As you can see, the Firefox package reuses code from a whole bunch of others. What’s the difference between a “completed, production program” and a “component”? Everything can be a “component” of something at a higher layer.

> Most libraries that I've aren't totally black boxes, but have many
> options and things that can be included or not, etc.

Same with lots of executables I have built. Ask me about my custom script for building Blender <https://www.blender.org/> from source...

> Good libraries could in theory be a great asset to Forth, but every time
> this subject comes up it's always structured as "somebody [else] should
> write more libraries," not "here's a great library I have written."
> People on clf would rather write a DIY Forth system than a library.

Seems like a cultural issue, then. The Perl, Python and Ruby worlds, by contrast, are full of good libraries, with more being added all the time.

[lawren...@gmail.com]

On Friday, August 12, 2016 at 4:51:30 PM UTC+12, HAA wrote:
> My browser regularly crashes.

Do you use Windows, by any chance?

I use Firefox/Iceweasel on Linux, and can leave it running for weeks at a time.

> I have little doubt there exists pre-written code in Forth but it will be
> proprietary material that's been written by the companies concerned and
> adapted as needed.

No concept of Free Software, then?

[hughag...@gmail.com]

On Thursday, August 11, 2016 at 9:51:30 PM UTC-7, HAA wrote:
> I have little doubt there exists pre-written code in Forth but it will be proprietary
> material that's been written by the companies concerned and adapted as needed.
> It's what I do for my projects. I don't hear Forth Inc, MPE, other vendor/consultants
> calling for portable general-purpose Forth libraries so they can use them in their
> projects.

The key word here is "portable." Forth Inc. and MPE down't want *portable* Forth libraries because these could be used by common ANS-Forth programmers in competition against them. If they have any proprietary material it will be vendor-specific --- Stephen Pelc routinely makes his code VFX-specific even when it could easily be made ANS-Forth --- they want people like me to be customers, but they don't want us to write programs in competition with them.

ANS-Forth was purposely crippled. It is a pitfall for the unwary! Forth programmers get trapped in ANS-Forth writing toy programs and believing that they have to stick with ANS-Forth compatibility (limitations) and that they can't use code libraries because this isn't the "Forth Way" --- the only real effect of ANS-Forth is to prevent Forthers from writing commercial software --- the only people who benefit from ANS-Forth are Forth Inc. and MPE, but they don't use ANS-Forth themselves; they benefit because potential competition gets trapped in ANS-Forth and Gforth and never succeed at anything.

> What they do seem to want is capable programmers.

Really? There are no job offerings for Forth programmers.

Also, the term "capable programmer" implies to me somebody who can write something like my novice-package --- yet Elizabeth Rather and Stephen Pelc insist that I'm totally incompetent at Forth and not a Forth programmer at all --- they would sooner hire the Devil than hire me!

I think what Forth Inc. and MPE want are brown-nosers --- they want the Forth community to take them seriously as being the Forth-200x committee who alone among all Forthers are capable of determining what the Forth Standard is --- this is effectively free advertising for them (very impressive to their potential customers that they are on the Forth-200x committee and I'm not).

A lot of people on the Forth-200x mailing list believe that if they brown-nose enthusiastically they will eventually get hired by Forth Inc. or MPE --- they are delusional --- they aren't going to get hired.

[m...@iae.nl]

"Elizabeth D. Rather" <era...@forth.com> writes Re: "Forth is Sudoku for programmers"

> On 8/11/16 4:59 PM, lawren...@gmail.com wrote:
>> On Friday, August 12, 2016 at 2:22:38 PM UTC+12, HAA wrote:
>>
>>> I don't claim to be a programmer but it would take a lot before I'd trust a
>>> pre-written library.
>>
>> You trust the browser and the OS it's running on when you read and post to
>> this group, do you not? And all the servers between you and me that are
>> relaying your words to me, and mine to you.
>>
>> The time is long past when you could do any serious computing without putting
>> a lot of 'trust' in pre-written code.

Look at hardware: We use opamps, comparators, timers,
voltage stabilizers etc. all over the place. For digital
parts it's even worse: almost everything is at least MSI
and some engineers don't even bother to look up more than
the pin numbering.

All these IC's are horribly complex and not at all
documented as to their nuts and bolts. In almost every case
they do much more than is needed for the application. But
everybody uses them. Engineers that would insist on designing
their own opamp would get very strange looks indeed. And even
if they succeeded in designing their perfect opamp, it certainly
wouldn't improve the quality of the complex and large application
that it is to be used in. Of course, there are the very good
engineers that can take a board full of LSI chips and bring
it down to the essentials (which then somebody would produce
an single IC for).

Now why doesn't this work analogously with (Forth) software?
The inverse question is easier. Say that engineers would have
the designs of all these IC's at their fingertips, and changing
functionality or interface pins would be as simple as pressing a
key or a double-click, because we could reprogram any chip at
zero cost?
Being human nature what it is, it would instantly kill
the general-purpose IC market (and probably bring industry to
a grinding halt). The focussed engineers that still want to
use the general-purpose stuff would be unable to buy it because
the market for these IC's would shrink. (You design it the old
way and it works according to spec., but then costs must be cut
and out go the general IC's because a few cents can be inevitably
saved by a pin swap or making an output stage less powerful).

If you follow this train of thought, then libraries of source
code will never make it: they can't gain momentum as the user
base is too small (at most the programmers of the language-du-jour).

What could make it (if you want to follow my analogy) is open
source software that is compiled as a shared library. In this
way everybody/every language can use the library. Improvements
are still possible but they have to go through the package
maintainers. In principle it is still possible for an engineer
to fork an existing package and maintain it privately, but in
most cases it is not unlike designing and manufacturing your
own IC: too many different skills are needed, can't bother.

So, the question is not the programming language(s) to use,
but how well what we use is able to interface to all the
binary packaged stuff that is out there. What about using
a .dll or .so in Standard Forth? We still can't do this
in a standard way!

Own quote:
"Of course, there are the very good engineers that can take
a board full of LSI chips and bring it down to the essentials
(which then somebody would produce an single IC for)."

I guess this is the spot for a Forth PROGRAM, which then
might become a library.

> There's a big difference between using a completed, production program
> and using a body of code that is intended to be a component of a program
> that you're writing. Most libraries that I've aren't totally black
> boxes, but have many options and things that can be included or not,
> etc. To be useful it would have to be provided in source, be both
> readable and well-documented, and fully compatible with the Forth system
> I'm using.

It sound very reasonable and I like it a lot. However, it is
*completely* at odds with my analogy above.

> This is certainly not impossible; polyFORTH came with
> extensive database and graphics libraries, for example, and SwiftForth
> and SwiftX include a number of smaller application-oriented bodies of
> code. But we were disappointed in the math library that was circulated
> many years ago, due to issues both with code quality and documentation.

Your stab at the FSL is not nice. What did Forth Inc. do to improve this
situation? Code quality of a Forth library could be excellent: distribute
the output of VFX or iForth, or F2C or whatever else we can come up with.
For documentation the obvious candidate is Forth Inc :-)

> Good libraries could in theory be a great asset to Forth, but every time
> this subject comes up it's always structured as "somebody [else] should
> write more libraries," not "here's a great library I have written."

> People on clf would rather write a DIY Forth system than a library.

I wonder what would happen if Forth source could be compiled with
the best systems around and be distributed as shared libraries.
It would separate the tasks of writing code and designing something
that runs efficiently. Of course, not every (not many?) Forth programs
can or should work as a shared library.

-marcel

[hughag...@gmail.com]

All of this sounds like a well-made argument for code-libraries.

I haven't forgotten however, that you took my LC53 encryption-cracking program and posted it on comp.lang.forth with my name removed from the copyright notice, then later on you admitted that you didn't know what my algorithm did:

https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D

I agree with this statement that you made:

> What could make it (if you want to follow my analogy) is open
> source software that is compiled as a shared library. In this
> way everybody/every language can use the library. Improvements
> are still possible but they have to go through the package
> maintainers. In principle it is still possible for an engineer
> to fork an existing package and maintain it privately, but in
> most cases it is not unlike designing and manufacturing your
> own IC: too many different skills are needed, can't bother.

What will most likely happen however, is that somebody like you will take a code-library written by somebody like me and claim that you wrote it yourself --- just so you can pretend to be a better programmer than you are --- the result will be a disincentive for future code-library writers and a balkanization of present code-libraries.

[hughag...@gmail.com]

On Thursday, August 11, 2016 at 9:23:05 PM UTC-7, Elizabeth D. Rather wrote:
> Good libraries could in theory be a great asset to Forth, but every time
> this subject comes up it's always structured as "somebody [else] should
> write more libraries," not "here's a great library I have written."

This is just too funny! LOL! So, the blame for the lack of code-libraries goes to c.l.f. folks such as myself, and not to Forth Inc. --- really???

This comes from the same person who made the following comment regarding the general-purpose data-structures in my novice package:
----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------

The only reason I continue reading c.l.f. is the entertainment value --- this stuff is just too funny! --- professional comedians couldn't come up with such great comedy!

> People on clf would rather write a DIY Forth system than a library.

Now you are insisting that the "Forth Way" is to pay $$$ for SwiftForth that generates code that runs about 1/4 the speed necessary for commercial programming, but a public-domain Forth system is not the "Forth Way" at all --- and you expect people like me to write code-libraries for SwiftForth for free (I did actually write a significant amount of SwiftForth assembly-language in the novice-package to boost SwiftForth's abysmal speed to at least marginal levels).

[Brad Eckert]

Well, it is kind of funny how huge apps can fail to trip on bugs. The programming style used to write the huge app is the same style used to write all of its small components. So, it's the style that fails to break the compiler.

[Julian Fondren]

On Friday, August 12, 2016 at 1:16:58 AM UTC-5, hughag...@gmail.com wrote:
> Forth Inc. and MPE ... benefit because [Forth programmers] [get] trapped in
> ... Gforth

They sell Forth systems to Forth programmers. If someone writes an
application that's 'trapped in gforth', then they can't use it with
these systems anyway, and so Forth Inc. and MPE may lose money that
more portability would've given them.

Actually if there were no portability concerns it might be easier to
sell Forth systems to Forth *users*. You could have a product that
runs under gforth normally, but if customers start running into CPU
issues with it, they can purchase another Forth and run it with that,
and get instant performance advantages. Offering a product with so-so
default performance and then selling people ways to make it run better
is AFAIK part of Magento's actual business strategy.

> they want people like me to be [Forth programmers], but they don't
> want us to write [Forth systems] in competition with them.

If a hundred people showed up to clf today, and 99 of them said "I
want to write a Forth system", and one said "I want to write some
Forth programs", would you prefer this ratio or the inverse one?

Isn't there also some self interest in your answer?

> the only real effect of ANS-Forth is to prevent Forthers from writing
> commercial software --- the only people who benefit from ANS-Forth are Forth
> Inc. and MPE,

That's odd. I would think that they'd benefit a lot more from having
more contracts like "we have an internal Forth program without a
maintainer, you guys do Forth stuff right, can you get it to run the
same on our new OSX desktops?"

> Really? There are no job offerings for Forth programmers.

That's too bad. You should write something good enough that people
start becoming Forth programmers just to work with it, and to solve
workplace problems with it, after which workplaces start wanting Forth
programmers to maintain the good software they have.

On Friday, August 12, 2016 at 1:49:28 AM UTC-5, hughag...@gmail.com wrote:
> I haven't forgotten however, that you took my LC53 encryption-cracking
> program and posted it on comp.lang.forth with my name removed from the
> copyright notice,

...
> https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D

From that:

> \ Copyright (C) 2009 by some cab driver

That's you, isn't it?

On Friday, August 12, 2016 at 2:04:24 AM UTC-5, hughag...@gmail.com wrote:
> On Thursday, August 11, 2016 at 9:23:05 PM UTC-7, Elizabeth D. Rather wrote:
> > Good libraries could in theory be a great asset to Forth, but every time
> > this subject comes up it's always structured as "somebody [else] should
> > write more libraries," not "here's a great library I have written."
>

> So, the blame for the lack of code-libraries goes to [Forth programmers] and not to [Forth vendors]?

You're the only one talking about blame. She's just said that

1. good libraries would be good

2. there's a lot more promotion of libraries than there is the writing
of them

I imagine that the 100th hundred that someone says "hey, you know what
we need? libraries!", you cheer a bit less enthusiastically than the
first time. Nobody opposes other people writing libraries. Go and
write them.


Right now we have two good sites for Forth stuff:

http://theforth.net/
http://soton.mpeforth.com/flag/

Also:
* searching through github, github lists, etc.

* bitbucket.org knows what Forth is, but searching for repos by
* 'Forth' doesn't work at the moment.

If you make a big useful library, I imagine that it would be easy to get it
listed on FLAG. I imagine that it would be harder to get your 'kilosecond time
converter' library onto FLAG.

If you make a gforth-compatible library of any size under
theforth.net's framework, then you can create an account and upload it
theforth.net yourself. A kilosecond time converter? sure! A library
that loads normally under SwiftForth but that needs some preludes
loaded first for other languages? Well you may be able to upload it
there's no provision for that kind of stuff...

Skipping to the end of this discussion, I don't think the
infrastructure matters that much. The people advocating for libraries
are still wrong. If people would write useful libraries, their
very usefulness would lead to the infrastructure.


But I do think PACKAGE ... END-PACKAGE would help a lot.

As would an even less likely OO standard.

> > People on clf would rather write a DIY Forth system than a library.
>
> Now you are insisting that the "Forth Way" is to pay $$$ for SwiftForth

No, you're hallucinating again. There's no reference to SwiftForth
here. If people wrote lots of libraries for gforth, that would be
fine for everyone. Libraries can be ported. If theforth.net were to
take off, it would be even more likely to grow some features to assist
with portable code, with shims and such for specific systems.
github.com thought all Forth source files were 'F-Sharp' or 'Fortran'
or whatever until it grew popular enough that it could justify
attending to lesser used languages.

Wealth yields wealth and poverty yields poverty. It would be foolish
and self-destructive, not clever and evil, for Forth companies to
sabotage Forth in order to *benefit* in some way.


-- Julian

[lawren...@gmail.com]

On Friday, August 12, 2016 at 8:34:27 PM UTC+12, Julian Fondren wrote:

> It would be foolish and self-destructive, not clever and evil, for Forth
> companies to sabotage Forth in order to *benefit* in some way.

Vendor lock-in is a chronic and recurring affliction in many parts of the computer industry. That’s what destroyed Unix and let Microsoft Windows dominate. Though now it is what is killing Windows and allowing Linux to take its place...

There is a thriving Free Software ecosystem built around a great many programming languages and other components right now, though seemingly not around Forth.

[hughag...@gmail.com]

Yes. ANS-Forth has severe problems --- anybody who writes commercial-quality Forth code has to abandon ANS-Forth on the first day of the project and just go with vendor-specific code (exactly what they would do if there were no standard) --- ANS-Forth is only capable of toy programs (Sudoku solvers, for example) that students write for educational purposes.

The "Forth Way" that is promoted by Forth Inc. doesn't involve structs --- no book from Forth Inc. has mentioned structs and there is no evidence that anybody at Forth Inc. knows what structs are (maybe they do know, but they consider this to be proprietary) --- without structs you can't have data-structures, so you can't have data, so you are limited to writing little toy programs like in the "Starting Forth" book.

Forth was the first programming language I learned. Previously I had programmed in line-number BASIC, but I don't really consider that to be a programming language. I had taken a class in Pascal in high-school, and I learned about records (aka structs), but I didn't really know what they were for because we never wrote any programs in the class.

I didn't know what structs were until I learned C on my own after high-school --- then I went back to Forth and tried to implement structs in Forth --- I have structs in the novice-package now.

[rickman]

Do libraries do this automatically?

--

Rick C

[Julian Fondren]

n Friday, August 12, 2016 at 10:53:22 AM UTC-5, hughag...@gmail.com wrote:
> Yes. ANS-Forth has severe problems --- anybody who writes commercial-quality Forth code has to abandon ANS-Forth on the first day of the project and just go with vendor-specific code (exactly what they would do if there were no standard) --- ANS-Forth is only capable of toy programs (Sudoku solvers, for example) that students write for educational purposes.
>

On the first day of writing a Straight Forth program, you'll have to
"abandon it and go with vendor-specific code" the moment you need
networking, or graphics, or an interface with a specific version of
PostgreSQL.

Does it follow that Straight Forth has "severe problems"?

No, it just means that you don't know what standards are for and
can't help but bury any actual point you may have in hyperbolic
nonsense.

I think your actual point is probably "structs and some other stuff
should be standardized AND ALSO (when you remind me that they *are*
standardized) have a reference implementation that satisfies me."

Well, wanting a larger standard is fine and all. But in the case
we're talking about, Forth was insulted because someone tried to
port nearly standard code to a Forth system that didn't implemement
all of ANS. A larger standard would just mean that such Forth
systems would fail to implement even more words.

pfth calls itself an "ANS Forth interpreter". Maybe some other
brand would be useful as a way to express that a system will also be
a relatively easy system to port Forth programs to.

How about a passenger seat metaphor?

Business Class (easy to port to due to extensive words)
First Class (as above + programmer luxuries like LOCATE)
Economy Class (standard but minimal)

> The "Forth Way" that is promoted by Forth Inc. doesn't involve structs

* Forth200x is part of an evil plot.
* Another part of the same plot: opposition to structures.
* Forth200x actually standardizes structures
* --but the reference implementation isn't optimal! How eeeevil!
* --and the docs don't *emphasize* a feature I now feel is essential!

#JustHughThings

Or how about

* Forth Inc. just wants you to buy SwiftForth.
* SwiftForth comes with SWOOP , providing structures and more.
* Forth Inc. are opposed to structures.

Man it's really difficult sometimes to get your malicious
characterizations to agree with your analyses of sinister plots.


-- Julian

[rickman]

On 8/12/2016 2:54 PM, Julian Fondren wrote:
> n Friday, August 12, 2016 at 10:53:22 AM UTC-5, hughag...@gmail.com wrote:
>> Yes. ANS-Forth has severe problems --- anybody who writes commercial-quality Forth code has to abandon ANS-Forth on the first day of the project and just go with vendor-specific code (exactly what they would do if there were no standard) --- ANS-Forth is only capable of toy programs (Sudoku solvers, for example) that students write for educational purposes.
>>
>
> On the first day of writing a Straight Forth program, you'll have to
> "abandon it and go with vendor-specific code" the moment you need
> networking, or graphics, or an interface with a specific version of
> PostgreSQL.
>
> Does it follow that Straight Forth has "severe problems"?

I have a question for you. Has anything you've written to Hugh in the
past had any impact on his opinions or actions? If not, why do you keep
trying to explain anything to him?

There is a character in the ham radio groups who loves to argue with
people. His MO is to ask what seems to be an innocent question only to
respond to replies with inane explanations of his own. Others try to
correct him and when he refuses to accept any rational discussion they
end up arguing with him. He sees it as others bashing him, but he is
always happy to respond with his own vitriol. In one group in
particular they finally got tired of him and shunned him, ignoring all
his posts. When no one responded to him he left for greener pastures.
I think he was arguing with people in the Raspberry Pi group for a while.

It could work here if people would stop responding to Hugh's insanity as
if reason would have any impact whatsoever. I mean, how long will you
continue responding to Hugh rationally when it fails to get a rational
reply? At some point you are the one who is being irrational.

--

Rick C

[hughag...@gmail.com]

On Friday, August 12, 2016 at 11:54:21 AM UTC-7, Julian Fondren wrote:
> * Forth Inc. just wants you to buy SwiftForth.
> * SwiftForth comes with SWOOP , providing structures and more.
> * Forth Inc. are opposed to structures.
>
> Man it's really difficult sometimes to get your malicious
> characterizations to agree with your analyses of sinister plots.

SWOOP is only available under SwiftForth (hence the name), and SwiftForth costs money. Forth Inc. is opposed to structs (such as used in my novice package) because they are selling SWOOP as the only way to obtain structs.

Lets compare SWOOP with my novice-package method. Here is a super-simple example (no inheritance, no cloning, no pointers to other structs in the struct, etc.):
------------------------------------------------------------------------
marker swoop.4th

\ this is SWOOP

class point
variable x
variable y
: show ( -- ) x @ . y @ . ;
: dot ( -- ) ." Point at " show ;
end-class

: test ( -- )
point new >r
5 r@ using point x !
8 r@ using point y !
r@ using point dot
r@ using point destroy
rdrop ;

\ this is my method

0
w field .x
w field .y
constant pnt

: init-pnt ( x y node -- node )
>r
r@ .y !
r@ .x !
r> ;

: new-pnt ( x y -- node )
pnt alloc
init-pnt ;

: kill-pnt ( node -- )
dealloc ;

: show-pnt ( node -- )
>r
cr ." X: " r@ .x ?
cr ." Y: " r@ .y ?
rdrop ;

: my-test ( -- )
5 8 new-pnt >r
r@ show-pnt
r@ kill-pnt
rdrop ;
------------------------------------------------------------------------

I think my code is much more readable that the SWOOP code. Anybody using POINT in SWOOP is going to get tired of writing
USING POINT

The only problem with my method is that I don't have polymorphism. You can't have other structs with fields called .X and .Y etc.. This is easy to solve though --- just call your fields PNT.X and PNT.Y etc.. --- this bloats out the source-code somewhat (it is like USING POINT except not as bad), but it is reasonable in a large program that uses a lot of different structs.

Here is a start on disassembling MY-TEST:

see my-test
491CAF 8 # EBP SUB 83ED08
491CB2 EBX 4 [EBP] MOV 895D04
491CB5 5 # 0 [EBP] MOV C7450005000000
491CBC 8 # EBX MOV BB08000000
491CC1 491BEF ( new-pnt ) CALL E829FFFFFF
491CC6 EBX PUSH 53
491CC7 491C3F ( show-pnt ) CALL E873FFFFFF
491CCC 4 # EBP SUB 83ED04
491CCF EBX 0 [EBP] MOV 895D00
491CD2 0 [ESP] EBX MOV 8B1C24
491CD5 480CDF ( dealloc ) CALL E805F0FEFF
491CDA EAX POP 58
491CDB RET C3 ok
see new-pnt
491BEF 4 # EBP SUB 83ED04
491BF2 EBX 0 [EBP] MOV 895D00
491BF5 8 # EBX MOV BB08000000
491BFA 480C8F ( alloc ) CALL E890F0FEFF
491BFF 491BAF ( init-pnt ) JMP E9ABFFFFFF ok
see init-pnt
491BAF EBX PUSH 53
491BB0 4 # EBX ADD 83C304
491BB3 0 [EBP] EAX MOV 8B4500
491BB6 EAX 0 [EBX] MOV 8903
491BB8 4 [EBP] EBX MOV 8B5D04
491BBB 8 # EBP ADD 83C508
491BBE 4 # EBP SUB 83ED04
491BC1 EBX 0 [EBP] MOV 895D00
491BC4 0 [ESP] EBX MOV 8B1C24
491BC7 0 [EBP] EAX MOV 8B4500
491BCA EAX 0 [EBX] MOV 8903
491BCC EBX POP 5B
491BCD 4 # EBP ADD 83C504
491BD0 RET C3 ok

I would estimate the speed of SWOOP to be one or two orders of magnitude slower than the speed of my code. Realistically, nobody is ever going to use SWOOP for any program in which speed matters at all. Using simple code such as I have in the novice-package, SwiftForth is about 1/4 the speed necessary for commercial programming and would only be usable for programs that don't really have any speed requirements (possibly those that spend all of their time waiting for user input).

Here is just a start on disassembling TEST however. I can't figure out what BROADCAST does because SEE can't find it, but it may be a whopper. I also can't figure out what the code in POINT does because SEE doesn't work on it either. I think my estimate of one or two orders of magnitude slower than my code is reasonable however.

see test
491A8F 49198F ( point ) CALL E8FBFEFFFF
491A94 426F9F ( NEW ) CALL E80655F9FF
491A99 EBX PUSH 53
491A9A 5 # EBX MOV BB05000000
491A9F 4 # EBP SUB 83ED04
491AA2 EBX 0 [EBP] MOV 895D00
491AA5 0 [ESP] EBX MOV 8B1C24
491AA8 0 [EBP] EAX MOV 8B4500
491AAB EAX 0 [EBX] MOV 8903
491AAD 4 [EBP] EBX MOV 8B5D04
491AB0 8 # EBP ADD 83C508
491AB3 4 # EBP SUB 83ED04
491AB6 EBX 0 [EBP] MOV 895D00
491AB9 8 # EBX MOV BB08000000
491ABE 4 # EBP SUB 83ED04
491AC1 EBX 0 [EBP] MOV 895D00
491AC4 0 [ESP] EBX MOV 8B1C24
491AC7 4 # EBX ADD 83C304
491ACA 0 [EBP] EAX MOV 8B4500
491ACD EAX 0 [EBX] MOV 8903
491ACF 4 [EBP] EBX MOV 8B5D04
491AD2 8 # EBP ADD 83C508
491AD5 4 # EBP SUB 83ED04
491AD8 EBX 0 [EBP] MOV 895D00
491ADB 0 [ESP] EBX MOV 8B1C24
491ADE A8 [ESI] PUSH FFB6A8000000
491AE4 EBX A8 [ESI] MOV 899EA8000000
491AEA 0 [EBP] EBX MOV 8B5D00
491AED 4 # EBP ADD 83C504
491AF0 A4 [ESI] PUSH FFB6A4000000
491AF6 8D98F # A4 [ESI] MOV C786A40000008FD90800
491B00 491A59 ( point +CA ) CALL E854FFFFFF
491B05 A4 [ESI] POP 8F86A4000000
491B0B A8 [ESI] POP 8F86A8000000
491B11 4 # EBP SUB 83ED04
491B14 EBX 0 [EBP] MOV 895D00
491B17 0 [ESP] EBX MOV 8B1C24
491B1A 42701F ( DESTROY ) CALL E80055F9FF
491B1F EAX POP 58
491B20 RET C3 ok
see new
426F9F 4 # EBP SUB 83ED04
426FA2 EBX 0 [EBP] MOV 895D00
426FA5 42585F ( SIZEOF ) CALL E8B5E8FFFF
426FAA 8 # EBX ADD 83C308
426FAD 40A15F ( ALLOCATE ) CALL E8AD31FEFF
426FB2 4054AF ( THROW ) CALL E8F8E4FDFF
426FB7 4 # EBP SUB 83ED04
426FBA EBX 0 [EBP] MOV 895D00
426FBD 2159F # EBX MOV BB9F150200
426FC2 EBX EAX MOV 8BC3
426FC4 0 [EBP] EBX MOV 8B5D00
426FC7 4 # EBP ADD 83C504
426FCA EAX 0 [EBX] MOV 8903
426FCC 4 # EBX ADD 83C304
426FCF 4 # EBP SUB 83ED04
426FD2 EBX 0 [EBP] MOV 895D00
426FD5 4 [EBP] EBX MOV 8B5D04
426FD8 EBX EAX MOV 8BC3
426FDA 0 [EBP] EBX MOV 8B5D00
426FDD 4 # EBP ADD 83C504
426FE0 EAX 0 [EBX] MOV 8903
426FE2 4 # EBX ADD 83C304
426FE5 0 [EBP] EAX MOV 8B4500
426FE8 4 # EBP SUB 83ED04
426FEB EBX 4 [EBP] MOV 895D04
426FEE EAX 0 [EBP] MOV 894500
426FF1 4 # EBP SUB 83ED04
426FF4 EBX 0 [EBP] MOV 895D00
426FF7 22CCF # EBX MOV BBCF2C0200
426FFC 426DBF ( BROADCAST ) JMP E9BEFDFFFF ok
see destroy
42701F 4 # EBP SUB 83ED04
427022 EBX 0 [EBP] MOV 895D00
427025 4 # EBX SUB 83EB04
427028 0 [EBX] EBX MOV 8B1B
42702A 4 # EBP SUB 83ED04
42702D EBX 0 [EBP] MOV 895D00
427030 4 [EBP] EBX MOV 8B5D04
427033 4 # EBP SUB 83ED04
427036 EBX 0 [EBP] MOV 895D00
427039 22CEF # EBX MOV BBEF2C0200
42703E 426DBF ( BROADCAST ) CALL E87CFDFFFF
427043 4 # EBX SUB 83EB04
427046 4 # EBX SUB 83EB04
427049 40A19F ( FREE ) CALL E85131FEFF
42704E 4054AF ( THROW ) JMP E95CE4FDFF ok

[hughag...@gmail.com]

Here is MY-TEST disassembled in VFX:

MY-TEST
( 004E4330 8D6DF4 ) LEA EBP, [EBP+-0C]
( 004E4333 C7450008000000 ) MOV DWord Ptr [EBP], 00000008
( 004E433A C7450405000000 ) MOV DWord Ptr [EBP+04], 00000005
( 004E4341 895D08 ) MOV [EBP+08], EBX
( 004E4344 BB08000000 ) MOV EBX, 00000008
( 004E4349 E8E2B7FEFF ) CALL 004CFB30 ALLOC
( 004E434E 53 ) PUSH EBX
( 004E434F 8B5500 ) MOV EDX, [EBP]
( 004E4352 895304 ) MOV [EBX+04], EDX
( 004E4355 8B1C24 ) MOV EBX, [ESP]
( 004E4358 8B5504 ) MOV EDX, [EBP+04]
( 004E435B 8913 ) MOV 0 [EBX], EDX
( 004E435D 8B1C24 ) MOV EBX, [ESP]
( 004E4360 8D6D08 ) LEA EBP, [EBP+08]
( 004E4363 E858FFFFFF ) CALL 004E42C0 SHOW-PNT
( 004E4368 8B1424 ) MOV EDX, [ESP]
( 004E436B 8D6DFC ) LEA EBP, [EBP+-04]
( 004E436E 895D00 ) MOV [EBP], EBX
( 004E4371 8BDA ) MOV EBX, EDX
( 004E4373 E818B8FEFF ) CALL 004CFB90 DEALLOC
( 004E4378 8D642404 ) LEA ESP, [ESP+04]
( 004E437C C3 ) NEXT,
( 77 bytes, 22 instructions )
ok

[lawren...@gmail.com]

On Saturday, August 13, 2016 at 4:36:59 AM UTC+12, rickman wrote:

> On 8/11/2016 11:54 PM, Lawrence D’Oliveiro wrote:
>> On Friday, August 12, 2016 at 2:59:06 PM UTC+12, rickman wrote:
>>
>>> What's primitive about word sets?
>>
>> Do they define separate namespaces? How about managing dependencies?
>
> Do libraries do this automatically?

Well-designed languages and package managers do provide these facilities.

[hughag...@gmail.com]

Assuming that Straight Forth were a well-designed language --- how would it provide these facilities?

[Doug Hoffman]

I don't know SWOOP very well. Is that really a requirement?

> The only problem with my method is that I don't have polymorphism.

> You can't have other structs with fields called .X and .Y etc..

That's right. A proper OOP package eliminates this issue. Also makes it
easy to share code libraries.

> This is
> easy to solve though --- just call your fields PNT.X and PNT.Y etc.. ---
> this bloats out the source-code somewhat (it is like USING POINT except
> not as bad), but it is reasonable in a large program that uses a lot of
> different structs.

Maybe.

There are other OOP extensions that do it differently.

Here's one that uses Anton Ertl's*(see reference below) 2-instruction
dynamic message send technique. I've an FMS derivative that uses it and
it is used below.

A good OOP package gives you more than just inheritance, polyporphism,
dynamic binding, open recursion, and data namespace protection. But it
seems everyone has their own ideas on that.

Dynamic OOP will always carry some speed penalty. But it doesn't have to
be large. See the disassembly of TEST below.

On VFX:

100 value x

:class point <super object
cell bytes x
cell bytes y
:m init: ( x y -- ) y ! x ! ;m
:m show x ? y ? ;m
:m dot ." Point at " self show ;m
;class

: test
5 8 point >heap \ init: is called implicitly
dup dot
<free ;

test \ => Point at 5 8
x . \ => 100 \ no conflict with point's x

see test
( 00087E70 8D6DF0 ) LEA EBP, [EBP+-10]
( 00087E73 C74500607B0800 ) MOV DWord Ptr [EBP], 00087B60
( 00087E7A C7450408000000 ) MOV DWord Ptr [EBP+04], 00000008
( 00087E81 C7450805000000 ) MOV DWord Ptr [EBP+08], 00000005
( 00087E88 895D0C ) MOV [EBP+0C], EBX
( 00087E8B 8B1D647B0800 ) MOV EBX, [00087B64]
( 00087E91 FF15051F0200 ) CALL [00021F05] ALLOCATE
( 00087E97 E85078F9FF ) CALL 0001F6EC THROW
( 00087E9C 8B5500 ) MOV EDX, [EBP]
( 00087E9F 8B12 ) MOV EDX, 0 [EDX]
( 00087EA1 8913 ) MOV 0 [EBX], EDX
( 00087EA3 53 ) PUSH EBX
( 00087EA4 8B13 ) MOV EDX, 0 [EBX]
( 00087EA6 8D6D04 ) LEA EBP, [EBP+04]
( 00087EA9 FF5204 ) CALL [EDX+04]
( 00087EAC 5A ) POP EDX
( 00087EAD 8B0A ) MOV ECX, 0 [EDX]
( 00087EAF 8D6DF8 ) LEA EBP, [EBP+-08]
( 00087EB2 895500 ) MOV [EBP], EDX
( 00087EB5 895D04 ) MOV [EBP+04], EBX
( 00087EB8 8BDA ) MOV EBX, EDX
( 00087EBA FF5110 ) CALL [ECX+10]
( 00087EBD 8B13 ) MOV EDX, 0 [EBX]
( 00087EBF 8D6DFC ) LEA EBP, [EBP+-04]
( 00087EC2 895D00 ) MOV [EBP], EBX
( 00087EC5 FF5208 ) CALL [EDX+08]
( 00087EC8 FF15591F0200 ) CALL [00021F59] FREE
( 00087ECE E81978F9FF ) CALL 0001F6EC THROW
( 00087ED3 C3 ) NEXT,
( 100 bytes, 29 instructions )

-Doug

*Methods in objects2: Duck Typing and Performance
M. Anton Ertl
2012 EuroForth Conference

[Julian Fondren]

On Friday, August 12, 2016 at 4:38:57 PM UTC-5, rickman wrote:
> I have a question for you. Has anything you've written to Hugh in the
> past had any impact on his opinions or actions?

Yes. Thanks for asking.

>
> There is a character in the ham radio groups who loves to argue with
> people. His MO is to ask what seems to be an innocent question only to
> respond to replies with inane explanations of his own. Others try to
> correct him and when he refuses to accept any rational discussion they
> end up arguing with him. He sees it as others bashing him, but he is
> always happy to respond with his own vitriol.
>

Sounds like an amusing fellow, at least on a communications medium
where he can't drown out other discussion. Once you understood his
MO, and could clearly see the bait he was laying out, you should've
been less irritated by it, and could've even had some fun with it.
Familiarity breeds contempt; it also breeds tolerance. A stranger
that makes a pass at your wife, you might hang; when Rasputin does it,
well, that's just the way he is.

That fellow has nothing to do with Hugh however, who is characterized
by unprompted attacks on third parties.

> In one group in
> particular they finally got tired of him and shunned him, ignoring all
> his posts. When no one responded to him he left for greener pastures.
> I think he was arguing with people in the Raspberry Pi group for a while.
>
> It could work here if people would stop responding to Hugh's insanity

I think there might've been an age, before I came around, when people
weren't so obsessed with filtering conversation. Maybe they only
weren't when duelling was common, and people were more circumspect
about what they said in the first place. But for my whole life, it's
been a progression from personal ignore lists to moderated forums to
shadow bans to shared ignore lists managed by bots to having the
Clintons express their dissatisfaction with your speech by having you
whacked.

Still at the 'personal ignore lists' stage, I decided that these tools
were really only appropriate for spam or abuse. People who merely
annoyed me, I could ignore well enough with only my brain doing the
ignoring.

That's served me well.

> I mean, how long will you
> continue responding to Hugh rationally when it fails to get a rational
> reply? At some point you are the one who is being irrational.
>

Rather, it seems that you think I'm talking to Hugh like a janitor
trying to open a door to which he's forgotten the key. You, watching
me repeatedly fail to open the door, have decided that the key
actually isn't on my keychain, or the lock is jammed, and that I'm
wasting my time. And it would be irritating to watch that.

But that's not what I'm doing. Please don't worry about my goals.


-- Julian

[Julian Fondren]

On Friday, August 12, 2016 at 4:56:19 PM UTC-5, hughag...@gmail.com
wrote:

>
> SWOOP is only available under SwiftForth (hence the name), and
> SwiftForth costs money.
>

A portable version is available here:

http://soton.mpeforth.com/flag/swoop/index.html

It *is* slightly more tedious in some uses than the version
accompanying SwiftForth, since it lacks the [OBJECTS ... OBJECTS]
syntax for local objects, with which you could've written:

: test ( -- )
point new [OBJECTS point NAMES p OBJECTS]
5 p x ! 8 p y !
p dot
p destroy ;

It works with VFX and SwiftForth, and can easily be made to work with
gforth and iforth. It is a bit much for ciforth, though.


MY-TEST (including NEW-PNT and SHOW-PNT) vs. TEST is the real
comparison to make, for my purposes. Don't you think your interest in
speed is at odds with your eagerness to use dynamic memory?


-- Julian

[lawren...@gmail.com]

On Saturday, August 13, 2016 at 2:05:15 PM UTC+12, Doug Hoffman wrote:

> A good OOP package gives you more than just inheritance, polyporphism,
> dynamic binding, open recursion, and data namespace protection.

A good language will give you more than just OOP. Functions as first-class objects can be rather useful, too.

For example, consider the “interpolator” and “draw procedure” mechanisms I created as part of anim_framework <https://github.com/ldo/anim_framework>. Here
<https://github.com/ldo/anim_framework_examples/blob/master/anim_vimeo_2> is a non-trivial illustration of them in action.

[hughag...@gmail.com]

On Friday, August 12, 2016 at 9:05:53 PM UTC-7, lawren...@gmail.com wrote:
> On Saturday, August 13, 2016 at 2:05:15 PM UTC+12, Doug Hoffman wrote:
>
> > A good OOP package gives you more than just inheritance, polyporphism,
> > dynamic binding, open recursion, and data namespace protection.
>
> A good language will give you more than just OOP. Functions as first-class objects can be rather useful, too.

Hasn't Forth always had this? So long as you can obtain the xt with FIND or tick then you have a function as a first-class object.

I relied on this in LowDraw.4th (my first-ever ANS-Forth program) to allow the user to write functions for various drawing strategies and then run the program with those strategies being used, without needing to recompile the program or rerun the table-building word.

[hughag...@gmail.com]

On Friday, August 12, 2016 at 8:18:44 PM UTC-7, Julian Fondren wrote:
> Don't you think your interest in
> speed is at odds with your eagerness to use dynamic memory?

I have CONCRETE-ALLOCATE that is like ALLOCATE except allots in the dictionary.

FREE works on memory blocks from either (it does nothing if the memory block is in the dictionary).

RESIZE works on memory blocks from either (if the memory block is in the dictionary, it gets copied into a memory block in the heap of the correct size).

ALLOCATION works on memory blocks from either, so CLONE-NODE works either way.

Because everything works on memory blocks of either, I can switch from heap to dictionary in the constructor and all of the rest of the code will work correctly without being changed.

[hughag...@gmail.com]

On Friday, August 12, 2016 at 8:18:44 PM UTC-7, Julian Fondren wrote:

> On Friday, August 12, 2016 at 4:56:19 PM UTC-5, hughag...@gmail.com
> wrote:
> >
> > SWOOP is only available under SwiftForth (hence the name), and
> > SwiftForth costs money.
>
> A portable version is available here:
>
> http://soton.mpeforth.com/flag/swoop/index.html
>
> It *is* slightly more tedious in some uses than the version
> accompanying SwiftForth, since it lacks the [OBJECTS ... OBJECTS]

> syntax for local objects...

Why are you telling me this? What are you, a salesman for Forth Inc.?

I already said that my OOP system in the novice-package is at least an order of magnitude more efficient than SWOOP. I showed a disassembly of the two functions and the SWOOP code was abysmal. I don't care if Forth Inc. gives away a free kazoo to every user --- I'm not going to waste my time on their crappy software.

Why are you promoting SWOOP when you didn't write SWOOP? You are such a brown-noser! You disgust me!

[Julian Fondren]

On Saturday, August 13, 2016 at 12:52:03 AM UTC-5, hughag...@gmail.com wrote:
> On Friday, August 12, 2016 at 8:18:44 PM UTC-7, Julian Fondren wrote:
> > On Friday, August 12, 2016 at 4:56:19 PM UTC-5, hughag...@gmail.com
> > wrote:
> > >
> > > SWOOP is only available under SwiftForth (hence the name), and
> > > SwiftForth costs money.
> >
> > A portable version is available here:
> >
> > http://soton.mpeforth.com/flag/swoop/index.html
> >
> > It *is* slightly more tedious in some uses than the version
> > accompanying SwiftForth, since it lacks the [OBJECTS ... OBJECTS]
> > syntax for local objects...
>
> Why are you telling me this?

You made some false claims. I corrected them.

I have a general interest in the truth.


-- Julian

[lawren...@gmail.com]

On Saturday, August 13, 2016 at 5:15:08 PM UTC+12, hughag...@gmail.com wrote:

> On Friday, August 12, 2016 at 9:05:53 PM UTC-7, Lawrence D’Oliveiro wrote:
>> Functions as first-class objects can be rather useful, too.
>
> Hasn't Forth always had this? So long as you can obtain the xt with FIND or
> tick then you have a function as a first-class object.

In order for this to work properly, call frames need to be allocated on the heap. This way an inner function can continue to refer to the outer environment even after the outer function has exited. Consider the following Python snippet:

def make_counter(prefix) :
count = 0
def counter() :
nonlocal count
count += 1
print("%s count = %d" % (prefix, count))
#end counter
#begin make_counter
return counter
#end make_counter

counter1 = make_counter("counter1")
counter2 = make_counter("counter2")
counter1()
counter2()
counter1()
counter2()

which produces this output:

counter1 count = 1
counter2 count = 1
counter1 count = 2
counter2 count = 2

[Julian Fondren]

On Saturday, August 13, 2016 at 1:39:10 AM UTC-5, lawren...@gmail.com wrote:
> In order for this to work properly, call frames need to be allocated on the heap. This way an inner function can continue to refer to the outer environment even after the outer function has exited. Consider the following Python snippet:

You're talking about closures. Normal Forth definitions don't
enclosure on any variables either. First-class definitions are just
as powerful as the normal kind. 'First-class function' also
doesn't imply closures.

>
> def make_counter(prefix) :
> count = 0
> def counter() :
> nonlocal count
> count += 1
> print("%s count = %d" % (prefix, count))
> #end counter
> #begin make_counter
> return counter
> #end make_counter
>
> counter1 = make_counter("counter1")
> counter2 = make_counter("counter2")
> counter1()
> counter2()
> counter1()
> counter2()
>
> which produces this output:
>
> counter1 count = 1
> counter2 count = 1
> counter1 count = 2
> counter2 count = 2

Yeah, Paul Graham's thing. He has Forth submissions but didn't list
them because it depends on bignums and loadable bignum libraries don't
make Forth a bignum language.

This can be accomplished in Forth by doing, explicitly, what other
languages do implicitly with closures: attach some memory to a
function. Shared variables, like in the banking example, are also
possible, but at that point people start wondering if you haven't
heard of OO.

: counter ( n-init "name" -- )
create , does> 1 over +! ;

cr
5 counter blah
blah ?
blah ?
blah ?

: counter ( n-init -- xt )
here >r , :noname r>
]] literal 1 over +! ; [[ ;

100 counter
dup execute ?
dup execute ?
dup execute ?
drop

Output:

6 7 8 101 102 103

Obviously, returning an integer isntead of an address is no problem.


-- Julian

[Paul Rubin]

lawren...@gmail.com writes:
> In order for this to work properly, call frames need to be allocated
> on the heap. This way an inner function can continue to refer to the
> outer environment even after the outer function has exited.

In Forth without garbage collection, the best I see as feasible is to
allocate those closures on the locals or return stack, so they go away
when the outer function cleans up and returns.

C++ allocates closures on the stack, and has a way to copy them to the
heap (std::function), where those copied closures (IIUC) are freed
automatically when their surrounding scope exits. I think there are
some mechanisms for transferring their ownership from one scope to
another if they have to last beyond the current scope, but I don't
completely understand this feature at the moment.

I think it wouldn't be practical to use the std::function approach in
Forth, since it relies on C++'s concept of scopes and running object
destructors when a scope exits. You could free them manually, but
overall if you want to program in Scheme then you should download one of
the many fine Scheme implementations and use it ;-).

I find that extensive use of closures and HOFs gets confusing in Scheme
or Python even though their automatic gc takes care of reclaiming
storage. It's easy to lose track of how many levels of nested calls you
are in, In Haskell, the compile-time type system tracks that for you, so
the compiler squawks at you if you make a mistake. In Scheme or Python
the runtime checks will usually give you an error condition with a stack
dump as soon as the erroneous code is executed. But in Forth you're
likely to get garbage results that take effort to debug.

[HAA]

lawren...@gmail.com wrote:
> On Friday, August 12, 2016 at 4:51:30 PM UTC+12, HAA wrote:
> > My browser regularly crashes.
>
> Do you use Windows, by any chance?
>
> I use Firefox/Iceweasel on Linux, and can leave it running for weeks at a time.
>
> > I have little doubt there exists pre-written code in Forth but it will be
> > proprietary material that's been written by the companies concerned and
> > adapted as needed.
>
> No concept of Free Software, then?

Or don't see the need. Forth is a 'nuts and bolts' language whose
users have traditionally shown little interest in free software libraries,
preferring to DIY what they need. Forth offers enthusiasts more
things to do than just write applications - which baffles users of other
languages. Forth is philosophically engaging. Users can extend it
in ways that are beneficial, or diabolical, depending on your view.
More than a computing language? 'A Game of Thrones'?

[Elizabeth D. Rather]

On 8/12/16 4:05 PM, Doug Hoffman wrote:
...

>> I think my code is much more readable that the SWOOP code. Anybody
>> using POINT in SWOOP is going to get tired of writing USING POINT
>
> I don't know SWOOP very well. Is that really a requirement?

May I suggest you get a free evaluation copy of SwiftForth, read the
manual, and look at the code?

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."
==================================================

[HAA]

hughag...@gmail.com wrote:
> On Thursday, August 11, 2016 at 9:51:30 PM UTC-7, HAA wrote:
> ...
> > What they do seem to want is capable programmers.

>
> Really? There are no job offerings for Forth programmers.

I agree there would be few, but everybody wants a capable programmer.
Tom Zimmer had to switch to a language where the jobs were.

[Jan Coombs]

On Fri, 12 Aug 2016 22:55:18 -0700 (PDT)
Julian Fondren <julian....@gmail.com> wrote:
>
> I have a general interest in the truth.

so muddy pearls it is then?

[dhoff...@gmail.com]

On Saturday, August 13, 2016 at 4:11:28 AM UTC-4, Elizabeth D. Rather wrote:
> On 8/12/16 4:05 PM, Doug Hoffman wrote:
> ...
> >> I think my code is much more readable that the SWOOP code. Anybody
> >> using POINT in SWOOP is going to get tired of writing USING POINT
> >
> > I don't know SWOOP very well. Is that really a requirement?
>
> May I suggest you get a free evaluation copy of SwiftForth, read the
> manual, and look at the code?

When I get the time perhaps. Meanwhile I'll take that as a "no". The original poster should note this.
Thanks Elizabeth.

-Doug

[Doug Hoffman]

On 8/13/16 3:07 AM, Paul Rubin wrote:

> But in Forth you're
> likely to get garbage results that take effort to debug.

Often manual de-allocation is not difficult for me. But you've a valid
point for certain situations. Lately I've implemented a simple region
based scheme (with RESIZE support) when the going gets too complex. It
works well. Downside is it takes more memory than a GC, I believe though
I've no measurements to quantify.

-Doug

[humptydumpty]

On Wednesday, August 10, 2016 at 11:06:23 PM UTC+3, foxaudio...@gmail.com wrote:
> *Don't shoot the messenger please**
>
> I was doing some research on Lisp internals having found some old code
> by Martin Tracy on my drive. I went looking around and found this discussion:
>
> http://forums.parallax.com/discussion/160027/lisp-technically-scheme-written-in-forth
>
>
> <quote>"Dave Hein Posts: 4,831
> February 2015 edited February 2015 0
> I found a lisp interpreter written in C at http://www.umcs.maine.edu/~chaitin
> /lisp.c . I was able to get it to run on the Prop in a matter of minutes by
> changing the #define for SIZE from 1000000 to 400, and using the CMM model. The
> program is 950 lines of C code. I don't know lisp, but the program seems to do
> the right thing when I type in (+ 1 2).
>
> I've officially given up trying to port lisp.fs to pfth. I could probably get it to work in another day or so, but it seems a bit pointless. This exercise has reinforced my belief that Forth is just not a good language for writing large programs. It's fine for peeking and poking and dinking around. However, serious programming should really have library support and standards and compilers that assist the developer. Forth is fine if you want a challenge, but if you want to get something done use something else.
>
> As I've said before, Forth is Sudoku for programmers."
> </quote>
>
> The Scheme they were trying to port was for Gforth.
> (http://www.complang.tuwien.ac.at/schani/oldstuff/#lisp)
>
> And of course moving it to the little Parallax board was not possible.
> The Forth on the board is not quite standard.
>
> It seems a shame that we don't have code examples like the 'C' Scheme
> example that are as easily configured for different hardware.
>
> The comments in the posts mentioned the fact the the C code used arrays
> and the Forth code used Structs (and locals). Maybe simpler is better?
>
> Now where have I heard that before?
>
> It looks like a good project for my spare time.
>
>
> BF
>
> So much code so little time.

Hi!

I polished a little source file, words preserved their stack-effect
and added user input(exit through Ctrl+D). Now I can have fun, something like:

bo@linux-h5s7:~/src/lisp> gforth lisp.fs
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
ok
repl

(define fac
(lambda (n)
(cond ((eq? n 1)
1)
(t
(* n (fac (- n 1)))))))
;
(display (fac 5)) ; 120

bo@linux-h5s7:~/src/lisp>

--
Have a nice day,
humptydumpty

[foxaudio...@gmail.com]

Is there a place that we can see your source code.
That's very cool.

BF

[lawren...@gmail.com]

On Saturday, August 13, 2016 at 11:35:06 PM UTC+12, Doug Hoffman wrote:
> Downside is it takes more memory than a GC...

Python, like Perl, does both reference-counting and garbage collection. Reference-counting takes care of all the cases where there are no reference cycles. Then, for the stubborn cases, it resorts to garbage collection.

Best of both worlds--speed and convenience.

[hughag...@gmail.com]

I don't think that closures are useful, but I may be wrong about this because I've never programmed in Scheme or Python etc., so I don't have any practical experience with closures.

You have a function that returns a closure and it accesses the locals of the function. You can call this function many times and get many closures each with their own set of locals to work with.

This is very similar to having an OOP system and getting an object (the fields in the object are like the locals) and this class of object has one method (the method is like the closure). So, closures are effectively a kind of OOP --- this is a pretty limited kind of OOP though, because the class can only have one method --- normally in OOP systems a class can have several methods.

It is possible for the function to generate more than one closure, and all of them will access the same local-frame from this execution of the function that generated them. This means that the function has multiple return values, rather than just one. Now all of those return values have to be put somewhere, such as in a struct. But if you have a struct with several closures in it, then isn't that a lot like what you would have in OOP, with a struct with several methods?

All in all, closures seem like a gratuitous complication to me --- it is better to have a good OOP system that allows you to have classes with multiple methods --- the only advantage of closures is that you get to access your fields with the syntax you are accustomed to for accessing local variables, but this advantage is so minor as to be meaningless.

I think rquotations are useful for implementing general-purpose data-structures (in this case the parent is still in scope because it called the HOF and so the rquotation can stuff its locals with data which the parent can use after the HOF exits) --- closures can be used similarly but they are an overkill because they also provide the feature of outliving the parent, but this useless feature comes at a heavy cost (storing a local-frame in the heap is much slower than storing it on the return-stack, and it requires GC) --- of course, when I tried to make this point on comp.lang.lisp, it was treated as blasphemy, as they have elevated the concept of closures to a kind of holiness.

[Julian Fondren]

On Saturday, August 13, 2016 at 7:17:11 PM UTC-5, lawren...@gmail.com wrote:
> On Saturday, August 13, 2016 at 11:35:06 PM UTC+12, Doug Hoffman wrote:
> > Downside is it takes more memory than a GC...
>
> Python, like Perl, does both reference-counting and garbage collection.

Perl uses reference counting for the lifetime of the program, except
on exit. Which means it only uses referencing counting as far as
you'll ever care.

> Reference-counting takes care of all the cases where there are no reference cycles. Then, for the stubborn cases, it resorts to garbage collection.
>
> Best of both worlds--speed and convenience.

I suspect - just based on usage by different programming languages,
for example, anything used by Python is suspect - that reference
counting isn't great for performance, in addition to its other
problems, but I didn't look hard for sources on that. I did find this
post:

http://codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html

You can find a conservative GC for Forth at:

http://www.complang.tuwien.ac.at/projects/forth.html

From which:

> However, gc.fs needs to know if there is a reference to the object
> (if there is none, the object is certainly dead, and its storage can
> be recycled). You have to follow some rules to make sure gc.fs
> notices the reference:
>
> * The reference must reside on the data stack, in a memory location
> specified with root-address (see below), or in a naturally aligned
> cell in a referenced alloced object (naturally aligned cell means
> that its address is divisible by 1 cells). I would have liked to add
> the return and locals stack, but unfortunately there is no standard
> way to access them, so they are out.
>
> * The reference is the address where the object starts (i.e., the
> address returned by alloc). I.e., you cannot use addresses pointing
> into the middle of an object (e.g., a pointer walking an array),
> unless you also keep a pointer to the start in a place where gc.fs
> will find it.

[lawren...@gmail.com]

On Sunday, August 14, 2016 at 3:04:13 PM UTC+12, Julian Fondren wrote:

> ... reference counting isn't great for performance ...

Let me offer a high-performance counterexample to that: the Linux kernel. Which uses reference-counting heavily for managing its internal objects.

Can you point to a kernel which uses garbage collection instead? No, because nobody would seriously use one.

[lawren...@gmail.com]

On Sunday, August 14, 2016 at 3:00:30 PM UTC+12, hughag...@gmail.com wrote:
> I don't think that closures are useful, but I may be wrong about this
> because I've never programmed in Scheme or Python etc., so I don't have any
> practical experience with closures.

That was just a toy example. See the anim_framework examples I linked to previously for more non-trivial instances.

[Julian Fondren]

If you don't know anything about GC performance either, there's
nothing to discuss.

On Saturday, August 13, 2016 at 10:39:44 PM UTC-5, lawren...@gmail.com wrote:
> That was just a toy example. See the anim_framework examples I linked to previously for more non-trivial instances.

I glanced through that and saw nothing of interest. Why don't you
excerpt from it and say why the excerpt is interesting?


-- Julian

[Paul Rubin]

Julian Fondren <julian....@gmail.com> writes:
> I suspect - just based on usage by different programming languages,
> for example, anything used by Python is suspect - that reference
> counting isn't great for performance, in addition to its other
> problems, but I didn't look hard for sources on that.

Refcounting in single threaded CPython works ok. It has caused a lot of
pain with multi-threading because have to put locks around the refcounts
(killing performance in the single threaded case), or lock the whole
interpreter (the infamous Global Interpreter Lock or GIL) when executing
bytecodes. One "advantage" of refcounts was that objects are freed as
soon as the last reference disappeared, so people relied on that for
timely release of stuff like file descriptors, a lame style imho. Later
the "with" statement was added to Python which explicitly releases stuff
at the end of its scope, which is preferable.

Micropython uses pure gc instead of refcounts, if that matters.

> http://codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html

That article is pretty unpersuasive. C++ smart pointers work pretty
well if you remember that C++ is a totally different language than C and
don't use legacy C stuff in your program. The refcounted pointers are
useful when they are needed, but unique_ptr is good enough most of the
time, and has almost no overhead. unique_ptr means the pointer has a
single owner, so the object is freed when the owner goes out of scope,
unless you transfer the ownership to another unique_ptr first.

C++ std::shared_ptr (the ref counted ones) do have locks around the
refcounts, which must be expensive. I believe Seastar has its own
version of shared_ptr that can't be shared across threads, so that would
get rid of the need for locks.

There's some hooks in C++ for a real GC but I don't know of any
implementations or what the obstacles to them are. But, part of the
idea of C++ is to control your program's memory resources. If you want
a GC'd language you might as well use one designed for GC from the start.

> You can find a conservative GC for Forth at:
> http://www.complang.tuwien.ac.at/projects/forth.html

Yes, that's way cool.

>> * The reference must reside on the data stack,.... I would have liked

>> to add the return and locals stack, but unfortunately there is no
>> standard way to access them, so they are out.

I think it's worth supporting the return and locals stack in specific
implementations using carnal knowledge of those implementations.

[humptydumpty]

Hi!

Here is the link: https://we.tl/fANcCUBrge

[hughag...@gmail.com]

On Saturday, August 13, 2016 at 9:53:17 PM UTC-7, Paul Rubin wrote:
> That article is pretty unpersuasive. C++ smart pointers work pretty
> well if you remember that C++ is a totally different language than C and
> don't use legacy C stuff in your program. The refcounted pointers are
> useful when they are needed, but unique_ptr is good enough most of the
> time, and has almost no overhead. unique_ptr means the pointer has a
> single owner, so the object is freed when the owner goes out of scope,
> unless you transfer the ownership to another unique_ptr first.
>
> C++ std::shared_ptr (the ref counted ones) do have locks around the
> refcounts, which must be expensive. I believe Seastar has its own
> version of shared_ptr that can't be shared across threads, so that would
> get rid of the need for locks.

I skimmed through that article but I was turned off by the writer's arrogant and smarmy attitude (calls people "retards" if they use reference-counting). I'm not surprised that Julien Fondren posted the link, because he is arrogant and smarmy too.

I agree with you and Lawrence that reference-counting is a valid GC technique --- this is what I would most likely use if I were ever to implement GC --- I don't think that GC is a good idea in Forth though; if you want this, then program in C++ with its "smart pointers."

Franck seems to be pretty knowledgeable on programming. I would be interested in finding out how he does GC in his Oforth, but he hasn't yet posted anything in this thread --- he may have posted something about GC in Oforth in some other thread, but I missed it.

Earlier, Franck said this about my string-stack.4th package:

On Thursday, March 10, 2016 at 11:42:43 AM UTC-7, franck....@gmail.com wrote:
> Le lundi 7 mars 2016 04:09:14 UTC+1, hughag...@gmail.com a écrit :
>
> > 1.) JUGGLERS --- These include SWAP$ etc. and they just move items around on the string-stack.
> >
> > 2.) DUPLICATORS --- These include DUP$ etc. and they make a derivative item.
> >
> > 3.) CONSUMERS --- These include .$ etc. and they consume an item. If the item is a derivative it is just dropped. If the item is a unique, then FIX-DERIVATIVES is called first (this searches the string-stack for derivatives that are inside of this unique and changes them into uniques) and then it is dropped.
> >
> > 4.) MUTATORS --- These include UCASE$ etc. and they modify an item. If the item is a derivative it gets changed into a unique first, and if the item is a unique then FIX-DERIVATIVES gets called first, then the item is modified.
> >
>
> This is an interesting memory management. I wonder how this compare to
> a memory management using a garbage collector.

Whenever a unique string gets dropped or modified, FIX-DERIVATIVES gets called first --- FIX-DERIVATIVES searches the entire string-stack for any derivatives of this unique and, if found, converts them into uniques --- this is pretty fast because there are typically only a handful of strings on the string-stack.

The user can assume that all strings on the string-stack are unique and his code will work fine. In actuality, most of the strings are derivatives. When a new derivative is made with DUP$ or whatever, all that needs to be copied is the address of the string --- if a new unique were made, than ALLOCATE would need to be called and the string would need to be copied, which would be very slow.

[jim.bra...@ieee.org]

On Saturday, August 13, 2016 at 7:17:11 PM UTC-5, lawren...@gmail.com wrote:

Another choice is for the calling procedure to provide the work space and room for results to the called procedure. Works well for scientific computing.

[Melzzzzz]

On Sat, 13 Aug 2016 21:53:12 -0700
Paul Rubin <no.e...@nospam.invalid> wrote:

> Julian Fondren <julian....@gmail.com> writes:
> > I suspect - just based on usage by different programming languages,
> > for example, anything used by Python is suspect - that reference
> > counting isn't great for performance, in addition to its other
> > problems, but I didn't look hard for sources on that.
>
> Refcounting in single threaded CPython works ok. It has caused a lot
> of pain with multi-threading because have to put locks around the
> refcounts (killing performance in the single threaded case), or lock
> the whole interpreter (the infamous Global Interpreter Lock or GIL)
> when executing bytecodes.

Classic GC either have to lock whole program or to synchronize on every
pointer access as well...

[Paul Rubin]

Melzzzzz <m...@zzzzz.com> writes:
>> lock the whole interpreter (the infamous Global Interpreter Lock or
>> GIL) when executing bytecodes.
>
> Classic GC either have to lock whole program or to synchronize on every
> pointer access as well...

Classic GC only has to lock the program -during garbage collection-.
The Python GIL has to lock the interpreter essentially -all the time-.
That means your program is always running on a single cpu core even if
you use multiple threads. That was ok when most cpus were single core,
but it's a significant source of frustration now.

[lawren...@gmail.com]

On Monday, August 15, 2016 at 5:32:33 AM UTC+12, jim.bra...@ieee.org wrote:
> Another choice is for the calling procedure to provide the work space and
> room for results to the called procedure. Works well for scientific
> computing.

Interestingly, Python is popular for that, too <http://www.scipy.org/>.

[lawren...@gmail.com]

On Monday, August 15, 2016 at 6:17:21 AM UTC+12, Paul Rubin wrote:
> The Python GIL has to lock the interpreter essentially -all the time-.
> That means your program is always running on a single cpu core even if
> you use multiple threads. That was ok when most cpus were single core,
> but it's a significant source of frustration now.

That may apply to pure Python code, but it doesn’t need to apply to extension modules written in C. In these, you can release the GIL during the CPU-intensive parts, allowing them to be multithreaded, then reacquire it for returning results back to Python.

I used this technique here <https://github.com/ldo/grainypy/blob/master/grainyx.c>--look for the sequences bracketed by Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS.

[Paul Rubin]

lawren...@gmail.com writes:
> That may apply to pure Python code, but it doesn’t need to apply to
> extension modules written in C. In these, you can release the GIL

Yes, I know about that, and it helps some of the time (I think numpy
does that). I meant the interpreter has to hold the GIL while running
Python code. For occasional CPU-intensive stuff I do in Python, I can
usually split up the problem and run multiple Python instances on
different cores, but the GIL is still a big wart on Python.

[humptydumpty]

Have traveled trough source expression '(display 3)' as 'REPL' does step by step.
Quite a journey! :)

A little improved version is here, most important is 'repl' modification.

: REPL BEGIN parsetext lisp-load-from-string drop AGAIN
;

as originally forgotten 'drop' :|

Link is here: https://we.tl/wVEZgZqk2e

--
humptydumpty

[Gerry Jackson]

On 14/08/2016 14:02, hughag...@gmail.com wrote:
> In my string-stack.4th I use a technique different from either GC or reference-counting. I have unique and derivative strings. When a unique gets dropped or modified, I first call FIX-DERIVATIVES --- this searches the entire string-stack for any derivatives of this unique and, if found, converts them into uniques --- it doesn't take long to do this, as there are generally only a handful of items on the string-stack.
>
> The user can assume that every string on the string-stack is unique and there are no dependencies --- in practice, most of the strings on the string-stack are derivatives --- making a derivative with DUP$ etc. is much faster than making a unique because ALLOCATE doesn't have to be called and the string doesn't have to be copied, but only the address of the string has to be copied.

String packages with string stacks and garbage collection have been
around for some time e.g. see
http://www-personal.umich.edu/~williams/archive/forth/strings/smodel.html

--
Gerry

[lawren...@gmail.com]

On Monday, August 15, 2016 at 9:09:32 AM UTC+12, Paul Rubin wrote:

> I meant the interpreter has to hold the GIL while running
> Python code.

If you want speed, you’re going to recode that bit in C, not Python, anyway. That’s why the GIL hasn’t been seen as a big problem.

[hughag...@gmail.com]

I skimmed through that article. I found this paragraph:
----------------------------------------------------------------------------
A more likely problem is the transfer of a bound string to the data stack for some manipulation. The MSA on the data stack may become invalid if a dynamic string operation is performed in the meantime which causes garbage collection. The simplest rule is to avoid dynamic string operations while manipulating bound strings on the data stack. But we do include a locking mechanism by which the user can explicitly disallow or repermit garbage collection.
----------------------------------------------------------------------------

That is no good! In my documentation I say this:
----------------------------------------------------------------------------
$> ( -- adr len ) \ string: a --
This is how strings get removed from the string-stack. These strings are in the heap so the address needs to be given to DEALLOC eventually or there will be a memory leak. This function is only used if the string needs to be stored in a data-structure of some kind. The user should not use $> and then consume the string with TYPE or whatever. The user should consume the string on the string-stack, with .$ instead of TYPE for example, so the string is automatically freed from the heap.
----------------------------------------------------------------------------

$> is similar to DROP$ in that it does FIX-DERIVATIVES first.

I expect all strings to remain on the string-stack at all times. You don't copy them to the data-stack and do operations on them there, and expect them to still be valid on the string-stack. You don't use TYPE as mentioned above --- there is .$ available for typing out a string.

The reason why my memory-management scheme is efficient is because all the strings are on the string-stack --- you don't have strings scattered all over --- everything is contained in one place, so it is easy to manage. Of course, you sometimes need to store a string in a data-structure of some kind, in which case you need to use $> to first put it on the data-stack --- now memory-management is your responsibility and you have to use DEALLOC explicitly to get rid of it or you will have a memory leak.

[Paul Rubin]

lawren...@gmail.com writes:
> If you want speed, you’re going to recode that bit in C, not Python,

No really, that's considered a somewhat drastic step. It's generally
preferable to run separate python instances, or use the multiprocessing
module, or wait the extra time for the python program to run.

[HAA]

hughag...@gmail.com wrote:
> On Friday, August 12, 2016 at 11:54:21 AM UTC-7, Julian Fondren wrote:
> > * Forth Inc. just wants you to buy SwiftForth.
> > * SwiftForth comes with SWOOP , providing structures and more.
> > * Forth Inc. are opposed to structures.
> >
> > Man it's really difficult sometimes to get your malicious
> > characterizations to agree with your analyses of sinister plots.
>
> SWOOP is only available under SwiftForth (hence the name), and SwiftForth costs money.

That's not quite correct. Forth Dimensions V20N5/6 published an article by
Rick Van Norman "SWOOP: Object-Oriented Programming in SwiftForth".
It contained the full source code. Conditions of use were as follows:

"(C) Copyright 1999 FORTH, Inc. www.forth.com
FORTH, Inc. grants to members of the Forth Interest Group permission to use this
code providing the user clearly acknowledges FORTH, Inc. as author. FORTH, Inc.
assumes no responsibility for the accuracy or completeness of this code. We will
greatly appreciate being notified of any improvements users may make or recommend."

Specifics conditions aside, it is clear this code was intended for public use and
modification. One user, Gene LeFave, subsequently made changes which Forth Inc
adopted and it became ASWOOP - the package currently supplied with SwiftForth.

p.s. that FD issue also contains "PRESWOOP" - ANS prelude code for SWOOP
by Wil Baden.

[HAA]

p.p.s. Googling uncovered a later version here:
http://soton.mpeforth.com/flag/swoop/index.html

[Anton Ertl]

Julian Fondren <julian....@gmail.com> writes:
>But that's not what I'm doing. Please don't worry about my goals.

Here's a Hughish theory: You are paid by Forth, Inc. to provoke him to
spend even more time on posting rather than developing Straight Forth,
because Staright Forth, when it is finally there, will blow SwiftForth
and everything else away, so better delay that day.

- 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 2016: http://www.euroforth.org/ef16/

[Alex McDonald]

On 15/08/16 08:10, Anton Ertl wrote:
> Julian Fondren <julian....@gmail.com> writes:
>> But that's not what I'm doing. Please don't worry about my goals.
>
> Here's a Hughish theory: You are paid by Forth, Inc. to provoke him to
> spend even more time on posting rather than developing Straight Forth,
> because Staright Forth, when it is finally there, will blow SwiftForth
> and everything else away, so better delay that day.
>
> - anton
>

It's not often you get as much as a chuckle on clf, especially when Hugh
is in the mix, but this one made me laugh out loud. Thank you.

--
Alex

[hughag...@gmail.com]

On Monday, August 15, 2016 at 12:14:38 AM UTC-7, Anton Ertl wrote:
> Julian Fondren <julian....@gmail.com> writes:
> >But that's not what I'm doing. Please don't worry about my goals.
>
> Here's a Hughish theory: You are paid by Forth, Inc. to provoke him to
> spend even more time on posting rather than developing Straight Forth,
> because Staright Forth, when it is finally there, will blow SwiftForth
> and everything else away, so better delay that day.

Ultimately, Forth-200x is known by the company that they keep --- Julien Fondren, Alex McDonald --- total suck ups.

[Anton Ertl]

Julian Fondren <julian....@gmail.com> writes:
>If you make a gforth-compatible library of any size under
>theforth.net's framework, then you can create an account and upload it
>theforth.net yourself.

While I really encourage you all to make your libraries
Gforth-compatible, theforth.net does not require that.

[Anton Ertl]

m...@iae.nl writes:
>If you follow this train of thought, then libraries of source
>code will never make it: they can't gain momentum as the user
>base is too small (at most the programmers of the language-du-jour).
>
>What could make it (if you want to follow my analogy) is open
>source software that is compiled as a shared library. In this
>way everybody/every language can use the library. Improvements
>are still possible but they have to go through the package
>maintainers. In principle it is still possible for an engineer
>to fork an existing package and maintain it privately, but in
>most cases it is not unlike designing and manufacturing your
>own IC: too many different skills are needed, can't bother.

The practice of other programming languages (e.g., JavaScript or
Python) demonstrates that source code libraries do make it. In the
case of Javascript, even very small ones that just provide some
substring function or something.

Why have they not made it in Forth (yet)? I can think of several
factors:

* A culture rejecting libraries; after all, Chuck Moore spoke against
them and his saying about favouring rewriting instead of reusing
code as-is are frequently repeated here.

* Along with that, we get vendors who do not understand what is needed
to support source code libraries, and fight hard against including
the necessary features in the standard.

* Small embedded systems play a big role in the minds of many Forth
programmers, and there you generally cannot afford the inefficiency
of using a library as-is (neither source code, nor binary).

* We have a small community, and thanks to the factors above, the
number of people working on source code libraries is even smaller,
so it does not reach the critical mass, unlike JavaScript or Python.

* There are also technical issues. We have explicit memory
management, and often this means that you can have one library that
manages memory in one way, but is good only for some uses, and
another library that manages memory in another way and is also good
for some uses. As a result, we have, e.g., lots of different string
libraries, and none gains general acceptance.

>So, the question is not the programming language(s) to use,
>but how well what we use is able to interface to all the
>binary packaged stuff that is out there. What about using
>a .dll or .so in Standard Forth? We still can't do this
>in a standard way!

Various Forth systems offer C interfaces and you can call shared
libraries containing C code (or other ABI-compatible code) with this,
and certainly standardizing the C interface is on the agenda.

But Forth systems producing shared libraries from Forth source code
are rare; IIRC bigForth can do binary modules, but they are not
standard .so or .dll files, are they?

So in terms of binary Forth libraries, we don't have anything. But I
also doubt that they would help. None of the points I made above go
away when the library is supplied in binary. We have a way to deal
with source libraries; it needs some more standardizations, but we are
certainly much farther there than for binary libraries.

[lehs]

Does it have to be binary libraries? Isn't INCLUDE fast enough?

[HAA]

Anton Ertl wrote:
> ...

> The practice of other programming languages (e.g., JavaScript or
> Python) demonstrates that source code libraries do make it. In the
> case of Javascript, even very small ones that just provide some
> substring function or something.
>
> Why have they not made it in Forth (yet)? I can think of several
> factors:
>
> * A culture rejecting libraries; after all, Chuck Moore spoke against
> them and his saying about favouring rewriting instead of reusing
> code as-is are frequently repeated here.
>
> * Along with that, we get vendors who do not understand what is needed
> to support source code libraries, and fight hard against including
> the necessary features in the standard.
>
> * Small embedded systems play a big role in the minds of many Forth
> programmers, and there you generally cannot afford the inefficiency
> of using a library as-is (neither source code, nor binary).
>
> * We have a small community, and thanks to the factors above, the
> number of people working on source code libraries is even smaller,
> so it does not reach the critical mass, unlike JavaScript or Python.
>
> * There are also technical issues. We have explicit memory
> management, and often this means that you can have one library that
> manages memory in one way, but is good only for some uses, and
> another library that manages memory in another way and is also good
> for some uses. As a result, we have, e.g., lots of different string
> libraries, and none gains general acceptance.

So whenever an idea fails to fly, we can blame it on Forth's creator,
the Standard, the vendors, the users or lack of numbers :)

[franck....@gmail.com]

Le dimanche 14 août 2016 16:45:16 UTC+2, hughag...@gmail.com a écrit :

> I would be interested in finding out how he does GC in his Oforth, but he hasn't yet posted anything in this thread --- he may have posted something about GC in Oforth in some other thread, but I missed it.
>

Oforth implements a mark and sweep incremental GC.

Incremental means that, when the GC is running, it runs by steps.
After each step, the GC stops, the programm runs again a little,
then the GC restarts again, and so on until the end of the GC phase.
This allows to not have a "stop the world" GC.

If you are interested, you can read how Oforth handles memory and how
GC works here :

http://www.oforth.com/memory.html

As for a reference counting GC, I am not fond of it.
It is a good choice for a mono-thread programs, but when you use it
in a multi-thread context, things are getting more complex.
I much prefer a mark and sweep incremental GC.

As for the Point class, here is an Oforth implementation :

Object Class new: Point ( x, y )

Point method: << // ( aStream aPoint -- aStream )
"X:" << @x << " Y:" << @y << ;

Point method: initialize // ( x y -- )
:= y := x ;

: my-test // ( -- )
5 8 Point new . // intialize is called by #new and #. uses #<<
;

#my-test see
6a: 4:c7:47 : 0 : push 4
c7:47:fc: 5 : 2 : mov c0000005, -4(edi)
c7:47:f8: 8 : 9 : mov c0000008, -8(edi)
bd:ac:de:69 : 10 : mov 69deac, ebp
83:ef: 8:e8 : 15 : sub 8, edi
e8:c7:2b:d8 : 18 : call 401A40
e8:3a:62:ff : 1D : call 6750B8
83:c4: 4:c3 : 22 : add 4, esp
c3: 0: 0:b9 : 25 : ret
ok

About performances, if you want to compare, here is a bench that creates
many Point objects :

: b-test // ( n -- )
| i |
loop: i [ i i Point new drop ] ;

On my laptop (core i7), creating (and freeing with GC) 100000000 Points takes
about 1,4 seconds.

#[ 100000000 b-test ] bench
1420136
ok

Franck

[Stephen Pelc]

On Mon, 15 Aug 2016 08:52:40 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>Why have they not made it in Forth (yet)? I can think of several
>factors:
>
>* A culture rejecting libraries; after all, Chuck Moore spoke against
> them and his saying about favouring rewriting instead of reusing
> code as-is are frequently repeated here.

This certainly not true for the commercial vendors. Our clients want
as much functionality as they can get. What distinguishes them from
other users is that they have to pay for code. They also have
different expectations of the code.

>* Along with that, we get vendors who do not understand what is needed
> to support source code libraries, and fight hard against including
> the necessary features in the standard.

Rubbish. We have code bases and clients of 30 years standing. We are
just not prepared to break that code.

>* Small embedded systems play a big role in the minds of many Forth
> programmers, and there you generally cannot afford the inefficiency
> of using a library as-is (neither source code, nor binary).

Since the ANS standard, portability of embedded code above the
driver layer has improved enourmously. However, this has required
authors to consider portability from the outset.

To add another issue, there is a resistance in some areas to add
necessary complexity to parsing to reduce application programmer
effort. MPE released the source code for our EXTERN: interface to
shared libraries some years ago. I only know of one system adopting
it. It may be significant that the interface is designed for ease
of use rather than ease of implementation.

>>So, the question is not the programming language(s) to use,
>>but how well what we use is able to interface to all the
>>binary packaged stuff that is out there. What about using
>>a .dll or .so in Standard Forth? We still can't do this
>>in a standard way!
>
>Various Forth systems offer C interfaces and you can call shared
>libraries containing C code (or other ABI-compatible code) with this,
>and certainly standardizing the C interface is on the agenda.

I would certainly support standardising this, even if we end up
with a notation driven by implementation requirements. However,
a notation that ignores type information just won't cut it.

Note also that we are not just discussing hosted systems here. The
MPE Sockpuppet interface (thank you, Robert Sexton) to C for
embedded systems uses the same notation as the EXTERN: interface
but for linking embedded Forth to embedded C code.

>But Forth systems producing shared libraries from Forth source code
>are rare; IIRC bigForth can do binary modules, but they are not
>standard .so or .dll files, are they?

VFX Forth for Windows has been able to produce DLLs for many years,
and other commercial systems can do so too. It isn't always easy
and the implementation cost is often considerable.

Once you include embedded systems, source code portability is still
far more valuable than binary portability.

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

[lawren...@gmail.com]

On Saturday, August 13, 2016 at 12:45:20 PM UTC+12, hughag...@gmail.com wrote:
>
> On Friday, August 12, 2016 at 3:10:59 PM UTC-7, Lawrence D’Oliveiro wrote:
>>
>> Well-designed languages and package managers do provide [separate
>> namespaces and dependency management].
>
> ... how would [Forth] provide these facilities?

Look at Python as an example of how to do namespaces. In order to reference a separate module, you have to use an “import” statement. E.g. before you can use any of the definitions provided by the “math” module <https://docs.python.org/3/library/math.html>, you have to write

import math

then you can use “math.sin” for the sin function, and similarly for the others. If you want to use unqualified names, then you can bring them in individually, e.g.

from math import sin, cos

Now when you use “sin” and “cos” in that program, a reader searching through the code for those names, wondering where they came from, will eventually hit the “import” statement.

You can also replace names defined in the original module with your own names, e.g. <https://docs.python.org/3/library/xml.etree.elementtree.html>

from xml.etree import \
ElementTree as XMLElementTree

Or where a module like ctypes <https://docs.python.org/3/library/ctypes.html> gets referenced heavily, I can shorten its name thus <https://github.com/ldo/qahirah>:

import ctypes as ct

Python also allows wildcard imports, e.g.

from math import *

which means “pollute my global namespace with everything exported from math”. Personally I avoid this.

As for dependency management, you need to have package management integrated at the OS level, not the language level. Look at most common Linux distros for examples of this.

[Julian Fondren]

On Sunday, August 14, 2016 at 5:48:11 PM UTC-5, lawren...@gmail.com wrote:
> If you want speed, you're going to recode that bit in C, not

> Python, anyway. That's why the GIL has't been seen as a big
> problem.

Right. So I'll look forward to your continued attempts to enlighten
us poor Forth people via the vast wisdom and creativity of Guido :-)

* mutating a function-level variable is significantly faster than
mutating a module-level variable.

* += operators are too confusing to include in the language

* one-statement lambdas are a good idea

* lambda is ugly and should be phased from the language

* sorry guys the only way to fix unicode support is to "pull a
perl6" over features that perl5 developed more naturally because
I was way too hackish with my early attempts at providing them

* += operators, decorators, generators, list comprehensions, and all
this new stuff that people have stuffed into my 'one way to do it'
baby language are OK because -- hey look a goat! Please continue
to think of Python as the easiest possible language in the world!
People thinking that for no reason have *really* helped, thanks.

Anyway, interfacing with C for speed is a novel idea. I think Forth
systems usually do that purely to interface with legacy C libraries,
and try to do it without the programmer having to write any C, but
"do it in C for speed" is perhaps not something we're culturally
aware of, and there must be many missed opportunities for
improvement due to that.

On Monday, August 15, 2016 at 8:40:12 PM UTC-5, lawren...@gmail.com wrote:
> Look at Python as an example of how to do namespaces.

Do we have to? It's not as good as close related languages, like
it's not as good at most things. For example, there's no "import a
default selection of interesting things" as an alternative to
"import * from module" in Python.

Not that Python has *nothing* to teach us. It has good propaganda.
But, as far as programming language design... I guess, Python
teaches that it doesn't matter that much? Just call your personal
failures 'language warts' and then demand that everyone rewrite
their code to change the pattern of these warts whenever you feel
like some new books need to be written about a new major version of
the language.

Rewriting working code? Why, that's just part of my commitment to
making this the most learnable language ever. Just give that job
to the new guy! He'll learn so much!

...


Anyway, Let's suppose we use the PACKAGE wordset extensively.

> import math

There's no analogue of this -- PUBLIC words will always enter your
current wordlist. There's also no 'math.foo'. With a recognizer
stack the latter could be added easily. The former would require
another wordlist to wrap the public words, and then another 'open a
package' word to account for this.

package math-public
private
include math.fs
end-package

Or you could do just do like python and write your packages without
any public words.

> from math import sin, cos

> from xml.etree import \
> ElementTree as XMLElementTree

For actually private words, and with the libraries already included,

package math
public
synonym sin sin
synonym cos cos
end-package

package xml-etree
public
synonym XMLElementTree ElementTree
end-package

> import ctypes as ct

require ctypes.fs
synonym ct ctypes

> from math import *

also math

Or, slightly more robustly (if math redefines private words as
public words, with the above you'll see the private ones before the
public ones in the search order),

get-order math -rot 1+ set-order

Of course, none of this is syntax, built into the language, so
over-long or ugly sequences of words can just be placed into a
definition, allowing this to be the equivalent of the last example:

also private math

> which means "pollute my global namespace with everything exported
> from math". Personally I avoid this.

Well, the PACKAGE wordset allows people to say "here, have my well
designed API. If you insist, my internal words are all under this
blanket." Curation and also everything, without pollution of your
namespace unless you ask for it.

In general, the way to add features to wordlists is with
conventions. The PACKAGE wordset uses the convention that your
current wordlist, whatever it is at the time of the definition of
the package, is where you want PUBLIC words to go.

Another convention you could use is "*modules* are wordlists that
include definitions of this or these words, which the module wordset
invokes to do module things."

: import ( "module" -- )
also ' execute c" i-got-imported" find drop execute ;

include math.fs
import math

\ I-GOT-IMPORTED in MATH filled my current wordlist with its
\ public words, linked in its documentation, added a MATH.
\ recognizer, etc.

Add other words as needed for other features. Of course, the
modules wordset can also come with words that modules can use to
easily implement these words, provided that conventional behaviors
are desired.


-- Julian

[humptydumpty]

Cleaned up a little and added few words.
wetransfer link: https://we.tl/tsml9LM5e9

Examples:

bo@linux-h5s7:~/tmp/lisp> cat scaled-math.scm sqrt.scm
; scaled-math.scm
(define pi (lambda (x) (*/ 355 113))) ;
(define math-scale 1000) ;
(define s+ (lambda (x y) (+ x y))) ;
(define s* (lambda (x y) (*/ x y math-scale))) ;
(define s/ (lambda (x y) (*/ math-scale x y))) ;
(define s1/ (lambda (x) (*/ math-scale math-scale x))) ;
; sqrt.scm - Square root by Heron method
(load scaled-math.scm) ;
(define average
(lambda (x y)
(/ (s+ x y) 2))) ;

(define heron-step
(lambda (x y)
(average x (s/ y x)))) ;

(define heron
(lambda (x y0 y1)
(cond ((eq? y1 y0) y1)
(t
(heron x y1
(heron-step y1 x)))))) ;

(define sqrt
(lambda (x)
(heron x x (/ x 2)))) ;

Starting scheme:

bo@linux-h5s7:~/tmp/lisp> gforth scheme.fs

Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit

repl
(load sqrt.scm) ;
(display (sqrt 5000)) ; square root of 5.000 is : 2236
; Ctrl+D to exit

[Paul Rubin]

humptydumpty <oua...@gmail.com> writes:
> bo@linux-h5s7:~/tmp/lisp> gforth scheme.fs

> (load sqrt.scm) ;
> (display (sqrt 5000)) ; square root of 5.000 is : 2236

This is really cute. Do you use Anton's GC?

[humptydumpty]

On Tuesday, August 16, 2016 at 10:57:46 AM UTC+3, Paul Rubin wrote:

> humptydumpty writes:
> > bo@linux-h5s7:~/tmp/lisp> gforth scheme.fs
> > (load sqrt.scm) ;
> > (display (sqrt 5000)) ; square root of 5.000 is : 2236
>
> This is really cute. Do you use Anton's GC?

Hi!

I have not (yet) plan to use extensively, just intended to get some insights
of Scheme interpreter :)

I'm happy that I get such (mental food) in Forth. Following byte by byte
REP cycle for an particular input is an adventure itself! :)

[Brad Eckert]

On Friday, August 12, 2016 at 1:34:27 AM UTC-7, Julian Fondren wrote:
> Wealth yields wealth and poverty yields poverty. It would be foolish
> and self-destructive, not clever and evil, for Forth companies to
> sabotage Forth in order to *benefit* in some way.
>

Well, the customers of both commercial Forth companies have a huge investment in Forth and Forth systems that are still in service and are not cost effective to replace. Protecting that investment is long term security.

As far as new growth goes, I think it's more a matter of cultural innovation. Forth does a lot of things well, but programming is more than doing things well. There's a psychology of simplicity, of which Chuck was a pioneer, that is sorely lacking in today's profession. Chuck even went so far as to serve as a cautionary tale of the excesses of oversimplification, in true pioneer fashion. Had Elizabeth and Ned reigned him in, who knows how far they could have taken FORTH Inc? Every kite needs a tether.

But as it is, Forth has fallen into other hands. Our hands. It's just good programming without all the pomp and pretense. In other words, a language ahead of its time. Maybe the world just needed time to soften a bit before it was ready for Chuck's Manhattan Beach dream. Getting the complexity out of the way. That was the groove.

So here we are, taking up the cross. But it's not a cross, it's a groove. There's this body of Forth ideas, a framework on which to build things. But really, a framework upon which to build a life and a psyche and a worldview. Maybe that was all too much for Chuck, but he did a great job with the role he played. The weaknesses of genius go with its strengths, without which Forth would not exist.

There's no reason that programming as a profession should not be a holistic way of being. The dissolution of artificial boundaries should be second nature because you keep attacking the artificial boundaries in yourself. You keep tearing down the walls of complexity in your life. Although I'll admit it's easy to go too far, and then wonder why people aren't wholeheartedly behind your next reckless endeavor. Ah, the life of a cowboy.

I almost forgot to mention: You are totally wasting your time engaging Hugh because he doesn't want to be reasoned with. He loves to share his code but refuses an honest critique. Here is not a man with a simple inner world. Lots of walls, of which he will build himself in the process of tearing them down. I suspect it will take a while.

[lehs]

I guess that Forth is more of an idea than a computer language and that the idea of Forth will develop as other good ideas develop in a long-term perspective. Charles Moore have said that Forth is an approach to programming and he never seems to use any standards. I guess he use no libraries neither, but copy and paste from his own code.

I think a lot of forthers is a bit like Charles Moore. It's all about the idea and our own code. I rather use a less effective code (in progress) of my own, than some alien code by someone else, especially when it comes to packages. What I do use is others definitions and Forth implementations. And I also like to test other peoples code from time to time, last the fancy Lisp implementation that humptydumpty manage to get running. And I want the possibility of other people to run my code if they want.

The CORE and DOUBLE words in ANS Forth are the most important definitions to be standardized. And they shouldn't change from standard to standard. FLOATING and FILE are nice but could maybe be developed further. Personally I'm not interested at all in future implementations of various computer scientific ideas that maybe not belong in Forth at all.

Recognizers seems to be a good idea if implemented in a smart and simple way. From there really nice implementations of new data types would be possible.

Also, why are there no discussion of a standard for rudimentary graphic words? Or are there?

[Mark Wills]

As I'm doing (paid) embedded development at the moment, I'm currently
rather sad at the Forth world. The term "Sudoko for programmers" might
be true. I'd like to do embedded Forth, but there's little out there
to drive real hardware that one will typically use these days in the
embedded world: LCDs, touch panels, that sort of stuff.

One possible option is noForth. Those guys seem to have developed the
software libraries to drive a whole host of hardware on the MSP430
platform. That's very encouraging.

[Cecil Bayona]

I been using a whole lot of different platforms to do personal embedded
projects but I came to the conclusion that that needs to stop, and I
need to concentrate all my efforts on one platform so I can develop my
own set of libraries to access the built in hardware devices and not
have to re-invent the wheel with every device out there.

I've settled on the ST family of ARM devices and from now on I will only
buy Nucleo and Discovery boards to keep the variation of hardware down
to a minimum. They are powerful, they are inexpensive and even if they
are overkill for a task, I will stick to these two families to keep the
variation down to a minimum and stabilize my software environment. Right
now my software of choice is MPE's VFX ARM compiler, and eForth for FPGA
soft CPUs, for the desktop, the jury is still out. I also own a copy of
Rowley's Crossworks C development system for ARM but I have not used it
in a while.
--
Cecil - k5nwa