I'm aware that this already has been discussed, and until recently I was content with clojure not exposing the readtable, because of the inherent modular problems. However, for CL, a nice approach to readtables was lately released:
http://trittweiler.blogspot.com/2009/10/ann-named-readtables-09.html I dabbled with it for some time and, in my opinion, this is a viable solution, even though Clojure already is full of reader macros, such a facility could be the solution to this kind of problem. Sure, one can like reader macros, and one can detest them, but in general I tend to prefer freedom to restriction, and nobody would be forced to use such a facility. Regards, dhl On 11 Okt., 23:38, Greg <g...@kinostudios.com> wrote: > Dear Clojure group and developers, > > In a recent discussion on #clojure it was pointed out that another > language called newLISP has an excellent feature that would be neat to > adopt into clojure, namely its special text delimiters {} and [text][/ > text]. It uses these delimiters to specify verbatim text (i.e. what's > in the parens is *exactly* what the string is, including the newlines). > > This feature makes it incredibly easy to write and include various > bits of text in the language such as example code, html, and it makes > writing regular expressions simple by avoiding the need for some > escapes. > > For example (newLISP code): > > (replace {"quoted" text} my-str {"quoted" string}) > > vs > > (replace "\"quoted\" text" my-str "\"quoted\" string}) > > As this has numerous advantages we discussed how such a construct > could be brought in to the benefit of Clojure, as in Clojure both the > {} and [] characters are reserved. > > The following candidates were considered and rejected for various > reasons: > > <> ; rejected because conflicts with statements like (< x 1) > #"" ; rejected because represents regex > #[] ; rejected because implies some sort of data structure like sets, > > #{} > [t][/t]; rejected because conflicts with arrays > > Finally we agreed that #s{ ... } would make a nice fit, as it fits > nicely with clojure's existing syntax and tendency to use the sharp to > signify a shorthand for something. On irc 'Chousuke' pointed out that > this construct could be used to make it easier to write doc strings > that include sample code for Clojure's functions, but of course there > are many other uses for such a construct (which I should note exists > in many other languages as well, even bash, but I referenced newLISP > as it's also a lisp and has a particularly elegant implementation). > > Any and all input is welcome on this proposal! > > Kind regards and thanks in advance for taking this into consideration, > Greg (irc: itistoday) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
