On Fri, Aug 14, 2009 at 7:00 PM, Jonathan Smith
wrote:
>
> It would be nice if someone wrote a separate extension to clojure that
> (reads in a text file and) that does tokenization and manipulation of
> said tokens (I'm thinking YACC, flex/bison sort of thing).
>
> (Then you could substitute in c
Hi,
On Aug 20, 4:59 pm, Brian Hurt wrote:
> This I like better, and I may take a crack at doing this over the next
> weekend. Have some sort of parser object that starts life parsing the same
> s-expression syntax as the standard Clojure reader but allows for
> extensions. This would sidestep
> Reading the responses to this thread, and thinking about things,
> I've come around to this point of view.
>
> What I wanted was the ability to read Clojure data structures from a
> file or from stdin in a way that I could extend- for long, involved
> reasons I need to specify byte arrays
On Aug 14, 11:46 am, Brian Hurt wrote:
> On Thu, Aug 13, 2009 at 4:59 PM, Daniel Lyons wrote:
>
>
>
>
>
> > On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:
>
> > I'm just wondering what people's response would be to allow user-generated
> > reader macros. I'm not sure, but I think the only chang
On Thu, Aug 13, 2009 at 4:59 PM, Daniel Lyons wrote:
>
> On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:
>
> I'm just wondering what people's response would be to allow user-generated
> reader macros. I'm not sure, but I think the only change to the clojure
> core that would be necessary in order
On Aug 14, 2009, at 10:49 AM, Chouser wrote:
> So in general 1 is in my opinion a fairly minor syntax
> thing, while 2 could be somewhat alleviated if Clojure had
> a string literal format that allowed un-escaped double
> quotes and left backslashes unmolested. This would allow
> things like (in
> Similarly #"" is pretty close to what the re-pattern
> function does. One difference is that #"" compiles the
> regex at read time while re-pattern compiles it runtime. If
> re-pattern were a macro that difference would essentially
> disappear.
In code, yes, it would disappear because you can
On Fri, Aug 14, 2009 at 3:28 AM, Daniel Lyons wrote:
>
> On Aug 14, 2009, at 12:12 AM, Chouser wrote:
>> Perhaps these different desires can fulfilled with two different
>> constructs.
>
> The two being:
>
> 1. To remove parens from a function or macro call. You mean e.g. #"
> and #()?
Right, tho
> Clojure spells this #_ instead of / and it is indeed
> implemented as a (builtin) reader macro.
Nice, thanks!
:)
>
> --Chouser
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to thi
On Fri, Aug 14, 2009 at 10:20 AM, Boris Mizhen - 迷阵 wrote:
>
> One thing that I would like to see implemented seems like a good
> candidate for a reader macro...
>
> I find it useful to have a way to comment out an expression by
> prefixing it with some symbol.
>
> I.E. if a '/' before an expressi
One thing that I would like to see implemented seems like a good
candidate for a reader macro...
I find it useful to have a way to comment out an expression by
prefixing it with some symbol.
I.E. if a '/' before an expression is an expression comment, it is
easy to experiment with code:
(foo
I suspect that reader macros are necessary to fully realize named-
argument message passing.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.co
Just to add a bit of contradiction to the debate: it is generally told to
people coming to lisp that "lisp is all about giving power to users, and
it's up to them to take care of not shooting themselves in the foot".
E.g. that' the general answer when one complains that there's no static
typing wit
On Aug 14, 2009, at 12:12 AM, Chouser wrote:
> That particular example may not have to be a macro at all:
>
> http://paste.lisp.org/display/75230
Wonderful! :)
> I think people want reader macros for a couple different reasons.
> Sometimes it's just to remove parens from a function or macro cal
On Aug 14, 2009, at 2:03 AM, Chouser wrote:
>
>
> On Aug 14, 2009, at 12:48 AM, Daniel Lyons
> wrote:
>
>>
>>
>> On Aug 13, 2009, at 5:30 PM, Bradbev wrote:
>>
> More complex "reader" macros could be (infix x + y + z / 3).
I think you can already do that with regular macros.
>
On Aug 14, 2009, at 12:48 AM, Daniel Lyons
wrote:
>
>
> On Aug 13, 2009, at 5:30 PM, Bradbev wrote:
>
More complex "reader" macros could be (infix x + y + z / 3).
>>>
>>> I think you can already do that with regular macros.
>>
>> I don't think so. Macros are invoked after the read stag
On Aug 13, 2009, at 5:30 PM, Bradbev wrote:
>>> More complex "reader" macros could be (infix x + y + z / 3).
>>
>> I think you can already do that with regular macros.
>
> I don't think so. Macros are invoked after the read stage but before
> evaluation of arguments. This kind of macro would b
Hmm, not so sure this is related, but I've often thought it would be
great to have some way of having "embedded" source of other types as a
"special" string defined as normal in the clojure source but marked in
such as way that the editor (vim, emacs, etc) could recognise this and
do formatting, s
On Aug 13, 5:47 pm, Chas Emerick wrote:
>
> A good thought, but #"foo" is reader syntax for defining a regular
> expression with the pattern "foo". :-/
>
Sorry about that, I'm not experienced at Clojure, but I should have
been more clear. The first important part isn't which character
trigge
>> So, what are people's thoughts?
>
> Trying to use them in Common Lisp has frustrated the crap out of me.
> The only library I know of that promulgates them seriously is CL-SQL
> and the gymnastics you have to do to install the reader macros are
> frustrating. Another library I tried to us
On Aug 14, 2:47 am, Chas Emerick wrote:
> On Aug 13, 2009, at 8:29 PM, Scott wrote:
>
> > A single "super quoted" string reader would avoid this problem.
> > Instead of defining a new read syntax like:
>
> > #my-syntax(your DSL goes between here and here)
>
> > Clojure could provide a general pu
On Aug 13, 2009, at 8:29 PM, Scott wrote:
> A single "super quoted" string reader would avoid this problem.
> Instead of defining a new read syntax like:
>
> #my-syntax(your DSL goes between here and here)
>
> Clojure could provide a general purpose string creating read syntax.
> Something like
On Aug 13, 1:30 pm, Brian Hurt wrote:
> I'm just wondering what people's response would be to allow user-generated
> reader macros. [...]
I think you could get most of the benefits for DSL's by using regular
strings, except that regular strings have quoting issues:
(my-dsl-macro "Here is my
On Aug 13, 3:43 pm, Daniel Lyons wrote:
> On Aug 13, 2009, at 3:35 PM, Bradbev wrote:
>
>
>
>
>
> > What is the main point of reader macros? Is it so you can define your
> > own short-hand syntax, or is it the ability to get more direct access
> > to the reader?
> > If it is the first point, t
On Aug 13, 2009, at 3:35 PM, Bradbev wrote:
>
> What is the main point of reader macros? Is it so you can define your
> own short-hand syntax, or is it the ability to get more direct access
> to the reader?
> If it is the first point, then I'd be happy to not have them - to me
> shorthand doesn
What is the main point of reader macros? Is it so you can define your
own short-hand syntax, or is it the ability to get more direct access
to the reader?
If it is the first point, then I'd be happy to not have them - to me
shorthand doesn't buy much.
If it is the second point then why not simply
On Thu, Aug 13, 2009 at 5:23 PM, Aaron Cohen wrote:
> On Thu, Aug 13, 2009 at 5:14 PM, Meikel Brandmeyer wrote:
>> Hi,
>>
>> Am 13.08.2009 um 22:30 schrieb Brian Hurt:
>>
>>> Now, I can certainly see a lot of potiential downsides to this.
>>> Redefining what #{} or #() means is just the start.
>>
On Thu, Aug 13, 2009 at 5:14 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 13.08.2009 um 22:30 schrieb Brian Hurt:
>
>> Now, I can certainly see a lot of potiential downsides to this.
>> Redefining what #{} or #() means is just the start.
>
> I think, this is the reason Rich is not very positive for
On Aug 13, 2009, at 4:59 PM, Daniel Lyons wrote:
> On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:
>
>> I'm just wondering what people's response would be to allow user-
>> generated reader macros. I'm not sure, but I think the only change
>> to the clojure core that would be necessary in ord
Hi,
Am 13.08.2009 um 22:30 schrieb Brian Hurt:
Now, I can certainly see a lot of potiential downsides to this.
Redefining what #{} or #() means is just the start.
I think, this is the reason Rich is not very positive for that idea:
because nobody came up with a way of defining "namespaces
On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:
> I'm just wondering what people's response would be to allow user-
> generated reader macros. I'm not sure, but I think the only change
> to the clojure core that would be necessary in order to do this
> would be that in clojure/src/jvm/clojur
I'm just wondering what people's response would be to allow user-generated
reader macros. I'm not sure, but I think the only change to the clojure
core that would be necessary in order to do this would be that in
clojure/src/jvm/clojure/lang, LispReader.dispatchMacros would have to be
made public.
32 matches
Mail list logo
