Comments:<slyrus_> ok, I vote for infinite extent of the macro-environment. all in favor?<pkhuong> cltl-style environment manipulation!<slyrus_> well, it seems to work, so I'm just going to ignore this little detail of environment extent.<pkhuong> slyrus_: in my experience, it works in SBCL, not sure about other implementations.<slyrus_> yeah, that's good enough for me :)<pkhuong> just hack python's type inferer! :p<slyrus_> actually, I have thought about that<Riastradh> It would be nice to be able to define parametric structure types that would allow this kind of simultaneous optimization and reflection.<slyrus_> yes, and something like extensible arrays a la extensible sequences<pkhuong> Riastradh: seems doable w/ CLOS, but you'd need a lot of runtime compilation.<Riastradh> pkhuong, that doesn't help the compiler, though.<Riastradh> Ideally, the compiler should be able to look at slyrus_'s matrix code, and, with (DECLARE (TYPE (MATRIX DOUBLE-FLOAT) M)), generate direct double-float memory references for MREF.<pkhuong> Riastradh: well the body of the parameterised function might be able to exploit it.<Krystof> (dunno if this has been said, but) you can emulate compiler-let with explicit macroexpands and (symbol-)macrolets<slyrus_> Riastradh: yes, that was what I was thinking<Riastradh> Krystof, yes, slyrus_ already pasted code that does so, but the problem is that it inserts a literal reference to the environment descriptor in the macro's output, which violates the dynamic extent of environment descriptors.

<rahul> Krystof: I was trying to come up with code that does that, yes<rahul> but I've been distracted by other concerns :)<Krystof> ah. That is indeed wrong<slyrus_> Krystof: is there a right way to do that or is this just a fundamentally bad idea?<rahul> about 1/2 hour ago I was typing some rough code into the channel that does this kind of thing<slyrus_> rahul: the symbol-macrolet stuff?<rahul> yes<Krystof> slyrus_: you're meant to take the decisions based on the environment at macroexpand time<cmm> while Krystof wasn't looking, #lisp has came up with portable implementations of COMPILER-LET and SPECIAL-P, and got almost to the point of solving the halting problem.<rahul> you symbol-macrolet some symbol to an alist that includes previous definitions<Riastradh> Krystof, he does -- it's in a macro that the macro *generates* that the environment is used.<rahul> then you ASSOC into that alist to find the actual expansion<Riastradh> Krystof, the paste is here, by the way: <http://paste.lisp.org/display/34363><Riastradh> (I think slyrus probably also fixed the bug with passing the wrong form to MACROEXPAND by using &WHOLE now, but that's an unrelated issue.)<slyrus_> look at the annotation #1, not the original paste<pkhuong> cmm: almost-compiler-let isn't that bad if you allow 1. having to wrap code that uses it in with-compiler-let; and 2. dynamic scoping :\<rahul> mmm global compiler lock<Riastradh> ...ah, I see.<rahul> actually, wouldn't need to be global. just a mutex on that with-compiler-let<rahul> then again, most decent implementation of dynamic scoping will have different bindings visible only in the originating thread<pkhuong> rahul: it's the implementation's problem if threads and dynamic scoping don't work right.<rahul> pkhuong: yes<rahul> cmm: NO!<pkhuong> slyrus_: now you made me want to try to implement type propagation with (only) macros, no codewalker.<rahul> pkhuong: haha<cmm> *nice* hack, though<rahul> I think it's a beautiful abstraction<slyrus_> thanks cmm, rahul<cmm> slyrus_: I suspect rahul's general idea (use a macroletted alist) is workable, btw<rahul> I just can't afford to thrash my mind with that and work at the same time :)<rahul> you have been preempted :P<slyrus_> ok, rahul, if you're still relatively un-preemepted, I don't get what goes in the ,(lambda ...)<rahul> heh<rahul> slyrus_: the function that would get applied to expand the macro<slyrus_> well, yes, but I'm not sure what that looks like :)<rahul> heh<pkhuong> slyrus_: it's also missing a macroexpand around the third argument to acons<rahul> like the macros you defined<rahul> yeah, what pkhuong said<pkhuong> (w/ the environment containing the old binding for the alist)<Modius> I've written a defun that converts functions into continuation style. The functions return normally if called from a "normal" toplevel, or send the result into a continuation if one is enclosing it.<Modius> I've done let, let*, labels (yes, recursion works) - no tagbody<Modius> Obviously, a call/cc from within a mapcar's (unmodded mapcar) lamda wouldn't get the right continuation.<rahul> doesn't python already do a CPS conversion?<rahul> what do you need to do? you're gonna end up writing your own compiler :P<pkhuong> rahul: it's a weird almost-anf, iiuc. And so what?<Modius> Well, I wanted one in common lisp<Riastradh> The use of CPS as an intermediate format doesn't imply trivial support for reification of continuations in programs.<rahul> that's why I asked what he needs to do<Modius> No; but it'd be a fun tool for playing with continuations<rahul> and now how he's going to implement unwind-protect :)<Modius> I would imagine unwind-protect is impossible, and the thing would choke upon being preseneted with it.<Modius> You guys already beat into me before that call/cc or yield are useless inside of io operations.<rahul> heh<rahul> I thought I was the only one who thought that<pkhuong> no, unwind-protect is possible. Much harder if you use CPS, though.<Modius> Hmm - I'll go off and think about it - and whether or not I've already designed in such a way as to prohibit unwind-protect :)<Modius> I was thinking about the IO type operations.<Modius> I'm kind of new to lisp, haven't thought about that much<slyrus_> rahul: but I still want to be able to call the function mref at the end of this if I don't find an mref-expander

<Modius> I learned a TON doing this - obviously I may have implemented a feature that is of marginal use; but got to see how things just "click" for writing a code generator/reader for lisp<rahul> slyrus_: ok, if assoc returns NIL, leave it as MREF<rahul> slyrus_: make it a compiler-macro, actually<rahul> that will allow this behavior :)<Modius> The code is 300-ish lines - doing some equivalent in other languages would be nigh impossible.<slyrus_> mref is a compiler macro already<slyrus_> but I don't want to keep re-expanding that.<eh> I want to build a threaded and non-threaded sbcl on the same machine, preferrably from the same checkout. Does SBCL support out-of-tree builds?<lisppaste> slyrus annotated #34363 with "no, this isn't right..." at http://paste.lisp.org/display/34363#2<slyrus_> eh: not as far as I know<pkhuong> slyrus_: unquote the acons<eh> ok. too bad. thanks though.<lisppaste> cmm annotated #34363 with "seems to work for me" at http://paste.lisp.org/display/34363#3<slyrus_> thanks cmm. trying that now.<cmm> slyrus_: it has no error checking (so (MREF <something bogus> ...) will bomb cryptically during macroexpansion), but that would not be hard to add :)<pkhuong> cmm: seems to me having mref/row-major-mref would make for better errors (once you have error checking) than defining them inside with-typed-mref too.<cmm> pkhuong: yeah. would also make the w-t-m macro definition tidier.<cmm> oh well, bedtime.<pkhuong> (insert `toplevel' somewhere in the last line, btw)<cmm> pkhuong: haven't even noticed the word's absence. I need to get a life!<slyrus_> thanks cmm<slyrus_> huh. looks like emacs indentation for ,(m-v-b is wrong<cmm> emacs's indentation tends to break if you don't insert a space after a comma<slyrus_> and yes, that seems to work here too. thanks again.<nyef> Hello all.<slyrus_> ney nyef<quotemstr> What do you call &symbols, as distinct from :keyword symbols?<nyef> quotemstr: LAMBDA-LIST-KEYWORDS.<slyrus_> nyef: check logs if you're interested in a working with-typed-mref that we were talking about the other day<quotemstr> Thanks.<nyef> slyrus_: I noticed. Very cool.<slyrus_> heh. it would be cooler if it didn't need to be so complex :)<quotemstr> Can you think a situation where lambda-list-keywords are used outside a lambda list?<nyef> quotemstr: Yes. They could be used for constructing a new lambda list or parsing one, for starters.<antifuchs> they can be useful if you define your own lambda-list like things<quotemstr> So it'd be worthwhile to fontify them wherever they appear.<slyrus_> lichtblau: that collect-key-table form never seems to return<slyrus_> that defconstant gensym line isn't happy though<pkhuong> slyrus_: just use an unexported symbol?<pkhuong> (and you can then do (define-symbol-macro .mref-expanders. nil) )<slyrus_> pkhuong: you lost me again. :(<pkhuong> Just keep using .mref-expanders. instead of gensymming a symbol.<pkhuong> Keep mref and row-major-mref as (toplevel) macros and then w-t-m doesn't have to check whether .mref-expanders. is symbol-macrolet-bound (it always is)<attila_lendvai> cmm: how is slime broken? it works here with a fresh emacs build<kmr> good evening. I see the SBCL invokes the debugger if a signal is handle. But, does anyone know how to catach a signal HUP in a SBCL program?<slyrus_> pkhuong: you mean I wouldn't need the check for if expanded-p?<slyrus_> hey kmr<pkhuong> slyrus_: yup. Just define a sane default value (nil, since it's an alist)<Xach> kmr: SB-SYS:ENABLE-INTERRUPT<kmr> reference for unhandled signals (http://www.sbcl.org/manual/Debugger-Invokation.html)<kmr> xach: thanks, I review enable-interrupt!<Xach> kmr: your english is a little wacky today :)<kmr> xach: ues, you are correct! ;-)<kmr> xach: too much playing attention the the little ones. I suspect your small one is now toddling and causing additional watchfulness.<lisppaste> slyrus annotated #34363 with "pkhuong, what am I doing wrong?" at http://paste.lisp.org/display/34363#4<rahul> (symbol-macrolet ((.mref-expanders. ,(acons z vals (macroexpand .mref-expanders. env)))<rahul> macroexpand-1<rahul> clhs ~{<specbot> http://www.lispworks.com/reference/HyperSpec/Body/22_cgd.htm<slyrus_> thanks rahul. working agin.<slyrus_> again even.<slyrus_> (m-1 '.mref-expanders. ...<rahul> yeah :P<pkhuong> *that* would be hard to debug.<slyrus_> pkhuong: what's the *that*?<pkhuong> macroexpand instead of macroexpand-1<slyrus_> ah, ok.<rahul> heh yeah<slyrus_> who knew macros could be so much fun?<timor> me<timor> :-D<pkhuong> slyrus_: that part of CL macros (communication between macros) feels like C++'s templates.<lisppaste> slyrus annotated #34363 with "the (next) final product" at http://paste.lisp.org/display/34363#5<slyrus_> this will all be in clem 0.4 when I roll up a release.