I program primarily in Ruby and have been trying to find time to learn
Lisp. One of the things that attracts me to Lisp is the macro
facility. Consider the following pattern:
if a_long_expression > value
foo(a_long_expression)
bar(a_long_expression)
else
baz(a_long_expression)
end
This can be made more concise via an assignment:
if (x = a_long_expression) > value
foo(x)
bar(x)
else
baz(x)
end
However, this seems like a pragmatic hack since a new variable is
introduced simply for conciseness. Would you consider this an
appropriate case for a macro in Common Lisp?
Perhaps used as follows:
(my-if (> a-long-expression value)
(progn
(foo lhs)
(bar lhs))
(baz lhs))
where a-long-expression has been replaced by lhs
Brian Adkins wrote:
> However, this seems like a pragmatic hack since a new variable is
> introduced simply for conciseness. Would you consider this an
> appropriate case for a macro in Common Lisp?
>
> Perhaps used as follows:
>
> (my-if (> a-long-expression value)
> (progn
> (foo lhs)
> (bar lhs))
> (baz lhs))
>
> where a-long-expression has been replaced by lhs
It would be a rather simple macro, but if used that same pattern all
of the time, why not?
If the macro is always going to be invoked with a PROGN with two forms
and one form, you could make it accept three. You could also make it
so you can control what variable the value of a-long-expression is
bound to.
Brian Adkins wrote:
> I program primarily in Ruby and have been trying to find time to learn
> Lisp. One of the things that attracts me to Lisp is the macro
> facility. Consider the following pattern:
>
> if a_long_expression > value
> foo(a_long_expression)
> bar(a_long_expression)
> else
> baz(a_long_expression)
> end
>
> This can be made more concise via an assignment:
>
> if (x = a_long_expression) > value
> foo(x)
> bar(x)
> else
> baz(x)
> end
>
> However, this seems like a pragmatic hack since a new variable is
> introduced simply for conciseness. Would you consider this an
> appropriate case for a macro in Common Lisp?
Certainly if you're going to do it, you'd do it with macros. Whether you
should do it is a matter of debate.
> Perhaps used as follows:
>
> (my-if (> a-long-expression value)
> (progn
> (foo lhs)
> (bar lhs))
> (baz lhs))
>
> where a-long-expression has been replaced by lhs
See Anaphoric Macros for a common approach to this:
http://www.bookshelf.jp/texi/onlisp/onlisp_17.html#SEC111
Chris Riesbeck wrote:
> Brian Adkins wrote:
>
>> I program primarily in Ruby and have been trying to find time to learn
>> Lisp. One of the things that attracts me to Lisp is the macro
>> facility. Consider the following pattern:
>>
>> if a_long_expression > value
>> foo(a_long_expression)
>> bar(a_long_expression)
>> else
>> baz(a_long_expression)
>> end
>>
>> This can be made more concise via an assignment:
>>
>> if (x = a_long_expression) > value
>> foo(x)
>> bar(x)
>> else
>> baz(x)
>> end
>>
>> However, this seems like a pragmatic hack since a new variable is
>> introduced simply for conciseness. Would you consider this an
>> appropriate case for a macro in Common Lisp?
>
>
> Certainly if you're going to do it, you'd do it with macros. Whether you
> should do it is a matter of debate.
>
>> Perhaps used as follows:
>>
>> (my-if (> a-long-expression value)
Not such a great example since > will return t or nil, but we get the idea.
>> (progn
>> (foo lhs)
>> (bar lhs))
>> (baz lhs))
>>
>> where a-long-expression has been replaced by lhs
>
>
> See Anaphoric Macros for a common approach to this:
>
> http://www.bookshelf.jp/texi/onlisp/onlisp_17.html#SEC111
>
And throw in a var to be found so you can nest the things without surprises:
(my-if ale (a-long-search expression value)
(drink ale)
(go-thirsty))
My bif has a little diff syntax:
(bif (ale (a-long.....)) ; extra pair of parens
etc etc)
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 31, 1:52 pm, Ken Tilton <···········@optonline.net> wrote:
> Chris Riesbeck wrote:
> > Brian Adkins wrote:
>
> >> I program primarily in Ruby and have been trying to find time to learn
> >> Lisp. One of the things that attracts me to Lisp is the macro
> >> facility. Consider the following pattern:
>
> >> if a_long_expression > value
> >> foo(a_long_expression)
> >> bar(a_long_expression)
> >> else
> >> baz(a_long_expression)
> >> end
>
> >> This can be made more concise via an assignment:
>
> >> if (x = a_long_expression) > value
> >> foo(x)
> >> bar(x)
> >> else
> >> baz(x)
> >> end
>
> >> However, this seems like a pragmatic hack since a new variable is
> >> introduced simply for conciseness. Would you consider this an
> >> appropriate case for a macro in Common Lisp?
>
> > Certainly if you're going to do it, you'd do it with macros. Whether you
> > should do it is a matter of debate.
>
> >> Perhaps used as follows:
>
> >> (my-if (> a-long-expression value)
>
> Not such a great example since > will return t or nil, but we get the idea.
Well, I did want > to return t or nil so that either the 'then' or
'else' expression would be evaluated - I also wanted to grab the left
hand side to be used in the body.
But I agree that it's a poor example after reflecting on it a bit. I
noticed a repetitive pattern in Ruby code and had a knee-jerk reaction
about how I might reduce that if Ruby had macros, but either way a
variable will be introduced, so the explicit in place assignment is
hard to improve on in the original i.e.
changing: if a-long-expression > value
to: if (x = a-long-expression) > value
doesn't seem so bad, and makes clear what is happening. I'll have to
look elsewhere for compelling macro advantages. I may find them more
readily by coding more Lisp than by looking for opportunities in a
language that doesn't provide them. Of course, just converting the
some of the Rails runtime metaprogramming to compile time is pretty
compelling.
> >> (progn
> >> (foo lhs)
> >> (bar lhs))
> >> (baz lhs))
>
> >> where a-long-expression has been replaced by lhs
>
> > See Anaphoric Macros for a common approach to this:
>
> >http://www.bookshelf.jp/texi/onlisp/onlisp_17.html#SEC111
>
> And throw in a var to be found so you can nest the things without surprises:
>
> (my-if ale (a-long-search expression value)
> (drink ale)
> (go-thirsty))
>
> My bif has a little diff syntax:
>
> (bif (ale (a-long.....)) ; extra pair of parens
> etc etc)
>
> kt
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
On Mar 31, 1:30 pm, Brian Adkins <···········@gmail.com> wrote:
> I'll have to look elsewhere for compelling macro advantages. I may find them more
> readily by coding more Lisp than by looking for opportunities in a
> language that doesn't provide them.
Think of them more like a tool at your disposal than a solution
looking for a problem.
How are you using Ruby's meta-programming abstraction right now?
On Mar 31, 2:54 pm, Griff <·······@gmail.com> wrote:
> On Mar 31, 1:30 pm, Brian Adkins <···········@gmail.com> wrote:
>
> > I'll have to look elsewhere for compelling macro advantages. I may find them more
> > readily by coding more Lisp than by looking for opportunities in a
> > language that doesn't provide them.
>
> Think of them more like a tool at your disposal than a solution
> looking for a problem.
That's a good point, but given that macros are a key differentiator
between Lisp and many other languages, I'm particularly interested in
understanding them better, and part of that is looking for problems
where they offer a superior solution than a non-macro one.
On Mar 31, 2:26 pm, Brian Adkins <···········@gmail.com> wrote:
> > Think of them more like a tool at your disposal than a solution
> > looking for a problem.
>
> That's a good point, but given that macros are a key differentiator
> between Lisp and many other languages, I'm particularly interested in
> understanding them better, and part of that is looking for problems
> where they offer a superior solution than a non-macro one.
I feel like your approach may impede your progress, and ultimately
result in dissatisfaction.
Lisp is a multi paradigm programming language that allows for
syntactic extension. You can do pure FP, FP with side effects, and
even OO programming. So when you talk about solving programs with
macros you can use any of the aforementioned approaches in combination
with macros.
You need to pare down exactly that which you are looking to
understand. Are you dying to know why people love Lisp? Do you want to
know why it is the "programmable programming language" and perhaps
more importantly why you might care about that? You probably already
know OO, as you are not inquiring about CLOS. It sounds like you want
to see what is special about Lisp. Here is a good study plan to show
you what is so neat about it and in particular give you the details to
work with macros.
Take 1 week to read _The_Little_Schemer_ to learn about functional
programming (Common Lisp equivalents are in the annotations)
<You can tailor the following for Common Lisp, but someone needs to
chime in on the equivalent steps>
Take 1 week to read _The_Scheme_Programming_Language_2nd_Edition to
learn how the Scheme programming language, do as many problems as
possible, and skip what you don't grok
Take 1 week to re-read _The_Scheme_Programming_Language_2nd_Edition
and this time don't skip anything
By then you some of your questions will probably have been answered.
Here is question for you, how do you create your own object system in
Ruby using meta programming? The answer is that "you can't". That is
"big difference" number one.
Chris Riesbeck wrote:
> Brian Adkins wrote:
>> I program primarily in Ruby and have been trying to find time to learn
>> Lisp. One of the things that attracts me to Lisp is the macro
>> facility. Consider the following pattern:
>>
>> if a_long_expression > value
>> foo(a_long_expression)
>> bar(a_long_expression)
>> else
>> baz(a_long_expression)
>> end
>>
>> This can be made more concise via an assignment:
>>
>> if (x = a_long_expression) > value
>> foo(x)
>> bar(x)
>> else
>> baz(x)
>> end
>>
>> However, this seems like a pragmatic hack since a new variable is
>> introduced simply for conciseness. Would you consider this an
>> appropriate case for a macro in Common Lisp?
>
> Certainly if you're going to do it, you'd do it with macros. Whether you
> should do it is a matter of debate.
>
>> Perhaps used as follows:
>>
>> (my-if (> a-long-expression value)
>> (progn
>> (foo lhs)
>> (bar lhs))
>> (baz lhs))
>>
>> where a-long-expression has been replaced by lhs
>
> See Anaphoric Macros for a common approach to this:
>
> http://www.bookshelf.jp/texi/onlisp/onlisp_17.html#SEC111
>
I think I should finally buy the On Lisp book!