Hi Tomas,

> >> Why error?  Understanding of the three simple rules above is enough and
> > ...
> > There are. You gave (1 2 3 . 4 . 5) as an example.
> > ...
> no, the sexp '4' gets lost as a consequence of the rules not because I
> violated the rules (simply because the last cell before reading 4 is the

The initial question was whether to signal an error or not in such a
case. I think it should be an error, because the expression is not
well-formed. On the same level as an error is signalled when other
meta-character markup doesn't match (no closing parentheses or double
quotes at end of file, non-matching super-parentheses, etc.).

> Any other lisp reader is more constrained in these corner/error cases
> and/or appears to have some additional arbitrary rules which I think are
> not necessary.

This is the old conflict between being strict and giving the user an
error, or being tolerant with the result of more flexibility but the
danger of errors going unnoticed. Usually, picoLisp prefers the second
way (but not on the lower level of syntactic markup).

Anyway, in the current implementation of picoLisp, I believe that an
error is necessary here.

Our implementations differ only in a single detail: While picoLisp
handles _all_ reader structure with meta-characters (white space, single
and double quotes, parens, super-parens, the backquote and the tilde),
you handle the dot in a special way on the symbol level.

This has no advantages, except that you, by definition, cannot use the
dot as a symbol.

> never use it.  And, the user has always an option to intern a string.
> It might get tricky with the dot inside a list but it is possible;
> : '(1 2 3 . `(cons (intern ".")) 4 . 5)
> -> (1 2 3 . 4 . 5)

This will not work, if I understand your implementation correctly. The
cons in the backquote is evaluated at read time, so your reader again
will see the interned dot and assume it is a dotted pair.

> >       (ifn (= "(" NextToken)
> >          (readAtom)
> >          (make
> >             (loop
> >                (T (= ")" NextToken)
> >                   (skip) )
> >                (T (= " . " NextToken)
> >                   (chain (read)) )
> >                (link (read)) ) ) ) )
> >
> > So the rule is that the dot is only treated as a meta-character when
> >
> >    - appearing in a list
> >    - unescaped
> >    - and not as part of a symbol
> I don't think you stick to the rules though:-) See the examples I sent
> before.  You'd have to add a few more rules like:

No, it does stick to the rules. " . " is a delimiter, so the observed
behavior is a direct result. The dot needs to be escaped when a dotted
pair can be expected. Not needing to escape it in other situations like

> : '(. 1 2)
> -> (\. 1 2)

is just a convenience. For example, one the things I type thousand times
a day is

   : .
   -> NIL

just go check if the REPL is alive, or to get a vertical space (as just
ENTER will leave the REPL).

> - if last thing of the list, make the list circular
> - unless the dot (meta-character) was before which won't make it
>   circular but will treat is as a symbol

Yes, a direct consequence of the dot being a meta-char. It has higher
precedence, so after the dotted pair is detected it is accepted without
need to escape. What you call "not sticking to the rules" is simply
relaxing the requirement to escape the dot in cases where it is not
really necessary in the given context.

The _whole_ dilemma arised, if you remember, arose from the fact that we
_want_ to use the dot in symbol names and numeric atoms, without needing
to escape it. Without that, the dot would be a pure meta-character and
everything would be simple.

- Alex
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to