> 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 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 -~----------~----~----~----~------~----~------~--~---