<oriansj>xentrac: valid; however the C language family has more matching behaviors across implementations. For example given (define (foo a b) (if a b)) when given (foo #f (exit 42)) why do many schemes exit? <oriansj>The correct behavior should be expand (foo #f (exit 42)) into (if #f (exit 42)); which when passed to most schemes doesn't result with an exit at all... <oriansj>perhaps the correct recommendation is to use any mature language which can be bootstrapped from GCC or has a bootstrap chain that exists back to a languge that GCC can bootstrap. <xentrac>because Scheme is in general an eager language, not a lazy language <xentrac>I mean I've never seen an implicitly lazy Scheme and I'm not sure it would comply with any of the RnRS <xentrac>you're saying that the correct behavior is to be implicitly lazy, and that's a plausible point of view, but making an implicitly lazy language usable requires restricting side effects somehow, which Scheme doesn't <xentrac>Miranda and Haskell are of course the best-known implicitly lazy ("purely applicative") languages. Bicicleta is also purely applicative, but so far it does a great job of illustrating Perlis's epigram, "Purely applicative languages are poorly applicable." <xentrac>C also is eager; foo(0, exit(42)) will exit in any implementation of C if foo is an ordinary function rather than a preprocessor macro or a compile error or something <xentrac>(in Scheme a "function" is called a "procedure", which is what the `define` form above creates) <oriansj>in fact foo(0, exit(42)); will be straight "invalid use of void expression" <oriansj>but you are correct in that C is an eager language (most are because it is easy to do) <oriansj>although a common optimization for C compilers actually moves the work inside of the called function; resulting in lazy behavior inside of an eager language. <xentrac>oh, that's a good point; C didn't use to have void <xentrac>most compilers will still let you get away with it if you don't #include anything that declares exit's return type. in general in C it's valid to call undeclared functions but I think their return type needs to be int for it to be actually valid C <xentrac>it happens that modern GCC and clang don't let you get away with it, but you won't have to go back very far in their history to get them to accept it <gio>You can hae that with modern compilers, you just have to ask them to interpret an old C standard, like C89. <gio>That's not very important, though. If your problem is matching types, it is enough to wrap the exit() call in another function returning int. <janneke>oriansj: just reading about your father, my condolences <janneke>oriansj: macro substitution should be a separate phase; in my first prototypes i tried to do it like that and in scheme, not in c <janneke>oriansj: i think rain1 once suggested a very similar thing, to run a scheme function after the reader to do macro expansion and possibly other optimizations <janneke>oriansj: that would really clean things up, another thing that i have been postponing <janneke>oriansj: on the good news front: i just ran a slightly modified ice/boot-9.scm: modules with hierarchical name spaces and am now looking into integrating that <janneke>oriansj: i have also split-up x86/kaem.run in my mescc-tools-seed @ gitlab <janneke>xentrac: i have a working gzip, pulled from industria/weinholt in gash and translated from r6rs into plain guile <janneke>it makes heavy use of syntax-case, that's ok for but probably won't run on mes atm ***ng0_ is now known as ng0
<vagrantc>which means, we wait an indefinite amount of time and hope someone processes it :) <janneke>oh, it still says GuixSD in its description...and so does the GNU Mes homepage...oh well <vagrantc>the description could use a little elaborating ... hopefully it doesn't get rejected over that <vagrantc>so once that's in debian is it feasible to try to reproducibly cross-disto builds of tcc or something? :) <vagrantc>maybe i need to start working on mescc-tools-seed or something too <vagrantc>W: mes: manpage-has-useless-whatis-entry usr/share/man/man1/mes.1.gz <vagrantc>W: mes: manpage-has-useless-whatis-entry usr/share/man/man1/mescc.1.gz <janneke>vagrantc: ah, yes that title is a bit silly <civodul>lintian is stricter than guix lint :-) <vagrantc>civodul: guix also has a bunch of identical and similar manpage issues lintian complains about :) <janneke>i don't have a plan/date for 0.21 yet <vagrantc>janneke: i grabbed two of the patches from mes/wip-0.20 ... if they could end up somewhere more permanent that woudl be nice :) <janneke>vagrantc: or actually, i don't have decided on a target/theme for 0.21; i have been working on several things in parallel and none of them are finished <vagrantc>janneke: not sure if it's worth adding a configure flag for that or something else <janneke>vagrantc: ah, yes; well the configure --includedir is a fix that will certainly be in 0.21, the x86_64 XFAIL is trickier -- as i said i cannot reprocuce the failure; i would like to get some grip on it <vagrantc>not sure if anything leaps out as something you could fix or enable workarounds for upstream <janneke>vagrantc: yes, thanks -- i have seen that and was wondering if i am doing something irregular that should be fixed but had no time today <vagrantc>no urgency, this will likely sit at least a few weeks or months before i do anything different <vagrantc>just figured i'd mention the packaging workarounds and hacks to make it a proper debian package <janneke>yes, i will try to minimize the diff you need for debian, as that will probably help not only you/debian but others as well <vagrantc>yeah, all those other distros with more FHS like structure, probably :) <vagrantc>anyways, it was pretty nice to finally have something to upload ... i forget when i started on this, but it was a while ago <vagrantc>i guess july 2018, if the RFP bug report is to be believed <janneke>i have a `wip-auto' branch with autotools setup that is bitrotting and i have been pondering on resurrecting that; mes also needs a bootstrap build...i don't want to duplicate too much but mimicking autotools is also a bit silly and error prone <janneke>vagrantc: do you know if a debian package can be built without the `build-essential' dependency? build-essential includes gcc, which is not really what we want when attempting an alternative bootstrap <vagrantc>though i wonder if you have build-conflicts if it would remove them *vagrantc has long thought the build-essential set on debian should be much smaller <janneke>yes, i would really want to be sure that gcc was not used, when creating a gcc-less bootstrap :-) <janneke>(implicit statements can also be annoying ;) <Hagfish>can you tell debuild to run in a custom chroot that doesn't have access to gcc?