Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #51247 > unrolled thread

Oforth manual and V0.9.25 released

Back to article view | Back to comp.lang.forth

Contents

  Oforth manual and V0.9.25 released franck.bensusan@gmail.com - 2016-09-24 13:10 -0700
    Re: Oforth manual and V0.9.25 released Cecil Bayona <cbayona@cbayona.com> - 2016-09-24 17:28 -0500
      Re: Oforth manual and V0.9.25 released franck.bensusan@gmail.com - 2016-09-25 03:25 -0700
    Re: Oforth manual and V0.9.25 released Ron Aaron <rambamist@gmail.com> - 2016-09-25 06:38 +0300
      Re: Oforth manual and V0.9.25 released franck.bensusan@gmail.com - 2016-09-25 03:25 -0700
    Re: Oforth manual and V0.9.25 released albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-25 12:02 +0200
      Re: Oforth manual and V0.9.25 released franck.bensusan@gmail.com - 2016-09-25 03:28 -0700
        Re: Oforth manual and V0.9.25 released albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-25 19:44 +0200
          Re: Oforth manual and V0.9.25 released Doug Hoffman <glidedog@gmail.com> - 2016-09-25 21:47 -0400
          Re: Oforth manual and V0.9.25 released franck.bensusan@gmail.com - 2016-09-26 01:03 -0700
            Re: Oforth manual and V0.9.25 released albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 10:46 +0200
              Re: Oforth manual and V0.9.25 released Paul Rubin <no.email@nospam.invalid> - 2016-09-26 01:50 -0700
                Re: Oforth manual and V0.9.25 released Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-26 11:00 +0200
                  Lisp on Forth was Re: Oforth manual and V0.9.25 released albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 12:25 +0200
                    Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released lawrencedo99@gmail.com - 2016-09-26 21:30 -0700
                      Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 14:32 +0200
                    Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released Paul Rubin <no.email@nospam.invalid> - 2016-09-26 22:35 -0700
                      Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 13:40 +0200
                        Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released Paul Rubin <no.email@nospam.invalid> - 2016-09-27 08:01 -0700
                Re: Oforth manual and V0.9.25 released albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 11:24 +0200
              Re: Oforth manual and V0.9.25 released franck.bensusan@gmail.com - 2016-09-26 02:05 -0700
              Re: Oforth manual and V0.9.25 released franck.bensusan@gmail.com - 2016-09-27 15:18 -0700
              Re: Oforth manual and V0.9.25 released luser droog <mijoryx@yahoo.com> - 2016-09-27 23:37 -0700
      Re: Oforth manual and V0.9.25 released Doug Hoffman <glidedog@gmail.com> - 2016-09-25 06:45 -0400
    Re: Oforth manual and V0.9.25 released Doug Hoffman <glidedog@gmail.com> - 2016-09-25 06:39 -0400
      Re: Oforth manual and V0.9.25 released franck.bensusan@gmail.com - 2016-09-25 05:01 -0700

Page 1 of 2  [1] 2  Next page →

#51247 — Oforth manual and V0.9.25 released

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

[toc] | [next] | [standalone]

#51252

On 9/24/2016 3:10 PM, franck.bensusan@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).
>
> Have fun,
> Franck
> http://www.oforth.com
>

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

[toc] | [prev] | [next] | [standalone]

#51277

Le dimanche 25 septembre 2016 00:28:56 UTC+2, Cecil - k5nwa a écrit :
> On 9/24/2016 3:10 PM, franck.bensusan@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).
> >
> > Have fun,
> > Franck
> > http://www.oforth.com
> >
> 
> 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

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

[toc] | [prev] | [next] | [standalone]

#51260

On 24/09/2016 23:10, franck.bensusan@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!

[toc] | [prev] | [next] | [standalone]

#51278

Le dimanche 25 septembre 2016 05:38:32 UTC+2, Ron Aaron a écrit :
> On 24/09/2016 23:10, franck.bensusan@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!

Thanks, Ron. 

[toc] | [prev] | [next] | [standalone]

#51273

In article <7c7971f7-72eb-4d28-925c-64444e025837@googlegroups.com>,
 <franck.bensusan@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

[toc] | [prev] | [next] | [standalone]

#51279

Le dimanche 25 septembre 2016 11:53:43 UTC+2, Albert van der Horst a écrit :
> In article <7c7971f7-72eb-4d28-925c-64444e025837@googlegroups.com>,
>  <franck.bensusan@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

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 ?

[toc] | [prev] | [next] | [standalone]

#51286

In article <cb977291-bc33-4d1c-ada0-850d8abd2dc7@googlegroups.com>,
 <franck.bensusan@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-925c-64444e025837@googlegroups.com>,
>>  <franck.bensusan@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-kernel@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

[toc] | [prev] | [next] | [standalone]

#51304

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

[toc] | [prev] | [next] | [standalone]

#51314

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-kernel@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

[toc] | [prev] | [next] | [standalone]

#51315

In article <ae263410-268e-4f52-afcf-ab3f9e4089ba@googlegroups.com>,
 <franck.bensusan@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-kernel@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

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

[toc] | [prev] | [next] | [standalone]

#51316

albert@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.

[toc] | [prev] | [next] | [standalone]

#51317

> 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

[toc] | [prev] | [next] | [standalone]

#51322 — Lisp on Forth was Re: Oforth manual and V0.9.25 released

In article <861t07f32y.fsf@molnjunk.nocrew.org>,
Lars Brinkhoff  <lars.spam@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.

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

[toc] | [prev] | [next] | [standalone]

#51354 — Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released

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

[toc] | [prev] | [next] | [standalone]

#51377 — Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released

In article <d2457423-b1c4-4f6b-9422-defb4be0b5b3@googlegroups.com>,
 <lawrencedo99@gmail.com> wrote:
>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>.

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.

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

[toc] | [prev] | [next] | [standalone]

#51358 — Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released

albert@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

[toc] | [prev] | [next] | [standalone]

#51371 — Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released

In article <87k2dx7vlx.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>albert@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

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, 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

[toc] | [prev] | [next] | [standalone]

#51389 — Re: Lisp on Forth was Re: Oforth manual and V0.9.25 released

albert@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.

[toc] | [prev] | [next] | [standalone]

#51320

In article <8760pj82oq.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>albert@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.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web