> Similarly #"" is pretty close to what the re-pattern
> function does. One difference is that #"" compiles the
> regex at read time while re-pattern compiles it runtime. If
> re-pattern were a macro that difference would essentially
> disappear.
In code, yes, it would disappear because you can shift the operation
into a later phase. In data, not so, because those later phases never
occur.
user=> (type (second (read-string "(foo #\"hello\")")))
java.util.regex.Pattern
user=> (type (second (read-string "(foo (re-pattern \"hello\"))")))
clojure.lang.PersistentList
user=> (type (eval (read-string "(re-pattern \"hello\")")))
java.util.regex.Pattern
This is to say, forms that have reader support can be treated as data
but still contain concrete objects without evaluation. Forms that do
not must be somehow evaluated.
When you have arbitrary forms arriving from user data -- such as a
query language -- it's really nice to avoid having to write a generic
tree walker...
We use these concrete reader-supported objects all the time, such as
when reading config files off-disk, taking advantage of Clojure's
literal reader support for maps, strings, numbers, etc.
Right now you can embed a regex literal, or a BigDecimal, in a literal
form. You can't embed a URI, or a complex number, without involving
explicit evaluation. I imagine that if Rich was building Semantic Web
tools, or working in complex mathematics, there would be syntactic
support for these things.
(This is not to gripe, or bitch, or say that Rich has made wrong
decisions. I'm just pointing out that extensibility allows you to
build the tools you need for your domain without waiting for the
language implementor. That's the touted advantage of Lisp...)
> So in general 1 is in my opinion a fairly minor syntax
> thing, while 2 could be somewhat alleviated if Clojure had
> a string literal format that allowed un-escaped double
> quotes and left backslashes unmolested. This would allow
> things like (infix #'''5*2'''). Again, not pretty but
> perhaps better than nothing.
That's probably convenient, but note that this supports your own regex-
like mini-language (;)) but requires the same contortions for
something like language annotations:
"chien"@fr
The point of reader macros is to offer the same extensibility
processing strings in the reader as programmers get from macros
processing forms at compile time.
Ultimately, disallowing reader macros puts the burden of syntactic
extension on the end user and the developer: they must come up with
some alternative, probably involving parsing strings at compile- or
run-time, and the user must use them.
That might be a good tradeoff if syntactic extension is uncommon --
Clojure is certainly very useful now, extensible reading carries a
cost, and I'm hardly one to say that aping Common Lisp is a great idea
-- but maybe syntactic extension is avoided because it has thus far
been impossible (Clojure) or unsafe (Common Lisp)?
> One argument against wide-open user defined reader macros
> that I don't think I've heard is that currently any .clj
> file can be parsed without evaluating any of the code. It
> can't be compiled without executing macros, but at least it
> can be parsed.
That's a good point, though it's only true to say "without evaluating
any of the code in user files". Clojure core reader macro code runs
all the time when reading; that's the point. I think it's fair to say
that reader macros are in a different category to 'ordinary' code, and
I wouldn't object to restrictions such as "no reader macros operating
in the same file or namespace".
-R
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
