Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58510
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Recognizers and DT-TOKEN: |
| Date | 2017-05-02 14:13 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2017May2.161352@mips.complang.tuwien.ac.at> (permalink) |
| References | (3 earlier) <2017Apr30.115146@mips.complang.tuwien.ac.at> <RO-dnQW1TY3gQJjEnZ2dnUU7-fednZ2d@supernews.com> <2017Apr30.160125@mips.complang.tuwien.ac.at> <oe4sin$dm3$1@dont-email.me> <ELSdncIQzKOq1ZXEnZ2dnUU7-SXNnZ2d@supernews.com> |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>My basic objection is that this proposal essntially turns the Forth
>interpreter inside out, with the dictionary search subservient to the
>recognizer loop.
Currently, we have a semi-hard-coded text interpreter, with dictionary
search and integer conversion hard-coded in, and hooks for extending
this in various places. IIRC Stephen Pelc boasts five (or was it
seven?) hooks in various stages of the text interpreter for various
optional features.
The proposal is to make the interpreter flexible and general. No need
to have special-purpose hooks, no need for hard-coded parts of the
text interpreter.
Is this inside out? Is the dictionary search now "subservient" to the
integer number or some other recognizer? I don't think so. The
dictionary search is still working as a recognizer side by side with
the integer recognizer and the other recognizers.
>Such an extraordinary overhaul of the language, the
>most dramatic since ANS 94, IMO requires extraordinary justification.
>And that justification must be pulled by the needs of application
>writers, not pushed by implementers.
First of all, in Forth we typically value implementation simplicity
enough that we don't need to search for applications to justify
simplifying implementations in a way that does not break application
programs. Is a text interpreter with a hard-coded dictionary search
and then a call to the recognizers simpler than one that just calls
the recognizers? No. Does it make it impossible to call the
dictinary search first? No.
Concerning application needs, I am sure each of the hooks in VFX came
from an application need; IIRC when Stephen Pelc showed the source
code of the VFX interpreter loop, there was at least one hook that was
called before the hard-coded dictionary search. So at least among the
VFX customers there is an application need to have some other
recognizer precede the dictionary search.
Another application need is the meta/cross-compiler application
discussed elsewhere in this thread: One way to implement this is to
have a meta-compiler dictionary search recognizer, meta-compiler
number recognizers, etc., and put them on the recognizer stack before
(or instead of) the ordinary dictinary search etc. Sure one can also
do it in other ways, but are they simpler?
>More specifically:
>
>If libraries use recognizers, the client code of those libraries may
>also need to use recognizers provided by the library. This is fine as
>long as only one library adds recognizers. But there is no proposal
>for a way to control conflicting recognizers, and none may be
>possible.
The proposal contains GET-RECOGNIZERS and SET-RECOGNIZERS to control
the presence and order of recognizers. If an application uses two
libraries, each of which adds a recognizer, and the recognizers
conflict, the application has several options: Order the recognizers
in a convenient way, and use non-conflicting literals for the later
recognizer (just like in classical Forth we use 0ADD instead of ADD if
we want to specify a hex number); or reorder the recognizers as
appropriate (similar to using BASE in classical Forth; not a practice
I would recommend); or define non-conflicting recognizers based on the
conflicting ones, and use those (e.g., #123. and 123e for doubles and
FP numbers in Forth2012).
>It could be argued that this is no worse than conflicting
>word names in libraries, but at least words can be renamed if they
>conflict. This isn't the case with recognizers, which define entire
>classes of names.
You can also define a recognizer based on the conflicting recognizer
that does not conflict. It's a little more work than renaming a word,
but, OTOH, I expect that we will hardly, if ever, have the need for
it.
>The recognizer stack is a large slab of global
>state, and managing it will not be an easy problem to solve.
What's currently being proposed is in exactly the same style as the
search order words GET-ORDER and SET-ORDER, and there have been few
complaints about that yet (I don't remember any from you).
I have some ideas for an alternative, and have expressed them to
Matthias Trute (I don't want to bikeshed it to death with a public
discussion), but he seems to prefer sticking with the
GET-ORDER-inspired interface, and he may well be right: If it's good
enough for the search order, it should certainly be good enough for
the recognizer order which changes much more rarely. And sticking
with the same style of interface reduces the mental load on the
programmers of the interface and on the people reading the proposal.
>The proposal allows recognizers to precede dictionary searches, so
>that even if a word would have been found it might not be executed
>because a recognizer got in there first. This will not help
>debugging; it is not a good thing.
Yes, you can shoot yourself in the foot in Forth. The programmer is
responsible. The proposal is very much in the Forth spirit by
providing that possibility.
On the practical side, you have been able to put something else before
the search order for a while in Gforth, and it has not resulted in
problems yet. By contrast, I have tripped across a number of nasty
issues over the years:
* "2," being interpreted as double, not as word (VFX and SwiftForth do
it to this day).
* "1000000" interpreted as hex number (startup BASE was HEX). BASE is
a much bigger bug magnet in my experience than anything I have seen
done with recognizers yet.
* "u" (actually a typo) interpreted as FP number thanks to a too-loose
FP number recognizer, although that sat behind the search order;
this recognizer was written by the system implementor, so that can
occur even without standardized recognizers.
>The proposal is too complex. It doesn't have the property of clarity
>and "just right" elegance that characterizes the Forth interpreter,
>and indeed good Forth in general.
Please be more concrete. What's too complex?
Is it a problem with the proposal text or with the proposal content?
Admittedly the proposal text had the "tl;dr" effect on me at first,
and maybe it could benefit from being condensed into just the basic
proposal without the surrounding discussions on alternatives etc. But
then there would be complaints that the discussion is too short and
should cover this and that. Whatever he does, there will always be
complaints. But if you want a different presentation, you can read
either my EuroForth 2016 paper or watch my talk:
https://www.complang.tuwien.ac.at/anton/euroforth/ef16/papers/ertl-recognizers.pdf
https://wiki.forth-ev.de/lib/exe/fetch.php/events:recognizers.mp4
>Examples of the use of recognizers serve only to reinforce my
>disquiet. For example, the "0x" example recognizer does this:
>
>: plit postpone literal ;
>
> ' noop \ interpret: do nothing
> ' plit \ compile as a literal
> :noname plit postpone plit ; \ postpone a literal
>dt-token: dt:0x ( n -- )
That's actually the dt-token for all single-cell literals.
>The multi-level POSTPONE took me a little while to understand. And
>it's totally unnecessary because no application will ever need to
>
> POSTPONE 0x25
Sure, you can ask the application programmer to write
0x25 POSTPONE literal
instead, and do that every time he wants to postpone a literal. If
you prefer to write it this way, that recognizer won't stop you. But
I prefer to actually write
POSTPONE 0x25
or
]] 0x25 [[
instead. What's more, I prefer writing
]] dup 0x25 + [[
instead of
]] dup [[ 0x25 ]] literal + [[
or
POSTPONE dup 0x25 POSTPONE literal POSTPONE +
But sure, if you prefer writing the latter, or hardly use POSTPONE,
you may not care for the postponing part of a recognizer. But there
are those of us who do care for that. Not everybody has the same
taste or needs: some hate locals, some hate BASE, and some hate if
others are able to POSTPONE literals.
>The above could be rewritten as
>
> ' noop \ interpret: do nothing
> :noname postpone literal ; \ compile as a literal
> ' abort \ WTF?
>dt-token: dt:0x ( n -- )
>
>This is shorter, much easier to understand, and doesn't get carried
>away with pointless features.
You think that
0x25 POSTPONE literal
is easier to understand than
POSTPONE 0x25
? I don't.
>More broadly, much of the discussion of recognizers reflects an
>obsession with syntax which is not in keeping with the spirit of
>Forth. Forth carefully eschews syntatctic minutiae and concentrates
>on semantics:
>
> THIS THAT OTHER
>
>does this then that the the other, and we know that's what it does.
>There's no superfluous punctuation. Literals are confined to simple
>numbers. This simplicity is a feature, not a bug. Where this general
>rule has been broken, for example as in TO, it has been a wart on the
>language.
TO has been implemented as a word, long before the issue of
standardizing recognizers has ever been discussed, so it's a red
herring.
A more relevant issue is S". This follows exactly your dogma of
having only the search order and "simple numbers" in the text
interpreter. Words like these have given us STATE-smart words (which
break in corner cases), arbitrary combinations of interpretation and
compilation semantics in Forth-94/2012, it's implementation in Gforth
(not particularly complex, but not a poster example of simplicity,
either, but in any case, it also works correctly in corner cases), and
it's implementation in VFX (which breaks in different corner cases
than the STATE-smart implementation. Is that really the right way to
go? No!
By contrast, the Forth-94 floating-point wordset has not followed your
dogma; instead, systems have added an extra recognizer for them
(traditionally using a system-specific hook). Problems: Except for
the too-loose FP recognizer above, none have come to my attention.
And in contrast to the discussions about how to implement S"
(STATE-smartness etc.) that have existed since at least Forth-83, and
flare up regularly here, I don't remember any controversies about the
implementation of the FP recognizer.
In the long term, S" and other words with arbitrary combinations of
interpretation and compilation semantics could be replaced by
recognizers providing the same functionality, and eventually eliminate
these words, and all the bugs, complexity and controversies they
entail.
>Better to take a step back, take a hard look at what is really
>required, and come up with something that can be described more
>easily, managed more easily, and is a reasonable solution in
>proportion to the magnitude of the problem.
Yes, we have done that, and the result is in this proposal.
- 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 2017: http://www.euroforth.org/ef17/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 03:31 +0100
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-04-29 20:21 -0700
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-30 03:30 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 09:51 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-30 07:50 -0500
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 14:05 +0100
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-30 08:11 -0500
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 14:18 +0100
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 14:01 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 15:36 +0100
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-01 01:48 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 11:13 +0100
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-01 04:40 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 18:01 +0100
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-01 11:42 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 20:47 +0100
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-01 13:56 -0700
Re: Recognizers and DT-TOKEN: Julian Fondren <julian.fondren@gmail.com> - 2017-05-01 14:07 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 23:17 +0100
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-01 22:33 +0100
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 03:49 -0500
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-02 12:27 +0200
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 11:42 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-02 11:41 +0100
Re: Recognizers and DT-TOKEN: john <anon@example.com> - 2017-05-02 12:13 +0100
Re: Recognizers and DT-TOKEN: "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:42 -1000
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-02 14:13 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:32 -0500
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-02 18:55 +0100
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:05 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:18 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:55 -0500
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 11:36 -0700
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-03 06:39 -0700
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-08 10:22 -0700
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-08 11:52 -0700
Re: Recognizers and DT-TOKEN: krishna.myneni@ccreweb.org - 2017-05-09 02:45 -0700
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-09 03:47 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-09 12:52 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-09 10:38 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 11:08 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 08:33 -0500
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-09 15:39 +0200
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 09:14 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 16:40 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:48 -0500
Re: Recognizers and DT-TOKEN: Joel Rees <joel.rees@gmail.com> - 2017-05-12 07:47 -0700
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 11:10 -0700
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 11:47 -0700
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:47 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:31 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:01 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:10 -0500
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:29 -0500
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-03 12:27 -0700
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:35 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 14:00 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:21 -0500
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-04 19:14 +0100
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-05 09:17 -0500
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-05 07:31 -0700
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-05 10:27 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 15:25 +0000
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-05 12:21 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:37 +0000
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-06 13:18 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-05 20:32 +0100
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:06 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:54 -0500
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 13:46 +0200
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 07:59 -0500
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-07 11:31 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-07 20:22 +0100
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-08 04:17 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 15:30 +0000
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-08 12:00 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:50 +0000
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-08 09:51 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 15:40 +0000
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-09 16:32 +0200
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 16:19 +0000
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-09 18:53 +0200
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-09 18:12 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-09 10:41 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-09 19:12 +0100
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:46 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 03:50 -0500
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 02:42 -0700
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 03:58 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-08 12:35 +0100
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 05:49 -0700
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-08 16:28 +0200
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 07:54 -0700
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-08 17:16 +0200
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 09:23 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 16:31 +0000
Re: Recognizers and DT-TOKEN: mhx@iae.nl - 2017-05-08 11:14 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-08 19:27 +0100
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-09 16:39 +0200
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:53 +0000
Re: Recognizers and DT-TOKEN: Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:43 -0700
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-08 15:02 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-09 12:24 +0100
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:34 +0000
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-08 01:17 -0700
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-08 12:30 +0000
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-08 07:49 -0700
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 10:58 -0500
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 11:44 +0000
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-08 08:04 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 17:30 +0000
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-10 04:07 -0700
Re: Recognizers and DT-TOKEN: Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:11 +0300
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 13:59 +0200
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 14:04 +0100
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 14:06 +0100
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 13:02 +0100
Re: Recognizers and DT-TOKEN: pahihu <pahihu@gmail.com> - 2017-05-10 06:07 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 14:30 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-10 11:59 -0700
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 15:10 +0200
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 14:33 +0100
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 16:08 +0200
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-05-10 16:02 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-10 09:10 -0700
Re: Recognizers and DT-TOKEN: Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 18:38 +0200
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:03 -0500
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-08 13:32 +0000
Re: Recognizers and DT-TOKEN: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-08 16:11 +0200
Re: Recognizers and DT-TOKEN: stephen@mpeforth.com (Stephen Pelc) - 2017-05-04 20:29 +0000
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 14:55 +0000
Re: Recognizers and DT-TOKEN: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 02:47 -0500
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-02 15:02 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 12:11 +0100
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-04-30 06:34 -0700
Re: Recognizers and DT-TOKEN: Julian Fondren <julian.fondren@gmail.com> - 2017-04-30 06:59 -0700
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 15:04 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-04-30 09:38 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 09:36 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 11:46 +0100
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 14:12 +0000
Re: Recognizers and DT-TOKEN: Alex <alex@rivadpm.com> - 2017-04-30 16:39 +0100
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-04-30 09:25 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-30 16:23 +0000
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-04-30 09:06 -0700
Re: Recognizers and DT-TOKEN: Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-04-30 18:00 +0100
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-01 01:30 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-02 13:06 +0000
Re: Recognizers and DT-TOKEN: minforth@arcor.de - 2017-05-02 06:24 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:13 +0000
Re: Recognizers and DT-TOKEN: JennyB <jennybrien@googlemail.com> - 2017-05-03 04:20 -0700
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:17 +0000
Re: Recognizers and DT-TOKEN: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-02 12:46 +0000
Re: Recognizers and DT-TOKEN: Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:58 +0100
Re: Recognizers and DT-TOKEN: mhx@iae.nl - 2017-05-03 10:52 -0700
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-04-30 08:51 -0700
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-04-30 22:54 +0000
Re: Recognizers and DT-TOKEN: Matthias Trute <matthias.trute@gmail.com> - 2017-05-01 01:01 -0700
Re: Recognizers and DT-TOKEN: Bernd Paysan <bernd@net2o.de> - 2017-05-02 15:10 +0000
csiph-web