IRC channel logs
2019-10-16.log
back to list of logs
<OriansJ>janneke: what is the purpose of vector-entry as it isn't used nor is it supported by guile <janneke>OriansJ: it creates a REFerence to a vector cell for non-atomic types <janneke>OriansJ: i see it being used in mes_gc and mes_vector ... ah, or do you mean why it is exposed as a builtin? i simply expose all builtins, so that we can always decide to move/override core functionality from scheme <janneke>and yes indeed, it's a mes internal, it should really be named `vector_entry_' and thus core:vector-entry <OriansJ>since grep -R 'vector-entry' doesn't show it used at all in the version of MesCC we imported into mes-m2 <OriansJ>but grep -R 'vector_entry' shows it being used internally <OriansJ>as I am trying to make a set of vector tests to match behavior between mes-m2 and guile <OriansJ>(although I still need to figure out how to ensure that mes-m2's make-vector supports both (make-vector 4) and (make-vector 4 1) ) <OriansJ>also commit 314917c343232bae70a86cb07b936ddc30cea834 for mes-m2 is up <janneke>OriansJ: i would prefer/choose to rename it to vector_entry_, core:vector-entry; but removing its exposure is okay too; i am really only interested in its effect, not the underlying implementation <janneke>and we can always bring things back, of course -- that's also a matter of taste <OriansJ>janneke: well, I am planning on making tests for all exposed functionality and I am aiming at making sure the behavior exactly matches guile <OriansJ>So if something isn't in guile and I don't have a specific reason for the difference; I would prefer to pull it out <janneke>OriansJ: sure, but all core:xxx functions have no real match in guile, they somehow provide an incompatible subset <janneke>OK -- my previous remark was replying your earlier message <OriansJ>janneke: completely fair and for those specific cases, I'd prefer to document the why and make it obvious to anyone else in the future why it exists and how it should be used. <janneke>okay, just so you understand my rationale, then it's much easier to see which viewpoint is better :-) <OriansJ>aka if we plan on using core:foo because we need the exposed functionality to do X; we should make it absolutely clear <janneke>also, with some (all?) core: functions, where i am coming from is a very minimal subset; core:display for example used to be really, really minimal <janneke>"only recently" you gave us the perspective that mes would not need to be translated/rewritten in some sort of assembly; M2 is almost as good as C <OriansJ>janneke: actually it is C with only a handful of minor differences <janneke>meanwhile, core:display also grew, and it could make sense for the (mes display) module to be removed in favour of a full implementation in C/M2 <OriansJ>janneke: indeed; freedom to do things the way that makes how everything works most clear <OriansJ>and as we go along, I plan on making the code more beautiful and well commented. <OriansJ>as the code slowly becomes more clean, it will also be easier to build/debug with M2 <OriansJ>we can also supercharge the reader to make it's internals more inspectable <OriansJ>it'll be a heavily iterative process but I figure, you spent 2+ years making mes.c; it would be foolish to believe I can magically overnight change how it worked inside and out <OriansJ>it wasn't until recently that I managed to change from array to objects and alter the behavior of strings <janneke>hah, making something simple and clean is often much more work... <OriansJ>also I am unwinding the tight coupling inside of mes-m2; mostly to reduce the cognative load for understanding what is being done at every step <OriansJ>also by reducing branching and heavy nesting it will also run faster