Kaz Kylheku
12/22/2015 10:33:00 PM
On 2015-12-22, snrh4x0r@gmail.com <snrh4x0r@gmail.com> wrote:
> I'm trying to design a simple language that name is smile which is
> similar to lisp. I have written its lexer. Nevertheless, I don't have
> any idea to write its parser. It is really hard for me. I need help
> about it.
>
> As simple input, if I have `( + 9 10 )` It gives as output about my
> lexer
>
> Tokens:
> Operator_(
You're wrong right off the bat with the terminology, which could point
to incorrect thinking.
Parentheses aren't operators in Lisp. They are, effectively,
punctuation.
> Operator_+
+ is a token which converts to a symbol, in anything that can be
reasonably called a member of the Lisp family of languages.
The role of of a symbol as "operator", or any other role, is determined
by what *binding* that symbol has, in some environment. That is all
semantics, nothing to do with parsing.
> VALUE_INT_9
> VALUE_INT_10
> Operator_)
> Identifiers:
>
> I don't have any idea about writing parser.
That predicament is convenient, because it goes perfectly
hand-in-hand with not really needing one.
Common Lisp is parsed entirely by character dispatch tables, and
some supporting routines. As in, in an nutshell, when we see this
character, or this pair of characters, call this function.
In Lip's read table there is an entry for the ( character. It
dispatches a function which keeps reading objects (via a recursive call
to the reader), while peeking at the next character in the stream. If
the lookahead character in the stream is a closing ) then it returns the
list of objects it has scanned so far.
And that's basically how the whole nested structure is read, like
(a b c (d e (f g) . h))
Ah, except for specially handling that dot! I lied! The function also
peeks whether there is a consing dot, and handles that case.