IRC channel logs
2019-12-07.log
back to list of logs
<oriansj>(lambda (a b) (foo a b)) ?= (macro (a b) (foo a b)) <janneke>oriansj: you're right...but my mes.c that build with m2-planet has not been released yet <oriansj>janneke: well our joint work, I am pushing as I figure things out <janneke>oh yeah, "my mes" of course, really your mes-m2 work merged! <oriansj>janneke: none of this is really mine, I think of this as our work <oriansj>still need to figure out good tests for define-macro that expose the macro expand but work in guile too <oriansj>as in theory (define-macro (foo a b) (+ a b)), should simply transform (foo 1 3) into (+ 1 3) to be evaluated by eval but how to capture that cleanly <oriansj>as guile's macroexpand does the wrong thing (unless I am missing something so trivially obvious) <oriansj>So, I stole from define's handbook to implment define-macro; now to get the behavior of macros correct <oriansj>(with the fun side effect (define foo (macro (a b) (+ a b))) does the same thing) <oriansj>odd that guile fails so hard when given: (display (define-macro (foo a b) (+ a b))) <oriansj>and an patch is up for initial framework for support for define-macro <oriansj>now to figure out the application of transformation <oriansj>although adding this macro bit probably is going to make this lisp even slower <oriansj>it is kinda amazing the sheer number of schemes that don't support macros <oriansj>it is almost as if everyone hits it and does one of two things: nope or fuck it we'll do it live <oriansj>figuring out define-macro is kicking my ass <oriansj>I keep feeling like I need to create a weird mirror of mes_eval.c in mes_macro.c to get it working right <oriansj>(although I'd be happy to accept better tests if anyone has any handy) <oriansj>rain1: how are the macros in your single_cream behaving? <rain1>they seem to work well but they are a basic unhygenic defmacro type thing <rain1>the way i did it without having 2 evals was that everything is evaluated tice <rain1>the preprocess procedure is initially a no-op but gets redefined as a macro expander <oriansj>rain1: I honestly could use your perspective on mes-m2's slow_lisp branch <oriansj>as I am trying to figure out the most flexible solution to providing macro functionality, while still preserving as much introspectability as possible (via gdb) <rain1>i'll have a look at it, it sounds tricky to help GDB though <oriansj>rain1: I thought the same thing about doing that with the reader and the tokenizer but one can break mes.c:61 to look at the S-expression in text form before it gets tokenized <oriansj>even if I force it go through a big ugly meh of a file; a break mes.c:66 should be the correct way of doing it if I can figure out the correct way to deal with macro expansion <rain1>looking at mes_macro.c I feel like it's going to be really difficult to write even a simple macro expander because you're still having ot work at that low level ->car->cdr type stuff in C <rain1>that's why i used the double eval trick, so i could write the expander in scheme <oriansj>rain1: that I could do rather straight forward in C <oriansj>although I'd have to figure out the box, unbox bit <xentrac>macros are required by at least r5rs, I think r4rs too (and certainly r6rs and r7rs) <oriansj>now just to figure out the correct way to shoe-horn macros into slow_lisp in a well defined spot <oriansj>and it is in the public domain, so that's nice <oriansj>well this is officially the ugliest single s-expression I have seen yet <oriansj>it is really janky right now but it actually can do the previously posted tests <oriansj>janneke_: I really need your comments on this one <oriansj>The best part, it allows the addition of syntax-rules in an incremental fashion