After reading higly informative article http://c2.com/cgi/wiki?ThreeStarProgrammer
saying
The more indirect your pointers are (i.e. the more "*" before your
variables), the higher your reputation will be. In the lisp world that
would roughly correspond to Three Macro Programmer, or someone who
writes a macro that uses another his macro that uses another his macro.
(Macro coming with the language or the library should probably not be
counted.) What is the normal rating for a lisper ? And what is
your highest rating achieved ?
Slobodan Blazeski wrote:
> After reading higly informative article http://c2.com/cgi/wiki?ThreeStarProgrammer
> saying
> The more indirect your pointers are (i.e. the more "*" before your
> variables), the higher your reputation will be. In the lisp world that
> would roughly correspond to Three Macro Programmer, or someone who
> writes a macro that uses another his macro that uses another his macro.
> (Macro coming with the language or the library should probably not be
> counted.) What is the normal rating for a lisper ? And what is
> your highest rating achieved ?
>
This is very different !
Macros are mostly used to capture a common pattern under a single name.
They actually make the code's intent easier to grasp.
Sacha
Sacha wrote:
> Macros are mostly used to capture a common pattern under a single name.
> They actually make the code's intent easier to grasp.
That's where functions should be preferred. Macros exist for use in
situations where the evaluation of operands has to be different from the
functional case. It's mostly not a good idea to use macros where
functions could also be used.
Matthias Buelow wrote:
> Sacha wrote:
>
>> Macros are mostly used to capture a common pattern under a single name.
>> They actually make the code's intent easier to grasp.
>
> That's where functions should be preferred. Macros exist for use in
> situations where the evaluation of operands has to be different from the
> functional case. It's mostly not a good idea to use macros where
> functions could also be used.
Though i agree that functions should be preferred whenever possible, I
think you're being a bit restrictive there.
Consider with-output-to-string for instance. There's no specific
evaluation of operands taking place, it's merely a syntactic shortcut,
and indeed captures a common pattern under a single name.
Of course we could open the debate again on macros vs higher order
functions, with-open-file would be a good starting point for that =)
Sacha
Sacha wrote:
> Consider with-output-to-string for instance. There's no specific
> evaluation of operands taking place,
Yes there is, the body forms are substituted unevaluated.
Matthias Buelow wrote:
> Sacha wrote:
>
>> Consider with-output-to-string for instance. There's no specific
>> evaluation of operands taking place,
>
> Yes there is, the body forms are substituted unevaluated.
Well at that rate, if I write a "macro that could as well be a
function", the body forms will also be substituted unevaluated, so that
would make it valid, though it is not.
I see what's your problem with this statement of mine. Macros and
function are both used to capture a pattern under a single name. They're
not fully orthogonal concepts IMO.
Sacha
Sacha wrote:
> Well at that rate, if I write a "macro that could as well be a
> function", the body forms will also be substituted unevaluated, so that
> would make it valid, though it is not.
I don't really understand what you mean by that. You cannot pass an
argument to a function unevaluated, you'd have to quote them.
The above macro could hypothetically be replaced by a function if you
quote the body form parameters, and then in the function wrap them in a
lambda list of 1 argument (named appropriately), coerce that to function
and then call it with the string variable as parameter, or something
like that. But the invocation would still be different to the macro
form, since you'd have to quote the body forms (and probably the
variable argument too, unless you use a fixed name), so it would look
something like:
(with-output-to-string-fn 'var string
'(body form 1)
'(body form 2)
...
'(body form n))
vs.
(with-output-to-string (var string)
(body form 1)
(body form 2)
...
(body form n))
which is more "natural", imho.
Handling of the optional/keyword operands would be different, too.
A simplified version of with-output-to-string-fn could look something
like that:
(defun with-output-to-string-fn (var string &rest forms)
(let* ((lamlis `(lambda (,var) ,@forms))
(fn (coerce lamlis 'function)))
(unwind-protect ...
(funcall fn string)
...))
string)
I wrote:
> The above macro could hypothetically be replaced by a function if...
One additional note, if you use this variant, you don't have access to
lexical variables in outer forms, which would complicate the whole
thing. I can't see any practical way how this particular construct could
be done without a macro.
Matthias Buelow <···@incubus.de> wrote:
+---------------
| I wrote:
| > The above macro could hypothetically be replaced by a function if...
|
| One additional note, if you use this variant, you don't have access to
| lexical variables in outer forms, which would complicate the whole
| thing. I can't see any practical way how this particular construct
| could be done without a macro.
+---------------
Well, if instead of using (QUOTE form) to wrap argument forms you
used (LAMBDA () form), that would give you [selective] access in
the called function to lexical variables in the calling function.
That used to be done all the time in Scheme before R5RS macros
appeared.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Matthias Buelow <···@incubus.de> writes:
> One additional note, if you use this variant, you don't have access to
> lexical variables in outer forms, which would complicate the whole
> thing. I can't see any practical way how this particular construct could
> be done without a macro.
If the function may require callers to quote the body forms,
thus moving away from the syntax used by WITH-OUTPUT-TO-STRING,
then I think this should also be allowed:
(call-with-output-to-string
(lambda (var)
(body form 1)
(body form 2)
...
(body form n))
string :element-type 'base-char)
Matthias Buelow wrote:
> Sacha wrote:
>
>
>>Macros are mostly used to capture a common pattern under a single name.
>>They actually make the code's intent easier to grasp.
>
>
> That's where functions should be preferred. Macros exist for use in
> situations where the evaluation of operands has to be different from the
> functional case.
Nonsense. C macros are about mere substitution, Lisp macros allow me to
write arbitrary Lisp code to do arbitrary fun things in expanding the
macro. There is a pattern, but not one that lends itself to mere
substitution.
They also let me hide boilerplate without forever coding (do-this x y
(lambda (a b c) ...whatever), which is not even as flexible as using a
macro because my lambda arglist and do-this need modification every time
the lambda body wants a new variable from the caller's lexical scope.
kenny
Sacha <····@address.spam> writes:
> Macros are mostly used to capture a common pattern under a single
> name. They actually make the code's intent easier to grasp.
I tend to think of macros as being most useful for extending the
syntax of the language so that some set of problems and solutions can
be expressed more readily. It usually means that the code's intent is
clearer, but I don't know how that relates to common patterns.
Slobodan Blazeski <·················@gmail.com> writes:
> After reading higly informative article http://c2.com/cgi/wiki?ThreeStarProgrammer
> saying
> The more indirect your pointers are (i.e. the more "*" before your
> variables), the higher your reputation will be. In the lisp world that
> would roughly correspond to Three Macro Programmer, or someone who
> writes a macro that uses another his macro that uses another his macro.
> (Macro coming with the language or the library should probably not be
> counted.) What is the normal rating for a lisper ? And what is
> your highest rating achieved ?
It's not macros that _use_ macro, this is trivial, it's macros that _generate_ macros.
If you write a non trivial macro that generates macros that generate
macros, you might get some points.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jul 10, 6:57 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > After reading higly informative articlehttp://c2.com/cgi/wiki?ThreeStarProgrammer
> > saying
> > The more indirect your pointers are (i.e. the more "*" before your
> > variables), the higher your reputation will be. In the lisp world that
> > would roughly correspond to Three Macro Programmer, or someone who
> > writes a macro that uses another his macro that uses another his macro.
> > (Macro coming with the language or the library should probably not be
> > counted.) What is the normal rating for a lisper ? And what is
> > your highest rating achieved ?
>
> It's not macros that _use_ macro, this is trivial, it's macros that _generate_ macros.
>
> If you write a non trivial macro that generates macros that generate
> macros, you might get some points.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> NOTE: The most fundamental particles in this product are held
> together by a "gluing" force about which little is currently known
> and whose adhesive power can therefore not be permanently
> guaranteed.
Yes you're absolutely right, the new definitoon should be Trimacro
Lisp programmer is someone who writes non trivial macro that generates
macros that generates macro. Any candidate running?
> macros, you might get some points.
Slobodan Blazeski wrote:
> Yes you're absolutely right, the new definitoon should be Trimacro
> Lisp programmer is someone who writes non trivial macro that generates
> macros that generates macro. Any candidate running?
How does one have to imagine this? A macro that generates
defmacro/macrolet code, that in turn will expand to defmacro/macrolet code?
Doesn't sound very interesting, if you ask me...
Matthias Buelow wrote:
> Slobodan Blazeski wrote:
>
>> Yes you're absolutely right, the new definitoon should be Trimacro
>> Lisp programmer is someone who writes non trivial macro that generates
>> macros that generates macro. Any candidate running?
>
> How does one have to imagine this? A macro that generates
> defmacro/macrolet code, that in turn will expand to defmacro/macrolet
> code? Doesn't sound very interesting, if you ask me...
Something like once-only?
One could imagine that there might be a version called once-only-1, used
like
(defmacro square (x)
(once-only-1 (x)
`(* ,x ,x)))
and we might want to say
(defmacro pythag (x y)
(once-only-1 (x)
(once-only-1 (y)
`(+ (* ,x ,x) (* ,y ,y)))))
and so we might write a macro once-only-n
(defmacro pythag (x y)
(once-only-n (x y)
`(+ (* ,x ,x) (* ,y ,y))))
And although it is possible that it might work as above, would it not be a
nice optimization to have once-only-n generate once-only-2, or once-only-3
macros as needed?
And if we imagine that this is perhaps not the best conceivable way of
finding the square on the hypotenuse, well, forgive a poor newbie, but I am
a little more at home in C, and it has never been my impression
that 'three-star-programmer' was a compliment.
Although I have only actually seen it done once, and that was done by a
genius, and it worked a treat and made everything much easier to understand
once you'd got over the fear.
Cheers, John.
--
Contractor in Cambridge UK -- http://www.aspden.com