IRC channel logs
2019-11-23.log
back to list of logs
<oriansj>janneke: MES_PREFIX and MES_BOOT are now working in the slow_lisp branch (along with all of the other environmental variables <oriansj>Although the need for a scheme reader probably is going to disappear as the lisp becomes more powerful (adding primitives is both simple and fun) <oriansj>xentrac: I'll earn that after I add support for macros <xentrac>but you should totally do macros too! your life will be better <oriansj>plus by adding macro expansion as a seperate stage in REPL, it makes it trivial to understand what the macros are actually generating <xentrac>well, "trivial" may be overstating the case, but certainly less difficult <xentrac>one of the debatable benefits of syntax-rules is that it's harder to write macros that misbehave in really surprising ways than with defmacro <oriansj>when you can p* R0->cdr your way to see the expanded S-expression; it is kinda hard to not know exactly what transformation has done <xentrac>yeah, being able to see the final expanded S-expression helps a lot with debugging <xentrac>so you can see what the result of the transformation was, although if the result is large that may take a long time <xentrac>and sometimes if you use gensyms or syntactic closures you can have an S-expression that looks right but isn't <oriansj>plus with the recent addition require(bool, char*); I'll be peppering it with more checks to prevent problems from occuring <xentrac>a lot of lisps also provide a macroexpand-1 for interactive use in debugging macros, which does only one stage of macro expansion <xentrac>this can be helpful when you know that the final result is wrong but not how it got that way <oriansj>well I was thinking of making a trivial pattern match expander; from oldest to newest macro definition <xentrac>you're thinking of supporting multiple independent macro definitions for the same head symbol? <xentrac>it'll be interesting to see how that comes out. there are some interesting languages that work that way, like Aardappel and Q <oriansj>honestly, I'll probably force it to work like guile; bugs and all <xentrac>you want it to be compatible with guile's macro system? <oriansj>(probably an essential subset only) and Guix <xentrac>well, so, Guile supports hygienic macros with syntax-rules and I think maybe also with syntax-case <xentrac>doing hygienic macros correctly is reputedly very difficult; I've never done it <oriansj>I wonder if it is easier to do correctly in C or Scheme <xentrac>(that isn't evidence that it's difficult, just evidence that I'm speaking for hearsay) <xentrac>but maybe there are simpler ways now' <oriansj>I guess what I need is a guile developer to write some tests for macros and yell at me when I implement that functionality wrong <oriansj>Then I could do the same with adding support for scheme modules <xentrac>That's a possibility, but I think there's every possibility that implementing Macros That Work will involve around ten thousand lines of code <oriansj>xentrac: so? M2-Planet can compile 100Kloc per second (when compiled by GCC) <xentrac>code that people have to check for potential backdoors <oriansj>I kept adding functionality and the state machine grew larger and larger <oriansj>I also starting doing match("=", global_token->s) instead of (global_token->s[0] == '=') <oriansj>now "==" isn't mistaken for assignment <oriansj>xentrac: well the good news is disabling macros in slow_lisp is a handful a commented out lines and removal of one file (mes_macro.c) <oriansj>and right now all functionality is only 2243 lines of C <oriansj>I can't imagine adding a handful primitives should be 3 times larger than a garbage compacting collecting lisp with 52 primites <xentrac>do you have call-with-current-continuation? that's one primitive <oriansj>xentrac: don't have a good test for it yet <xentrac>I mean, I don't want to discourage you from adding macros, I'm just saying that maybe the Scheme design for macros may not have the best strength-to-weight ratio among possible macro designs <oriansj>xentrac: I honestly have no great desire for supporting macros but I do have a great desire for supporting MesCC, Nyacc and Guix; which do appear to use macros <oriansj>Thus any primative they require, I'll add <oriansj>plus we still need to solve the psyntax bootstrap problem <xentrac>it might be easier to implement the particular macros those three things use than to implement hygienic macros <xentrac>what's the psyntax bootstrap problem? <oriansj>psyntax requires guile to build from source; but guile requires a processed psyntax to build <oriansj>xentrac: well we should probably get janneke's and civodul's views on that approach; there might be trade-offs such as just having define-macro might be a reasonable level of functionality <xentrac>probably it's worth trying some things first <xentrac>and possibly reading the paper I linked above, although I hesitate to suggest that that should preced prototyping <xentrac>does psyntax implement syntax-case only or also syntax-rules? <oriansj>honestly, I haven't looked at solving that yet but it looks at first glance a bit ugly <xentrac>so presumably that's the approach Guile takes <oriansj>honestly, everytime I get told something is too hard; I keep discovering it is far easier than people think <oriansj>->no one has ever written a C compiler in Assembly<- *does it in a day*; why it was so fun ^_^ <oriansj>I'm betting that macros could be done in 2 weeks and under 1000 lines if I had someone to write the tests for me <oriansj>(Because finding good scheme macro examples frankly sucks) and if I write them I might forget something important in that time frame <oriansj>but then again I love being proved wrong; it means people care enough to improve my understanding <jackhill>thanks for the great work, and for thinking out loud <theruran>how come when I run bin/mes-m2 I get this message? unbound-variable: %version\n <xentrac>what is this about "no one has ever written a C compiler in assembly"? what do people think the original C compiler was written in, RATFOR? <xentrac>there are a bunch of excellent macro examples in R5RS <xentrac>I pasted an edited version of one of them here the other day <xentrac>I'm not sure how you would write a test to verify that a macro system was hygienic. <xentrac>so I think this is another reason why nobody else is doing this stuff: they think it's harder than it is (for you) <xentrac>I think people are way too scared of assembly. But it's true that doing things in assembly is slow, and it's a pain to debug <oriansj>theruran: because the slow_lisp branch never defined that variable yet; if you do export MES_CORE=0 it should drop you directly into the repl <oriansj>xentrac: well the original C compiler was written in B and the cain C compiler was cross compiled from a Bell C compiler; so unless there is something that I am missing (which is entirely possible) <zig>what is the purpose of the slow_lisp branch? <oriansj>zig: well janneke willing, a beautiful scheme that is trivial to understand and audit but also capable of running everything required to bootstrap guix <zig>talking about trivial to undertand compiler for scheme, I find the nanopassframework approach very elegant, one might just tweak `match` macro to make it one step closer to the original framework <theruran>I was reading a paper, "A Security Kernel Based on the Lambda-Calculus", and it describes a Scheme− dialect that may be useful <theruran>ah well, it's the author's PhD dissertation. It also includes an appendix on Macros That Work. <oriansj>theruran: honestly extending slow_lisp to include pair?, symbol?, eq?, new-cell, cell-ref, cell-set!, enclose and control wouldn't take much effort at all and I have the rest already and other primitives like define and cond <oriansj>zig: well we are familiar with it, however janneke never went that direction and I just now am getting to building a major scheme (the original slow_lisp was written in assembly and died before becoming useful) So I haven't had the chance to leverage for anything useful yet <oriansj>I need someone to do a FOSDEM talk for me on stage0