jonesforth: taking up the challenge

[Albert van der Horst]

Remember we discussed jonesforth at the German convention?
I take up the challenge to make a similar forth.

What do we want? The enticement of jonesforth but
- ISO compatibility (for all words with an ISO name that is)
- no words in assembler if Forth is feasible
- one file, Forth coded in assembler


The last two points are related, jonesforth has a startup library
in Forth:

cat jonesforth.f - | jonesforth

But this means a whole working interpreter must be present and be
coded in assembler. This I don't like at all.


Part of the enticement of jonesforth is its introduction.

I cannot totally agree with it. Here are my proposed changes.

jones:
FORTH is one of those alien languages which most working
programmers regard in the same way as Haskell, LISP, and so
on. Something so strange that they'd rather any thoughts of it
just go away so they can get on with writing this paying code.
But that's wrong and if you care at all about programming then
you should at least understand all these languages, even if
you will never use them.

horst:
FORTH is one of those alien languages which most working
programmers regard in the same way as Haskell, LISP, and so
on. Something so strange that they'd rather any thoughts of it
just go away so they can get on with writing this paying code.
But that's wrong and if you care at all about programming then
you should at understand at least a bit about other languages
than the ubiquitous c, Java or Python.

jones:
LISP is the ultimate high-level language, and features from
LISP are being added every decade to the more common
languages. But FORTH is in some ways the ultimate in low level
programming. Out of the box it lacks features like dynamic
memory management and even strings. In fact, at its primitive
level it lacks even basic concepts like IF-statements and
loops.

horst:
~ LISP is the ultimate lanugages, with unlimited flexibility as
~ long as you're prepared to use round brackets. Forth rivals
that flexibility, as long as you're prepared to separate your
words with spaces. Forth is the ultimate do-it-yourself
language. Even basic concepts like IF-statements and loops
are molded to you liking. Things like dynamic memory
management are an add on. Out of the box it lacks almost
everything.

jones:
Why then would you want to learn FORTH? There are several very
good reasons. First and foremost, FORTH is minimal. You really
can write a complete FORTH in, say, 2000 lines of code. I
don't just mean a FORTH program, I mean a complete FORTH
operating system, environment and language. You could boot
such a FORTH on a bare PC and it would come up with a prompt
where you could start doing useful work. The FORTH you have
here isn't minimal and uses a Linux process as its 'base PC'
(both for the purposes of making it a good tutorial). It's
possible to completely understand the system. Who can say they
completely understand how Linux works, or gcc?

horst:
Why then would you want to learn FORTH? There are several very
good reasons. First and foremost, there is a bright side to
this minimality. Not counting the comment lines you can have
a complete FORTH in 768 lines of code. I don't just mean a
FORTH program, I mean a complete FORTH operating system,
environment and language. You could boot such a FORTH on a
bare PC and it would come up with a prompt where you could
start doing useful work. The FORTH you have here is equally
minimal, as long as you take for granted the Linux environment
where it lives. (requiring you to use a bare pc would not make
for a good tutorial) It's possible to completely understand
the system. Who can say they completely understand how Linux
works, or gcc?

Comments welcome. Trying to make a working jonesforth look alike
today. The text will be more work, I presume.

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
> What do we want? The enticement of jonesforth but
> - ISO compatibility (for all words with an ISO name that is)
> - no words in assembler if Forth is feasible
> - one file, Forth coded in assembler

Is that basically what eforth is?

[Andrew Haley]

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> Remember we discussed jonesforth at the German convention?
> I take up the challenge to make a similar forth.
>
> What do we want? The enticement of jonesforth but
> - ISO compatibility (for all words with an ISO name that is)
> - no words in assembler if Forth is feasible

Erm, why? Are you going to write

: - negate + ;

?

> - one file, Forth coded in assembler

Why?

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> Erm, why? Are you going to write
> : - negate + ;

http://www.calcentral.com/~forth/forth/eforth/e4.src/EFORTH.SHTML has:

: + ( n n -- n ) ( 6.1.0120 )( 0x1E ) UM+ DROP ;
: INVERT ( n -- n ) ( 6.1.1720 )( 0x26 ) D# -1 XOR ;
: NEGATE ( n -- n ) ( 6.1.1910 )( 0x2C ) INVERT D# 1 + ;
: - ( n n -- n ) ( 6.1.0160 )( 0x1F ) NEGATE + ;

UM+, DROP, and XOR are CODE words. I guess D# is a metacompiler primitive.

[Ed]

Paul Rubin wrote:
> ...

> I guess D# is a metacompiler primitive.

D# interprets the next word as a number in base 10.

H# B# do hex and binary respectively.

It's an easy and portable way of getting the forth interpreter to
recognize different classes of number. I use F# in my "finput"
demo to permit interpretation of floating-point numbers.

[Rod Pemberton]

"Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in
message news:51ae2e6d$0$26867$e4fe...@dreader37.news.xs4all.nl...

> Remember we discussed jonesforth at the German convention?

No. Were you there? Oh, sorry, I didn't see you, or Bernd
either... Oh, well, that's because _I_ wasn't there.

> I take up the challenge to make a similar forth.

By "take" did you mean "will take" or "did take"?

> What do we want?

We? You just said it's your challenge... Didn't you?

> What do [I] want? The enticement of jonesforth but

> - ISO compatibility (for all words with an ISO name that is)
> - no words in assembler if Forth is feasible
> - one file, Forth coded in assembler
>

As Paul pointed out, that's basically eForth, if you exclude the
ISO compatibility part, maybe the one file part, ...

As Andrew pointed out, primitives (or low-level words) are needed
to build a system.

Albert, if you really want only a few primitives, you could look
at something like Mikael Patel's 9 or 11 primitive Forth.

https://groups.google.com/d/msg/comp.lang.forth/ESZD4h1prcw/jFXN7dvtCFMJ

IIRC, there are some other minimal Forths buried in the
comp.lang.forth archives too.

There are also many, many definitions for other Forth words hidden
throughout the comp.lang.forth archives.

Although, I've not found a complete ANS wordset for pre-ANS
Forths.

> The last two points are related, jonesforth has a startup
> library in Forth:
>
> cat jonesforth.f - | jonesforth
>
> But this means a whole working interpreter must be present
> and be coded in assembler. This I don't like at all.

You have to have some functionality to build up the system. It's
easier to do that if you use what you have, e.g., if AND, OR, XOR
are supported by your target machine, you'd use them because
they're available. Although, you can define them in terms of
lower level logic, i.e., fewer words. Simiarly, you'll likely use
the native mechanism for KEY and EMIT, etc. If you don't like
assembler, then text hex to binary bytes can be done. What's the
minimum you need? Build the system from those definitions. Once
bootstrapped, for speed, rebuild the system with a different set
of more efficient definitions.


Rod Pemberton

[Mark Wills]

On Jun 4, 7:14 pm, alb...@spenarnc.xs4all.nl (Albert van der Horst)
wrote:

I'd be interested in seeing this. I could help out with English
documentation if required.

I remember that Ting did a lot of work (for years?) on distilling his
Forths down to the very minimum of code words, and having the vast
majority of his Forth systems written in Forth. Was that eForth? I
think it was. Can't remember now.

[Paul Rubin]

Mark Wills <markrob...@yahoo.co.uk> writes:
> I remember that Ting did a lot of work (for years?) on distilling his
> Forths down to the very minimum of code words, and having the vast
> majority of his Forth systems written in Forth. Was that eForth? I
> think it was. Can't remember now.

Ting was involved with FigForth and eForth as I understand it. In both
cases the original versions were metacompiled, and Ting's versions were
released as assembler programs, on the theory that they were easier to
bootstrap that way. Jeff Fox takes Dr. Ting to ask for this, sonewhere
on his (Jeff's) web site. Jeff liked metacompilers.

[Albert van der Horst]

In article <JJWdnUypFu5rby3M...@supernews.com>,

Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
>> Remember we discussed jonesforth at the German convention?
>> I take up the challenge to make a similar forth.
>>
>> What do we want? The enticement of jonesforth but
>> - ISO compatibility (for all words with an ISO name that is)
>> - no words in assembler if Forth is feasible
>
>Erm, why? Are you going to write
>
>: - negate + ;

Hell no! ``-'' translates directly to assembler.
Only fundamentalist take such detours.

>
>?
>
>> - one file, Forth coded in assembler
>
>Why?

Last I wanted to have factor. For that I needed perl and for that I
needed gcc in source. The latter alone amounted to one Gbyte.

In this time and age there is just one reassurement to counter that:
one file
as in "one file no includes excepts as implicit in the assembler system."

like so
>fasm albertjonesmyyoutforth.fas

>albertjonesmyyoutforth
1 2 + .
3 OK

Anyway, it is the starting point.

>
>Andrew.

[Albert van der Horst]

In article <korjrn$pns$1...@speranza.aioe.org>,
Rod Pemberton <do_no...@notemailnotq.cpm> wrote:
<SNIP>

>
>You have to have some functionality to build up the system. It's
>easier to do that if you use what you have, e.g., if AND, OR, XOR
>are supported by your target machine, you'd use them because
>they're available. Although, you can define them in terms of
>lower level logic, i.e., fewer words. Simiarly, you'll likely use
>the native mechanism for KEY and EMIT, etc. If you don't like
>assembler, then text hex to binary bytes can be done. What's the
>minimum you need? Build the system from those definitions. Once
>bootstrapped, for speed, rebuild the system with a different set
>of more efficient definitions.

I think this comment is stupid. The starting point of jonesforth and
its seduction is utmost simplicity. How can you accuse me or jones
of go beating around the bush with Forth high level if a Forth
word translates to one assembler word?

>
>
>Rod Pemberton

Oh yes, and when I say "take" present sense, that means that it is
something I'm doing right now.

[Albert van der Horst]

In article <37cdeb58-1e3d-45fd...@l5g2000vbn.googlegroups.com>,
Mark Wills <markrob...@yahoo.co.uk> wrote:
<SNIP>

>>
>>
>
>I'd be interested in seeing this. I could help out with English
>documentation if required.

Thanks, I'll take you up on that.
Currently I have reduced the generic lina system (12000) lines to about
6000, all the time passing the lina regression test as well as the Hayes test.
(Rid of blocks, user variables, to do: doubles and the likes of ." .( [CHAR] )
But of the literate programming of jones almost nothing has been paraphrased.

>
>I remember that Ting did a lot of work (for years?) on distilling his
>Forths down to the very minimum of code words, and having the vast
>majority of his Forth systems written in Forth. Was that eForth? I
>think it was. Can't remember now.

Tings starting point was easy portability. Jones/albert's starting point is
understandability, if must be at the expense of usability.
As I have explained in other posts, assembler may well be better understandable
than Forth.
So for each word I have to make a decision as Ting did, and none of his
decisions I could take for granted.
My starting point is my own ciforth and for good reason. Jones took ciforth
as a starting point himself, because it was nearest the simplicity goal.

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
> In this time and age there is just one reassurement to counter that:
> one file
> as in "one file no includes excepts as implicit in the assembler system."

But now you need an assembler. Unix systems these days are more likely
to come with Perl than an assembler.

Why not write completely in Forth, and bootstrap with something like
gforth?

> The starting point of jonesforth and its seduction is utmost simplicity.

Well, it was 1) very heavily commented, and 2) started from bare
assembler with no Forthish capabilities at all. For newbies, the
comment density probably mattered more.

[Albert van der Horst]

In article <7xfvwun...@ruckus.brouhaha.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> In this time and age there is just one reassurement to counter that:
>> one file
>> as in "one file no includes excepts as implicit in the assembler system."
>
>But now you need an assembler. Unix systems these days are more likely
>to come with Perl than an assembler.
>
>Why not write completely in Forth, and bootstrap with something like
>gforth?

This is *not* just another "forth-in-assembler".

1 We have gone over this a million times. You can't write '+' "completely"
in Forth.
2 The build process using fasm is so much more simple that it is
almost incredible.
3 We want transparency and simplicity, the feeling of being absolutely
and totally in command, of understanding the very last bit.
gforth is tributary to c-czars, if not held hostage.

This is addressing the people that Jones reached by using the means
that appeal to those people. That may be filling a niche rather than
making the best Forth possible, and then having endless discussions
about what makes the best Forth, as if that doesn't depend.

>
>> The starting point of jonesforth and its seduction is utmost simplicity.
>
>Well, it was 1) very heavily commented, and 2) started from bare
>assembler with no Forthish capabilities at all. For newbies, the
>comment density probably mattered more.

That is not a contradiction. Of course it is about the fact that
jones was a newbie and documented his every step of the way.
What I want is a good starting point for the documentation
by having even a simpler Forth. Then I add some ANSI awareness
such that people can make the step to more serious work with Forth
more easily.

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>Why not write completely in Forth, and bootstrap with something like
>>gforth?

> 1 We have gone over this a million times. You can't write '+' "completely"
> in Forth.

By "completely in Forth" I just mean the traditional way, where the
assembler is written in Forth and is part of the Forth system, and it's
bootstrapped from another Forth. Then you write + as a CODE word, in Forth.

> 2 The build process using fasm is so much more simple that it is
> almost incredible.

$ fasm
bash: fasm: command not found...
$ sudo yum install fasm
...
No package fasm available.

> gforth is tributary to c-czars, if not held hostage.

What about fasm? Not the same? Gforth and C are at least available in
most Linux distros.

OK, I just found fasm online (http://flatassembler.net/) and it's
written in itself, which means you may have to start with a binary, or
else port it to some other assembler, i.e. now your Forth depends on two
assemblers.

> 3 We want transparency and simplicity, the feeling of being absolutely
> and totally in command, of understanding the very last bit.

I'd certainly expect a self-hosted Forth to achieve that better than one
dependent on an external assembler, once the bootstrap phase is
completed. It may even be ok to bootstrap from something like Python.

I don't claim to have examined every detail of eforth, but I was
impressed by the readability of the parts that I looked at. It helped
that it was Forth with very little assembler.

[Rod Pemberton]

"Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in

message news:51b1f122$0$6358$e4fe...@dreader35.news.xs4all.nl...

> In article <korjrn$pns$1...@speranza.aioe.org>,
> Rod Pemberton <do_no...@notemailnotq.cpm> wrote:
<SNIP>

> >
> >You have to have some functionality to build up the system.
> > It's easier to do that if you use what you have, e.g., if AND,
> > OR, XOR are supported by your target machine, you'd use
> > them because they're available. Although, you can define
> > them in terms of lower level logic, i.e., fewer words.
> > Simiarly, you'll likely use the native mechanism for KEY
> > and EMIT, etc. If you don't like assembler, then text hex to
> > binary bytes can be done. What's the minimum you need?
> > Build the system from those definitions. Once bootstrapped,
> > for speed, rebuild the system with a different set of more
> > efficient definitions.
>
> I think this comment is stupid.

Well, that's how it's done, or has been, numerous times.

That's also what you described in your own list...

You also stated that you intend to to do the same thing in your
reply to Andrew:
AvdH: "Hell no! ``-'' translates directly to assembler."

It's also what you state you intend to do in your reply to Paul:
AvdH: "You can't write '+' 'completely' in Forth."

Perhaps, you should indicate what exactly you thought was
"stupid".

You should already know you need 30 to 55 code words or
'primitives' for a useable Forth-in-Forth, but can get by with
fewer. The rest can be written in Forth.

That's what C.H. Ting's eForth did (36 primitives). That's also
what Mark Hays MRForth (23) did, 8086 GForth (46) did, Chris
Jakeman's MAF (48) did, etc. Brad Rodriquez of the Moving Forth
series says 13 is the minimum to bootstrap a Forth. Mark Hays of
MRForth says 9 is. Paul Stevens says 4 is.

Yes, you can write '+' 'completely' in Forth, it just won't be
without using some 'primitives' or code words (or low-level words)
at some level. In the link I posted, Mikael defines '+' in terms
of a whole bunch of stuff including 1+ 1- and SWAP. In another
Forth I saw '+' was defined in terms of NAND and NOR. Of course,
1+ 1- or NAND NOR would be code words or 'primitives'.

Are you bipolar or manic depressive? You say one thing, then
contradict my statements which supported you and help with just
that.

> The starting point of jonesforth and its seduction is utmost
> simplicity.

Yet, you just criticized my explanation of utmost simplicity
above. Yet, you just criticized jonesforth. And, you seem to be
ignoring all comments on eForth.

> How can you accuse me or jones of go beating around the
> bush with Forth high level if a Forth word translates to one
> assembler word?

I didn't. That was Andrew... But, he was just pointing out that
you need some functionality to build from, which you must agree
with since you're going to code '+' in assembly.


Rod Pemberton

[Rod Pemberton]

"Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in
message news:51b212a5$0$620$e4fe...@dreader34.news.xs4all.nl...

> What I want is a good starting point for the documentation
> by having even a simpler Forth.

I just posted a link to an "even simpler Forth". What was wrong
with it? You can implement '+' as code if you wish instead of
the convoluted code there....

What's wrong with eForth for that matter? What is wrong the
half-dozen or so other Forths that start with 30 to 55 code words
(or primitives or low-level words)?


Rod Pemberton

[Andrew Haley]

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> In article <JJWdnUypFu5rby3M...@supernews.com>,
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
>>
>>> - one file, Forth coded in assembler
>>
>>Why?
>
> Last I wanted to have factor. For that I needed perl and for that I
> needed gcc in source. The latter alone amounted to one Gbyte.

So why not write it in Forth? Assembler was the fig-FORTH way of doing
it back when the internet didn't exist and people typed in listings.
Writing Forth in assembler today makes no sense whatsoever.

Andrew.

[Albert van der Horst]

In article <kotirp$9k8$1...@speranza.aioe.org>,

Okay, now take a very careful read of jonesforth and ask yourself why
a professor asks his students to make a modification of that particular
Forth, while c.l.f is complaining that Forth is banned from the academia.

>
>
>Rod Pemberton

[Albert van der Horst]

In article <kotir2$9j1$1...@speranza.aioe.org>,

Rod Pemberton <do_no...@notemailnotq.cpm> wrote:
>
>Perhaps, you should indicate what exactly you thought was
>"stupid".
>
>You should already know you need 30 to 55 code words or
>'primitives' for a useable Forth-in-Forth, but can get by with
>fewer. The rest can be written in Forth.

That is stupid: thinking that it is easier to understand or
'simpler' because it contains less assembler words.


>Rod Pemberton

[Bernd Paysan]

Albert van der Horst wrote:

> In article <kotir2$9j1$1...@speranza.aioe.org>,
> Rod Pemberton <do_no...@notemailnotq.cpm> wrote:
>>
>>Perhaps, you should indicate what exactly you thought was
>>"stupid".
>>
>>You should already know you need 30 to 55 code words or
>>'primitives' for a useable Forth-in-Forth, but can get by with
>>fewer. The rest can be written in Forth.
>
> That is stupid: thinking that it is easier to understand or
> 'simpler' because it contains less assembler words.

The idea of JonesForth (or the JonesForth approach) as a teaching tool is
the bottom-up idea. You start where your audiance is, which is much more
likely x86 assembler than Forth. And then you build up knowledge; slowly.
First, how the primitives work. And then how high-level Forth works. How
it works, and what it does; for the "how it works", the assembler notation
is helpful.

A Forth system that lifts itself has a bootstrap problem; but that can be
overcome by using another Forth for a start. However, a Forth system that
lifts itself has a teaching bootstrap problem. Which is why there was the
commented figForth listing and "Inside F83".

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> The idea of JonesForth (or the JonesForth approach) as a teaching tool is
> the bottom-up idea. You start where your audiance is, which is much more
> likely x86 assembler than Forth.

30 years ago in the Figforth era, that may have been so. Who knows
anything about assembler now? Who even cares about the x86? The AVR
(as in Arduino) or ARM or other similar cpus are all more plausible as
Forth targets than the x86.

Macro Spitbol has an interesting approach: it's written in abstract
assembly language that gets transliterated by a Spitbol program into asm
code for specific machines. See:

https://github.com/hardbol/spitbol/blob/master/minimal-reference-manual.html

[Lars Brinkhoff]

Bernd Paysan wrote:
> The idea of JonesForth (or the JonesForth approach) as a teaching
> tool is the bottom-up idea. You start where your audiance is, which
> is much more likely x86 assembler than Forth. And then you build up
> knowledge; slowly.
>

> A Forth system that lifts itself has a bootstrap problem; but that
> can be overcome by using another Forth for a start. However, a
> Forth system that lifts itself has a teaching bootstrap problem.

Then how about this:

1. Start by cleaning up Jonesforth.
2. Add an assembler. Explain the beauty of Forth assemblers.
3. Add a metacompiler. This could be a mind-warping lesson.
4. Rebuild itself; now self-hosting.

[m...@iae.nl]

On Saturday, June 8, 2013 7:29:02 AM UTC+2, Lars Brinkhoff wrote:
> Bernd Paysan wrote:
>
> > The idea of JonesForth (or the JonesForth approach) as a teaching
> > tool is the bottom-up idea. You start where your audiance is, which
> > is much more likely x86 assembler than Forth. And then you build up
> > knowledge; slowly.
> >

[..]

> Then how about this:
>
> 1. Start by cleaning up Jonesforth.
>
> 2. Add an assembler. Explain the beauty of Forth assemblers.

> 3. Add a metacompiler. This could be a mind-warping lesson.

> 4. Rebuild itself; now self-hosting.

Great idea!

1) is easy.

2) Proves to be so small that a real assembler isn't needed.
You could use C, and , (with comments) or use a trick with
a pipe/socket/file to fasm or whatever other assembler.

Use http://www.calcentral.com/~forth/forth/
(Bill Muench's e-forth site) for 3) and 4), really beautiful
code!

-marcel

[Paul Rubin]

Lars Brinkhoff <lars...@nocrew.org> writes:
> 1. Start by cleaning up Jonesforth.
> 2. Add an assembler. Explain the beauty of Forth assemblers.
> 3. Add a metacompiler. This could be a mind-warping lesson.
> 4. Rebuild itself; now self-hosting.

You probably understand this stuff better than me, but I thought
Jonesforth's approach was the opposite of the metacompilation approach.
Jonesforth starts with nothing but assembler, and builds up Forth one
little bit at a time; while metacompilation starts with a fully working
Forth, which it uses to build another one, normally from the same code.

[Lars Brinkhoff]

Paul Rubin wrote:

I don't claim any expertise. I assumed that the intent was to provide
a updated Jonesforth using modern Froth implementation techniques
while still retaining most of its newbie-friendly pedagogical properties.
So my (somewhat obvious) idea was to boostrap with the current
assembly listing approach, and then switch into the everything-in-Forth
mindset.

I'm not sure this was what Albert had in mind.

[Albert van der Horst]

This has been said before, but seldomly so clear.

>
>--
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://bernd-paysan.de/
>

[Albert van der Horst]

In article <85vc5p2...@junk.nocrew.org>,

Lars Brinkhoff <lars...@nocrew.org> wrote:
>Bernd Paysan wrote:
>> The idea of JonesForth (or the JonesForth approach) as a teaching
>> tool is the bottom-up idea. You start where your audiance is, which
>> is much more likely x86 assembler than Forth. And then you build up
>> knowledge; slowly.
>>
>> A Forth system that lifts itself has a bootstrap problem; but that
>> can be overcome by using another Forth for a start. However, a
>> Forth system that lifts itself has a teaching bootstrap problem.
>
>Then how about this:
>
>1. Start by cleaning up Jonesforth.

Bad idea. jonesforth is a toy and you can't base serious
production work on it, even after cleaning up.

>2. Add an assembler. Explain the beauty of Forth assemblers.
>3. Add a metacompiler. This could be a mind-warping lesson.
>4. Rebuild itself; now self-hosting.

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:

>>A Forth system that lifts itself has a bootstrap problem; but that can be
>>overcome by using another Forth for a start. However, a Forth system that
>>lifts itself has a teaching bootstrap problem. Which is why there was the
>>commented figForth listing and "Inside F83".
> This has been said before, but seldomly so clear.

Inside F83 was a great book but I thought it was mostly about F83's
OS-like features, which were pretty cool. I always wonder what it was
like to see F83 in actual use. I might try it myself sometime, if I can
set up or emulate suitable hardware.

I think the clarity of Jonesforth and F83 came from their extensive
comments, and not because they were in assembler. There's a style of
Forth programming that really avoids comments, and that's kind of
unhelpful. A metacompiled Forth with enough comments would IMHO be more
readable than something that used a lot of assembly code and boostrapped
from zero. Jonesforth did contorted things because it didn't have a
full Forth available in its early stages..

[m...@iae.nl]

On Saturday, June 8, 2013 8:17:46 AM UTC+2, m...@iae.nl wrote:

> Use http://www.calcentral.com/~forth/forth/
> (Bill Muench's e-forth site) for 3) and 4), really beautiful
> code!

About 25 changes are needed to let the metacompiler
build on iForth. It should be less on JonesForth.

Compare: (<)C:\dfwforth\examples\eforth\emeta.frt
with: (>)C:\dfwforth\examples\eforth\EMETA.X86

5,18d5
< -- needed for iForth -------
< ANEW -emeta
< VARIABLE BREAK?
< : PARSE-WORD ( -- a u ) BL WORD COUNT ;
<
< ALSO ASSEMBLER DEFINITIONS
< : jmp CR ." jmp at " H. ;
< VARIABLE 'C@
< VARIABLE 'C!
< VARIABLE 'C,
< VARIABLE 'HERE
< PREVIOUS DEFINITIONS
< -- -------------------------
<
46,47c32
< \ *** iForth : ROOT ( -- ) FORTH-WORDLIST DUP 2 SET-ORDER DEFINITIONS ;
< : ROOT ( -- ) ONLY FORTH ALSO DEFINITIONS ;
---
> : ROOT ( -- ) FORTH-WORDLIST DUP 2 SET-ORDER DEFINITIONS ;
56a41,42
> \ : PARSE-WORD ( -- a u ) BL WORD COUNT ;
>
73c60
< : >IMAGE ( a -- d ) #IMAGE @ OVER U< IF S" image" SERR THEN ISEG @ + ;
---
> : >IMAGE ( a -- d ) #IMAGE @ OVER U< IF S" image" SERR THEN ISEG @ ;
77,78c64,65
< IF R@ ALLOCATE IF S" seg alloc" SERR THEN
< DUP ISEG ! R> [CHAR] b ( a s u c ) FILL EXIT
---
> IF R@ 0 16 UM/MOD NIP alloc IF S" seg alloc" SERR THEN
> DUP ISEG ! R> [CHAR] b ( a s u c ) LFILL EXIT
82,86c69,81
< S" eforth.com" 2DUP R/W BIN CREATE-FILE THROW ( handle) >R
< ISEG @ #IMAGE @ R@ WRITE-FILE THROW
< R> CLOSE-FILE THROW ;
<
< : ENDIAN ( n -- n ) ;
---
> ACTIVE @ ( save current file id )
> S" EFORTH.COM" 2DUP 0 ( normal ) CREATE-FILE ?DOS hHCB
> H# 100 ( offset for .COM file )
> #IMAGE @ OVER - ISEG @ LONG! WRITE CLOSE
> ACTIVE ! ( restore open file if any ) ;
>
> VARIABLE 'ENDIAN
> : ENDIAN ( n -- n ) 'ENDIAN @EXECUTE ;
> : ?ENDIAN ( -- ) ( check host byte order )
> BASE C@
> IF ['] NOOP ( little endian )
> ELSE ['] FLIP ( big endian )
> THEN 'ENDIAN ! ;
90,91c85,86
< VOCABULARY TARGET
< ' TARGET >BODY CONSTANT TARGET-WORDLIST
---
> WORDLIST CONSTANT TARGET-WORDLIST
> TARGET-WORDLIST >VOC TARGET
95,96c90,91
< VOCABULARY INSIDE
< ' INSIDE >BODY CONSTANT INSIDE-WORDLIST
---
> WORDLIST CONSTANT INSIDE-WORDLIST
> INSIDE-WORDLIST >VOC INSIDE
104,105c99,100
< VOCABULARY OUTSIDE
< ' OUTSIDE >BODY CONSTANT OUTSIDE-WORDLIST
---
> WORDLIST CONSTANT OUTSIDE-WORDLIST
> OUTSIDE-WORDLIST >VOC OUTSIDE
143,144c138,139
< :O C@ ( a -- c ) >IMAGE C@ ;O
< :O C! ( c a -- ) >IMAGE C! ;O
---
> :O C@ ( a -- c ) >IMAGE LC@ ;O
> :O C! ( c a -- ) >IMAGE LC! ;O
148,152c143,147
< :O @ ( a -- n ) >IMAGE @ ENDIAN ;O
< :O ! ( n a -- ) SWAP ENDIAN SWAP >IMAGE ! ;O
< :O , ( n -- ) [O] HERE 1 [O] CELLS [O] ALLOT [O] ! ;O
<
< : MOVE-C ( a a n -- ) >R >IMAGE R> CMOVE ;
---
> :O @ ( a -- n ) >IMAGE L@ ENDIAN ;O
> :O ! ( n a -- ) SWAP ENDIAN SWAP >IMAGE L! ;O
> :O , ( n -- ) [O] HERE 1 [O] CELLS [O] ALLOT [O] ! ;O
>
> : MOVE-C ( a a n -- ) >R CS0 SWAP >IMAGE R> LCMOVE ;
247c242
< ALSO ASSEMBLER
---
> ALSO ASM86
255c250
< : TASM ( -- ) ALSO ASSEMBLER ;
---
> : TASM ( -- ) ALSO ASM86 !ASM ;
301,302c296,297
< 0 [O] ORG
< DECIMAL !CSP-T [I] [ ;
---
> H# 0 [O] ORG
> DECIMAL ?ENDIAN !CSP-T [I] [ ;

[Anton Ertl]

Lars Brinkhoff <lars...@nocrew.org> writes:

>Paul Rubin wrote:
>> You probably understand this stuff better than me, but I thought
>> Jonesforth's approach was the opposite of the metacompilation
>> approach. Jonesforth starts with nothing but assembler, and builds
>> up Forth one little bit at a time; while metacompilation starts with
>> a fully working Forth, which it uses to build another one, normally
>> from the same code.
>
>I don't claim any expertise. I assumed that the intent was to provide
>a updated Jonesforth using modern Froth implementation techniques
>while still retaining most of its newbie-friendly pedagogical properties.

I think the intent is to provide a standard Forth that uses the same
pedagogical approach as JonesForth. JonesForth was criticised because
it just implements some words with standard names and non-standard
meaning, which is probably very confusing when people switch from
JonesForth to a standard Forth.

>So my (somewhat obvious) idea was to boostrap with the current
>assembly listing approach, and then switch into the everything-in-Forth
>mindset.

The in-assembly-language approach was another criticism of JonesForth.
But I think that it is the best approach for doing what JonesForth
does, and JonesForth's success supports this. But if you think that
the secret is just in the extensiveness of the comments, a way to
prove that would be to do what you suggest and see if your version
becomes more popular than the original.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/

[Lars Brinkhoff]

Anton Ertl writes:
> I think the intent is to provide a standard Forth that uses the same
> pedagogical approach as JonesForth.

Oh, never min dthen.

> But if you think that the secret is just in the extensiveness of the
> comments, a way to prove that would be to do what you suggest

I read through Jonesforth some time ago, and thought it was quite
pleasant. I found myself quite willing to overlook the various
idiosyncrasities. So no, I'm not particularly intersted in this
challenge.

However: TELL instead of TYPE, what's up with that?

[Lars Brinkhoff]

> I think the intent is to provide a standard Forth that uses the same
> pedagogical approach as JonesForth. JonesForth was criticised because
> it just implements some words with standard names and non-standard
> meaning, which is probably very confusing when people switch from
> JonesForth to a standard Forth.

Mission accomplished?

"I've already modified Jonesforth (v45) to be ANS-compliant at the
CORE level (including CREATE...DOES>). My version fully passes the
Hayes CORE tests, the COREPLUS tests and those CORE EXT tests that are
relevant (i.e. for words that are implemented)."

http://www.rtr.myzen.co.uk/bb4wforth.zip

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
>
> I think the clarity of Jonesforth and F83 came from their extensive
> comments, and not because they were in assembler. There's a style of
> Forth programming that really avoids comments, and that's kind of
> unhelpful. A metacompiled Forth with enough comments would IMHO be more
> readable than something that used a lot of assembly code and boostrapped
> from zero. Jonesforth did contorted things because it didn't have a
> full Forth available in its early stages..

I think so. I remember a few years back when I added DOES> to
jonesforth, and it was a real PITA to do because there was no way to
test anything written in assembler without rebuilding the whole
system. It was also hard to figure out where stuff was supposed to
go, and you had to build dictionary enties explicitly. Argh!

Andrew.

[Bill Richards]

I was going to say yeah! but then I see you have to fork over 50 bucks to
buy bbc basic for windows if the site that sells it ever comes back
online. Seems like it would have been a neat project but why oh why did you
do that on a system that requires people to pay money and only runs on
Windows?

Bill

[Bill Richards]

On 2013-06-07, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> Currently I have reduced the generic lina system (12000) lines to about
> 6000, all the time passing the lina regression test as well as the Hayes test.
> (Rid of blocks, user variables, to do: doubles and the likes of ." .( [CHAR] )
> But of the literate programming of jones almost nothing has been paraphrased.
>
>>
>>I remember that Ting did a lot of work (for years?) on distilling his
>>Forths down to the very minimum of code words, and having the vast
>>majority of his Forth systems written in Forth. Was that eForth? I
>>think it was. Can't remember now.
>
> Tings starting point was easy portability. Jones/albert's starting point is
> understandability, if must be at the expense of usability.
> As I have explained in other posts, assembler may well be better understandable
> than Forth.
> So for each word I have to make a decision as Ting did, and none of his
> decisions I could take for granted.
> My starting point is my own ciforth and for good reason. Jones took ciforth
> as a starting point himself, because it was nearest the simplicity goal.
>
> Groetjes Albert

I agree with this and would love to see something updated to a standard
Forth. I tried Jones a few years ago and the first Forth word I tried using
with it didn't work but it did on other Forths I had so I gave up on
Jones. The ideas and explanations in Jones would help a lot of people get
started but as you said it seems to be a wolf in sheeps clothing and once
you do get it built it's not actually standard Forth and wouldn't be
something you could use from then on.

Please keep on with this project!

Thanks,

Bill

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> In this time and age there is just one reassurement to counter that:
>> one file
>> as in "one file no includes excepts as implicit in the assembler system."
>
>But now you need an assembler. Unix systems these days are more likely
>to come with Perl than an assembler.

Most Unix systems these days use GCC as C compiler, and GCC does not
work without an assembler. Maybe more people have Perl installed than
GCC; popcon says: 151316 (99.63%) have perl installed, 111503 (73.42%)
have binutils installed.

So, if JonesForth was about ease of installation, basing it on Perl
would be better than basing it on assembly language. But it's about
learning and understanding, and starting from the bottom up; that is a
good approach in my experience*. If you start with assembly language,
you learn a number of concepts useful for Forth, and you will
appreciate the benefits Forth gives; if you start with Perl, why build
or use Forth?

>Why not write completely in Forth, and bootstrap with something like
>gforth?

Gforth has a much smaller installed base than assembler; but more
importantly, this requires to understand using Forth first, and then
understanding meta-compilation in addition.

While learning to "use Forth" first is the approach advocated by
Elizabeth Rather, Forth has always been an interesting language for
those who want to understand how to implement it. And if you approach
Forth from that direction, then the JonesForth approach is the way to
go.

Sure, once they understand it, they notice that the assembly form is
not the most flexible source form for Forth, and will arrive at the
idea of meta-compilation themselves. But for most doing all of this
in one step is too big a leap.

*) My "Introduction to Computer Science" course was great, and it
started with transistors, went through ALUs to assembly language, then
higher-level languages and operating systems.

[Bill Richards]

On 2013-06-11, Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

> So, if JonesForth was about ease of installation, basing it on Perl
> would be better than basing it on assembly language. But it's about
> learning and understanding, and starting from the bottom up; that is a
> good approach in my experience*. If you start with assembly language,
> you learn a number of concepts useful for Forth, and you will
> appreciate the benefits Forth gives; if you start with Perl, why build
> or use Forth?

Indeed. If you start with Perl you'll put off anyone who might have been
interested from ever looking at Forth again ;-)

> *) My "Introduction to Computer Science" course was great, and it
> started with transistors, went through ALUs to assembly language, then
> higher-level languages and operating systems.

The problem now on Intel is the significant ABI difference between 32 and 64
bit. And then there's the issue of gcc vs. Intel vs. MASM etc. Even assembly
language isn't a simple matter. And then if you don't use libc there's the
issue of which syscalls you use and it won't be portable across the range of
Linux/UNIX/Windows.

32 bit Linux as it was first presented is probably still the best choice
although I think most people prefer the human-looking Intel syntax over the
machine readable "gas" syntax.

Bill

[Bernd Paysan]

Anton Ertl wrote:
> Sure, once they understand it, they notice that the assembly form is
> not the most flexible source form for Forth, and will arrive at the
> idea of meta-compilation themselves. But for most doing all of this
> in one step is too big a leap.

Jens once added an "output as assembler" mode to Gforth's cross compiler.
This approach could make a JonesForth-like system maintainable for the
people who write it (you want to write the high-level and the headers in
Forth). It needs a way to pass the comments through, as well, and it quite
likely doesn't need all the features a cross compiler normally needs.

The big advantge of the bottom-up teaching style is that there never is a
magic "we will explain this later" component. You can easily write an
"Introduction to Computer Science" where you go to a Forth CPU instead of
assembler.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> The big advantge of the bottom-up teaching style is that there never is a
> magic "we will explain this later" component.

I don't understand this desire. There is "explain later" in every
learning process, about everyting in life. Before most people learn how
to drive a car, they usually first ride in one driven by someone else.
And before they learn how to fix a car, they first learn how to drive
it. And before they learn about the details of machining internal
combustion engines from blocks of iron, they first learn basic repairs
like changing the spark plugs. And before they deal with the partial
differential equations describing the fuel-air flame front in the
cylinders after the spark plug fires, they first hear about the Otto
cycle that runs the engine. And before they study the quantum mechanics
that explains combusion, they first learn that gasoline burns when you
apply a spark. And before they study superstrings or quarks or the
fundamental physics theory du jour, they first hear about the
Schroedinger equation, and Newton's laws before that. You get the idea.
High level first. So I found JSForth and eForth much more enlightening
than JonesForth. That seems perfectly natural to me.

[Gerry Jackson]

Yes but learning a skill is achieved bottom-up, learn the basics before
moving on to more complex things. Isn't that what JonesForth does.

Other examples of building a Forth or Forth-like system from a low level
are:

http://www.rano.org/bcompiler.html which starts from a lower level than
assembler

http://www.ioccc.org/1992/buzzard.2.design which starts from a simple VM
written in C. You can find the obfuscated version of the VM, as well as
other files in the same directory (see the buzzard.2.README). A readable
version of the VM can be found at
http://www.japanisshinto.com/stuff/buzzard.2.c

Surely both the bottom-up and top-down approaches are instructive.

--
Gerry

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Most Unix systems these days use GCC as C compiler, and GCC does not
> work without an assembler.

And the GAS assembler is written in C, so we're going around in circles.
A bottom-up understanding of Forth written in GAS now has to include
understanding C.

> If you start with assembly language, you learn a number of concepts
> useful for Forth, and you will appreciate the benefits Forth gives;

Is this not also gained by writing the assembler in Forth, and using it
as needed?

> if you start with Perl, why build or use Forth?

To run in targets that can't support Perl, or if Perl is too slow, etc.
I'm still not persuaded that using Forth makes much sense in situations
where Perl is an option. (I wouldn't use Perl myself, but if Perl is an
option, then Python etc. are probably also options, and I'd use one of
them).

> Gforth has a much smaller installed base than assembler; but more
> importantly, this requires to understand using Forth first, and then
> understanding meta-compilation in addition.

I guess I still don't understand this. Eforth has a few dozen CODE
words, logically sepraated from each other, and most of them just a few
instructions long. Surely the assembly aspect of that is easier to
understand than a complex monolithic assembler program with a lot of
interrelated moving parts.

> Forth has always been an interesting language for those who want to
> understand how to implement it. And if you approach Forth from that
> direction, then the JonesForth approach is the way to go.

But, metacompilation is (IMHO) one of the main features that makes Forth
implementation interesting. Understanding what it was about was an
eye-opening moment.

> Sure, once they understand it, they notice that the assembly form is
> not the most flexible source form for Forth, and will arrive at the
> idea of meta-compilation themselves. But for most doing all of this
> in one step is too big a leap.

Something seems unique about Forth then. For almost any other language
L, it's very typical for L to be implemented in in L plus a little bit
of low-level assistance. So GCC is written in C, GHC is written in
Haskell, MLton is written in Standard ML, Lisp is usually written in
Lisp, Python is finally being rewritten in Python (PyPy)--why would
Forth be written in anything but Forth?

> *) My "Introduction to Computer Science" course was great, and it
> started with transistors, went through ALUs to assembly language, then
> higher-level languages and operating systems.

I'm glad you liked it. I haven't had personal experience with such an
approach so I can't say empirically that it's non-optimal. But why
start with transistors instead of even lower level, like with charge
carriers, or with tubes that can be explained in terms of electrostatics
and magnets? I think most people learn some mathematics (at the level
of knowing what functions are, and maybe vectors) before they start
programming, so approaches that start with mathematical concepts seem
pretty natural. And in fact the SICP approach (based on Scheme) was
quite successful when it was in vogue.

[Paul Rubin]

Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
> Surely both the bottom-up and top-down approaches are instructive.

True.

[Mark Wills]

On Tuesday, June 11, 2013 6:33:04 PM UTC+1, Paul Rubin wrote:
> I don't understand this desire. There is "explain later" in every
> learning process, about everyting in life. Before most people learn how
> to drive a car, they usually first ride in one driven by someone else.
> And before they learn how to fix a car, they first learn how to drive
> it. And before they learn about the details of machining internal
> combustion engines from blocks of iron, they first learn basic repairs

> like hanging the spark plugs. And before they deal with the partial

> differential equations describing the fuel-air flame front in the
> cylinders after the spark plug fires, they first hear about the Otto
> cycle that runs the engine. And before they study the quantum mechanics
> that explains combusion, they first learn that gasoline burns when you
> apply a spark. And before they study superstrings or quarks or the
> fundamental physics theory du jour, they first hear about the
> Schroedinger equation, and Newton's laws before that. You get the idea.
> High level first. So I found JSForth and eForth much more enlightening
> than JonesForth. That seems perfectly natural to me.

Nah. Jones Forth all the way for me. To be honest, I wasn't that interested in the assembly code, and using macro's for the dictionary headers was unwanted obfuscation.

It was *purely* the comments and commentary that accompanied the code. When I read that, *everything* fell into place for me, in terms of *how* a Forth interpreter and compiler work.

Bloody brilliant.

[Andrew Haley]

Bill Richards <bill...@gmx.com> wrote:
>
> 32 bit Linux as it was first presented is probably still the best choice
> although I think most people prefer the human-looking Intel syntax over the
> machine readable "gas" syntax.

Eh? Heavens, no! And BTW, it's AT&T UNIX syntax; nothing to do with
GNU as, which implements it for compatibility.

Andrew.

[Bill Richards]

Yes, yes, we know. The UNIX snobs at AT&T knew better than Intel. After all
Intel only designed the chips and wrote the first assemblers blah blah blah.
Whatever the UNIX snobs used on their PDP *must* be the way to go on Intel
especially now that PDPs are all but gone and Intel's been the leading
desktop arch for the last thirty years or so.

GNU as and compatibility? With what? Itself? Yes, it was designed (loosely)
to process the output of their C compiler not for humans to write code
in. It's the worst of all known x86 assemblers. Nobody should use it as an
example for anything except what not to do when it comes to designing an
assembler...

Bill

[Albert van der Horst]

In article <jvGdnW-R26tN7yXM...@supernews.com>,

Intel deviates from the convention in assemblers with its destination
source order in operands. It is the first time I hear some one refer to
that as human.
It may be a great pain for us who switch between assemblers all the time,
but it is firmly entrenched in the Intel world. An educational Forth in
assembler has no choice but to use the Intel order.
Even if I were to use gas for lina/jones I would require the Intel order,
which is accomodated by gas for some time now.
(Around 2000 I had this terrible sed script to reverse the order of operands
from my generic source to generate gas assembly code. What a relief to be
able to scrap that!)

>
>Andrew.

[Albert van der Horst]

In article <51ae2e6d$0$26867$e4fe...@dreader37.news.xs4all.nl>,

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:

>Remember we discussed jonesforth at the German convention?
>I take up the challenge to make a similar forth.
<SNIP>

Some progress has been made.

This is a snippet from my logboek 2013 jun 12

The lina/jones Forth is a decendant of my ci86.gnr, i.e.
it contains documentation and tests. jones.cfg is a configuration
file like lina64.cfg and directs the generation of an assembler file.

I'm down to 260 words among them 68 code words, and 5000 commented lines.

I kept the tests up to date such that the lina/jones now passes three
tests:
1. Hayes, with a preambule
2. single precision Hayes
3. tests generated from ci86.gnr by the build system.
I've removed the booting, windows, windows dpmi, mSDOS, OSX
conditional code from ci86.gnr, and with additional trimming
it is down to less than 5000 lines. This includes a reference
manual, the white box tests and none of jones-like educational material.

The preambule test guarantees that lina/jones can be expanded
to a fairly good ISO Forth, at least to the point that someone
using it that way, doesn't develop bad habits.
(Well, using string denotations ( "AAP" instead of S" AAP" C" AAP"
." AAP" .( AAP) may be considered a bad habit. Then put
'" HIDDEN
in the preambule. Attention to this is drawn in a separate document
about "I like Forth, now what?".)

I've made a single precision Hayes test, to replace the Hayes
test. This test must be passed with no preambules.

This test driven development pays off. Some really small changes
triggered large test failings. I've 26 versions that all pass
the tests stored with them.
The great advantage of this approach is that I've something that
works, even if I stop right now.

In the educational section:
The only multiplication words are UM* and UM/MOD and probably SM/REM.
These are the only things involving doubles, and the
only reason is to be able to input and output unsigned singles.
The <# formatting is replaced by <% single formatting.

This is a pretty full Forth still. With a small preambule
it passes the Hayes test. I'm not sure whether I'll keep this
up. This requires keeping some nasty multiplication assembler
in the kernel as the preambule is in Forth.

The following words are candidates for removal from version 6.26.
Prefixes: A B C D E F
Normal: 2! 2@ D+ C/L VOC-LINK U< ?DUP 1+ BODY> (;) (;CODE)
COUNT ." .( ERASE (FIND) [COMPILE] POSTPONE M* SM/REM
XOS5 CREATE-FILE DELETE-FILE REPOSITION-FILE KEY KEY?
TERMIO SET-TERM ?
Looping: DO LOOP +LOOP I J

The following control stuff is never used in the kernel
and could be had via INCLUDE, or EVALUATE of a large
string.
(BACK BACK) (FORWARD FORWARD) BEGIN THEN UNTIL AGAIN
REPEAT IF ELSE WHILE
DOES>

A SAVE-SYSTEM in an included facility would convince the
reader that even if lina/jones is a toy, a Forth based on
similar principles is not.

linajones has the elegant small interpreter with one loop-construct
and one if-then-else construct.

[Bill Richards]

On 2013-06-12, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> In article <jvGdnW-R26tN7yXM...@supernews.com>,
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>Bill Richards <bill...@gmx.com> wrote:
>>>
>>> 32 bit Linux as it was first presented is probably still the best choice
>>> although I think most people prefer the human-looking Intel syntax over the
>>> machine readable "gas" syntax.
>>
>>Eh? Heavens, no! And BTW, it's AT&T UNIX syntax; nothing to do with
>>GNU as, which implements it for compatibility.
>
> Intel deviates from the convention in assemblers with its destination
> source order in operands.

There is no such convention. And as you would expect a correct and useful
assembler exposes the ISA it was designed to run on. Intel's encoding is
reflected in the choice of op dest, src. Why anyone would intentionally
bass-ackwards an assembler is hard to figure. For once Microsoft seems to
have done the right thing as well ;-)

> It is the first time I hear some one refer to that as human.

If you want to be isolated from the chip you're working on then by all
means, the AT&T/gnu "compatability" syntax helps quite a bit. Otherwise
Intel ought to know what they're doing when it comes to writing assemblers
and assembly language for their chips don't you think?

Bill

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Most Unix systems these days use GCC as C compiler, and GCC does not
>> work without an assembler.
>
>And the GAS assembler is written in C, so we're going around in circles.
>A bottom-up understanding of Forth written in GAS now has to include
>understanding C.

Jeff Fox's second coming?

No, that's not necessary, because the goal is to understand the
implementation of Forth, not the implementation of the assembler.
This approach takes the "mere user" attitude towards assembly
language, but the implementor attitude towards Forth.

>> If you start with assembly language, you learn a number of concepts
>> useful for Forth, and you will appreciate the benefits Forth gives;
>
>Is this not also gained by writing the assembler in Forth, and using it
>as needed?

If you present an assembler written in Forth, you take the implementor
attitude towards assembler and the "mere user" attitude towards Forth.

>> Gforth has a much smaller installed base than assembler; but more
>> importantly, this requires to understand using Forth first, and then
>> understanding meta-compilation in addition.
>
>I guess I still don't understand this. Eforth has a few dozen CODE
>words, logically sepraated from each other, and most of them just a few
>instructions long. Surely the assembly aspect of that is easier to
>understand than a complex monolithic assembler program with a lot of
>interrelated moving parts.

CODE performs quite a bit of magic, in particular building dictionary
entries, that is explicit in assmbly language. For modification
automagics is better, for first understanding explicit is better.

>> Sure, once they understand it, they notice that the assembly form is
>> not the most flexible source form for Forth, and will arrive at the
>> idea of meta-compilation themselves. But for most doing all of this
>> in one step is too big a leap.
>
>Something seems unique about Forth then. For almost any other language
>L, it's very typical for L to be implemented in in L plus a little bit
>of low-level assistance. So GCC is written in C, GHC is written in
>Haskell, MLton is written in Standard ML, Lisp is usually written in
>Lisp, Python is finally being rewritten in Python (PyPy)--why would
>Forth be written in anything but Forth?

The unique thing about Forth is that a significant number of people
don't go through the "mere user" stage before being interested in the
implementation.

>> *) My "Introduction to Computer Science" course was great, and it
>> started with transistors, went through ALUs to assembly language, then
>> higher-level languages and operating systems.
>
>I'm glad you liked it. I haven't had personal experience with such an
>approach so I can't say empirically that it's non-optimal. But why
>start with transistors instead of even lower level, like with charge
>carriers, or with tubes that can be explained in terms of electrostatics
>and magnets?

Why start lower, and especially with long-obsolete technology? A
(digitally used) transistor is a pretty simple element, and the point
of all that is to show that you can build complex and versatile things
out of very simple elements. Going lower does not make things
simpler, on the contrary.

>I think most people learn some mathematics (at the level
>of knowing what functions are, and maybe vectors) before they start
>programming, so approaches that start with mathematical concepts seem
>pretty natural. And in fact the SICP approach (based on Scheme) was
>quite successful when it was in vogue.

I don't think the mathematical concepts they learn in school are much
help in learning to program. Indeed we had Knuth here a few weeks
ago, and he said that when he has his mathematicians hat on he is
using a different kind of thinking than when he has his programmer's
hat on.

Anyway, Scheme still is a nice language for introducing programming (I
started teaching an introductory programming course this semester and
used Scheme/Racket at the start; next year I will probably use Forth,
though, so the students get a better grasp of what addresses are).

But the point of something like JonesForth is not an introduction to
programming, but an introduction to programming language
implementation (especially if you don't feel like teaching scanning
and parsing).

[Bernd Paysan]

Paul Rubin wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>> The big advantge of the bottom-up teaching style is that there never is a
>> magic "we will explain this later" component.
>
> I don't understand this desire. There is "explain later" in every
> learning process, about everyting in life. Before most people learn how
> to drive a car, they usually first ride in one driven by someone else.
> And before they learn how to fix a car, they first learn how to drive
> it.

Well, that's you build your experience on what you already know. The
JonesForth approach says "people already know assembler", and therefore goes
bottom-up. Maybe for a Lisp user, top down is the right approach, because
the top is similar enough to get down from there.

JonesForth is successful as Forth teaching vehicle, so there's a point with
the bottom-up strategy. And most of us lerned Forth through a combination
of Starting Forth (which digs deep into implementation details), fig Forth
Listings, Inside F83, and so on; most of them written around 30 years ago.

[Andrew Haley]

Bill Richards <bill...@gmx.com> wrote:
> On 2013-06-12, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>> Bill Richards <bill...@gmx.com> wrote:
>>>
>>> 32 bit Linux as it was first presented is probably still the best choice
>>> although I think most people prefer the human-looking Intel syntax over the
>>> machine readable "gas" syntax.
>>
>> Eh? Heavens, no! And BTW, it's AT&T UNIX syntax; nothing to do with
>> GNU as, which implements it for compatibility.
>
> Yes, yes, we know. The UNIX snobs at AT&T knew better than Intel. After all
> Intel only designed the chips and wrote the first assemblers blah blah blah.

Well, yeah.

> Whatever the UNIX snobs used on their PDP *must* be the way to go on
> Intel especially now that PDPs are all but gone and Intel's been the
> leading desktop arch for the last thirty years or so.
>
> GNU as and compatibility? With what?

UNIX.

> Itself? Yes, it was designed (loosely) to process the output of
> their C compiler not for humans to write code in.

Eh? Where do you get this weird stuff from?

> It's the worst of all known x86 assemblers. Nobody should use it as
> an example for anything except what not to do when it comes to
> designing an assembler...

I'm mystified. AT&T syntax is much simpler and doesn't have all that
WORD PTR blah stuff. Why would anyone want Intel syntax?

Andrew.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Paul Rubin wrote:
>
>> Bernd Paysan <bernd....@gmx.de> writes:
>>> The big advantge of the bottom-up teaching style is that there never is a
>>> magic "we will explain this later" component.
>>
>> I don't understand this desire. There is "explain later" in every
>> learning process, about everyting in life. Before most people learn how
>> to drive a car, they usually first ride in one driven by someone else.
>> And before they learn how to fix a car, they first learn how to drive
>> it.
>
> Well, that's you build your experience on what you already know. The
> JonesForth approach says "people already know assembler", and therefore goes
> bottom-up.

Mmm, but I don't think that assumption holds today.

Andrew.

[Albert van der Horst]

In article <7x8v2lx...@ruckus.brouhaha.com>,

May I add to this? The contorted things result from doing it himself
and starting from scratch. There is a bright side to this. All steps
into gaining insight in a Forth compiler are present as he recorded
them on the way.

Groetjes Albert

[Albert van der Horst]

In article <kpa2o7$8gc$1...@speranza.aioe.org>,

Bill Richards <bill...@gmx.com> wrote:
>On 2013-06-12, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:

<SNIP>

>>
>> Intel deviates from the convention in assemblers with its destination
>> source order in operands.
>
>There is no such convention. And as you would expect a correct and useful

Care to name a few processors besides Intel's that use
dst,src
order of operands?

>
>Bill

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> The JonesForth approach says "people already know assembler", and

> therefore goes bottom-up. ... JonesForth is successful as Forth

> teaching vehicle, so there's a point with the bottom-up strategy.

An alternative theory is that the Jonesforth approach went "people
aready know English", and that the success came from the extensive
comments written in English that explained to readers what was going on.
Of course it would have worked out about the same way in other
languages, for non-English speakers. Under this (admittedly unproven,
but IMHO plausible) theory, the use of assembler was incidental to
Jonesforth's success, and may have even impaired understanding compared
to doing the whole thing in Forth or an HLL.

> And most of us lerned Forth through a combination of Starting Forth
> (which digs deep into implementation details), fig Forth Listings,
> Inside F83, and so on; most of them written around 30 years ago.

Interesting, I don't remember much about implementation detail from
Starting Forth (I might look at it again). I looked at Figforth
recently and found it pretty incomprehensible due to its lack of
comments. Inside F83 looked like a very useful book, but I didn't get
to read very much of it. I also remember believing that Thinking Forth
was a deeper and more interesting book than Starting Forth. It's
been a while since I looked at either one though.

[Elizabeth D. Rather]

On 6/12/13 7:58 PM, Paul Rubin wrote:
> Bernd Paysan <bernd....@gmx.de> writes:

...

>> And most of us lerned Forth through a combination of Starting Forth
>> (which digs deep into implementation details), fig Forth Listings,
>> Inside F83, and so on; most of them written around 30 years ago.
>
> Interesting, I don't remember much about implementation detail from
> Starting Forth (I might look at it again). I looked at Figforth
> recently and found it pretty incomprehensible due to its lack of
> comments. Inside F83 looked like a very useful book, but I didn't get
> to read very much of it. I also remember believing that Thinking Forth
> was a deeper and more interesting book than Starting Forth. It's
> been a while since I looked at either one though.
>

Starting Forth explained ITC implementation in great detail, with the
assumption that this was an essential Forth characteristic. Thinking
Forth *was* deeper and more interesting, since it addressed the process
of thinking about coding solutions, rather than specific implementation
procedures and elementary semantic details.

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

[Lars Brinkhoff]

Albert van der Horst wrote:
> Care to name a few processors besides Intel's that use
> dst,src
> order of operands?

Entertaining question! I did a quick survey just now.

Most assemblers for RISC(-like) processors that I checked put the
destination first. The exception is store instructions, which usually
have the source register first, and the destination last.

These conform to this convention: PDP-10, MIPS, ARM, PowerPC, Alpha.

On the other hand, these consistently use src,dst (even in load/store
instructions): PDP-11 (MACRO-11), VAX (MACRO-32), M68000 (Motorola
syntax), SPARC.

[Elizabeth D. Rather]

However, Forth assemblers can use whatever order they wish. In most
cases that I'm familiar with, arguments such as src and dst precede the
mnemonic, which takes them as arguments and assembles the instruction. :-)

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>I'm mystified. AT&T syntax is much simpler and doesn't have all that
>WORD PTR blah stuff.

Yes, I find it more understandable, too. Apparently it's a matter of
taste. As to why the AT&T Unix people did it: Most Forths have their
own assembly language syntax, so why not Unix, especially given the
complexity of the Intel syntax.

> Why would anyone want Intel syntax?

The argument order of CMP is counterintuitive in AT&T syntax if you
then check for less than etc. I think they should have kept the
argument order consistent with the Intel syntax.

Concerning the claim that destination last is a convention in assembly
languages, DEC assembly languages have that (and that's probably why
AT&T syntax has it), but, e.g., IBM S/360 has destination first
<http://en.wikipedia.org/wiki/IBM_Basic_assembly_language>. MIPS and
PowerPC are destination first, SPARC and 68000 are destination last,
but they all came after Intel syntax.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:

>Bernd Paysan <bernd....@gmx.de> wrote:
>> Well, that's you build your experience on what you already know. The
>> JonesForth approach says "people already know assembler", and therefore goes
>> bottom-up.
>
>Mmm, but I don't think that assumption holds today.

The success of JonesForth (despite its shortcomings) demonstrates that
it does.

[Lars Brinkhoff]

Elizabeth D. Rather wrote:
> However, Forth assemblers can use whatever order they wish.

Obviously. But I believe the context was "manufacturer's preferred
assembly syntax". I.e. the good old assemblers from DEC, IBM, Intel,
Motorola, etc, as opposed to new-fangled contraptions in Unix, GNU,
or - horrors - Forth, Lisp.

[Anton Ertl]

Lars Brinkhoff <lars...@nocrew.org> writes:
>Most assemblers for RISC(-like) processors that I checked put the
>destination first. The exception is store instructions, which usually
>have the source register first, and the destination last.
>
>These conform to this convention: PDP-10, MIPS, ARM, PowerPC, Alpha.

Alpha uses destination last (like it's ancestors PDP-11 and VAX).
Given how close Alpha is otherwise to MIPS, this is pretty annoying.

[Albert van der Horst]

In article <kp7jf6$dmn$1...@online.de>, Bernd Paysan <bernd....@gmx.de> wrote:
>Anton Ertl wrote:
>> Sure, once they understand it, they notice that the assembly form is
>> not the most flexible source form for Forth, and will arrive at the
>> idea of meta-compilation themselves. But for most doing all of this
>> in one step is too big a leap.
>
>Jens once added an "output as assembler" mode to Gforth's cross compiler.
>This approach could make a JonesForth-like system maintainable for the
>people who write it (you want to write the high-level and the headers in
>Forth). It needs a way to pass the comments through, as well, and it quite
>likely doesn't need all the features a cross compiler normally needs.

I've this reverse engineering assembler ciasdis.

One of the examples is disassembling the (then current) version of the
underlying Forth, then reassembling it again. The disassembler regenerates
from the headers sensible lables for name fields and regenerates the
threaded code. It makes a distinction between assembler code and high level
code. It regenerates the elf header, but it falls down on hex bytes for
everything that is not reverse engineered.
The result is a readable assembler source inasfar a Forth assembler is readable.
This is somewhere on my web site.

>
>The big advantge of the bottom-up teaching style is that there never is a
>magic "we will explain this later" component. You can easily write an
>"Introduction to Computer Science" where you go to a Forth CPU instead of
>assembler.

That would be neat.

>
>--
>Bernd Paysan

[Bernd Paysan]

Anton Ertl wrote:

> Lars Brinkhoff <lars...@nocrew.org> writes:
>>Most assemblers for RISC(-like) processors that I checked put the
>>destination first. The exception is store instructions, which usually
>>have the source register first, and the destination last.
>>
>>These conform to this convention: PDP-10, MIPS, ARM, PowerPC, Alpha.
>
> Alpha uses destination last (like it's ancestors PDP-11 and VAX).
> Given how close Alpha is otherwise to MIPS, this is pretty annoying.

It looks like the big endian/little endian switch. As usual, the flip-over
thing happens after some time, e.g. IBM had dest, source at least since the
/360, but nowadays, they use gas examples to explain PowerPC assembler.
Don't expect any of these things to be constant or that there is a "winner".

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Bernd Paysan <bernd....@gmx.de> wrote:
>>> Well, that's you build your experience on what you already know.
>>> The JonesForth approach says "people already know assembler", and
>>> therefore goes bottom-up.
>>
>>Mmm, but I don't think that assumption holds today.
>
> The success of JonesForth (despite its shortcomings) demonstrates that
> it does.

That's a bit of a stretch, IMO. And I still think that a simple
Forth-in-Forth ould be much better. I wonder if there's some way to
make Forth-in-Forth easier to understand than assembly code.

Andrew.

[Anton Ertl]

For people who don't know Forth, I doubt it. Even for Forth-in-Forth
you have to understand assembly language (now Forth assembly language,
not some other assembly language), and you need to understand Forth,
and you need to understand the meta-compilation approach used.

I.e., even if they don't know assembly language at the start, the
Forth-in-assembly-language approach is easier to learn (for someone
new to Forth) than the Forth-in-Forth approach.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Anton Ertl wrote:
>
>> Lars Brinkhoff <lars...@nocrew.org> writes:
>>>Most assemblers for RISC(-like) processors that I checked put the
>>>destination first. The exception is store instructions, which usually
>>>have the source register first, and the destination last.
>>>
>>>These conform to this convention: PDP-10, MIPS, ARM, PowerPC, Alpha.
>>
>> Alpha uses destination last (like it's ancestors PDP-11 and VAX).
>> Given how close Alpha is otherwise to MIPS, this is pretty annoying.
>
>It looks like the big endian/little endian switch. As usual, the flip-over
>thing happens after some time, e.g. IBM had dest, source at least since the
>/360, but nowadays, they use gas examples to explain PowerPC assembler.

For PowerPC gas uses IBM's destination first approach.

I assume you mean http://www.ibm.com/developerworks/library/l-ppc/,
which shows IA-32 code in AT&T syntax first, then PowerPC code.
Apparently the authors of that page think that enough prospective
PowerPC programmers know IA-32 code in AT&T syntax.

[Bill Richards]

On 2013-06-13, Lars Brinkhoff <lars...@nocrew.org> wrote:
> Albert van der Horst wrote:
>> Care to name a few processors besides Intel's that use
>> dst,src
>> order of operands?

It's been mentioned IBM S360 (and probably the 1130, 7090 but I haven't
checked those) all use dest,source and that was 10 years before Intel if you
go by S360 and if you go by the earlier machines probably a good 20 years
before Intel since they were writing Fortran compilers in assembly in the
middle 1950's.

>
> Entertaining question! I did a quick survey just now.

Yes, when you look at it it really is interesting!

>
> Most assemblers for RISC(-like) processors that I checked put the
> destination first. The exception is store instructions, which usually
> have the source register first, and the destination last.
>
> These conform to this convention: PDP-10, MIPS, ARM, PowerPC, Alpha.

Notably MIPS assembly syntax (MIPSPro) goes the opposite direction from its
encoding.

>
> On the other hand, these consistently use src,dst (even in load/store
> instructions): PDP-11 (MACRO-11), VAX (MACRO-32), M68000 (Motorola
> syntax), SPARC.

Also notably SPARC assembly syntax goes opposite its encoding. I really find
this and MIPS choices odd all things considered. In most environments the
assembler seems to follow the encoding more often than not. Intel is a bit
of an exception since it isn't exactly clear which direction they're going
but I think it's unique to them as far as the other chips I've seen.

DOS, CP/M on 808X all used dest,src as well across quite a wide variety of
assemblers from Intel, Digital Research, Borland, IBM, Microsoft MASM of
course, and other small companies etc. Have forgotten how the 6502 and 6800
work but I gather from your comment on the 68K the 6800 probably goes the
same way. The new breed of Linux/UNIX assemblers nasm/yasm and fasm are also
all dest,source. fasm is self-hosted which is also fascinating.

I suppose the ultimate Jones Forth would be done in fasm and the entire
thing would end up metassembling/metacompiling itself twice before it was
done.

Bill

[Mark Wills]

Texas Instruments were using dest/source in 1976 on their TMS range.

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> For people who don't know Forth, I doubt it. Even for Forth-in-Forth
> you have to understand assembly language (now Forth assembly language,
> not some other assembly language),

I think there is a big difference between understanding the basic
principles of registers and machine instructions, and being able to
survey a complicated program and understand how it works. That's pretty
much the difference between a beginning programmer and an experienced
one in any language.

A real Forth assembler may not even be needed, to cover the handful of
instructions and formats needed. E.g.

CODE + NOS TOS ADD, NIP, END-CODE

the words used can be ordinary Forth words that push bits on the stack
(NOS and TOS) or write words to the heap (ADD, and NIP,) involving some
bit twiddling and hex constants.

> and you need to understand Forth, and you need to understand the
> meta-compilation approach used.

Understanding Forth is probably helpful to understanding any Forth
implementation no matter how it's written ;-). The metacompilation
approach would benefit a lot from being clearly documented.

> I.e., even if they don't know assembly language at the start, the
> Forth-in-assembly-language approach is easier to learn (for someone
> new to Forth) than the Forth-in-Forth approach.

Well, there's 4 mathematical combinations:

1) assembly language, few comments (Figforth)
2) metacompilation, few comments (CMForth)
3) assembly language, lots of comments (Jonesforth)
4) metacompilation, lots of comments (untried so far)

Figforth was understandable to assembly programmers but not to anyone
else. CMForth appears to have been understandable to few people (an
annotated version supposedly exists somewhere though). Jonesforth was
very popular, I think including among people who didn't really know x86
assembler, but could follow it because of the comments. So now we're
debating whether well-commented metacompiled Forth can be understood
equally well. I guess that can really only be determined by experiment.

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> No, that's not necessary, because the goal is to understand the
> implementation of Forth, not the implementation of the assembler.
> This approach takes the "mere user" attitude towards assembly
> language, but the implementor attitude towards Forth.

If understanding Forth doesn't involve understanding the underlying
tools, then as a "mere user" why pick something as messy as assembler,
instead of something like Ruby?

> CODE performs quite a bit of magic, in particular building dictionary
> entries, that is explicit in assmbly language. For modification
> automagics is better, for first understanding explicit is better.

It's possible that you're referring to something I don't understand. I
had thought CODE is basically like : (colon), i.e. it does a CREATE then
flips a state variable to assemble code until something like ENDCODE is
seen, but the created dictionary entry maybe has some bits set to
indicate that it's a code word, and also CODE may switch in an
assembler-specific word list. Is there more than that?

Anyway it's surely easier for most "mere user"s to understand the
creation of dict entries from something like
http://forthfreak.net/jsforth.js
than from an assembly program.

> I don't think the mathematical concepts they learn in school are much
> help in learning to program.

You mean like functions? Of course that seems useful.

> Indeed we had Knuth here a few weeks ago, and he said that when he has
> his mathematicians hat on he is using a different kind of thinking
> than when he has his programmer's hat on.

Sure, the stuff that mathematicians think about is different. Though,
maybe Knuth should try programming in Haskell ;-).

> Anyway, Scheme still is a nice language for introducing programming (I
> started teaching an introductory programming course this semester and
> used Scheme/Racket at the start; next year I will probably use Forth,
> though, so the students get a better grasp of what addresses are).

I think of addresses as a relatively advanced concept in programming
these days. One can be a productive Ruby programmer without knowing
what an address is.

Maybe what Forth really needs is a new name, like Erlang recently got:

https://www.youtube.com/watch?v=rRbY3TMUcgQ

;-)

> But the point of something like JonesForth is not an introduction to
> programming, but an introduction to programming language
> implementation (especially if you don't feel like teaching scanning
> and parsing).

JonesForth or any Forth seems like a terrible introduction to
programming language implementation, since Forth is relatively exotic
language. As a language nerd it interests me -because- of that
exoticness, but it's like learning about plant metabolism by studying
the Venus fly trap. It's surely interesting, but one shouldn't think
that type of plant is typical.

I came across an interesting term "wholemeal programming" recently.
http://www.cis.upenn.edu/~cis194/lectures/2012-01-12.html quotes
Ralf Hinze who attributes the term to Geraint Jones:

Wholemeal programming means to think big: work with an entire list,
rather than a sequence of elements; develop a solution space, rather
than an individual solution; imagine a graph, rather than a single
path. The wholemeal approach often offers new insights or provides
new perspectives on a given problem. It is nicely complemented by
the idea of projective programming: first solve a more general
problem, then extract the interesting bits and pieces by
transforming the general program into more specialised ones.

That's a Scheme-like approach but sort of the opposite of the Forth
approach.

[Elizabeth D. Rather]

On 6/15/13 9:54 AM, Paul Rubin wrote:
...

>> CODE performs quite a bit of magic, in particular building dictionary
>> entries, that is explicit in assmbly language. For modification
>> automagics is better, for first understanding explicit is better.
>
> It's possible that you're referring to something I don't understand. I
> had thought CODE is basically like : (colon), i.e. it does a CREATE then
> flips a state variable to assemble code until something like ENDCODE is
> seen, but the created dictionary entry maybe has some bits set to
> indicate that it's a code word, and also CODE may switch in an
> assembler-specific word list. Is there more than that?

Actually, less. Yes, in typical implementations, CODE does switch to an
ASSEMBLER wordlist, and use CREATE to make the header. But thereafter,
the various words are simply executed (there's no equivalent of a state
variable). For example:

CODE 0= ( n -- flag )
T T MOVS 0 T MOV 1 T T SUBEQ
LR BX END-CODE

Here words like T push addressing info on the stack (T is the name of
the register containing the top stack item on this platform), and MOVS,
etc., assemble an instruction using that addressing info. END-CODE just
restores the previous wordlist.

...

>
>> But the point of something like JonesForth is not an introduction to
>> programming, but an introduction to programming language
>> implementation (especially if you don't feel like teaching scanning
>> and parsing).
>
> JonesForth or any Forth seems like a terrible introduction to
> programming language implementation, since Forth is relatively exotic
> language. As a language nerd it interests me -because- of that
> exoticness, but it's like learning about plant metabolism by studying
> the Venus fly trap. It's surely interesting, but one shouldn't think
> that type of plant is typical.

But Forth is so simple! In an ideal world, someone would learn language
implementation via Forth and subsequently be appalled at the unnecessary
complexity of other languages :-)

> I came across an interesting term "wholemeal programming" recently.
> http://www.cis.upenn.edu/~cis194/lectures/2012-01-12.html quotes
> Ralf Hinze who attributes the term to Geraint Jones:
>
> Wholemeal programming means to think big: work with an entire list,
> rather than a sequence of elements; develop a solution space, rather
> than an individual solution; imagine a graph, rather than a single
> path. The wholemeal approach often offers new insights or provides
> new perspectives on a given problem. It is nicely complemented by
> the idea of projective programming: first solve a more general
> problem, then extract the interesting bits and pieces by
> transforming the general program into more specialised ones.
>
> That's a Scheme-like approach but sort of the opposite of the Forth
> approach.

Very much the opposite.

[Bernd Paysan]

Paul Rubin wrote:
> If understanding Forth doesn't involve understanding the underlying
> tools, then as a "mere user" why pick something as messy as assembler,
> instead of something like Ruby?

Honestly, the semantic gap between Ruby and Forth is significantly larger
than between assembler and Forth. So if you write a Forth in Ruby, you
either make it simple, and then you will get something considerably
different (RPL or so), or you try hard to implement Forth, and it will look
messy.

>> CODE performs quite a bit of magic, in particular building dictionary
>> entries, that is explicit in assmbly language. For modification
>> automagics is better, for first understanding explicit is better.
>
> It's possible that you're referring to something I don't understand. I
> had thought CODE is basically like : (colon), i.e. it does a CREATE then
> flips a state variable to assemble code until something like ENDCODE is
> seen, but the created dictionary entry maybe has some bits set to
> indicate that it's a code word, and also CODE may switch in an
> assembler-specific word list. Is there more than that?

No, but you ditched the dictionary entry entirely, by saying that "it does a
CREATE". Then the magic Anton mentions just goes to CREATE.

>> I don't think the mathematical concepts they learn in school are much
>> help in learning to program.
>
> You mean like functions? Of course that seems useful.

Maybe if you program in Haskell. Functions are not that common in programs,
as most subroutine have side-effects. The idea of programming languages
like Haskell is to put a lot of effort into a programming language so that
you just can stay in your mathematical mind, and program a computer that
way.

>> Indeed we had Knuth here a few weeks ago, and he said that when he has
>> his mathematicians hat on he is using a different kind of thinking
>> than when he has his programmer's hat on.
>
> Sure, the stuff that mathematicians think about is different. Though,
> maybe Knuth should try programming in Haskell ;-).

If someone implements TeX in Haskell, maybe. But as long as not, there's no
proof that you can do something useful in Haskell ;-).

A friend of mine tried learning Haskell, and his "proof of the pudding" is
writing a word count program. After he was 1/3 through the Haskell book, he
still couldn't. Because the I/O was still missing, and Haskell's file I/O
isn't done right.

IMHO, Haskell should treat the file system as a index -> value table. The
index is the file name, and the value is the file data (a string). That
sort of thinking fits with the way Haskell works, and with that thinking,
the wordcount program would actually be a trivial exercise - just as it is
with Forth.

> I think of addresses as a relatively advanced concept in programming
> these days. One can be a productive Ruby programmer without knowing
> what an address is.

Which explains why WJ asks us so many questions about "can this or that be
done in Forth". It's all trivial stuff, but you need to understand what an
address is to implement it.

IMHO, this lack of addresses in modern popular languages is to avoid the
thing you don't understand. When I've read K&R, I didn't quite understand
what a pointer is. Then I read Brodie, and it was very obvious what an
address is. Going back to K&R, I now understood, what a pointer is. It's a
bit more complicated, since pointer arithmetics knows the size of the
elemens the pointer points to, while addresses don't - they are just bytes.

> Maybe what Forth really needs is a new name, like Erlang recently got:
>
> https://www.youtube.com/watch?v=rRbY3TMUcgQ
>
> ;-)

Haha...

> JonesForth or any Forth seems like a terrible introduction to
> programming language implementation, since Forth is relatively exotic
> language. As a language nerd it interests me -because- of that
> exoticness, but it's like learning about plant metabolism by studying
> the Venus fly trap. It's surely interesting, but one shouldn't think
> that type of plant is typical.

It was about *implementation*, not about the language as such. Forth's
implementation is no way untypical, a lot of languages have VMs which, under
the hood, don't look that much different.

> I came across an interesting term "wholemeal programming" recently.
> http://www.cis.upenn.edu/~cis194/lectures/2012-01-12.html quotes
> Ralf Hinze who attributes the term to Geraint Jones:
>
> Wholemeal programming means to think big: work with an entire list,
> rather than a sequence of elements; develop a solution space, rather
> than an individual solution; imagine a graph, rather than a single
> path. The wholemeal approach often offers new insights or provides
> new perspectives on a given problem. It is nicely complemented by
> the idea of projective programming: first solve a more general
> problem, then extract the interesting bits and pieces by
> transforming the general program into more specialised ones.
>
> That's a Scheme-like approach but sort of the opposite of the Forth
> approach.

Oh, yes, Forth is about solving the problem at hand, not something general.
How would that wholemeal approach e.g. solve the Triceps playing Go stuff?
Task: you have a board with white and black stones. Write a program that
uses the webcam to know what's on the Go board.

Forth approach: Take the OpenGL texture the webcam renders its preview into,
and draw it with perspectivic correction so that it becomes a nice
horizontal and vertical matrix. Read in the pixels. Bin the pixels into
three classes: black, white, board (in our case, the board is green, but it
could be brown, as well). Define areas of interest (rectangles) in that
matrix. Do a majority decision on those pixels there, whatever is most is
the most likely thing there.

This sort of image recognition works only for exactly one thing: a game
board. It was quickly done, it's not 400 lines (including the interface to
the Go program and the robot). It's not perfect, because if you change the
color of the board, you have to adjust the board recognition code. If you
change the positon of the board, you have to adjust the perspective
correction. And so on. I'm probably going to solve some of these issues,
because they can be automated.

[rickman]

On 6/12/2013 11:05 AM, Bill Richards wrote:
> On 2013-06-12, Albert van der Horst<alb...@spenarnc.xs4all.nl> wrote:

>> In article<jvGdnW-R26tN7yXM...@supernews.com>,

>> Andrew Haley<andr...@littlepinkcloud.invalid> wrote:
>>> Bill Richards<bill...@gmx.com> wrote:
>>>>
>>>> 32 bit Linux as it was first presented is probably still the best choice
>>>> although I think most people prefer the human-looking Intel syntax over the
>>>> machine readable "gas" syntax.
>>>
>>> Eh? Heavens, no! And BTW, it's AT&T UNIX syntax; nothing to do with
>>> GNU as, which implements it for compatibility.
>>

>> Intel deviates from the convention in assemblers with its destination
>> source order in operands.
>
> There is no such convention. And as you would expect a correct and useful

> assembler exposes the ISA it was designed to run on. Intel's encoding is
> reflected in the choice of op dest, src. Why anyone would intentionally
> bass-ackwards an assembler is hard to figure. For once Microsoft seems to
> have done the right thing as well ;-)

I don't follow what you mean about the architecture. How does the CPU
architecture imply an order of operands in the assembly source code?
Are you talking about the sequence of fields in the opcodes? It would
seem quite a stretch to me to assume the opcode format should be
reflected in the assembly language source code. I realize that
sometimes it is nice to be able to hand assemble a few instructions, but
really, is this so important?

--

Rick

[rickman]

On 6/14/2013 4:25 AM, Mark Wills wrote:
> Texas Instruments were using dest/source in 1976 on their TMS range.

Can you be more specific? They use TMS for nearly all of their
processors, MCUs and DSPs. Are you saying they use this format across
the board?

--

Rick

[rickman]

On 6/11/2013 1:33 PM, Paul Rubin wrote:
> Bernd Paysan<bernd....@gmx.de> writes:

>> The big advantge of the bottom-up teaching style is that there never is a
>> magic "we will explain this later" component.
>

> I don't understand this desire. There is "explain later" in every
> learning process, about everyting in life.

...<snip>...
> That seems perfectly natural to me.

Not everything natural is preferable. Hemlock is natural, care for a
drink?

I think it is pretty clear that if you take a student on a linear path
from A to B to C to D that is much easier for them than going back and
forth leaving holes to be filled in later. Do you really not see that?

In fact, the only problem with this approach is that there are reasons
for doing things they way they are at the lower levels that aren't clear
until you see the higher levels. So there will be *some* holes which
need to be filled with both approaches, but fewer in the bottom up
approach.

--

Rick

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:
> Actually, less. Yes, in typical implementations, CODE does switch to
> an ASSEMBLER wordlist, and use CREATE to make the header. But
> thereafter, the various words are simply executed (there's no
> equivalent of a state variable).

Oh right, good point, I got confused by the presence of END-CODE which
only switches the word list back, or something.

[Mark Wills]

Okay. I was specifically talking about their long-retired TMS99xx range, but AFAIK the precedent still stands with TI's other parts, too. It was certainly src-->dest on the TMS340x0 DSPs.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> So if you write a Forth in Ruby, you either make it simple, and then
> you will get something considerably different (RPL or so), or you try
> hard to implement Forth, and it will look messy.

I guess JSForth is messy, though maybe it could be cleaned up some, and
maybe Ruby could be less messy than JS, I don't know.

> No, but you ditched the dictionary entry entirely, by saying that "it
> does a CREATE". Then the magic Anton mentions just goes to CREATE.

Then maybe there's something to CREATE that I don't understand, but I
thought it just reads the next input token, makes a dictionary entry (a
straightforward data structure) and adjusts a few variables.

>> You mean like functions? Of course that seems useful.
> Maybe if you program in Haskell. Functions are not that common in
> programs, as most subroutine have side-effects.

I think the concept of purity in functions doesn't really occur to most
programmers unless they've been exposed to something like Haskell.
Functions in programming conceptually start out as things like "square
root", but since they're code, they can have print statements and
whatnot, and nobody notices that this is impure.

> A friend of mine tried learning Haskell, and his "proof of the
> pudding" is writing a word count program. After he was 1/3 through
> the Haskell book, he still couldn't. Because the I/O was still
> missing, and Haskell's file I/O isn't done right.

http://www.haskell.org/haskellwiki/Simple_unix_tools

> IMHO, Haskell should treat the file system as a index -> value table.

This might make sense for a read-only file system, where you don't care
about large files.

Haskell's "lazy i/o" stuff (shown above) works pretty well for many
things and is fairly easy to understand for simple use cases, and it
should be fine for a word count program, or even for something like TeX.
It turns out to be impure in a way that bites you if you're writing
stuff like network servers and you find your program leaking file
descriptors, but this is mostly an issue if you're opening 1000's of
them. The "pure" way to do it that avoids these leaks is unfortunately
rather complicated. Various ways to bring clarity to it are still being
developed.

> It was about *implementation*, not about the language as such.
> Forth's implementation is no way untypical, a lot of languages have
> VMs which, under the hood, don't look that much different.

That's just the address interpreter. The text interpreter and compiler
is almost shocking ;-). The language and its programming practices
revolve around that one-pass transliteration into the dictionary.

> Oh, yes, Forth is about solving the problem at hand, not something
> general. How would that wholemeal approach e.g. solve the Triceps

> playing Go stuff?. .. Forth approach: Take the OpenGL texture the

> webcam renders its preview into, and draw it with perspectivic

Probably kind of similar except you'd have a series of transforms that
were composed with each other without a lot of explicit coordinates in
between.

[Bernd Paysan]

Paul Rubin wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>> So if you write a Forth in Ruby, you either make it simple, and then
>> you will get something considerably different (RPL or so), or you try
>> hard to implement Forth, and it will look messy.
>
> I guess JSForth is messy, though maybe it could be cleaned up some, and
> maybe Ruby could be less messy than JS, I don't know.

Both JavaScript and Ruby are essentially Lisps with a different syntax, so
the semantics is similar for both. Writing RPL in JavaScript or Ruby is
*much* easier, because you just define the stacks, and then push normal
JavaScript or Ruby things on that. Which aren't the same as Forth things.

JSForth maybe could use asm.js as fundation to implement Forth in a least-
messy way, asm.js is using JavaScript as portable assembler (and that maps
to real assembler code, by the use of a Forth program inside the JavaScript
engine - at least in Firefox, where asm.js comes from ;-).

>> No, but you ditched the dictionary entry entirely, by saying that "it
>> does a CREATE". Then the magic Anton mentions just goes to CREATE.
>
> Then maybe there's something to CREATE that I don't understand, but I
> thought it just reads the next input token, makes a dictionary entry (a
> straightforward data structure) and adjusts a few variables.

Yes, the data structure is actually not that complicated.

>>> You mean like functions? Of course that seems useful.
>> Maybe if you program in Haskell. Functions are not that common in
>> programs, as most subroutine have side-effects.
>
> I think the concept of purity in functions doesn't really occur to most
> programmers unless they've been exposed to something like Haskell.
> Functions in programming conceptually start out as things like "square
> root", but since they're code, they can have print statements and
> whatnot, and nobody notices that this is impure.

IMHO that is the essence of the programmer's mind: A computer is really a
state machine. The fact that "impure" procedures modify the state is the
real nature of a computer.

>> A friend of mine tried learning Haskell, and his "proof of the
>> pudding" is writing a word count program. After he was 1/3 through
>> the Haskell book, he still couldn't. Because the I/O was still
>> missing, and Haskell's file I/O isn't done right.
>
> http://www.haskell.org/haskellwiki/Simple_unix_tools

I know, the problem was that IO Monads were explained at the end of the
book. This means you pretty much can't do anything real before you reach
the end of the book. The wiki above is much more pragmatic.

>> IMHO, Haskell should treat the file system as a index -> value table.
>
> This might make sense for a read-only file system, where you don't care
> about large files.

Large files: mmap. Ok, on a 32 bit system, not always practical ;-), but
for 64 bit systems, mmap works quite well.

If you use the table metaphor, you can create new index -> value pairs, or
replace existing pairs, just like you do on a hash table, so it is read-
write.

What this approach doesn't do is operate on bytes or lines. I really don't
like that approach much; we use slurp in Gforth a lot (and there's a
counter-part, spit, which creates a file from a string). Especially with
the Haskell way of thinking, IMHO the "treat the file data as a whole, and
not as a stream of bytes" is the right way.

> Haskell's "lazy i/o" stuff (shown above) works pretty well for many
> things and is fairly easy to understand for simple use cases, and it
> should be fine for a word count program, or even for something like TeX.
> It turns out to be impure in a way that bites you if you're writing
> stuff like network servers and you find your program leaking file
> descriptors, but this is mostly an issue if you're opening 1000's of
> them. The "pure" way to do it that avoids these leaks is unfortunately
> rather complicated. Various ways to bring clarity to it are still being
> developed.

Yes, and my suggestion was to use something like slurp/spit. Even a
network works quite well that way: You define how your network stream is
packeted (e.g. a HTML request ends with an empty line). And then, you just
slurp in a packet, and respond with spitting another packet out. My web-
server (in Forth) pretty much works that way. It might be a bit more
difficult to handle keep-alive connections, but if a HTTP connection isn't
kept alive, it is a pretty pure function: Request maps to response,
stateless.

>> It was about *implementation*, not about the language as such.
>> Forth's implementation is no way untypical, a lot of languages have
>> VMs which, under the hood, don't look that much different.
>
> That's just the address interpreter. The text interpreter and compiler
> is almost shocking ;-). The language and its programming practices
> revolve around that one-pass transliteration into the dictionary.

Yes, and no. It revolves about simplicity, and doing just what needs to be
done, no more.

>> Oh, yes, Forth is about solving the problem at hand, not something
>> general. How would that wholemeal approach e.g. solve the Triceps
>> playing Go stuff?. .. Forth approach: Take the OpenGL texture the
>> webcam renders its preview into, and draw it with perspectivic
>
> Probably kind of similar except you'd have a series of transforms that
> were composed with each other without a lot of explicit coordinates in
> between.

Not sure, the Forth program has just three transforms: The OpenGL
perspectivic correction (draws a rectangle rotated in 3D space), the pixel
binning, and the majority decision.

If you solve the general problem, it's IMHO image recognition.

[rickman]

On 6/15/2013 5:35 PM, Mark Wills wrote:
> On Saturday, June 15, 2013 5:00:39 PM UTC+1, rickman wrote:
>> On 6/14/2013 4:25 AM, Mark Wills wrote:
>>
>>> Texas Instruments were using dest/source in 1976 on their TMS range.
>>
>>
>> Can you be more specific? They use TMS for nearly all of their
>>
>> processors, MCUs and DSPs. Are you saying they use this format across
>>
>> the board?
>>

>> Rick
>
> Okay. I was specifically talking about their long-retired TMS99xx range, but AFAIK the precedent still stands with TI's other parts, too. It was certainly src-->dest on the TMS340x0 DSPs.

Now I'm really confused. Initially you say TI uses dest/source which I
interpret as OP dst,src format. Here you say "src-->dest" which I'm not
sure how to interpret. Are you saying the src is the first operand of
the instruction or are you just showing a data flow?

--

Rick

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> JSForth maybe could use asm.js as fundation to implement Forth

Hmm, that's an interesting idea, though probably not that useful outside
the context of a cross compiler.

>> http://www.haskell.org/haskellwiki/Simple_unix_tools
>
> I know, the problem was that IO Monads were explained at the end of the
> book. This means you pretty much can't do anything real before you reach
> the end of the book. The wiki above is much more pragmatic.

Lazy i/o lets you deal with file contents without monadic actions
except possibly for originally "reading" the file:

contents <- readFile "filename"

and you can pretend that <- is something like an assignment operator.

> Large files: mmap. Ok, on a 32 bit system, not always practical ;-), but
> for 64 bit systems, mmap works quite well.

The trouble here is if you're both reading and writing the map in this
scheme, the reader and writer can interfere with each other, which is
supposed to be impossible if the map is presented as a pure string. The
existing mmap wrapper has impure access functions that work fine; it's
not worth doing another awful hack of making the impure appear pure.
Haskell is being used for hardcore systems programming these days, so
leaving weird edge cases around causes problems.

> Yes, and my suggestion was to use something like slurp/spit. Even a
> network works quite well that way: You define how your network stream is
> packeted (e.g. a HTML request ends with an empty line). And then, you just
> slurp in a packet, and respond with spitting another packet out.

This is sort of what's recommended now (enumerator i/o) though it's done
in the i/o monad where it belongs. Unfortunately it's conceptually
complicated right now, since it's a fairly new thing and the ideas are
still being distilled. You can also write traditional, imperative-style
code with i/o handles and that's perfectly ok, if a little bit ugly
at times.

> Yes, and no. It revolves about simplicity, and doing just what needs to be
> done, no more.

This may sound odd, but I think Forth implementation is more complicated
than Lisp implementation. There are really only a few concepts in
old-fashioned Lisp and they're less intricate than Forth. A naive
implementation just ends up being a lot less efficient than a minimal
Forth.

> Not sure, the Forth program has just three transforms: The OpenGL
> perspectivic correction (draws a rectangle rotated in 3D space), the
> pixel binning, and the majority decision.

Right, presumably the transforms have loops iterating through the
pixels, so you have to either write one loop combining all three
transforms (not so modular) or three separate loops somehow
communicating, or all modifying an in-memory image. In Haskell
you'd aim for something like

recognize = majority . pixelBin . deskew

where deskew and pixelBin are maps on entire images, and and (if you're
lucky) the compiler fuses all the loops.

[the_gavino_himself]

let me know when iso can boot a pc into a gui desktop adn run firefox or something equivalent so I can chat surf and check mail

[Elizabeth D. Rather]

On 6/15/13 8:22 PM, the_gavino_himself wrote:
> let me know when iso can boot a pc into a gui desktop adn run firefox or something equivalent so I can chat surf and check mail
>

Don't hold your breath.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
>
> JonesForth or any Forth seems like a terrible introduction to
> programming language implementation, since Forth is relatively exotic
> language. As a language nerd it interests me -because- of that
> exoticness, but it's like learning about plant metabolism by studying
> the Venus fly trap. It's surely interesting, but one shouldn't think
> that type of plant is typical.

It's not that unusual either. I spend most of my time inside the JVM
these days, and the same components are there, albeit in a much more
complex form.

Andrew.

[Andrew Haley]

I've been thinking some more, and I wonder if the best approach might
be a Forth-in-Forth with really good introspection and browsing
facilities. It'd allow you to browse the dictionary, look at
dictionary entries and assembly code, and give you a really easy way
to understand what is going on -- once you'd learned which buttons to
press. And it wouldn't require an _a priori_ knwledge of assembly
language, which would be a big plus.

Andrew.

[Alex McDonald]

On Jun 16, 12:26 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 6/15/13 8:22 PM, the_gavino_himself wrote:
>
> > let me know when iso can boot a pc into a gui desktop adn run firefox or something equivalent so I can chat surf and check mail
>
> Don't hold your breath.
>

I'd recommend he did.

> 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 90045http://www.forth.com

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> ... a Forth-in-Forth with really good introspection and browsing

> facilities. It'd allow you to browse the dictionary, look at

> dictionary entries and assembly code...

That sounds really neat, almost like a poor man's Lisp machine. Has
anything like it been done before? I've been wanting to see the old PC
Forth environments in operation sometime, partly to see how close they
came to that.

[Bernd Paysan]

Paul Rubin wrote:

> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> ... a Forth-in-Forth with really good introspection and browsing
>> facilities. It'd allow you to browse the dictionary, look at
>> dictionary entries and assembly code...
>
> That sounds really neat, almost like a poor man's Lisp machine. Has
> anything like it been done before?

Holon comes in mind, it has a pretty good browser/editor. Holon also did
show the documentation.

I've also done an object browser in bigForth, which could have been used as
browser for normal code, too.

> I've been wanting to see the old PC
> Forth environments in operation sometime, partly to see how close they
> came to that.

Many Forth systems had view and shadow screens.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> Holon comes in mind, it has a pretty good browser/editor. Holon also did
> show the documentation.

I remember thinking Holon looked interesting. But it doesn't seem to
have been released as source code, and I didn't notice anything saying
that the host side of it was actually written in Forth.

> I've also done an object browser in bigForth, which could have been
> used as browser for normal code, too.

Nice.

> Many Forth systems had view and shadow screens.

Yes, even in the CP/M and minicomputer era, apparently. I wonder what
it was like to use something like that. Arrayforth still sticks with
this system.

[Mark Wills]

Sorry - my bad. It's MOV SRC,DEST in all cases in TI land, as far as I know.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>I've been thinking some more, and I wonder if the best approach might
>be a Forth-in-Forth with really good introspection and browsing
>facilities. It'd allow you to browse the dictionary, look at
>dictionary entries and assembly code, and give you a really easy way
>to understand what is going on -- once you'd learned which buttons to
>press.

Something like that is the approach I take in my Forth course. I
teach them Forth, and in the end, I show them the innards. I use
DUMP, SEE, SIMPLE-SEE, and SEE-CODE for that. I don't use WORDS or
other dictionary browsing words for that, though.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> No, that's not necessary, because the goal is to understand the
>> implementation of Forth, not the implementation of the assembler.
>> This approach takes the "mere user" attitude towards assembly
>> language, but the implementor attitude towards Forth.
>
>If understanding Forth doesn't involve understanding the underlying
>tools, then as a "mere user" why pick something as messy as assembler,
>instead of something like Ruby?

It's useful to understand assembly language for understanding both
Forth-in-Forth and for understanding Forth-in-assembly. It's not very
useful for that purpose to understand the *implementation* of the
assembler.

>> CODE performs quite a bit of magic, in particular building dictionary
>> entries, that is explicit in assmbly language. For modification
>> automagics is better, for first understanding explicit is better.
>
>It's possible that you're referring to something I don't understand. I
>had thought CODE is basically like : (colon), i.e. it does a CREATE then
>flips a state variable to assemble code until something like ENDCODE is
>seen, but the created dictionary entry maybe has some bits set to
>indicate that it's a code word, and also CODE may switch in an
>assembler-specific word list. Is there more than that?

Someone who does not know Forth does not know what CREATE does. Also,
even if they know Forth, they may have no idea how the dictionary is
implemented.

>> I don't think the mathematical concepts they learn in school are much
>> help in learning to program.
>
>You mean like functions? Of course that seems useful.

It still does not help much.

>I think of addresses as a relatively advanced concept in programming
>these days. One can be a productive Ruby programmer without knowing
>what an address is.

Maybe, but we are at the start of a computer science program, not a
Ruby programmer course.

>> But the point of something like JonesForth is not an introduction to
>> programming, but an introduction to programming language
>> implementation (especially if you don't feel like teaching scanning
>> and parsing).
>
>JonesForth or any Forth seems like a terrible introduction to
>programming language implementation, since Forth is relatively exotic
>language.

The implementation techniques are similar to those of other languages,
though. And they are reduced to the essentials. E.g., how do you
implement an IF...ENDIF construct? Just the same as in most other
languages, but much simpler to implement. How are calls and returns
implemented? Also similar, with Forth being simpler. Symbol table?
Likewise.

Ok, if you want to study parsing or type checking, you don't study
Forth, but if don't know anything about language implementation yet,
you probably don't want to be confronted with everything at once.
Many textbooks (and the compiler course I teach) start with scanning
and parsing, but if you are more interested in generating running
code, you may not want to start there.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>> and you need to understand Forth, and you need to understand the
>> meta-compilation approach used.
>
>Understanding Forth is probably helpful to understanding any Forth
>implementation no matter how it's written ;-).

Yes, you need to know what the words are supposed to do, but you don't
really need to understand Forth at first whan you approach it from
this direction. That understanding may come during the course of
studing a Forth system like JonesForth (although there have been
complaints here about people who work on Forth implementations but do
not know Forth very well as Forth programmers). You need to
understand much more Forth to understand Forth-in-Forth.

>The metacompilation
>approach would benefit a lot from being clearly documented.

Brad Rodriguez wrote quite a bit about meta-compilation. See
<http://www.bradrodriguez.com/papers/index.html>. Not sure if it fits
the bill.

[Elizabeth D Rather]

On 6/17/2013 6:00 AM, Anton Ertl wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> I've been thinking some more, and I wonder if the best approach might
>> be a Forth-in-Forth with really good introspection and browsing
>> facilities. It'd allow you to browse the dictionary, look at
>> dictionary entries and assembly code, and give you a really easy way
>> to understand what is going on -- once you'd learned which buttons to
>> press.
>
> Something like that is the approach I take in my Forth course. I
> teach them Forth, and in the end, I show them the innards. I use
> DUMP, SEE, SIMPLE-SEE, and SEE-CODE for that. I don't use WORDS or
> other dictionary browsing words for that, though.

I follow a similar path, but focus primarily on showing source, with a
secondary focus on implementation strategy.

[Alex McDonald]

On Jun 17, 9:19 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

And end there.

> but if you are more interested in generating running
> code, you may not want to start there.

Far too much of the average compiler book is given over to scanning,
parsing and handling type systems. The other backend bits -- IL,
optimisation, register allocation, scheduling, code generation --
typically get mentioned briefly somewhere in Chapter 10, right next to
the index. One I picked up at a bookstore yesterday had a single page
on BURGs, yet devoted over a 1000 pages to other, mainly grammar,
topics.

[Albert van der Horst]

In article <0uqdncmMkYGZzSLM...@supernews.com>,

Elizabeth D Rather <era...@forth.com> wrote:
>On 6/17/2013 6:00 AM, Anton Ertl wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> I've been thinking some more, and I wonder if the best approach might
>>> be a Forth-in-Forth with really good introspection and browsing
>>> facilities. It'd allow you to browse the dictionary, look at
>>> dictionary entries and assembly code, and give you a really easy way
>>> to understand what is going on -- once you'd learned which buttons to
>>> press.
>>
>> Something like that is the approach I take in my Forth course. I
>> teach them Forth, and in the end, I show them the innards. I use
>> DUMP, SEE, SIMPLE-SEE, and SEE-CODE for that. I don't use WORDS or
>> other dictionary browsing words for that, though.
>
>I follow a similar path, but focus primarily on showing source, with a
>secondary focus on implementation strategy.

I intend to lighten up yourforth (as I probably are going to name the iso
version of jonesforth) with a number of exercises. They promote investigation
and exploration. About half of the examples they must type in, end in a crash
but I don't tell which.

>
>Cheers,
>Elizabeth
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Gerry Jackson]

Nobody seems to have mentioned MAF which is a Forth in Forth
http://www.forthfreak.net/index.cgi?MAF

"MAF is a minimal ANS Forth. It is written as an educational tool for
anyone planning to implement a Forth and includes extensive
documentation. MAF builds itself from a small kernel of 48 words and
provides all the words from the Core word set together with 25 from
extension word sets which are used in the building process. MAF is also
portable in confining the key decisions, such as dictionary mechanism,
cell size etc., to the kernel, which is detachable. The kernel supplied
is implemented in ANS Forth (so that MAF is ready to run) and intended
to be replaced by an equivalent kernel in Assembler or C"

It's difficult to know what a beginner would make of it.

--
Gerry

[rickman]

On 6/17/2013 6:31 AM, Mark Wills wrote:
> On Sunday, June 16, 2013 12:29:09 AM UTC+1, rickman wrote:
>> On 6/15/2013 5:35 PM, Mark Wills wrote:
>>
>>> On Saturday, June 15, 2013 5:00:39 PM UTC+1, rickman wrote:
>>
>>> Okay. I was specifically talking about their long-retired TMS99xx range, but AFAIK the precedent still stands with TI's other parts, too. It was certainly src-->dest on the TMS340x0 DSPs.

>

> Sorry - my bad. It's MOV SRC,DEST in all cases in TI land, as far as I know.

Ok. Many years ago when I was still learning micros, I bought a
Technico TMS9900 CPU board. It was huge compared to most and the guy
who sold it to me used gave me a monster of a switched power supply with
it. It must have been out of some piece of equipment, a bit too small
for a minicomputer but too big for anything desktop.

I didn't do tons with that machine, but it got me started with the 9900
line and I eventually built a board myself with the 9995 CPU. It was
targeted to turn a Selectric into a printer, but it was too worn to type
well. All the bails and links wear enough that the characters start
moving around as it types. :< My first, but not my last failed project...

I never used the 9995 for anything else. I picked up a Heathkit LSI-11
and started playing with Forth on that. Eventually I got my first PC, a
286 and the rest was history. I even used an old 8088 PC motherboard in
a project as an embedded controller. It booted from floppy disks and
used the on board timer to time events. A bit crude, but no wire
wrapping required!

--

Rick

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> It's useful to understand assembly language for understanding both
> Forth-in-Forth and for understanding Forth-in-assembly.

I suppose it's helpful to understand the concept of addresses, but
if you don't mind a VM implementation like retroforth, you can avoid
assembler altogether.

> Someone who does not know Forth does not know what CREATE does. Also,
> even if they know Forth, they may have no idea how the dictionary is
> implemented.

You mean they don't know the concept of a lookup table indexed by
strings, or you mean they don't understand the Forth approach of a
linear heap? For the former, it may be too early for them to be
implementing low level language interpreters if they don't know basic
data structures. For the latter, I think a high level implementation is
perfectly instructive (example: JSForth).

>> Forth is relatively exotic language.
> The implementation techniques are similar to those of other languages,
> though. And they are reduced to the essentials. E.g., how do you
> implement an IF...ENDIF construct? Just the same as in most other
> languages, but much simpler to implement. How are calls and returns
> implemented? Also similar, with Forth being simpler. Symbol table?
> Likewise.

No I think Forth is more complicated, because of the metaprogramming
stuff, parsing words, deferred words, the general consequences of not
really having separate compilation and interpretation phases but still
having an early-binding compiler, etc. A naive Lisp which is a pure
late-binding interpreter (even macros are just functions that receive
their args unevaluated) is much more conceptually clear, IMHO. After
that, optimizations can be discussed.

> Many textbooks (and the compiler course I teach) start with scanning
> and parsing, but if you are more interested in generating running
> code, you may not want to start there.

I think that is considered an old-fashioned approach. Here is CMU's
class info:

http://www.cs.cmu.edu/~rwh/courses/ppl/

http://www.qatar.cmu.edu/cs/15150/

The textbook is here (1.8MB PDF):

http://www.cs.cmu.edu/~rwh/plbook/book.pdf

It is an upper-level class though, not intro CS. The intro CS class
recently started using ML, and has apparently been successful:

http://www.qatar.cmu.edu/cs/15150/about.shtml

There are some posts about it on Harper's blog.