I favor using a map as the state because I think the information in
your example is an integral part of most parsing goals, not meta-data
retained to serve an auxiliary purpose. An example of what I would
consider meta-data for a parser would be the number of calls to
consumption functions the parser had to make before each token was
consumed. It's not used for parsing, but it would be useful for
determining the performance of your parser and possibly as debugging
information.
On Aug 21, 1:25 pm, samppi <rbysam...@gmail.com> wrote:
> I'm trying to make a decision in a parser library between using
> regular maps as states (containing a sequence of remaining tokens, as
> well as other info) vs. using metadata maps attached to the sequence
> of remaining tokens. In other words:
>
> {:remainder [\r \e \m], :index 3, :line 5, :column 2}
>
> vs.
>
> #^{:index 3, :line 5, :column 2} [\r \e \m]
>
> The two germane properties I can think of are accessing speed and
> equality of states in testing.
>
> If I do the former, then I can directly alter the index, line, and
> column. But in my tests, I have to write something like (make-state
> [\r \e \m] 3 5 2) every time. (That might be a good or bad thing; it's
> a lot more cluttered, but always explicit about what the expected
> values of the whole state are.)
>
> If I do the latter, then to access or alter the index, line, or
> column, I have to use 'meta or 'with-meta. Yet my tests would be a lot
> cleaner, because I wouldn't have to repeat the line or column every
> time I make a state. What I'm worried about is the speed impact that
> 'meta and 'with-meta may have. Are their time effects negligible?
> Which would be "better" Clojure?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
