Forgive me, but I'm unfamiliar with the readtable, are you just referring to where this syntax might be implemented? Or are you suggesting an alternative syntax?
- Greg On Oct 12, 2009, at 11:20 AM, DanL wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
