On Aug 14, 11:46 am, Brian Hurt <bhur...@gmail.com> wrote:
> On Thu, Aug 13, 2009 at 4:59 PM, Daniel Lyons <fus...@storytotell.org>wrote:
>
>
>
>
>
> > On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:
>
> > I'm just wondering what people's response would be to allow user-generated
> > reader macros.  I'm not sure, but I think the only change to the clojure
> > core that would be necessary in order to do this would be that in
> > clojure/src/jvm/clojure/lang, LispReader.dispatchMacros would have to be
> > made public.  This would allow user code to update this array and add new
> > macro functions.
>
> > Now, I can certainly see a lot of potiential downsides to this.  Redefining
> > what #{} or #() means is just the start.  But it'd make it a lot easier to
> > do things with DSLs.
>
> > So, what are people's thoughts?
>
> > Trying to use them in Common Lisp has frustrated the crap out of me. The
> > only library I know of that promulgates them seriously is CL-SQL and the
> > gymnastics you have to do to install the reader macros are frustrating.
> > Another library I tried to use I couldn't get to work at all (units, I
> > think).
>
> > In general I don't think they're worth the trouble. Reducing code
> > compatibility is also a problem. Perhaps with namespaces there could be a
> > better way to do it than CL does but I'm very wary of them. I don't think
> > Scheme lets you have them at all.
>
> 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.  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.
> And I don't think even plugging them into namespaces (which I don't see how
> to do) would help all that much.
>
> In any case, thanks everyone.
>
> Brian

It would be nice if someone wrote a separate extension to clojure that
(reads in a text file and) that does tokenization and manipulation of
said tokens (I'm thinking YACC, flex/bison sort of thing).

(Then you could substitute in clojure/clojure macros to make 'syntax'
tree, and pass it to eval...).

All of the stuff is there, as there are functions to flip between text/
symbols (regexp symbol-name etc).

Overall, I think a seperate tokenizer/lexer solution would end up
being more robust than being able to manipulate the read tables,
because instead of having to create a DSL that looks like lisp, you
could create a DSL that looks like /anything/. (Then gets turned into
clojure).

Besides, manipulating read tables turns into a pain.

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

Reply via email to