Oforth manual and V0.9.25 released

[franck....@gmail.com]

Hello clf,

Oforth manual is released... at last.
You can download it here : http://www.oforth.com/doc

This is the first version and it has not been reviewed yet, so
please be understanding (my english is far from fluent...)

This manual comes with Oforth V0.9.25.
Warning : this version, that prepares Oforth V1.0, is not compatible
with the previous one (see changelog).

Have fun,
Franck
http://www.oforth.com

[Cecil Bayona]

Thank you very much, I will be looking at it in the next few days in
detail. I took a brief look and it looks great, just checking what
subjects are covered.

I hope in a few days wait to see if there are corrections, if not then I
will print out a copy for reference. I been trying to write a test
program comparing Oforth, 8th, and VFX Forth and I had put off the
Oforth version due to lack of documentation, but now I should be able to
make some progress.

Thanks
--
Cecil - k5nwa

[Ron Aaron]

On 24/09/2016 23:10, franck....@gmail.com wrote:
> Hello clf,
>
> Oforth manual is released... at last.
> You can download it here : http://www.oforth.com/doc
>
> This is the first version and it has not been reviewed yet, so
> please be understanding (my english is far from fluent...)

Good first effort!

[Albert van der Horst]

In article <7c7971f7-72eb-4d28...@googlegroups.com>,

<franck....@gmail.com> wrote:
>Hello clf,
>
>Oforth manual is released... at last.
>You can download it here : http://www.oforth.com/doc
>
>This is the first version and it has not been reviewed yet, so
>please be understanding (my english is far from fluent...)
>
>This manual comes with Oforth V0.9.25.
>Warning : this version, that prepares Oforth V1.0, is not compatible
>with the previous one (see changelog).

I didn't read doc yet but there is a classical mistake in
the website, the examples using a proportional script.
Especially in

: hello "Hello, World" . ;

the spaces and the interpunction flow together.

The website has a small font. If I increase that to comfortable,
the website needs sideways scolling.

The linewidth is way over the optimal reading length of 55-60 chars
and it is forced.

>
>Have fun,
>Franck
>http://www.oforth.com
>

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

[franck....@gmail.com]

You're welcome.

I had in mind to release the manual for the V1.0 but, thanks to you,
I changed my mind and made it a priority. V1.0 can wait a little more...

[franck....@gmail.com]

Thanks, Ron.

[franck....@gmail.com]

That is strange because a non-proportional font is used for code
(Lucida console). Perhap's another one should be used.

What browser do you use ? On which OS ?

[Doug Hoffman]

On 9/24/16 4:10 PM, franck....@gmail.com wrote:

> Oforth manual is released... at last.

Good job with the manual Franck. I know that must have been a lot of
work by itself. I especially like the tables starting on p. 96 where one
can see the large reduction in number of words thanks to messaging
(e.g., max/fmax/dmax -> max).

> Warning : this version, that prepares Oforth V1.0, is not compatible
> with the previous one (see changelog).

I see you made some more changes to make Oforth even more familiar to
the Forth user: \ is now for comments, you have deferred words. Nice.

-Doug

[Doug Hoffman]

On 9/25/16 6:02 AM, Albert van der Horst wrote:

> I didn't read doc yet but there is a classical mistake in
> the website, the examples using a proportional script.
> Especially in
>
> : hello "Hello, World" . ;
>
> the spaces and the interpunction flow together.

They look fine to me. Safari browser.

> The website has a small font. If I increase that to comfortable,
> the website needs sideways scolling.
>
> The linewidth is way over the optimal reading length of 55-60 chars
> and it is forced.

I'm not having those problems either. ??

-Doug

[franck....@gmail.com]

Thank you, Doug.

In fact, for the first Oforth version, I worked alone and choose names very
freely (I didn't even know about clf before it was released).
At that time, I suppose Oforth source might be perceived very odd.

Since then, when it was possible, I tried to make changes to stick to
standard (naming and features). Hence, \ for commentaries.

For deferred words, I was not sure that they could be added, because, imo,
they could bring to security issues and don't fit well with the task
isolation model. But, there is a way to freeze them (using freeze as for
ArrayBuffers, ...). So one is well-informed and can decide to keep a
deferred word updatable or not.

Franck

[Albert van der Horst]

In article <cb977291-bc33-4d1c...@googlegroups.com>,
<franck....@gmail.com> wrote:
>Le dimanche 25 septembre 2016 11:53:43 UTC+2, Albert van der Horst a =C3=A9=
>crit=C2=A0:

>> In article <7c7971f7-72eb-4d28...@googlegroups.com>,
>> <franck....@gmail.com> wrote:
>> >Hello clf,
>> >
>> >Oforth manual is released... at last.
>> >You can download it here : http://www.oforth.com/doc
>> >
>> >This is the first version and it has not been reviewed yet, so
>> >please be understanding (my english is far from fluent...)
>> >
>> >This manual comes with Oforth V0.9.25.
>> >Warning : this version, that prepares Oforth V1.0, is not compatible
>> >with the previous one (see changelog).

>>=20

>> I didn't read doc yet but there is a classical mistake in
>> the website, the examples using a proportional script.
>> Especially in

>>=20
>> : hello "Hello, World" . ;
>>=20

>> the spaces and the interpunction flow together.

>>=20

>> The website has a small font. If I increase that to comfortable,
>> the website needs sideways scolling.

>>=20

>> The linewidth is way over the optimal reading length of 55-60 chars
>> and it is forced.

>>=20

>> >
>> >Have fun,
>> >Franck
>> >http://www.oforth.com
>> >

>>=20
>> Groetjes Albert
>> --=20

>> Albert van der Horst, UTRECHT,THE NETHERLANDS
>> Economic growth -- being exponential -- ultimately falters.

>> albert@spe&ar&c.xs4all.nl &=3Dn http://home.hccnet.nl/a.w.m.van.der.horst
>
>That is strange because a non-proportional font is used for code=20

>(Lucida console). Perhap's another one should be used.
>
>What browser do you use ? On which OS ?

I'm talking about e.g. the example fact in the home page
http://www.oforth.com/
It is important because apparently fact( is intended,
there is no space before the bracket.

I looked into the page source.
It says class=example. So the font comes in indirectly.

OS:
Linux version 3.2.0-4-amd64 (debian...@lists.debian.org) (gcc version 4.6.3
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.81-2
Browser:
Mozilla Iceweasel 38.8.0

I enlarged and double checked.

Groetjes Albert

P.S. I didn't look deeply into it yet, but the manual looks good.
If there are language deficiency, they don't detract from the
content.

[Doug Hoffman]

On 9/25/16 1:44 PM, Albert van der Horst wrote:

> I'm talking about e.g. the example fact in the home page
> http://www.oforth.com/
> It is important because apparently fact( is intended,
> there is no space before the bracket.

It appears that a space before the paren is optional.

So
: fact( n -- n1 ) | i | 1 n loop: i [ i * ] ;
is identical to
: fact ( n -- n1 ) | i | 1 n loop: i [ i * ] ;

with either resulting in the same definition named fact

Gleaned from observing the behavior of compiled code.

-Doug

[franck....@gmail.com]

Le dimanche 25 septembre 2016 19:35:37 UTC+2, Albert van der Horst a écrit :
>
> I'm talking about e.g. the example fact in the home page
> http://www.oforth.com/
> It is important because apparently fact( is intended,
> there is no space before the bracket.
>
> I looked into the page source.
> It says class=example. So the font comes in indirectly.
>
> OS:
> Linux version 3.2.0-4-amd64 (debian...@lists.debian.org) (gcc version 4.6.3
> (Debian 4.6.3-14) ) #1 SMP Debian 3.2.81-2
> Browser:
> Mozilla Iceweasel 38.8.0
>
> I enlarged and double checked.
>
> Groetjes Albert
>
> P.S. I didn't look deeply into it yet, but the manual looks good.
> If there are language deficiency, they don't detract from the
> content.
>
> 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

This is an (hard coded) recogniser. See Oforth manual chapter 2.1 :)
Some words are detected by the interpreter even if not separated by spaces
and "(" and ")" words are part of them.

btw, if you are still working on a lisp interpreter, imo, you could
have the same behavior : ( and ) words could be detected directly
by parse (or parse-name). If so, your interpreter could natively read lisp
code.

Franck

[Albert van der Horst]

In article <ae263410-268e-4f52...@googlegroups.com>,
<franck....@gmail.com> wrote:
>Le dimanche 25 septembre 2016 19:35:37 UTC+2, Albert van der Horst a =C3=A9=
>crit=C2=A0:
>>=20

>> I'm talking about e.g. the example fact in the home page
>> http://www.oforth.com/
>> It is important because apparently fact( is intended,
>> there is no space before the bracket.

>>=20

>> I looked into the page source.

>> It says class=3Dexample. So the font comes in indirectly.
>>=20
>> OS:
>> Linux version 3.2.0-4-amd64 (debian...@lists.debian.org) (gcc version=

> 4.6.3
>> (Debian 4.6.3-14) ) #1 SMP Debian 3.2.81-2
>> Browser:
>> Mozilla Iceweasel 38.8.0

>>=20

>> I enlarged and double checked.

>>=20
>> Groetjes Albert
>>=20

>> P.S. I didn't look deeply into it yet, but the manual looks good.
>> If there are language deficiency, they don't detract from the
>> content.

>>=20
>> Groetjes Albert
>> --=20

>> Albert van der Horst, UTRECHT,THE NETHERLANDS
>> Economic growth -- being exponential -- ultimately falters.

>> albert@spe&ar&c.xs4all.nl &=3Dn http://home.hccnet.nl/a.w.m.van.der.horst

>
>This is an (hard coded) recogniser. See Oforth manual chapter 2.1 :)
>Some words are detected by the interpreter even if not separated by spaces
>and "(" and ")" words are part of them.
>
>btw, if you are still working on a lisp interpreter, imo, you could
>have the same behavior : ( and ) words could be detected directly
>by parse (or parse-name). If so, your interpreter could natively read lisp
>code.

I don't need to add any words to the basic ciforth for that.
: fact ." parsing fart " ; PREFIX
: ( ." parsing bracket " ; PREFIX

fact(12 3 +

parsing fart parsing bracket OK
.
15 OK
This is a "recognizer" but its only merit is that the word
is recognized without a trailing space.

That is the point of my exercise, can forth be the implementation
language of lisp?
This is the next station:
(* 12 4 (+ 1 2 3 4 ) )

Of course a lisp that requires spaces
would be just as powerful, it would look like reversed
polish reversed back notation, instead of Lisp.

( * 12 4 ( + 1 2 3 4 ) 5 )

I'm trying to find out whether a parse tree must be build for the
whole expression, or while building the tree the + is evaluated,
such that the last object to be evaluated is
`( * 12 4 10 5 )`
where the backquotes denote some internal parse representation.
This could be a noname word that decompiles to
:NONAME *-lisp 12 4 10 5 ;
where 12 etc are present in the dictionary as lisp-CONSTANTS.

I can implement both easily.

Forthers take care, what Lisp calls evaluate is in fact our
execute. Read is our compilation. Sort of.

>
>Franck

[Paul Rubin]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> ( * 12 4 ( + 1 2 3 4 ) 5 )
> I'm trying to find out whether a parse tree must be build for the
> whole expression, or while building the tree the + is evaluated

You would normally read the whole expression and then evaluate it. I've
never seen a lisp that evaluates concurrently with reading, except
through things like read macros. Try to relax your Forth reflex of
feeling pain at the thought of temporarily allocating a half dozen extra
cons nodes. They get gc'd, and also, Lisp historically always ran on
relatively large machines compared to typical Forth platforms.

Lisp's heyday was more or less in the same era as Forth's (1980s) but
most interesting Lisp projects at that time ran on 32- or 36-bit
machines with a megabyte or more of memory, while Forth typically ran on
8- or 16-bit machines with 64k or less. Lisp had the reputation of
being a horrible memory hog, but these days of course, 1MB is nothing.

Anyway, it is ok in Lisp to read in an entire large function as an
S-expression before trying to process it.

[Lars Brinkhoff]

> Albert van der Horst wrote:

> > I'm trying to find out whether a parse tree must be build for the
> > whole expression, or while building the tree the + is evaluated

Read it all first, then evaluate.

Paul Rubin wrote:
> You would normally read the whole expression and then evaluate it.
> I've never seen a lisp that evaluates concurrently with reading

As far as I know, that has never been seriously considered, other than
as a thought experiment:

http://www.nhplace.com/kent/PS/Ambitious.html

[franck....@gmail.com]

Le lundi 26 septembre 2016 10:37:49 UTC+2, Albert van der Horst a écrit :
> This is a "recognizer" but its only merit is that the word
> is recognized without a trailing space.
>

Same here, The only merit is that ( and ) are recognized without
trailing space.

> I'm trying to find out whether a parse tree must be build for the
> whole expression, or while building the tree the + is evaluated,
> such that the last object to be evaluated is
> `( * 12 4 10 5 )`
> where the backquotes denote some internal parse representation.
>

> 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

I know almost nothing about lisp so I can't say, but, imo, a parse tree
must be build, or, at least, take care of some special lisp functions.

For instance (if I remember well) :

( if t x y )

x and y are not evaluated immediately. According to evaluation of t,
either x is evaluated or y is evaluated.

But I may be wrong, my knwoledge on Lisp is very limited.

[Albert van der Horst]

In article <8760pj8...@jester.gateway.pace.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>> ( * 12 4 ( + 1 2 3 4 ) 5 )
>> I'm trying to find out whether a parse tree must be build for the
>> whole expression, or while building the tree the + is evaluated
>
>You would normally read the whole expression and then evaluate it. I've
>never seen a lisp that evaluates concurrently with reading, except
>through things like read macros. Try to relax your Forth reflex of
>feeling pain at the thought of temporarily allocating a half dozen extra
>cons nodes. They get gc'd, and also, Lisp historically always ran on
>relatively large machines compared to typical Forth platforms.

So ( is not a "read macro". learned something. The pain is not in
defining all those cons nodes. The pain is to construct some reference
to (+ 1 2 3 4) in the * lisp, while an evaluate would allow
to replace it with a single node.

>
>Lisp's heyday was more or less in the same era as Forth's (1980s) but
>most interesting Lisp projects at that time ran on 32- or 36-bit
>machines with a megabyte or more of memory, while Forth typically ran on
>8- or 16-bit machines with 64k or less. Lisp had the reputation of
>being a horrible memory hog, but these days of course, 1MB is nothing.
>
>Anyway, it is ok in Lisp to read in an entire large function as an
>S-expression before trying to process it.

S-expression? Another interesting word to lookup.

That word is not used in the siod sources, nor even the word
expression for that matter.

[Albert van der Horst]

In article <861t07f...@molnjunk.nocrew.org>,

Lars Brinkhoff <lars...@nocrew.org> wrote:
>> Albert van der Horst wrote:
>> > I'm trying to find out whether a parse tree must be build for the
>> > whole expression, or while building the tree the + is evaluated
>
>Read it all first, then evaluate.

I quote form your reference below:
(disadvantage of char by char reading and handling rubouts:)

"
Syntax errors are not detected in a timely way. For example, in the
case of typing a multi-line expression with each line ended by Return,
the entire expression must be retyped to correct an error on any line.
"
Now suppose we have
(* 2 3 (+ 12 4 Q )
...
...
...
)

If Q is an unbound variable, that is only detected when Q is evaluated.
Apparently that is detected at the last closing bracket.
So the whole expression must be retyped.
I've tried it, and it is indeed the way Guile works on Debian.
That settles the question if there is any halfway evaluation.
This make this unbound Q probably a runtime error,

But with respect to the detection of syntax errors:
I don't succeed in generating a syntax error that is detected
before the multiline expression ends.

>
>Paul Rubin wrote:
>> You would normally read the whole expression and then evaluate it.
>> I've never seen a lisp that evaluates concurrently with reading
>
>As far as I know, that has never been seriously considered, other than
>as a thought experiment:
>
>http://www.nhplace.com/kent/PS/Ambitious.html

I see there a wrapper around the input that only passes cooked
characters. It doesn't even strike me as a Lisp issue.
I have this primitive lisp compiled from c-source, and it only
recognizes the rubout key. (siod)
Now if I call it as
rlwrap siod
then I have the whole emacs line editing available and can retrieve
previous commands by cursor up.
This issue seems to have little bearing on the original matter.
(rlwrap works the same on my Forth interpreter too).

But then this reference goes on about "design decisions
inherent in a Read-Eval-Print loop" and says
" but it's important to understand nature doesn't call for this behavior."
so apparently my question about evaluation while reading
was quite a fundamental question.
For a lisper it seems hard to realize there was a choice there.

It is interesting that the above quote presents an example that has
an equivalent interpretation difficulty in Forth:
DECIMAL
: test HEX 12 ;
The 12 is interpreted in DECIMAL. We could have made HEX
IMMEDIATE and then it would be hex, but we didn't.

In my efforts I will of course stick to classic lisp behaviour.
Implementing an "ambitious evaluator" sounds scary.

[lawren...@gmail.com]

On Monday, September 26, 2016 at 11:16:46 PM UTC+13, Albert van der Horst wrote:
> Syntax errors are not detected in a timely way. For example, in the
> case of typing a multi-line expression with each line ended by Return,
> the entire expression must be retyped to correct an error on any line.

Or you could use a notebook-type interface <http://jupyter.org/>. Look, someone has done a Jupyter kernel for Common Lisp <https://github.com/fredokun/cl-jupyter>.

[Paul Rubin]

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

> Syntax errors are not detected in a timely way. For example, in the
> case of typing a multi-line expression with each line ended by Return,
> the entire expression must be retyped to correct an error on any line.

In practice people usually write lisp code in an editing window that can
send the current function to the lisp evaluator.

Btw, I remembered that the TRAC(tm) language used what KMP calls
ambitious evaluation:

https://www.cs.rit.edu/~swm/cs450/TRAC.pdf
https://github.com/natkuhn/Trac-in-Python

[Albert van der Horst]

In article <87k2dx7...@jester.gateway.pace.com>,

You make it seem that I said that. It was a quote from that
article. If I'm trying my hand on a simple lisp I certainly
will not try to detect syntax errors in multi line expressions.

My question still stands, give an example of an syntax error
in LISP, which to me means something detected while reading
not evaluating. Or do lispers call evaluating an unbound
variable a syntax error?

Groetjes Albert

Groetjes

[Albert van der Horst]

In article <d2457423-b1c4-4f6b...@googlegroups.com>,

Sorry. I quoted the above behaviour, so you're wrong to attribute it
to me. You suggest something to me, apparently because you think I think
it is a problem. But I merely try to understand the LISP REPL
better.

It happens to be different from Forth compilation, but I can't say
it is a big deal to me either way.

[Paul Rubin]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> My question still stands, give an example of an syntax error
> in LISP, which to me means something detected while reading
> not evaluating.

Unbalanced parentheses, like )()))(((((((( is an example.

[franck....@gmail.com]

Le lundi 26 septembre 2016 10:37:49 UTC+2, Albert van der Horst a écrit :
> This is a "recognizer" but its only merit is that the word
> is recognized without a trailing space.
>
> That is the point of my exercise, can forth be the implementation
> language of lisp?
> This is the next station:
> (* 12 4 (+ 1 2 3 4 ) )
>
> Of course a lisp that requires spaces
> would be just as powerful, it would look like reversed
> polish reversed back notation, instead of Lisp.
>
> ( * 12 4 ( + 1 2 3 4 ) 5 )
>

Using the output interpreter to parse lisp code is interesting.
Here is a very basic lisp parser (no error detection) :

: decode( token -- x )
\ if token is ")" creates a Pair, otherwise an integer, a float or a symbol.
token "(" == ifTrue: [ -1 swap return ]
token ")" == ifTrue: [ null swap #[ Pair new ] times return ]
token asInteger dup ifNotNull: [ return ] drop
token asFloat dup ifNotNull: [ return ] drop
token asSymbol
;

: lisp-parse \ string -- aPair
\ Fill console input with lisp programm and parse tokens
System.Console refill
0 while( parse-name dup notEmpty ) [ decode swap 1+ ] 2drop
;


This parsing :
- Maps Lisp numbers to numbers (integers or floats).
- Maps Lisp symbols to symbols
- Maps Lisp empty list to null.
- Maps Lisp lists to a linked list of Pairs : [ x, next ].

Tests :

"()" lisp-parse
.
null ok

"(* 12 4 (+ 1 2 3 4 ))" lisp-parse
.s
[1] (Pair) [*, [12, [4, [[+, [1, [2, [3, [4, null]]]]], null]]]] ok


"(defun factorial (N) (if (= N 1) 1 (* N (factorial (- N 1)))))" lisp-parse
.s
[1] (Pair) [defun, [factorial, [[N, null], [[if, [[=, [N, [1, null]]], [1,
[[*, [N, [[factorial, [[-, [N, [1, null]]], null]], null]]], null]]]], null]]]]
ok

[luser droog]

On Monday, September 26, 2016 at 3:37:49 AM UTC-5, Albert van der Horst wrote:
>
> That is the point of my exercise, can forth be the implementation
> language of lisp?
> This is the next station:
> (* 12 4 (+ 1 2 3 4 ) )
>
> Of course a lisp that requires spaces
> would be just as powerful, it would look like reversed
> polish reversed back notation, instead of Lisp.
>
> ( * 12 4 ( + 1 2 3 4 ) 5 )
>

If it doesn't take you too far afield, you might want to
investigate the Logo language which is a Lisp with fixed
arity, allowing unparenthesized forward-Polish expressions.