IRC channel logs
2024-07-17.log
back to list of logs
<dthompson>ArneBab: getting closer but, that program can't be compiled without some work. (ice-9 rdelim) and (ice-9 pretty-print) have quite the large dependency graph, it turns out. I'm close to getting it, though. <dthompson>(srfi srfi-1) loads a C extension, annoyingly, so we need to patch that upstream in guile. <dthompson>hoot 0.5.0 should be out by the end of the month. hoping to have (ice-9 rdelim) and (ice-9 pretty-print) at least partially supported. <dthompson>it doesn't *need* it, but some of the procedures are implemented in C. it's just legacy code that needs modernizing. <old>will it be slower then? <dthompson>having scheme procedures implemented in C is hindering performance more than helping these days <haugh>If the Guile project modernized SRFI-1, is it more likely the implementation would be replaced or that new ice-9 module(s) would be created? I can see reasons for either <flatwhatson>haugh: SRFI 1 is SRFI 1, the interface wouldn't change, the discussion is just about whether it's implemented in C or pure scheme <dthompson>and put the equivalent scheme code in its place <rlb>flatwhatson: not promising I'll finish, but if that's the consensus and it helps you, I might go ahead and move it -- already handled about half the functions, though some were the easier ones. <flatwhatson>it's not my area, dthompson mentioned it because pure-scheme implementations are needed for hoot, i was just doing a drive-by clarification :) <flatwhatson>that said, i'm sure it would be useful and appreciated, that's clearly the direction things are going <rlb>flatwhatson: apologies -- I meant dthompson (tab completed wrong, and now I see they're gone :) ). <dthompson>rlb: if you want to port that code from c to scheme then... sure! I'd be a happy camper :) <rlb>dthompson: ok, we'll see -- converted about half last night. <rlb>(...ended up with some questions about type checking/error handling, but those are also something we could just adjust later if we like. e.g. the C code did *full* list validation (proper/nnon-circular) before a second traversal to do the work, but if that was primarily just to make it safe in C, then it's an extra cost we might not want to pay in scm, unless we do it in a way we know the compiler's likely to elide when repeated.) <dthompson>rlb: personally I think it's very silly to validate for a proper list first <dthompson>it's a complete waste of time. if you pass in a circular or improper list then that's on you lol <rlb>So far, I've omitted the full/double checking on the scheme side. <old>rlb: instead of traversing the list, could a property not be propagated to the head from the tail each time a cons happen? <old>Starting from '() which is a proper list, consing to it also yield a proper list. Could this information be stored as a single bit in each cdr slots of a pair? <old>then, list? become constant time check. <old>ofc that would require Scheme to be able to access raw bits in a pair memory <old>and ofc all of that won't work with mutable pairs <rlb>...clj lazily caches hashes, and depends on that for perf (somewhat related), but those are immutable/persistent structures (vectors, maps, sets, etc.). <dthompson>if you call a proc that expects a proper list but pass, say (1 . 2), then it will throw an exception. that's exactly the right thing, imo. <dthompson>likewise passing a circular list will just cause an unbounded loop, which is also fine imo <rlb>Course it also doesn't do improper lists at all... <dthompson>like if you're gonna make circular lists then you better know what you are doing lol, it shouldn't be every procedure's job to check for this case <rlb>Yeah, I tend to think something like srfi-1 (in particular) should favor avoiding costs you can't easily opt-out of. <dthompson>guile isn't even consistent about handling circular structures anyway. if you've ever checked out the r7rs benchmarks website you'll see that guile times out during the equal? benchmark <rlb>Wondered if there were any well known things we should do to clue in the optimizer. <rlb>Yeah, won't worry about it too much. <old>dthompson: It was more conerned about predicate like list? in a match form <dthompson>and in the big picture, bringing that code out of C and into Scheme is what will really let the compiler munch on the code ;) <rlb>i.e. there you just don't want to go further down the seq than you need to for the current question... <dthompson>old: there's no getting around list? being expensive when lists are made with pairs <dthompson>but there's rarely a reason to use that predicate <old>well the above proposition would work for immutable list <old>pair? is often prefer? <rlb>I *would* like for us to eventually have a good set of immutable types built-in, perhaps including immutable lists. <rlb>(i.e. list vector set map...) <old>as core instead of 3rd party? <rlb>Of course naming is the hardest part :) <rlb>After some previous discussion I've thought about putting Andy's fash/fector stuff "somewhere" (i.e. setting up a public repo) and collecting some bug fixes/improvements (iirc, I'm not the only one with some), but what to name it? iirc Andy also wanted to change the name(s) :) <rlb>(Currently lokke depends on fash, but not fector.) <rlb>(Also needs a *real* dissoc...) <rlb>But then eventually, perhaps those would be suitable for consideration for guile-proper. <rlb>I think f for "functional". <rlb>(not that many fixes, but a few) <rlb>You can see them in the "git log -p -- src/branch/main/mod/lokke/fash.scm" for that file. <rlb>And I think Andy has fector up somewhere, maybe indirectly. <rlb>(For vector's I rolled my own (in C), matching clj/jvm's approach -- though that was before I knew about fector I think, so don't know what I would have chosen if I'd compared that up front.) <dthompson>we need new names for these and to get into guile proper ;) <dthompson>we could really use them for goblins where we need functional hashes a lot <rlb>So far other than my having to "cheat" in a terrible way wrt dissoc, fash seems to be working just fine. Though I might also be roughly the only user atm :) <rlb>Without even knowing what I mean (*really*), I also wondered if there could be any appetite for some "unifying" (optional) abstraction on top of say fash/fector/... i.e. polymorphic operations (count thing) (first thing) (map f thing...). But perhaps *that* bit would best start outside guile -- see how it goes. <rlb>(And ignore the names, of course -- might well argue for less generic names in guile.) <rlb>Much more important imo just to have the persistent types. <dthompson>using generic procedures via goops sounds like the sensible thing there <dthompson>polymorphism can be handy for high-level abstractions, but usually I want monomorphic interfaces <rlb>Ideally, I'd like both. That's how I've structured much of lokke, fwiw. <rlb>e.g. there's lokke-vector-* and the polymorphic functions just redirect to those, so you can pick. <dthompson>it's when you only provide polymorphic that things get annoying <ArneBab>dthompson: sounds great! (partially supported) — pretty-print can be removed as dependency, I think. <dthompson>I'm (slowly) working on getting (ice-9 vlist) to compile with hoot and that covers a lot of the same modules that you are using.