Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #38642 > unrolled thread
| Started by | JennyB <jennybrien@googlemail.com> |
|---|---|
| First post | 2015-04-27 01:34 -0700 |
| Last post | 2015-05-03 20:38 +0200 |
| Articles | 20 on this page of 124 — 11 participants |
Back to article view | Back to comp.lang.forth
SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 01:34 -0700
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-27 14:52 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-27 21:17 +0200
Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-28 09:41 -0700
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 16:53 +0100
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 17:02 +0100
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 10:23 -0700
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 10:02 -0700
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 17:15 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 23:38 +0200
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 14:52 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 17:09 +0100
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 16:54 +0000
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-28 09:11 +0000
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-28 04:28 -0700
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-29 13:49 -0700
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-30 00:13 +0200
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 06:32 +0000
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-30 05:22 -0700
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 15:27 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-30 19:16 +0100
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 21:08 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-30 23:05 +0100
Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-30 15:47 -0700
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-01 12:29 +0100
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:25 +0000
Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-30 17:07 -0700
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 02:40 -0700
Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-05-01 10:24 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 22:55 +0200
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-02 01:32 -0700
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:27 +0000
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-03 08:36 -0700
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:44 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:37 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 01:33 +0200
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 03:15 -0700
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-01 12:47 +0000
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 10:29 -0700
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-01 20:32 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:51 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:29 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 14:59 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:11 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 12:04 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 03:22 +0200
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 11:09 +0000
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:30 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:58 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-02 20:42 +0200
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:28 +0000
Re: SET-COMPILER Mark Wills <markwills1970@gmail.com> - 2015-05-06 04:14 -0700
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 23:57 -0700
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 11:41 +0000
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:51 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 17:00 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-03 11:19 +0100
Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-03 07:30 -0700
Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-03 21:45 +0200
Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-03 21:48 +0200
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 22:03 +0100
Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-05 22:56 +0000
PREFIX JennyB <jennybrien@googlemail.com> - 2015-05-06 02:30 -0700
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 12:23 +0000
Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 16:44 +0100
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 16:03 +0000
Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 17:40 +0100
Re: PREFIX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-06 19:44 +0000
Re: PREFIX Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-06 22:05 +0200
Re: PREFIX Bernd Linsel <bl1@gmx.com> - 2015-05-07 04:23 +0200
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:48 +0000
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 12:04 +0000
Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:55 +0000
Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 14:20 +0100
Re: PREFIX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-06 19:41 +0000
Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 12:29 +0000
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 15:07 +0100
Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-09 03:02 -0700
Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-09 17:23 +0100
Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 08:07 +0100
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 11:20 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-12 10:05 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 18:34 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-12 12:07 -0700
Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-12 22:11 +0200
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 21:35 +0100
Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-13 01:31 +0200
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 16:20 +0000
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-13 12:20 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-13 22:24 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-14 11:26 +0000
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:00 -0700
Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-14 08:06 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 17:21 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:31 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 19:41 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:49 -0700
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 09:41 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 12:19 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 14:42 +0000
Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-15 10:37 -0700
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 23:00 +0100
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 13:52 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-16 19:24 +0100
Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-16 13:26 -0700
Re: Recognizer RfD was Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-17 00:27 +0200
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-17 10:03 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-17 23:25 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 10:02 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 12:35 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 15:33 +0000
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 14:01 +0000
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 13:14 +0000
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 17:07 +0000
Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-14 03:27 +0200
Re: Recognizer RfD was Re: SET-COMPILER hughaguilar96@gmail.com - 2015-05-13 19:23 -0700
Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-14 01:08 -0700
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 14:30 +0000
Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-14 03:40 +0200
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 13:26 +0000
Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 21:33 +0100
Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-13 10:36 +0000
Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 16:06 +0000
Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-03 20:38 +0200
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 15:51 +0000 |
| Message-ID | <2015May2.175103@mips.complang.tuwien.ac.at> |
| In reply to | #38752 |
JennyB <jennybrien@googlemail.com> writes:
>On Friday, 1 May 2015 13:47:57 UTC+1, Albert van der Horst wrote:
>Dual-wordlist Forths are interseting, but they can never
>be fully Standard.
Sure they can. Given enough thrust, even pigs can fly. But it is
really simpler to implement the standard in a different way.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 15:29 +0000 |
| Message-ID | <2015May2.172921@mips.complang.tuwien.ac.at> |
| In reply to | #38737 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>JennyB wrote:
>
>> If the xt is a single point of reference (as it has to be for SET-COMPILER
>> to work) is there any reason why there should not be a a 1:1
>> correspondence of xt to wordname, and the nt used by TRAVERSE-WORDLIST be
>> the xt?
>
>Remaining reason: SYNONYMs. I suppose that a synonym has the same xt as its
>original definition, but a different name. So you want TRAVERSE-WORDLIST to
>encounter both names, but not the same xt twice.
Why not? I see no restriction in the definition of SYNONYM or
TRAVERSE-WORDLIST that requires the synonym to have the same xt (nor
is there a requirement for a different xt), or that you get only
unique names when you apply NAME>INTERPRET to the nts produced by
TRAVERSE-WORDLIST. And I can think of implementations with all
variations of behaviour.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 14:59 +0000 |
| Message-ID | <2015May2.165924@mips.complang.tuwien.ac.at> |
| In reply to | #38725 |
JennyB <jennybrien@googlemail.com> writes:
>On Thursday, 30 April 2015 07:32:19 UTC+1, Stephen Pelc wrote:
>> On Wed, 29 Apr 2015 13:49:07 -0700 (PDT), JennyB
>> <jennybrien@googlemail.com> wrote:
>> >What is the use case for applying interp-compile to either?
>>=20
>> For making a system easy to use - basically for convenience. A
>> classic is a system that supports interpretation of S". Then you
>> may need to reuse the interpretation behaviour of S" in another
>> parsing word. Now you want/need to be able to compile the
>> interpretation behaviour of S". To make life easy, we
>> have a word [INTERP] <name> (by comparison with the old [COMPILE])
>> such that [INTERP] compiles the interpretation behaviour of whatever
>> it encounters.
>
>Yes, of course! If we don't want to add more words to the Standard, that's=
> exactly what [COMPILE] does, isn't it? It appends the xt's behaviour to t=
>he definition, regardless of any special compiling action that might be ass=
>ociated with it.
No.
|6.2.2530 [COMPILE]
|
|[...] If name has other than default compilation semantics, append
|them to the current definition; otherwise append the execution
|semantics of name. [...]
For traditional single-xt+immediate systems, it treats the following
word as non-immediate. But for a system like VFX, things are more
complex. I would not be surprised if one could find bugs in VFX when
it comes to [COMPILE]. We had a bug concerning [COMPILE] LEAVE in
Gforth for many years. Nobody reported it.
>I was wondering if it was ever necessary to do that with an xt on the stack=
>, but in that case LITERAL POSTPONE EXECUTE makes the intention clear.
COMPILE, makes the intention equally clear and results in better
efficiency. If a buggy system does not implement COMPILE, correctly,
complain to the system implementor, and then you can define
: compile, postpone literal postpone execute ;
No need to penalize all the correct systems around, just to pamper one
bad one.
>> XTs were designed as single point of reference to a word. The four
>> words
>> > > interp-execute
>> > > comp-execute
>> > > interp-compile,
>> > > comp-compile,
>> preserve that. Because it's Forth we're talking about, we have
>> to accept that words implementing behaviours also have xts, but
>> we should not be fooled into thinking that the xts of these
>> behaviours are part of the original word.
>>=20
>I'm beginning to think of them as 'raw' (default compiler behaviour) or 'co=
>oked.' With Anton's scheme you can only get a cooked xt easily using FIND w=
>hile compiling, and if you let that loose on the stack you have no Standard=
> way to get from there to the original.
As Stephen writes, they are not part of the original word; they might
be used for several words. Do you have a usage case for getting from
the xt of some particular implementation of a behaviour to the xt of a
word that uses that xt for implementing the behaviour?
>All words can be ticked to return an xt that, when EXECUTEs, performs its '=
>raw' behaviour. FIND returns the same xt.=20
>(At present a Standard system that wishes to do otherwise has to abort or=
>=20
>change the returned xt once the 'wrong' word has been found. It cannot=20
>simply make the word invisible to search in either compile or interpret=20
>state.)=20
I cannot follow you here. cmForth makes the compilation semantics
visible in compile state and invisible in interpretation state.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-04 16:11 +0000 |
| Message-ID | <2015May4.181147@mips.complang.tuwien.ac.at> |
| In reply to | #38720 |
JennyB <jennybrien@googlemail.com> writes:
>If COMPILE, is interp-compile then it can't be used with words lacking
>interpretation semantics.
You cannot use it for the 0 coming out of NAME>INTERPRETER, or
whatever comes out of FIND in interpret state, yes. You can use it on
the xt part of the compilation token coming out of NAME>COMPILER, or
on whatever comes out of FIND in compile state.
>Which leaves the true INTERMEDIATEs such as (,
>and dual words, which the Standard doesn't properly address.
>
>What is the use case for applying interp-compile to either?
Universality of use-2 code. No need to document: "You can use it for
some xts that you can EXECUTE, but for others you will get unexpected
results."
>It looks as if a COMPILE, that does comp-execute can enable Forth to finally
>get rid of immediacy.
I am not sure what you mean by that, but anyway, you can implement
immediacy with SET-COMPSEM, so there is no need to destroy COMPILE,
for that.
>But the SET-COMPILER syntax could also work with FIND.
>Here's a toy implimentation for a Forth with separate headers
>
> : HEADER \ xt ++ create a default header
> CREATE , ;
> : SET-COMPILER \ xt -- compiling action of latest definition
> , IMMEDIATE
> DOES> 2@ EXECUTE ;
>
> : FIND FIND DUP IF
> 1= STATE @ AND IF EXIT THEN ; \ compiling xt
> SWAP >BODY @ SWAP \ interpreting xt
> THEN ;
That's more along the lines of SET-COMPSEM than SET-COMPILER.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 12:04 +0000 |
| Message-ID | <2015May2.140431@mips.complang.tuwien.ac.at> |
| In reply to | #38684 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Mon, 27 Apr 2015 16:54:17 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>"Alex McDonald" <blog@rivadpm.com> writes:
>>>on 27/04/2015 15:52:33, wrote:
>>>> However, COMPILE, is not only used in the text interpreter. It is
>>>> used in other contexts, in particular in contexts where it is a a kind
>>>> of delayed EXECUTE (examples: early binding in OOP packages, or macros
>>>> with xt parameters). If you change what semantics COMPILE, compiles
>>>> for an xt, these uses break.
>>>
>>>Is there a simple example of this that you can provide?
>>
>>: compile1, postpone literal postpone execute ;
>
>Please provide a version of POSTPONE that does not use COMPILE, so
>that we can avoid an infinite loop.
I see no infinite loop occuring here. What's your point?
>>\ should do the same thing as COMPILE,
>>: S0" [ ' s" compile, ] ;
>>: S1" [ ' s" compile1, ] ;
>>s0" bla" type
>>s1" bla" type
>>
>>Both S0" and S1" should work the same way. In Gforth and SwiftForth
>>they do, in VFX S0" works differently.
>>
>>This example is admittedly contrived.
>
>The ugliness in the definitions of S0" and S1" is a result of there
>being no standard way to access the interpretation and compilation
>behaviour of S" separately.
NAME>INTERPRET and NAME>COMPILE are standard ways to access them, now
we just need a FIND-NAME to go with them.
>The simple Forth-like solution to this
>problem is to provide the facilities. We end up with
> interp-execute
> comp-execute
> interp-compile,
> comp-compile,
>as the four primitives.
These are composite words, not primitives, as obvious from their
systematic names. Here are implementations of these words:
: interp-execute ( .. nt -- .. ) name>interpret execute ;
: comp-execute ( .. nt -- .. ) name>compile execute ;
: interp-compile, ( .. nt -- .. ) name>interpret compile, ;
: comp-compile, ( .. nt -- .. ) name>compile swap postpone literal compile, ;
> EXECUTE and COMPILE, map onto two of these
>(probably).
On a system where nt=xt, EXECUTE=INTERP-EXECUTE and
COMPILE,=INTERP-COMPILE,.
A problem with the approach Bernd Paysan is advocating (and that VFX
currently implements) is that it fails to distinguish between
INTERP-COMPILE, and COMP-EXECUTE. For words with default compilation
semantics, there is no difference, but for other words, there is.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-28 03:22 +0200 |
| Message-ID | <mhmnav$uk1$1@dont-email.me> |
| In reply to | #38652 |
Anton Ertl wrote: > Now Bernd tells me that I should not worry, that nobody will use the > xts of words like FOO in these contexts. However, given the immense > creativity of Forth programmers in exploiting various aspects of Forth > systems, I don't find this at all reassuring. One reason why this is unlikely is that most OOF systems use something like M:, :M, or a context-sensitive : to define methods, and therefore, these xts are not arbitary xts. IIRC, especially mini-oof and mini-oof2 allow arbitary xts to be assigned to methods, because it deliberately does not have a M: (would cost another line of code or two ;-). So maybe that's a dangerous idea. Most OOFs don't follow this dangerous part, which makes the impact of SET-COMPILER much lower. BTW: Many OOF systems (as Alex McDonald described it) have a number of parsing state-smart words now, which are problematic to tick, anyways. There's a lot of risk with using those; dot parser recognizer could help, but at the cost of different syntax. The next reason why this is unlikely is that these methods are user-defined words, not system words. Or at least only simple system words. mini-oof or mini-oof2 stubs probably get a ' DROP or ' 2DROP to clean up input parameters, stub flag returns a ' TRUE or ' FALSE. Would you really instantiate a method with S" or TO? Last: For sure, people do make creative use of the tools they get by a Forth systems (standard and non-standard tools). And there's no policing. That's fine, that's part of the Forth culture, you don't just get a two-edged sword, you get a bag of ninja throwing stars, too, they are sharp on all 10 sides. That however means, that once you have a SET-COMPILER for optimization purposes, people will use it for other purposes, too. This can't be avoided. There's also no point in discussing whether SET-COMPILER shall be banned: We might not make it standard, but it will continue to exist as non-standard feature. You may convince Stephen to make a dual-xt S" and TO, but you won't convince him to take SET-COMPILER out. So that means people who use VFX can use SET-COMPILER to create words which don't work as methods of mini-oof. So what? I remember Andrew Haley's response to recognizers. He thought they were a way too powerful tool, because with the recognizer proposal, the user can alter the complete outer interpreter. It can become a completely different language. IMHO, SET-COMPILER is a much smaller change to Forth. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 11:09 +0000 |
| Message-ID | <2015May2.130959@mips.complang.tuwien.ac.at> |
| In reply to | #38668 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Now Bernd tells me that I should not worry, that nobody will use the
>> xts of words like FOO in these contexts. However, given the immense
>> creativity of Forth programmers in exploiting various aspects of Forth
>> systems, I don't find this at all reassuring.
>
>One reason why this is unlikely is that most OOF systems use something like
>M:, :M, or a context-sensitive : to define methods, and therefore, these xts
>are not arbitary xts.
In objects.fs you can also use arbitrary xts.
But OOP packages are just one example for use 2. Another one is
macros. E.g., the Gforth tutorial contains:
|3.29 Execution Tokens
|=====================
|
|...
| The XT is similar to a function pointer in C. However, parameter
|passing through the stack makes it a little more flexible:
|
| : map-array ( ... addr u xt -- ... )
| \ executes xt ( ... x -- ... ) for every element of the array starting
| \ at addr and containing u elements
| { xt }
| cells over + swap ?do
| i @ xt execute
| 1 cells +loop ;
|...
|3.35 Advanced macros
|====================
|
|Reconsider `map-array' from *note Execution Tokens: Execution Tokens
|Tutorial. It frequently performs `execute', a relatively expensive
|operation in some Forth implementations. You can use `compile,' and
|`POSTPONE' to eliminate these `execute's and produce a word that
|contains the word to be performed directly:
|
| : compile-map-array ( compilation: xt -- ; run-time: ... addr u -- ... )
| \ at run-time, execute xt ( ... x -- ... ) for each element of the
| \ array beginning at addr and containing u elements
| { xt }
| POSTPONE cells POSTPONE over POSTPONE + POSTPONE swap POSTPONE ?do
| POSTPONE i POSTPONE @ xt compile,
| 1 cells POSTPONE literal POSTPONE +loop ;
>BTW: Many OOF systems (as Alex McDonald described it) have a number of
>parsing state-smart words now, which are problematic to tick, anyways.
>There's a lot of risk with using those; dot parser recognizer could help,
>but at the cost of different syntax.
>
>The next reason why this is unlikely is that these methods are user-defined
>words, not system words. Or at least only simple system words. mini-oof or
>mini-oof2 stubs probably get a ' DROP or ' 2DROP to clean up input
>parameters, stub flag returns a ' TRUE or ' FALSE. Would you really
>instantiate a method with S" or TO?
Me? No. Others? Probably yes! And if people start replacing
STATE-smart words with wrongly-written SET-COMPILER words (from the
frying pan into the fire), and especially if they write defining words
that produce such words, I expect that the frequency of passing the
xts of such words to use-2 uses of COMPILE, and the resulting problems
to become noticable.
>Last: For sure, people do make creative use of the tools they get by a Forth
>systems (standard and non-standard tools). And there's no policing. That's
>fine, that's part of the Forth culture, you don't just get a two-edged
>sword, you get a bag of ninja throwing stars, too, they are sharp on all 10
>sides. That however means, that once you have a SET-COMPILER for
>optimization purposes, people will use it for other purposes, too. This
>can't be avoided.
Yes. So if we provide them with SET-COMPILER or STATE, we should at
least give them a way to do that right. Since you love the
SET-COMPILER interface so much, it might be SET-COMPSEM.
>There's also no point in discussing whether SET-COMPILER shall be banned: We
>might not make it standard, but it will continue to exist as non-standard
>feature. You may convince Stephen to make a dual-xt S" and TO, but you
>won't convince him to take SET-COMPILER out.
Nobody is trying to, so that's a straw man. SET-COMPILER is fine for
providing a different, more optimized implementation of COMPILE, for a
particular word (such as +). It's not ok for changing the compilation
semantics of a word. We need something else for that, e.g.,
SET-COMPSEM.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-02 12:30 +0000 |
| Message-ID | <5544c35c$0$21273$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38767 |
In article <2015May2.130959@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >>> Now Bernd tells me that I should not worry, that nobody will use the >>> xts of words like FOO in these contexts. However, given the immense >>> creativity of Forth programmers in exploiting various aspects of Forth >>> systems, I don't find this at all reassuring. >> >>One reason why this is unlikely is that most OOF systems use something like >>M:, :M, or a context-sensitive : to define methods, and therefore, these xts >>are not arbitary xts. > >In objects.fs you can also use arbitrary xts. > >But OOP packages are just one example for use 2. Another one is >macros. E.g., the Gforth tutorial contains: Can you please recapitulate what "use 2" is. For me it is lost in the earlier message. >- anton 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 16:58 +0000 |
| Message-ID | <2015May2.185838@mips.complang.tuwien.ac.at> |
| In reply to | #38772 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>Can you please recapitulate what "use 2" is. For me it is lost in the
>earlier message.
|2) Use it to append the same semantics to a definition that EXECUTE
|executes.
Message-ID: <2015Apr24.132234@mips.complang.tuwien.ac.at>
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-02 20:42 +0200 |
| Message-ID | <mi35ou$vo8$1@dont-email.me> |
| In reply to | #38767 |
Anton Ertl wrote: > Yes. So if we provide them with SET-COMPILER or STATE, we should at > least give them a way to do that right. Since you love the > SET-COMPILER interface so much, it might be SET-COMPSEM. To avoid the problems of dual-xt, we at least have to get rid of FIND, too. dual-xt is only acceptable with the single-token FIND-NAME solution. >>There's also no point in discussing whether SET-COMPILER shall be banned: >>We might not make it standard, but it will continue to exist as >>non-standard >>feature. You may convince Stephen to make a dual-xt S" and TO, but you >>won't convince him to take SET-COMPILER out. > > Nobody is trying to, so that's a straw man. SET-COMPILER is fine for > providing a different, more optimized implementation of COMPILE, for a > particular word (such as +). It's not ok for changing the compilation > semantics of a word. We need something else for that, e.g., > SET-COMPSEM. You are confusing the system implementer with the user. If SET-COMPILER is there, the user can use it to change the compilation semantics, regardless if you like that or not. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-04 16:28 +0000 |
| Message-ID | <2015May4.182813@mips.complang.tuwien.ac.at> |
| In reply to | #38785 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Yes. So if we provide them with SET-COMPILER or STATE, we should at
>> least give them a way to do that right. Since you love the
>> SET-COMPILER interface so much, it might be SET-COMPSEM.
>
>To avoid the problems of dual-xt, we at least have to get rid of FIND, too.
>
>dual-xt is only acceptable with the single-token FIND-NAME solution.
Fine with me, although I don't know of any problems of dual-xt.
>> SET-COMPILER is fine for
>> providing a different, more optimized implementation of COMPILE, for a
>> particular word (such as +). It's not ok for changing the compilation
>> semantics of a word. We need something else for that, e.g.,
>> SET-COMPSEM.
>
>You are confusing the system implementer with the user. If SET-COMPILER is
>there, the user can use it to change the compilation semantics, regardless
>if you like that or not.
You mean that the user can misuse it to break COMPILE,; yes, that is
possible, but that's also possible with "!". If, OTOH, the user wants
to change the compilation semantics, SET-COMPSEM is the way to go.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-05-06 04:14 -0700 |
| Message-ID | <2b14bcdd-32a9-4233-a722-d735f2859999@googlegroups.com> |
| In reply to | #38785 |
On Saturday, 2 May 2015 19:42:38 UTC+1, Bernd Paysan wrote:
> Anton Ertl wrote:
> > Yes. So if we provide them with SET-COMPILER or STATE, we should at
> > least give them a way to do that right. Since you love the
> > SET-COMPILER interface so much, it might be SET-COMPSEM.
>
> To avoid the problems of dual-xt, we at least have to get rid of FIND, too.
>
> dual-xt is only acceptable with the single-token FIND-NAME solution.
>
> >>There's also no point in discussing whether SET-COMPILER shall be banned:
> >>We might not make it standard, but it will continue to exist as
> >>non-standard
> >>feature. You may convince Stephen to make a dual-xt S" and TO, but you
> >>won't convince him to take SET-COMPILER out.
> >
> > Nobody is trying to, so that's a straw man. SET-COMPILER is fine for
> > providing a different, more optimized implementation of COMPILE, for a
> > particular word (such as +). It's not ok for changing the compilation
> > semantics of a word. We need something else for that, e.g.,
> > SET-COMPSEM.
>
> You are confusing the system implementer with the user. If SET-COMPILER is
> there, the user can use it to change the compilation semantics, regardless
> if you like that or not.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> http://bernd-paysan.de/
Just factor your state-smart evil words properly, then all the problems
go away. No need for dual XT and other such nonsense. Forth should be
simple. I don't know whether I'm coming or going after reading this
thread! I'm in full-on panic mode to think all this dual-xt stuff
could be standardised. No! Leave my beautiful simple Forth alone :-)
Bad:
: 0x ( "hex_num" -- | "hex_num" -- n )
\ interpretation behaviour: push a hex value to stack
\ compilation: compile hex value as a literal
base @ >r
hex bl word number 0= if
state @ if compile lit , then
else
r> base !
true abort" Not a legal hex number"
then
r> base !
; immediate
Why bad? Because you can't get the compilation behaviour via tick.
That is NOT the fault of Forth. It is the fault of the programmer.
Good:
: (0x) ( n -- )
\ compilation behaviour: compile n as a literal
compile lit ,
;
: 0x ( "hex_num" -- | "hex_num" -- n )
\ interpretation behaviour: push a hex value to stack
\ compilation: compile hex value as a literal via (0x)
base @ >r
hex bl word number 0= if
state @ if (0x) then
else
r> base !
true abort" Not a legal hex number"
then
r> base !
; immediate
Trivial example, but if I want the compilation "semantics" then I tick
(0x). Simple as that. It requires discipline only, and appropriate
warnings and explanation in the documentation for 0x in my code or
my product docs.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-04-27 23:57 -0700 |
| Message-ID | <df9d1b95-9b1d-49f6-8eca-d8d835141721@googlegroups.com> |
| In reply to | #38652 |
On Monday, 27 April 2015 17:01:35 UTC+1, Anton Ertl wrote: > JennyB <jennybrien@googlemail.com> writes: > >It seems confusing to me to have rules for the interpretation and compilation behavior of Standard words that user-defined don't follow. > > User-defined words also follow the rules laid out in the standard. > > >At present: > > > > All user-defined words are tickable and return an xt that can be EXECUTEd. Whether it is designed to be executed while interpreting or while compiling, or both, is the user's decision. > > Sure, what they are designed to do is up to the programmer. All > user-defined words have both interpretation and compilation semantics. Yes, but this looks screwy if all you have is IMMEDIATE. What does 'interpretation semantics' mean for a word that is meant to be compile-only, or vice-versa? THe word only has its execution semantics. You can mark it as IMMEDIATE to have those execute at compile time, but you can't get its compilation semantics from the xt alone. > You are conflating two very different things: optimization and > compilation semantics. You are not alone in this mistake, and I'll > explore here why. > I know, but is that a distinction without a difference? Berndt has answered that better than I can. Standard Forth has many examples of words extending the meaning of other words, and so allowing code that is otherwise difficult or impossible. SET-COMPILER extends the meaning of COMPILE,. If we define : IMMEDIATE ['] EXECUTE SET-COMPILER ; what legacy code will that break?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 11:41 +0000 |
| Message-ID | <2015May2.134148@mips.complang.tuwien.ac.at> |
| In reply to | #38677 |
JennyB <jennybrien@googlemail.com> writes:
>On Monday, 27 April 2015 17:01:35 UTC+1, Anton Ertl wrote:
>> JennyB <jennybrien@googlemail.com> writes:
>> >It seems confusing to me to have rules for the interpretation and compil=
>ation behavior of Standard words that user-defined don't follow.
>>=20
>> User-defined words also follow the rules laid out in the standard.
>>=20
>> >At present:
>> >
>> > All user-defined words are tickable and return an xt that can be EXE=
>CUTEd. Whether it is designed to be executed while interpreting or while co=
>mpiling, or both, is the user's decision.
>>=20
>> Sure, what they are designed to do is up to the programmer. All
>> user-defined words have both interpretation and compilation semantics.
>
>Yes, but this looks screwy if all you have is IMMEDIATE. What does 'interp=
>retation semantics' mean for a word that is meant to be compile-only, or vi=
>ce-versa? THe word only has its execution semantics.
For a user-defined word (and most standard words), the interpretation
semantics are its execution semantics (3.4.3.2).
>You can mark it as IM=
>MEDIATE to have those execute at compile time, but you can't get its compil=
>ation semantics from the xt alone.=20
Well, if you know that it is immediate, the compilation semantics is
to EXECUTE the xt. If you mean that you only have an xt and want to
get the compilation semantics, no, you cannot get that in the
standard. We have managed to live without this capability; do you
have a use for it?
>> You are conflating two very different things: optimization and
>> compilation semantics. You are not alone in this mistake, and I'll
>> explore here why.
>>=20
>I know, but is that a distinction without a difference?
No. The compilation semantics of, e.g., S" is not an optimization of
compiling its interpretation semantics. They do different things.
> Berndt has answered=
> that better than I can. =20
Bernd Paysan knows the difference, but claims that it does not occur
in practice.
>If we define : IMMEDIATE ['] EXECUTE SET-COMPILER ; what legacy code will t=
>hat break?=20
Code that uses COMPILE, on the xt of an immediate word.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-02 12:51 +0000 |
| Message-ID | <5544c837$0$21329$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38769 |
In article <2015May2.134148@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >JennyB <jennybrien@googlemail.com> writes: >>On Monday, 27 April 2015 17:01:35 UTC+1, Anton Ertl wrote: >>> JennyB <jennybrien@googlemail.com> writes: >>> >It seems confusing to me to have rules for the interpretation and compil= >>ation behavior of Standard words that user-defined don't follow. >>>=20 <SNIP> >>> You are conflating two very different things: optimization and >>> compilation semantics. You are not alone in this mistake, and I'll >>> explore here why. >>>=20 >>I know, but is that a distinction without a difference? > >No. The compilation semantics of, e.g., S" is not an optimization of >compiling its interpretation semantics. They do different things. I've been there. I eliminated S" in favour of the denotation-" and the difference between compilation and execution of "AAP" is the same as between compilation and execution of 1234. BUT I had to allocate permanent storage to interpretation of "AAP". So where your S" in interpretation leaves out the allocation, it is in fact an optimisation issue. You could make S" "compile its interpretation semantics" and loose nothing but memory and speed. "AAP " Interpretation : put 0xFF80,9980 5 on the stack Compilation : add code to put 0xFF80,9980 5 on the stack which is the established state smart behaviour of numbers (I know you hate it when I say that.) <SNIP> >- anton -- 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 17:00 +0000 |
| Message-ID | <2015May2.190034@mips.complang.tuwien.ac.at> |
| In reply to | #38773 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2015May2.134148@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>No. The compilation semantics of, e.g., S" is not an optimization of
>>compiling its interpretation semantics. They do different things.
>
>I've been there. I eliminated S" in favour of the denotation-" and
>the difference between compilation and execution of "AAP" is the same
>as between compilation and execution of 1234.
Certainly. That is why recognizers are better than parsing words like
S"; no STATE-smartness or SET-COMPILER problems.
>BUT I had to allocate permanent storage to interpretation of "AAP".
>So where your S" in interpretation leaves out the allocation,
>it is in fact an optimisation issue. You could make S"
>"compile its interpretation semantics" and loose nothing but memory
>and speed.
The problem is if you have S" as a word with default compilation
semantics (with the FILE-S" interpretation semantics working as
execution semantics to base the default compilation semantics on), and
you write
: foo s" bla" ;
then S" will not parse at compile time and the compilation will
probably fail. If it did compile, it would then try to parse at run
time. So you can see that the compilation semantics of S" is
different from compiling its interpretation semantics.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-03 11:19 +0100 |
| Message-ID | <mi4sm2$rvg$1@dont-email.me> |
| In reply to | #38783 |
on 02/05/2015 18:00:34, Anton wrote: > That is why recognizers are better than parsing words like > S"; no STATE-smartness or SET-COMPILER problems. From EuroForth 2014: "Recognizers: Matthias Trute is working on an RfD". Did it eever get written? I've looked on the Forth RfDs and not seen it.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-05-03 07:30 -0700 |
| Message-ID | <01dd1f51-fe2b-495c-9068-fa0eecee511f@googlegroups.com> |
| In reply to | #38789 |
On Sunday, 3 May 2015 11:19:46 UTC+1, Alex McDonald wrote: > on 02/05/2015 18:00:34, Anton wrote: > > That is why recognizers are better than parsing words like > > S"; no STATE-smartness or SET-COMPILER problems. > > From EuroForth 2014: "Recognizers: Matthias Trute is working on an RfD". > Did it eever get written? I've looked on the Forth RfDs and not seen it. http://amforth.sourceforge.net/pr/Recognizer-rfc.pdf Recognizers offer a way to respond to different patterns, such as a prefix for alternative number formats. When they match, they return <something> (probably) on the stack, and a key to how to interpret, compile or postpone it. They are kinda-sorta like wordlists, and we've had some discussion as to how or whether they should be part of the Search Order. Although recognizers can deal with many patterns, the most common and easiest to decode is a fixed prefix followed by variable text. Then, for example, you can write "HELLO WORLD" instead of S" HELLO WORLD", so it is a possible replacement for dual words. You obviously can't tick a pattern, but it does make sense to POSTPONE it, because all the parsing is done at compile time, which makes compiler macros a bit neater. ]] lions tigers bears "Oh My!" type [[ With a well-behaved POSTPONE S" , on the other hand, the parsing would take place when the macro was executed.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-05-03 21:45 +0200 |
| Message-ID | <7jdgr7ptu7db.10zg0p5nqbjk3.dlg@40tude.net> |
| In reply to | #38792 |
Op Sun, 3 May 2015 07:30:31 -0700 (PDT) schreef JennyB: > On Sunday, 3 May 2015 11:19:46 UTC+1, Alex McDonald wrote: >> on 02/05/2015 18:00:34, Anton wrote: >>> That is why recognizers are better than parsing words like >>> S"; no STATE-smartness or SET-COMPILER problems. >> >> From EuroForth 2014: "Recognizers: Matthias Trute is working on an RfD". >> Did it eever get written? I've looked on the Forth RfDs and not seen it. > > http://amforth.sourceforge.net/pr/Recognizer-rfc.pdf > > Recognizers offer a way to respond to different patterns, such as a prefix for alternative number formats. When they match, they return <something> (probably) on the stack, and a key to how to interpret, compile or postpone it. They are kinda-sorta like wordlists, and we've had some discussion as to how or whether they should be part of the Search Order. > > Although recognizers can deal with many patterns, the most common and easiest to decode is a fixed prefix followed by variable text. Then, for example, you can write "HELLO WORLD" instead of S" HELLO WORLD", so it is a possible replacement for dual words. > > You obviously can't tick a pattern, but it does make sense to POSTPONE it, because all the parsing is done at compile time, which makes compiler macros a bit neater. ]] lions tigers bears "Oh My!" type [[ > > With a well-behaved POSTPONE S" , on the other hand, the parsing would take place when the macro was executed. : one ]] "hello, world" type cr [[ ; immediate ok : two one ; ok two hello, world -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-05-03 21:48 +0200 |
| Message-ID | <15slk5bdv2pyq$.kexdi5wvf3h5.dlg@40tude.net> |
| In reply to | #38797 |
Op Sun, 3 May 2015 21:45:19 +0200 schreef Coos Haak: > Op Sun, 3 May 2015 07:30:31 -0700 (PDT) schreef JennyB: > >> On Sunday, 3 May 2015 11:19:46 UTC+1, Alex McDonald wrote: >>> on 02/05/2015 18:00:34, Anton wrote: >>>> That is why recognizers are better than parsing words like >>>> S"; no STATE-smartness or SET-COMPILER problems. >>> >>> From EuroForth 2014: "Recognizers: Matthias Trute is working on an RfD". >>> Did it eever get written? I've looked on the Forth RfDs and not seen it. >> >> http://amforth.sourceforge.net/pr/Recognizer-rfc.pdf >> >> Recognizers offer a way to respond to different patterns, such as a prefix for alternative number formats. When they match, they return <something> (probably) on the stack, and a key to how to interpret, compile or postpone it. They are kinda-sorta like wordlists, and we've had some discussion as to how or whether they should be part of the Search Order. >> >> Although recognizers can deal with many patterns, the most common and easiest to decode is a fixed prefix followed by variable text. Then, for example, you can write "HELLO WORLD" instead of S" HELLO WORLD", so it is a possible replacement for dual words. >> >> You obviously can't tick a pattern, but it does make sense to POSTPONE it, because all the parsing is done at compile time, which makes compiler macros a bit neater. ]] lions tigers bears "Oh My!" type [[ >> >> With a well-behaved POSTPONE S" , on the other hand, the parsing would take place when the macro was executed. > >: one ]] "hello, world" type cr [[ ; immediate ok >: two one ; ok > two hello, world I wrote this in my own Forth, but Gforth knows this too. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web