***nckx is now known as jorts
<rlb>seems like we should <rlb>support #:prefix and #:select in the same form. <rlb>Or rather, might be nice. <rlb> #:use-module ((foo bar) #:prefix bar/ #:select (x y)) <rlb>I *think* right now it just ignores the #:select. <rlb>Oh, unless the prefix applies to the selected names too. Hmm. <rlb>(Not that it should necessarily influence guile, but used to that habit from clojure, i.e. there it's (:require [foo.bar :as bar :refer [x y]]) ***jorts is now known as nckx
***Aurora_iz_kosmos is now known as Aurora_v_kosmose
***zooey_ is now known as zooey
<ArneBab>“If you like what I do, why don’t you help me?” <lampilelo>Ugh, no parens? It feels kinda inferior from the editing point of view: you can't just transpose sexps (etc.) and move efficiently through the code, or can you? I wonder what's the rationale behind it <leoprikler>It's for people, who are afraid of parens, so yeah. <leoprikler>that said, in wisp sexps correspond to 1+ lines, so it works fine just by transposing regions <leoprikler>(that is unless you use fancy stuff like parens or the colon) <lampilelo>i guess different strokes for different folks <lampilelo>should the package maintainer be expected to have guile-snarf or should I distribute generated files? <leoprikler>imo guile-snarf should be present at build time, same with guild <rlb>Do we have any provisions for (or examples of) testing internal C functions? e.g. say I wanted to write independent tests for some normally static strings.c functions. <rlb>(I suppose to really do that without including the code in a final install, we'd have to compile it twice one way or another...) <rlb>Alternative I suppose might be to just accede to publishing them as scm_i_... functions and test those, but in this case, they really are internal functions, e.g. to sparsely reindex a utf-8 string, etc. Be nice to be able to test the corner cases there more directly. <leoprikler>well, that goes against most testing wisdoms, but you can try looking those symbols up with ffi <leoprikler>otherwise you'll have to find a way to test in C <rlb>Oh, I'm fine testing in C (in fact that's what (for this purpose) would be easier), just didn't know if we already had some way. <rlb>(And one reason this crossed my mind is that it may be difficult to even get guile to come up far enough to test strings.c from the scheme level, until it's mostly correct.) <rlb>(Since "everything" depends on it.) <rlb>(strings and symbols) <rlb>leoprikler: ahh, thanks, I'd forgotten about that. I'll take a look. <rlb>leoprikler: yeah, that might work. Thanks again. <rlb>And regarding standalone - not sure we'd want it, but I used the automake TAP driver for lokke, and that's worked out reasonably well, i.e. so a standalone test can, if it likes, report finer grain test information, and track multiple failures in one run (instead of only watching the exit status). <rlb>Which functions do we require to have correct scm_remember calls in libguile? I assume that SCM_DEFINEd functions to, and any public scm_* or scm_c_* functions, but there are no expectations wrt scm_i_* functions? i.e. if you call those, you need to make sure to remember() defensively because they're allowed to do whatever they like? Or rather, you need to make sure to hold on to any arguments *for them* because they might not? <rlb>"SCM_DEFINEd functions do" <rlb>Meaning scm_foo (scm_i_bar (x)) wouldn't be correct by itself -- you'd need to break that up so you can scm_remember_upto_here_1 (x)? <leoprikler>rlb: you use remember whenever you run in danger of using memory associated with a SCM, that might otherwise be GC'd <leoprikler>e.g. if scm_i_bar does not return anything related to x, you don't need to remember it, but if it converts it to a void* or similar, you should probably remember it <rlb>leoprikler: thanks, and right - so the "remember" responsibility is in the caller, and the call has to know whether or not the bits returned by the scm_i_ call are related to any given argument. <rlb>"caller has to know" <rlb>(wondering if I may have seen some missing calls in libguile, then -- will try to check later) <leoprikler>rlb: garbage collection also has to be a real hazard, which I suppose is often not the case in guile stdlib <leoprikler>e.g. you get a string, but you don't care if it's GC'd <rlb>leoprikler: a more specific case I was thinking of is a scm_i_foo (x) that returns a new SCM derived from x (though in the end, fully independent). During the derivation, scm_i_foo uses internal bits of x in a way that *would* require a remember half-way through the work if it were a "public" function. So is scm_i_foo expected to include that remember, or allowed to assume that the caller must protect x since the caller can't know <rlb>what scm_i_foo might do with it? <rlb>i.e. do I always need to protect x in the caller (before the return) for a call like "return scm_i_foo(x)" to be sure x can't be lost half-way through scm_i_foo. <rlb>e.g. "SCM result = scm_i_foo (x); scm_remember_upto_here_1 (x); return result;" <leoprikler>I don't think you should write scm_i_foos in a way, that they require additional remembers <rlb>Or is scm_i_foo required to make that unnecessary. <rlb>So do I have to know how each scm_i_works, or do we have requirements? That's really what I'm trying to figure out. <rlb>"scm_i_* works internally" <leoprikler>my personal interpretation of scm_i_* is, that they're mostly quick and dirty functions, wherein such concerns don't apply <rlb>(And if you "just have to know", perhaps we should note that in each one, so someone doesn't come along and rework the implementation in a way that violates the expectation...) <rlb>I ask all this because strings.c has a lot of internal functions and some scm_i_ functions (and calls some), and I'm trying to understand what my constraints are. <rlb>wrt toying with the sparsely indexed utf8 rearrangement. I suppose worst case I can just be very conservative, and then people can tell me where I've gone overboard wrt remembering -- just wanted to know whatever policies we had there. <leoprikler>I don't have the code in front of me rn, but I'm pretty sure some of those are just fancy accessors. <leoprikler>And that you need to remember the object if you plan on using their *return value*. <rlb>They were, but some things that were O(1) will become complicated, and some things that were complicated will be cached, and so O(1) i think. <leoprikler>that said, if you're adding stuff that's complicated and difficult to reason about, you should probably first ask yourself "Do I really want to do this?" rather than "Am I using correct scm_remember semantics?" <rlb>Well, we already had issues like that because strings are shared, etc. and we take pointers into the underlying stringbuf, etc. <rlb>That's the primary source of the issue, and it remains. <leoprikler>w.r.t. remember the best answer I can give you, is that the return value is the contract <rlb>Though some of that we might get around by recomputing the offsets all the time, i.e. avoid passing around raw internal pointers, but doesn't change the fact that you still have to remember the parent buffer object in all the right places. <leoprikler>can the caller reasonably assume, that it needs to remember x to use the scm_i_* return value → no internal remember necessary <rlb>Are you asking? Because that's what I was asking :) <leoprikler>is the stuff I'm doing opaque as fuck? better remember the arguments <rlb>i.e. if it's ok to omit the remembering in the _i_ functions and require the caller to handle it. <rlb>that was my question "or do we have existing 'requirements'". <leoprikler>As I said, the best answer I can give you, is "the return value is your contract". <rlb>Anyway, thanks -- at the very least, it doesn't sound like we have any hard and fast rules there atm. <leoprikler>even in public functions like scm_cdr you may need to remember post calling <rlb>i.e. it might be ok for me to say that "for these scm_i_* string calls you need to remember these arguments" <rlb>Though on the other hand, if the remember calls don't cost much (i.e. don't make an optimization mess or something), then why not just add the guards to the scm_i_ calls anyway. <rlb>i.e. just avoid the question/requirement. <rlb>Assuming they're not expensive(?) that's what I should probably do. <leoprikler>I think the rule of thumb here, is if you need to document it to reason about it, it's probably stupid. <leoprikler>but I have to go now and this is a little too abstract; if you have a more concrete MWE I'll look at it later <rlb>Yeah, I think maybe I'll at least guard all the scm_i_ functions (and of course scm_*), and may or may not guard the internal static functions (internally). Thanks again for the discussion. <ArneBab>lampilelo: you can move efficiently through the code, but the editor support still *is* inferior. That’s not an intrinsic problem, though, because the indentation+colon structure is an exact representation of the structure with parens. So the still existing limitation in editors is just because the work has not yet been done. The need is a bit smaller than with parens, because Emacs support for editing with indentation is pretty good. <ArneBab>lampilelo: for the reasoning: » I love the syntax of Python, but crave the simplicity and power of Lisp.« — Guile gives me the capabilities I wish for, and replacing *outer* parens with indentation gives an appearance which is close to Python (which is a better fit to my mind). <ArneBab>lampilelo: the deeper reason is that starting each procedure-call with a parenthesis makes visual recognition harder (until your mind starts to fade them out). I created a small presentation for the reasons, the first six slides of http://www.draketo.de/proj/wisp/why-wisp.html