Java linux HTML qmail C++ PHP Debian MySQL ASP JavaScript perl Delphi NetBSD Solaris etc etc etc [...]






Page: 1 2 3 4 5 6 7 8 9


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.


Name:

Comments:

Please enter the result of the sum 63 + 46 (to avoid spam):






Return to #lisp
or
Go to some related logs:

ip_relay syntax
kanarip
bash
suse
volari v3 on ubuntu
enable open_GL
mysql
ioctl: LOOP_SET_FD: Device or resource busy
automatrix mephis
libssl.so destest error while loading shared libraries