> Reading the responses to this thread, and thinking about things,
> I've come around to this point of view.
>
> What I wanted was the ability to read Clojure data structures from a
> file or from stdin in a way that I could extend- for long, involved
> reasons I need to specify byte arrays (as created by make-array Byte/
> TYPE) as fundamental data structures, and was thinking I could just
> use the standard clojure reader plus a new macro to do the byte
> arrays.
>
> Except for two things- first of all, I don't want to use the
> standard clojure reader in the first place, as I want to disallow
> things like lambda closures.
Reading != evaluation.
The form
{:foo (let [x 5] (fn [y] (+ x y)))}
contains no clojures, no lambdas… nothing executable at all. It's a
single-pair map, where the only object is a PersistentList.
Try it:
user=> (:foo (read-string "{:foo (let [x 5] (fn [y] (+ x y)))}"))
(let [x 5] (fn [y] (+ x y)))
user=> (type *1)
clojure.lang.PersistentList
To get a function object or a closure you need eval:
user=> (eval *2)
#<user$eval__91$fn__93 user$eval__91$fn_...@60498b39>
user=> (*1 3)
8
A reader macro allows you to produce a data structure at read time
from the user input; the reader turns a stream of characters into a
data structure. It's a parser.
You could write your own parser to produce data structures from a
stream of user input, but all that allows you to do is support non-
Lispy syntax and throw more meaningful errors. If you use Clojure's
reader, simply check the data structure you get out the other end —
you probably have to do that anyway.
The reader *is* a parser for reading Clojure data structures from a
file or stdin. You'd be doing a lot of unnecessary work if you wrote
your own. Furthermore, extending the built-in reader means that your
work can be reused — your tests can use the same syntax, your code
can, other people can use your library to express byte arrays. I'd use
it for sure.
[[
Sidenote:
A big motivation for reader macros is that, over the years, there have
been and will be hundreds of people like you who end up having to
write their own parser because they need just a tiny bit more
syntactic support. Individually it's easy to dismiss them -- "oh, it's
no big deal to write a custom parser for byte arrays", "oh, I can just
do this with a macro instead", "never mind, I didn't really need that
feature" -- but aggregated there's a lot of pointless work being done.
]]
> And second of all, the cost of allowing readers and rewriting the
> syntax of the language as it's parsed, is huge. I'd be imposing a
> huge and lasting cost on all clojure developers to save me a small
> cost right now.
Brian, I'm not sure that's the case, for two reasons:
1. Common Lisp implementations have supported reader macros for many
years, and their readers are very, very fast.
2. Clojure already has extensible reader macros — it simply doesn't
expose it to non-core code. I even hacked one in a couple of months
ago when I was experimenting with syntax support for multisets.
There should be no speed penalty for allowing user reader macros when
compared to core reader macros.
-R
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
