I said:
> Actually, that IS what I'm doing. By doing the transformation at read-time, I
> do the transformation BEFORE any macros run.
Egil Möller replied:
> Hm, wouldn't the obvious answer to this problem be to implement a layer of
> macro expansion between the reader and the current macro-expa
Title: FreeCode Signature
since I ALWAYS
expect postorder evaluation, why should I expect preorder macro expansion?
Not that you're in a position to change anything. :)
Actually, that IS what I'm doing. By doing the transformation at read-time, I
do the transformation BEFOR
Neil Toronto :
> This is what I was on about before. It seems to me that things would be
> safer, if upon
> (foomacro (nfx 1 + 1) ...)
> nfx was expanded first, and then foomacro. Then foomacro wouldn't have
> to care what nfx does, because foomacro always receives expanded
> s-exprs. It fi
David A. Wheeler wrote:
> I said:
>>> Actually, complex macros work just fine, as long as you stick to the
>>> Lisp convention that "operator is always named first in a list". As long
>>> as you do that,
>>> complex macros that reach deeply into their parameters will still work.
>>> But this is
I said:
> > Actually, complex macros work just fine, as long as you stick to the
> > Lisp convention that "operator is always named first in a list". As long
> > as you do that,
> > complex macros that reach deeply into their parameters will still work.
> > But this is
> > why infix operators h
On Feb 4, 2008 11:43 PM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> Alan Manuel Gloria:
> > However, having a rule about whether it ends up hooking into a macro
> > will then mean having an additional rule that has to be remembered by
> > the user of the new reader, as well as possibly the user
On Feb 5, 2008 12:04 PM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> > A little off-topic, seeking to understand Lisp macros a little better:
> > do complex macros tend to not compose well because they're expanded
> > preorder rather than evaluation order (postorder)?
>
> Actually, complex macros
> > What is "repl."?
>
> Read-Eval-Print Loop?
You're absolutely right. I've always seen that capitalized (REPL) and
didn't recognize it in lowercase. Perhaps too much Unix :-).
(There's a big brouhaha in Scheme because revision 6 switches
from case-insensitive to case-sensitive. I'm used to c
David A. Wheeler wrote:
> Alan Manuel Gloria:
>> As an aside, at the office we are using a Lisplike with an infix
>> notation, however I tend to avoid the infix notation except at repl.
>
> What is "repl."?
Read-Eval-Print Loop?
Ha ha! I'm not a Lisper and I got that one! Props to meee!
(Sorry
Alan Manuel Gloria:
> However, having a rule about whether it ends up hooking into a macro
> will then mean having an additional rule that has to be remembered by
> the user of the new reader, as well as possibly the user of any macro
> that has to do scanning of that type. So I propose that eithe
On Feb 4, 2008 11:52 AM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> (Note: Please make sure you reply to the GROUP, not just the From:
> address!).
Dang. I keep forgetting.
>
> I noted earlier:
> > > The problem with infix macros is that any OTHER macro that is invoked
> > > BEFORE
> > >
(Note: Please make sure you reply to the GROUP, not just the From:
address!).
I noted earlier:
> > The problem with infix macros is that any OTHER macro that is invoked BEFORE
> > the infix macro will necessarily see the WRONG operators. So, for example,
> > a
> > macro that looks for (* ..
Neil Toronto:
> Wouldn't that depend on what the reader spit out? What if
> b[1:5]
> becomes
> (bracketaccess b (slice 1 5))
>
> and
> d[0:3,x,5:7,9:]
> becomes
> (bracketaccess d '((slice 0 3) x (slice 5 7) (slice 9)))
Obviously the reader _could_ do that, or anything else.
B
David A. Wheeler wrote:
> Egil Möller:
>> It would also be interresting to implement the Pythonic list features,
>> e.g. slices and slice assignment. Extra points for implementing both a
>> destructive and a non-destructive version. E.g.
>
> That was the idea of "bracketaccess", but that means tha
Egil Möller:
> I am a little bit wary about the number of different types of braces and
> parens in
> modern expressions, and how their usage compares to other languages.
> In Python, () are used for function calls and tuples (read-only lists),
> [] are used for lists and {} are used for mapping
15 matches
Mail list logo
