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,
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
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
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, b
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
ana
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
On Tue, Feb 10, 2015 at 11:29 AM, Alex Miller 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
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
@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
I apologize to the readers that may have a hard time getting rid
of the image of myself in a bath :)))
Sorry :)
> Hi,
>
> Nice feature if you write a spreadsheet app maybe.
> Still wonder who would use a console to interact with a spreadsheet :))
>
> Just kidding.
>
> Tagged literals are the
Hi,
Nice feature if you write a spreadsheet app maybe.
Still wonder who would use a console to interact with a spreadsheet :))
Just kidding.
Tagged literals are the way to go to extend the reader.
If lisp notation is so much a pain then build your own reader using a tool like
... instaparse.
Y
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 aft
*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 y
13 matches
Mail list logo
