One idea is to reserve #[] for a concept that supersedes macros.
For instance, we have yet to apply the concept of protocols to macros.
Another direction is recursive subexpansion, a la mathematica.
If you consider transformations between code and data, there are 4
possibilities:
data->data (this is what a vanilla function does)
code->code (vanilla macros)
code->data (eval in lisp, HoldAll attribute in mathematica)
data->code (compiler)
There is quite a bit of room to play with the interaction and
composition of these operations. Macros are not the end of the road.
Problems that need to be solved include:
- multipass compiler
- feature expressions
- divergence in eval behavior between reader literals like [(+ 1 x)]
and tagged literals like #my/tag (+ 1 x)
On Fri, Dec 28, 2012 at 5:15 PM, vemv <v...@vemv.net> wrote:
> I was just wondering - given that we have the #() and #{} literals, why not
> a #[] as well? Queues look like a good fit.
>
> --
> 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 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
