Re: Extending the LispReader with embeded language lorms
For what it's worth, I see two things intertwined here, one being the desire to embed text in an arbitrary format and interpret it, the other being the mechanism in which you're doing it. To me, it seems you can do the kinds of things you have shown as examples by using just functions, macros, and strings, without having to resort to arbitrary reader extension. If you embed things as strings, say, similarly to how instaparse works, then you can still read in CSV text, code in other languages, etc. For example, rewriting your csv example using macros/functions/string: (def parse-csv (insta/parser file = record (line-break record)* _ = \ \+ CR = '\u000D' LF = '\u000A' CRLF = CR LF line-break = CRLF | CR | LF field-sep = #\ *, *\ field = unquoted-field | quoted-field unquoted-field = #\[a-zA-Z0-9]*\ quoted-field = '\' #\[^\n\\r]*\ '\' record = _? field (field-sep field)* _?)) (defmacro parse-csv! [csv] (parse-csv csv)) (parse-csv! foo , \bar man ccc\, boo fred , fox ) Now, while going through and quoting text is inconvenient, it's just that. It doesn't limit one from still using existing mechanisms to interpret text at run-time or compile-time via functions and macros respectively. To get around the inconvenience of quoting, having here docs, or triple-quoted strings ala Python, as a first-class construct in Clojure could address that. It's a smaller change that would seem to address making convenient what you're doing, but without the bigger costs that would occur with arbitrary reader extension. At least with this, the rest of the Clojure language remains the same (homoiconicity, commas as white space, indenting is insignificant, etc.). The only change that ripples out to users and tooling is that a string has a new way of being defined. (To note, alternate string quoting has been proposed at [1], which includes a link to an implementation of triple-quote reading, but this design page seems to have been around a while...) [1] - http://dev.clojure.org/display/design/Alternate+string+quote+syntaxes On Wednesday, February 11, 2015 at 3:59:45 AM UTC-5, Henrik Heine wrote: Hi, Am Dienstag, 10. Februar 2015 21:07:50 UTC+1 schrieb Gary Verhaegen: For the sake of completeness, in this context other users is not limited to humans: what about IDE support? Refactoring tools? Code analysis? I agree. You lock out others and that takes away a lot. For me that's the main argument against my proposal. I was not thinking to copypaste huge CSV data in to Clojure files. I'm thinking more about in-line configuration that you can copypaste to/from other sources, test data, maybe literate programming (haven't worked that out though). But not only data stuff could be in-lined: prolog code, SQL statements compiled to the corresponding Clojure libs. OK - the indirection through an external file does not cost that much. You could even use it to try out new Clojure features (like reader conditionals) without touching one line of Clojure core - just make it a #[CLJxxx ...] form and play around with it before you move it over to the Clojure core code. And you could back-port things just by supplying a lib/function. In this case the embedded syntax would still be Clojure. I still feel like being new to Clojure, so thanks for all the replies and the insights into The Clojure Way. Henrik -- 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.
Re: Extending the LispReader with embeded language lorms
Hi, Am Dienstag, 10. Februar 2015 21:07:50 UTC+1 schrieb Gary Verhaegen: For the sake of completeness, in this context other users is not limited to humans: what about IDE support? Refactoring tools? Code analysis? I agree. You lock out others and that takes away a lot. For me that's the main argument against my proposal. I was not thinking to copypaste huge CSV data in to Clojure files. I'm thinking more about in-line configuration that you can copypaste to/from other sources, test data, maybe literate programming (haven't worked that out though). But not only data stuff could be in-lined: prolog code, SQL statements compiled to the corresponding Clojure libs. OK - the indirection through an external file does not cost that much. You could even use it to try out new Clojure features (like reader conditionals) without touching one line of Clojure core - just make it a #[CLJxxx ...] form and play around with it before you move it over to the Clojure core code. And you could back-port things just by supplying a lib/function. In this case the embedded syntax would still be Clojure. I still feel like being new to Clojure, so thanks for all the replies and the insights into The Clojure Way. Henrik -- 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.
Re: Extending the LispReader with embeded language lorms
As an example of pushing data into an external DSL you could check out John Cowie's Scenic wrapper for Bidi - https://github.com/johncowie/scenic. Note that Scenic loads data from the external file at _compile_ time - so it comes closer to being like embedding a DSL in Clojure source and less like a configuration file that's read at runtime. Chris On 11 February 2015 at 19:59, Henrik Heine h3nr1k.h3...@googlemail.com wrote: Hi, Am Dienstag, 10. Februar 2015 21:07:50 UTC+1 schrieb Gary Verhaegen: For the sake of completeness, in this context other users is not limited to humans: what about IDE support? Refactoring tools? Code analysis? I agree. You lock out others and that takes away a lot. For me that's the main argument against my proposal. I was not thinking to copypaste huge CSV data in to Clojure files. I'm thinking more about in-line configuration that you can copypaste to/from other sources, test data, maybe literate programming (haven't worked that out though). But not only data stuff could be in-lined: prolog code, SQL statements compiled to the corresponding Clojure libs. OK - the indirection through an external file does not cost that much. You could even use it to try out new Clojure features (like reader conditionals) without touching one line of Clojure core - just make it a #[CLJxxx ...] form and play around with it before you move it over to the Clojure core code. And you could back-port things just by supplying a lib/function. In this case the embedded syntax would still be Clojure. I still feel like being new to Clojure, so thanks for all the replies and the insights into The Clojure Way. Henrik -- 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. -- 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.
Re: Extending the LispReader with embeded language lorms
@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 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.
Re: Extending the LispReader with embeded language lorms
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 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.
Re: Extending the LispReader with embeded language lorms
For a competent English speaker/reader, Infinite Jest is hard to read because it's dense and elliptical c. c. For that same reader, Tintin in the original French is hard to read because it's in French. I think that's a relevant distinction to make in this context. Extensibility is nice, but there comes a point where, for all intents and purposes, a piece of code stops being Clojure and starts being something else. On Tuesday, February 10, 2015 at 3:12:46 PM UTC-5, Gary Verhaegen wrote: I *think* Alex means read in the very specific and technical sense of a Lisp reader, i.e. a piece of program that turns a stream of characters into data structures in memory, and then I guess the other users are all of the other programs, beside the Clojure compiler itself, that may want to analyze or manipulate Clojure code. I certainly hope he's not proposing to excommunicate abybody writing hard to understand code on occasion. ;-) On Tuesday, 10 February 2015, Ben Wolfson wol...@gmail.com javascript: wrote: On Tue, Feb 10, 2015 at 11:29 AM, 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. What does that mean? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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. -- 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.
Re: Extending the LispReader with embeded language lorms
I *think* Alex means read in the very specific and technical sense of a Lisp reader, i.e. a piece of program that turns a stream of characters into data structures in memory, and then I guess the other users are all of the other programs, beside the Clojure compiler itself, that may want to analyze or manipulate Clojure code. I certainly hope he's not proposing to excommunicate abybody writing hard to understand code on occasion. ;-) On Tuesday, 10 February 2015, Ben Wolfson wolf...@gmail.com wrote: On Tue, Feb 10, 2015 at 11:29 AM, Alex Miller a...@puredanger.com javascript:_e(%7B%7D,'cvml','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. What does that mean? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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.
Re: Extending the LispReader with embeded language lorms
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.
Re: Extending the LispReader with embeded language lorms
On Tue, Feb 10, 2015 at 11:29 AM, 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. What does that mean? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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.
Re: Extending the LispReader with embeded language lorms
Not anybody? I'm a little puzzled: is this feature so useless? I thought embedding stuff like CSV data in Clojure code as is could be a nice feature. https://github.com/henrik42/extended-lisp-reader#parsing-csv No need to rewrite it in Clojure syntax/string literals or other forms. I think after having tagged literals (which still stick to Clojure forms/syntax) it could be the next step in building DSLs with Clojure. Henrik -- 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.
Extending the LispReader with embeded language lorms
Hi, I would like to be able to include non-Lisp-ish DSLs in my clojure code (like bash HERE documents) e.g. for copypasting CSV data into the code without having to go through an external file and consume that. So I hacked an experiment that does the parsing and embeding (transforming to Clojure target form is missing in the examples). If you're interested have a look at https://github.com/henrik42/extended-lisp-reader What do you think? Henrik -- 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.
Re: Extending the LispReader with embeded language lorms
*LOL* Can anybody change the title to embeded language forms? :-) -- 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.
