<OriansJ>janneke: I was thinking of moving the check for number of arguments to the actual functions themselves and with it reduce the types of function pointers to a single version which accepts a single argument. <OriansJ>I have demo'd the sort of change in vector_set_x <OriansJ>I've also noticed some places where you made a cell to point to a value, only to just jump through a hoop to get that value; I've removed a couple of those cases and with it made mes-m2 even more memory efficient <OriansJ>Hagfish: correction, the strnlen turns out to be a bug of my own making >.< <janneke>OriansJ: oh, that's a bigger change that i thought, i'll have a look tonight! ***Server sets mode: +cnt
***ChanServ sets mode: +o rekado_
<janneke>OriansJ: ah, yes vector_set_x i looked at all kinds of other stuff and got lost this morning :) <janneke>OriansJ: i have been wondering about this, esp after reading your slow lisp <janneke>OriansJ: it could make things cleaner/easier, there is only one puzzle that i have <janneke>OriansJ: what if a scheme program calls a primitive function with the wrong number of arguments, can we still catch that? it is OK for correct programs, but catching an error early can be very helpful <janneke>maybe we can keep the `parity' information, and only (optionally?) check that in check_formals? would that still make things faster/easier? <OriansJ>janneke: well determining the wrong number of arguments by being put into the primitive function themselves would allow make-vector be able to support both the (make-vector 4) and (make-vector 4 (cons 1 2)) cases <OriansJ>and for those that don't need to check, skip the check_formals entirely (aka + and - don't need to care) <janneke>i was just wondering if we would lose something valuable, error reporting is nice <OriansJ>we don't have to give up the error reporting <OriansJ>I could add error reporting to Slow_lisp to show you what it could look like if that would make it easier to see? <janneke>OriansJ: ah that's not necessary, i'm not even opposing your proposal, just asking <OriansJ>Honestly, I want mes-m2 to be as fun and easy to use as possible <janneke>yes, that's amply clear -- you are doing amazing work <OriansJ>I still haven't figured out a good guile compatible test for make-struct yet <OriansJ>as I want all of the mes-m2 primitives to behave exactly like guile's; to make porting of guix to mes-m2 as simple as possible <OriansJ>plus I still need to get back to slow-utils and finish off the pieces limiting us from eliminating all binaries save for guile <OriansJ>plus I still need to do an analysis of mes-m2 to ensure proper lexical binding in all scopes <OriansJ>I don't know about you janneke but some days I feel like the more I achieve, the more that just seems to keep piling up <janneke>OriansJ: yes...i have started to look into mes-m2 yesterday and again today <janneke>it's been a long time that i actually looked at mes core, i've been bootstrapping and doing mescc mainly for quite some time <janneke>seeing all the work you have done is inspiring and scary <janneke>just now i was wondering whether i would be able to revert the order of some of your latest patches <janneke>first finishing the struct-based work and having the 'major change in behaviour' float on top of that <OriansJ>well I was expecting for mes-m2 to be in a broken state for a little bit <janneke>it would be nice to have mes-m2 folded back into mes, and compile it with M2 and run the bootstrap (me dreaming) <janneke>yeah...seeing what work you are taking on is really great, but it could take a year to stabilize, i dunno <OriansJ>well once all of the primitives have tests <janneke>otoh, the big restructuring is inspiring, mes toplevel is crap <OriansJ>I can hammer out most of the details over a weekend <OriansJ>comparing the mes-m2 behavior exactly gainst guile <janneke>mes toplevel is tied together somewhat with the primitives, and also with macro-expansion <janneke>it would be nice if we could move macro expansion completely out of the C core <OriansJ>well, when I am done; you should be able to use the exact same code for guile and mes-m2 <OriansJ>and when I understand the macro expansion better; I'll figure out the correct solution <OriansJ>if macro expansion in the C core is essential, so be it <janneke>what guile does, is basically load psyntax; that creates most of `guile' on top of the primitives <janneke>guile has some variable and module handling in its C core for that <janneke>psyntax defines syntax-case, which defines syntax-rules and define-macro etc. <OriansJ>at the same time we can solve the psyntax problem by supporting enough guile in C code. <OriansJ>So, I am more than willing to throw hours at the problem but it would be must easier for me if someone more familiar with guile's behavior quirks helped with the writing of tests <OriansJ>If I end up needing to fork guile 1.0 or do something crazy to solve the problem so be it <janneke>i looked at that, the first guile releases :-) <janneke>it's very possible we would end up stealing some code from guile and still stay m2/mes and minimal <OriansJ>well it would be importing since mes-m2 is GPLv3 and I believe the FSF have licensed guile as GPLv3 <OriansJ>The work I can do (provided I know what the correct behavior is) <OriansJ>This is the last major piece of the bootstrap anyways <OriansJ>so it is only fitting that it is the one which takes the most effort <janneke>previously, i have given up on psyntax as a feasible route aften spending much time (a couple of months) <janneke>and psyntax has its own bootstrap problem -- however that might be OK and we might have someone else try to solve that for us later <janneke>ah right, you mentioned bootstrapping psyntax <OriansJ>by simply running the scheme code used to generate psyntax <janneke>yes, sure, but thats ~30,000 lines of opaque scheme -- not really "source" <OriansJ>which means when we add enough guile functionality to mes-m2, we can directly run the source used to generate psyntax <janneke>it will work and run, and we can re-create it, but we still load this huge expanded psyntax code to bootstrap <janneke>when i have up on psyntax i was hoping to find a nicer solution, or do without syntax-case <OriansJ>now it would be easier if we had someone willing to simplify that scheme code to be more scheme neutral so we wouldn't need to add support for syntax-case <janneke>however, i'm willing to give it another go and reach 100% guile compatibility <janneke>also we don't have to solve everything at once, by ourselves <OriansJ>plus we can revert to the KFFD algorithm for macro expansion as it is simpler (but slower) <OriansJ>but as always we have lots of room to work with in mes-m2 and the immediate goals should be our top focus <OriansJ>1) Solid tests for every primitive exposed <OriansJ>Then we can push towards 100% guix compatibility and finally then work to solve 100% compatibility <OriansJ>as mes-m2 is going to freeze after we get MesCC and guix running on it <OriansJ>(Or simply tag a release for bootstrapping) <OriansJ>that way when we push for 100% guile compatibility we can assume GCC (or MesCC) <janneke>i was skimming through guile-2.0 and guile-2.2's psyntax <janneke>guile-2.0 needs letrec, guile-2.2 needs letrec*; both need structs, module and variable primitives <janneke>yes, that's what i'm thinking now too <janneke>after ~400 lines of boot-9.scm, guile just loads psyntax -- so all the primitives we need for 100% compatibility are in that bit of code <janneke>we don't need 100% guile feature coverage, of course -- just 100% compatibility <janneke>we need `define' and letrec* in mes_eval, and some module/variable stuff, but we should be able to drop define-macro expansion from the eval_apply beast <janneke>i'm not sure about fluids and exceptions, how much we need initially <OriansJ>why don't we cross that bridge when we get there? <janneke>i worry a bit about how to get it going, extending it should be "just work" <janneke>yeah, just reading early boot-9.scm that uses those ... <janneke>thinking: hmm, i hope we can skip this initially <OriansJ>well we do know some guile developers... <OriansJ>and once we embed enough understanding about the various pieces, the the get going becomes alot simpler <OriansJ>heck, I'll even make their task easier; if they just give me good examples and tests, I'll do all the work making it happen in C <janneke>so yeah, i see what you mean by the more i do, the more work piles up <OriansJ>I can even get 3 months of full time dedicated programming effort allocated from my workplace if we can get another party to match that investment <OriansJ>and imagine what can be achieved in 3 months with me and another full time programmer working on this