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

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

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

[Madhu]

* Paul Rubin <87k2dx7...@jester.gateway.pace.com> :
Wrote on Mon, 26 Sep 2016 22:35:54 -0700:

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

The Lispworks listener is essentially an emacs-editor input: it uses
some ambitious evaluation to signal mismatched parenthesis and other
syntax errors -- which seems to be the the best of all possible worlds
(except I couldn't hack it so the final paren automatically sends the
form for evaluation as soon as it is typed)

[reinstated from the original poster upthread:]

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

I don't believe this is true. This was realized rightaway when the
1) language desingers chose to make a distinction between READ time and
EVAL time,
2) one understands what "code = data" means in lisp.

Remember the reader algorithm is also specified in common lisp.


I couldn't find kmp's classic example for this: The read/print
algorithms also depend on various READ-* PRINT-* dynamic variables which
control how the form is read or how it is printed. These well-defined
semantics when the "unit" is a form would have to be broken/ignored if
you want to intrepret partially read forms.

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

As the pithy goes:

Ambition destroys its possessor

in the case of R-E-P, ambition cerainly destroys the form that is being
built up partially

[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

[Elias Mårtenson]

On Tuesday, 27 September 2016 19:31:02 UTC+8, Albert van der Horst wrote:

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

In Lisp, the reader will read #\Space, #\Newline, etc… as the respecting literal characters. Trying to read #\Foo would result in a read-time error.

Lisp also allows you to specufy code that is evaluated during read-time. Thus, while FOO will not be a read-time error, #.FOO is.

Elias

[Lars Brinkhoff]

Albert van der Horst wrote:
> My question still stands, give an example of an syntax error
> in LISP, which to me means something detected while reading
> not evaluating.

Huh? That's easy. Just one off the top of my mind:

(read-from-string "(foo")

Just to be clear: READ-FROM-STRING does the reading. "(foo" is the
input which raises an error. This only involved the Lisp reader, no
evaluation.

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

[Albert van der Horst]

In article <f9f374b7-039d-437d...@googlegroups.com>,

=?UTF-8?Q?Elias_M=C3=A5rtenson?= <lok...@gmail.com> wrote:
>On Tuesday, 27 September 2016 19:31:02 UTC+8, Albert van der Horst wrote:
>
>> 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?
>

>In Lisp, the reader will read #\Space, #\Newline, etc=E2=80=A6 as the respe=
>cting literal characters. Trying to read #\Foo would result in a read-time =
>error.
>
>Lisp also allows you to specufy code that is evaluated during read-time. Th=

>us, while FOO will not be a read-time error, #.FOO is.

Thanks that fills a hole in my understanding of lisp.

The Forth jargon is totally different.
"Forth also allows you to specify code that is interpreted while compiling."
means essentially the same thing. In Forth you specify that by
attaching a property to a named word, not by syntactical means.

>
>Elias

[Paul Rubin]

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

>>Lisp also allows you to specufy code that is evaluated during read-time.

> Thanks that fills a hole in my understanding of lisp.

That's a feature of Common Lisp called "reader macros". They are
sometimes useful, but lots of other Lisps don't have them and get along
ok without them. They're different from syntactic macros, which are
present in most Lisps. Scheme doesn't have reader macros.

http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_r.htm#reader_macro
is a brief gloss on how they work in CL.

Several online Lisp books are linked from here: http://www.lispmachine.net/

[Albert van der Horst]

In article <8737kl7...@jester.gateway.pace.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>Lisp also allows you to specufy code that is evaluated during read-time.
>> Thanks that fills a hole in my understanding of lisp.
>
>That's a feature of Common Lisp called "reader macros". They are
>sometimes useful, but lots of other Lisps don't have them and get along
>ok without them. They're different from syntactic macros, which are
>present in most Lisps. Scheme doesn't have reader macros.

This looks pretty similar to a technique I use.

This is the way my Forth recognizes a word in the input as a number:
[- the word is not otherwise known ]
- the word starts with 7. 7 is known as a prefix.
- control is passed to 7's code and it parses a number.

Of course Forth will leave the number on the stack. From this stage
on lisp will do something different.

>
>http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_r.htm#reader_macro
>is a brief gloss on how they work in CL.
>
>Several online Lisp books are linked from here: http://www.lispmachine.net/

Useful links. Can keep someone busy for a while.

Groetjes Albert