Mark Engelberg <mark.engelb...@gmail.com> writes:
Hi Mark,
>> (def as-and-bs
>> (parser
>> S = AB* .
>> AB = A B .
>> A = "a" + .
>> B = "b" + .))
>
> I played around with that, but even if you suppress evaluation by
> using a macro, Clojure's reader makes strong assumptions about certain
> symbols. For example, it is standard in EBNF notation for {} to mean
> zero-or-more. But if you include {A B C} in your grammar using the
> macro approach, Clojure's reader will throw an error because it treats
> {} as a map and expects an even number of forms to follow.
Indeed, I didn't think about this one.
> That was the main reason, but it also makes the notation much more
> sensitive to whitespace (for example, AB * versus AB*). Gradually,
> those little issues start making it look less and less like
> traditional notation. There's something really nice about just being
> able to copy and paste a grammar off of a website and have it just
> work.
That's nice.
> I understand where you're coming from, though. It definitely is part of
> the Clojure culture to avoid string representations for many kinds of data
> (e.g., SQL queries). We do accept it for regular expressions, and for
> things like #inst "2011-12-31T19:00:00.000-05:00", though, and that's the
> kind of feel I was going for. Would it be more psychologically palatable
> to type:
> #insta/parser "S = 'a' 'b'"
> rather than
> (insta/parser "S = 'a' 'b'")
> ?
No, not really.
> What do you think would be gained by making it a macro?
I don't really care if it's a macro or a function, but if the grammar
was represented using symbols, keywords, and clojure collections, you'd
get at least a bit syntax highlighting and maybe a bit support for
indentation or refactoring.
> From my perspective, a macro is essentially just a string that is
> being processed by the Clojure reader (and thus subject to its
> constraints). If the grammar were expressed in the way you propose,
> is it any easier to build up a grammar programmatically? Is it any
> easier to compose grammars? If anything, I think it might be harder.
I think it would be nice if grammars were expressed in a format
processable by Clojure in the very same respect as why homoiconicity in
general is a strength of Lisps.
FWIW, the Bison equivalent Emacs Lisp parser Wisent uses grammars
represented as s-exps.
http://www.gnu.org/software/emacs/manual/html_node/wisent/Grammar-format.html#Grammar-format
IMHO, it would be cool if a clojure parser library would use a similar
format (exploiting clojure data structures beyond lists where they make
sense), at least internally. Of course, one could still have other
frontends like for the EBNF you are using which would be translated to
the internal format.
Bye,
Tassilo
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
