For the sake of completeness, in this context "other users" is not limited to humans: what about IDE support? Refactoring tools? Code analysis?
You have to balance the potential extra complexities with the benefit, which to me seems to be very sparse: how often do you actually need to embed large swaths of CSV in your code? How big of an effort is it to load it from another file? (Even as EDN, if you have much data, it is better to load it from an external file than try to compile it.) I understand that csv is just an example, but again, if your goal is to shield users from parentheses, isn't it better to go through the relatively small effort of loading a separate file, so dsl users do not even have to know the system is in Clojure? If you are thinking of embedded dsls for the application developer, the Clojure community seems to have settled on data-based dsls, where data essentially means EDN. If you are targetting non-coder users, and do not want to try the EDN route, i would suggest external files with instaparse (though language design is hard). Anyway, regardless of whether a completely extensible language syntax is a good idea in principle, I do not think you will find much support in this community. It just does not mesh well with the idiomatic way to do things around here. (And what would you say to someone who wants to embed J code, where brackets are not often matched?) On Tuesday, 10 February 2015, Alex Miller <a...@puredanger.com> wrote: > Hi Henrik, > > There is a long-standing philosophical position in Clojure that it should > not be possible to write programs that cannot be read by other users. > Because of this position, I do not believe there is any chance of this > moving forward in Clojure itself. > > Tagged literals allow creating new data that can still be read and > interpreted even if a reader is not available so they give a certain > measure of this capability without crossing that line. > > Alex > > > > On Tuesday, February 10, 2015 at 6:03:56 AM UTC-6, henrik42 wrote: >> >> @Luc: I see your points. Thanks for the reply. >> >> Just to make it clear: all I suggest is to integrate >> https://github.com/henrik42/extended-lisp-reader/blob/ >> master/src/extended_lisp_reader/core.clj >> into clojure.core - i.e. make #[...]-forms and the delegation to user >> code "official". >> The rest of my lib is just examples of how this feature *could* be used. >> >> So we're talking about ~15 lines of code. >> >> But again - this might open up a way that we do not want to go in the end. >> >> Time will tell. >> >> >> -- > 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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');>. > For more options, visit https://groups.google.com/d/optout. > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
