2023-07-01 14:48:34 -0400 < skeemer> hello all, do you guys think the little schemer series of books is a good series even for people who is already used to programming?
2023-07-01 16:00:42 -0400 < Zipheir> skeemer: Definitely.
2023-07-01 16:01:25 -0400 < Zipheir> skeemer: When I first started with Scheme, I ignored The Little Schemer for a while since it seemed too basic. I regret that, since it's a great book.
2023-07-01 16:01:53 -0400 < Zipheir> That being said, some people do not like the Little Book style.
2023-07-01 16:12:14 -0400 < wasamasa> it's indeed a very weird style
2023-07-01 16:12:21 -0400 < skeemer> it's a socratic style
2023-07-01 16:12:27 -0400 < skeemer> as far as i understand
2023-07-01 16:12:28 -0400 < wasamasa> I kinda get why they'd do this, but eh
2023-07-01 16:12:54 -0400 < wasamasa> to get a decent and intuitive understanding how a lisp works, you'll want to have a very good grasp on how an evaluator works
2023-07-01 16:13:31 -0400 < Zipheir> My favorite negative review of The Little Schemer said "this book seems to be written for the 8-year-old graduate student".
2023-07-01 16:14:37 -0400 < Zipheir> The Little books written without Matthias Felleisen are noticeable less repetitive.
2023-07-01 16:14:44 -0400 < Zipheir> *noticeably
2023-07-01 20:00:10 -0400 -!- Netsplit *.net <-> *.split quits: nerthus, sunarch, robin, leah2, Origin, ggoes, Everything, lechner, mdhughes, Gliese852,  (+2 more, use /NETSPLIT to show all of them)
2023-07-01 20:00:25 -0400 -!- Netsplit over, joins: Gliese852
2023-07-01 20:00:45 -0400 -!- Netsplit over, joins: Origin, lechner, leah2
2023-07-01 20:00:59 -0400 -!- Netsplit over, joins: cognemo
2023-07-01 21:30:34 -0400 -!- monix is now known as festerdam
--- Day changed Sun Jul 02 2023
2023-07-02 04:19:01 -0400 < skeemer> people is anybody here using geiser with emacs?
2023-07-02 04:19:12 -0400 < skeemer> i cannot understand how to send a sexp to the repl and evaluate in the repl
2023-07-02 04:19:22 -0400 < skeemer> instead of evaluating in place and seeing the result on the small buffer below
2023-07-02 05:57:33 -0400 -!- ormaaaj is now known as ormaaj
2023-07-02 06:03:01 -0400 < rgherdt> skeemer: I'm not really familiar with geiser, but as I understand it this is the way it's supposed to work. As I understand things are evaluated in the REPL, but output is redirected to the buffer
2023-07-02 06:03:41 -0400 < rgherdt> emacs' built-in scheme support works as you want
2023-07-02 06:04:51 -0400 < wasamasa> does it?
2023-07-02 06:05:04 -0400 < rgherdt> I mean, run-scheme
2023-07-02 06:05:22 -0400 < rgherdt> you see after C-x C-e the output in the repl
2023-07-02 07:06:41 -0400 < skeemer> rgherdt, i have no run-scheme command available
2023-07-02 07:07:25 -0400 < wasamasa> it's part of stock emacs
2023-07-02 07:09:06 -0400 < skeemer> wasamasa, i have stock emacs
2023-07-02 07:09:38 -0400 < skeemer> ok i have run-chicken
2023-07-02 07:09:48 -0400 < skeemer> tried but the output is still in the minibuffer
2023-07-02 07:09:51 -0400 < skeemer> so no big difference
2023-07-02 07:11:17 -0400 < wasamasa> apparently, M-x run-scheme is provided by MIT Scheme, wtf
2023-07-02 07:11:59 -0400 < wasamasa> sigh
2023-07-02 07:12:04 -0400 < wasamasa> why does it override this
2023-07-02 07:12:38 -0400 < wasamasa> yeah, run-scheme should be provided by cmuscheme.el
2023-07-02 07:12:47 -0400 < wasamasa> xscheme.el also provides it
2023-07-02 07:13:45 -0400 < wasamasa> yeah, after (unload-feature 'xscheme), I have restored expected behavior again
2023-07-02 07:13:46 -0400 < wasamasa> wonderful
2023-07-02 07:25:58 -0400 < rgherdt> skeemer: you also have to customize the variable 'scheme-program-name' to use your implementation
2023-07-02 18:51:11 -0400 < mwnaylor> Are there emacs yasnippets that work in scheme buffers?
2023-07-02 19:55:44 -0400 < zzz> i just started learning scheme. i can't understand if '() is supposed to be an atom or not, and why that matters
2023-07-02 20:04:27 -0400 < Zambyte> zzz: Are you using a particular resource to learn Scheme? Sounds like you might be using The Little Schemer?
2023-07-02 20:06:12 -0400 < mdhughes> rudybot: eval (atom? '()) (list? '())
2023-07-02 20:06:12 -0400 < rudybot> mdhughes: your sandbox is ready
2023-07-02 20:06:12 -0400 < rudybot> mdhughes: error: atom?: undefined; <NEWLINE>  cannot reference an identifier before its definition <NEWLINE>   in module: 'program
2023-07-02 20:06:25 -0400 < mdhughes> Blah.
2023-07-02 20:06:49 -0400 < Zambyte> That's why I asked what they are using to learn :) atom? isn't a standard Scheme procedure
2023-07-02 20:07:10 -0400 < mdhughes> Yeah, it's in Chez, but random if any other has it.
2023-07-02 20:07:32 -0400 < mdhughes> But my testing both is a koan: '() is an atom and a list.
2023-07-02 20:09:09 -0400 < mdhughes> Also (null? '()) => #t
2023-07-02 20:09:37 -0400 < mdhughes> AH, the preface to Little Schemer has a defn for atom? if yours doesn't have one.
2023-07-02 20:11:23 -0400 < Zambyte> I knew I saw it somewhere!
2023-07-02 20:12:09 -0400 < Zambyte> Looks like '() is not an atom for little scheming purposes
2023-07-02 20:17:44 -0400 < zzz> Zambyte: yup, little schemer. in chez `(atom? '()) => #t` but if i define `my-atom?` as proposed by the book the result is #f
2023-07-02 20:23:39 -0400 < Zambyte> zzz: It is significant that '() is not an atom? in the book, because it makes it clear that you don't want to you must check if the value is null? first before recursively operating on it. If the value is null?, then you probably reached the end of some recursive operation. If the value is an atom, than you probably want to do something with it. If the value is a non-empty list, than you probably want to recur on it.
2023-07-02 20:24:33 -0400 < Zambyte> If you check if the value is null? before you check if it's an atom (as the book does) then it doesn't actually matter if you check for null? before checking if it's an atom?.
2023-07-02 20:25:49 -0400 < Zambyte> That didn't make sense lol. The book checks for null? first always, therefore it doesn't matter if '() is considered an atom?.
2023-07-02 20:26:17 -0400 < zzz> ok
2023-07-02 20:26:56 -0400 < Zipheir> The term 'atom' is not used much outside of The Little & Seasoned Schemer. I noticed today that Felleisen uses it in some other books, though.
2023-07-02 20:27:29 -0400 < aeth> it's not a particularly useful concept
2023-07-02 20:27:37 -0400 < zzz> so i can partially ignore it. thanks
2023-07-02 20:27:44 -0400 < Zipheir> And atom? has no direct analog in standard Scheme, either.
2023-07-02 20:27:57 -0400 < aeth> where relevant, an atom usually is just the else branch of a COND or IF that cares more about the list part
2023-07-02 20:29:44 -0400 < zzz> is else just #t in disguise?
2023-07-02 20:29:51 -0400 < Zipheir> The important thing to remember (for TLS) is that an 'atom' is not a list.
2023-07-02 20:29:57 -0400 < Zipheir> zzz: Yes.
2023-07-02 20:30:48 -0400 < Zipheir> There's a funny question/answer pair in TLS: "else?" "Of course."
2023-07-02 20:34:49 -0400 < Zambyte> Certainly!
2023-07-02 20:35:28 -0400 < zzz> it's actually the last question in the book :)
2023-07-02 20:36:21 -0400 < zzz> else | Yes, it's time for a banquet.
2023-07-02 20:36:26 -0400 < zzz> at leas in my edition
2023-07-02 21:08:54 -0400 < Zipheir> Yup.
2023-07-02 21:09:24 -0400 < Zipheir> Lots of eating in the Little Schemer.
--- Day changed Mon Jul 03 2023
2023-07-03 11:56:11 -0400 < zzz> i notice i am able to use [] and () interchangeably
2023-07-03 11:58:35 -0400 < wasamasa> that's only guaranteed by R6RS, isn't it
2023-07-03 12:11:50 -0400 < sham1> Yes
2023-07-03 12:12:23 -0400 < sham1> It's only guaranteed by R6RS, but I don't see why for example an R7 implementation wouldn't also do that
2023-07-03 12:14:35 -0400 < sham1> Of course, if the plan is to make R6RS code also valid R7RS-Large code, as seems to be the case, then [] has to be made work
2023-07-03 12:14:44 -0400 < wasamasa> it's reserved syntax as per R7RS-small
2023-07-03 12:15:52 -0400 < rgherdt> just checked, from the implementations installed in my box mit-scheme and chibi do not support it
2023-07-03 12:15:53 -0400 < zzz> i'm just giving my first steps. when is it considered a good idea to use [] instead of
2023-07-03 12:15:57 -0400 < zzz> ()
2023-07-03 12:16:35 -0400 < sham1> Usually I've seen [] used in forms like let for distinctiveness
2023-07-03 12:17:10 -0400 < sham1> Something like (let [(a expr)] body-here)
2023-07-03 12:17:50 -0400 < sham1> Same with stuff like syntax-case, where they'd be used around each of the arms
2023-07-03 12:25:48 -0400 < rgherdt> ... and kawa
2023-07-03 12:25:57 -0400 < sham1> Okay, that's werids
2023-07-03 12:26:06 -0400 < sham1> There's no reason for them to not support it
2023-07-03 12:26:49 -0400 < sham1> Other than square brackets being technically reserved. But it's not like the standard is going to just break existing implementations by making them do something unexpected
2023-07-03 12:28:27 -0400 < wasamasa> I dunno, it seems silly to use square brackets if you want to write portable code
2023-07-03 12:28:44 -0400 < wasamasa> if you're gonna make life harder for yourself, then preferably on a different level than the lexical one
2023-07-03 13:01:46 -0400 < Zipheir> zzz: As sham1 says, square brackets are used (as in mathematics) to break up massively-nested blocks of parens.
2023-07-03 13:02:35 -0400 < Zipheir> It's very odd how that was added to R6 then effectively removed in R7.
2023-07-03 13:06:21 -0400 < wasamasa> sadly there was no "Square brackets considered harmful" essay explaining the why
2023-07-03 13:08:08 -0400 < Zipheir> Any such essay would sound pretty silly.
2023-07-03 13:09:33 -0400 < Zipheir> I think it was an odd thing to add to a Scheme standard in the first place. I wonder how many implementations supported it at the time R6RS was in progress.
2023-07-03 14:53:51 -0400 < dpk> mostly i think square brackets became something of a shibboleth for the anti-R6RS faction
2023-07-03 14:55:03 -0400 < dpk> there are a couple of arguments against them. one is that it's very weird to have two notations for the same thing. another may well have been that some implementations like Gambit already have their own ideas of what to do with square brackets
2023-07-03 14:56:03 -0400 < ecraven> personally, I don't find them very useful, I don't find code using them easier to read, but harder (which is of course related to my unfamiliarity with them).
2023-07-03 14:56:23 -0400 < ecraven> same thing happens with clojure for me, I've just read too many decades of "normal" lispy code
2023-07-03 14:58:27 -0400 < dpk> well, Clojure uses them for something different than round brackets, which i think is the correct approach
2023-07-03 14:58:44 -0400 < dpk> whether they should also have been used syntactically is another issue
2023-07-03 14:59:40 -0400 < dpk> personally if i'd been around in R6RS times i would have objected to them, but thanks to R6RS it's probably too late to give them any other meaning now
2023-07-03 15:08:52 -0400 < sham1> I wonder what {} could be
2023-07-03 15:09:20 -0400 < sham1> In Clojure it's for maps but I feel like that wouldn't work with Scheme, so I wonder what they could be used for
2023-07-03 15:10:54 -0400 < Oxyd> {(a b) e1 e2} could be short for (lambda (a b) e1 e2), that could be useful.
2023-07-03 15:12:44 -0400 < sham1> Eh, maybe. Although that does seem rather much for this kind of lexical stuff
2023-07-03 15:13:12 -0400 < Oxyd> Not that different from ' and friends.
2023-07-03 15:13:44 -0400 < sham1> Does lambda need that though
2023-07-03 15:14:04 -0400 < wasamasa> {} does indeed have precedent for that in languages like smalltalk, ruby and rust
2023-07-03 15:15:27 -0400 < mdhughes_> CHICKEN lets you use {} for () also. Gerbil uses [] for arrays, and {} for its object system.
2023-07-03 15:16:21 -0400 < mdhughes_> I really like [] for let and cond, so it's pretty frustrating that many R7s don't support it.
2023-07-03 15:16:26 -0400 -!- mdhughes_ is now known as mdhughes
2023-07-03 15:16:46 -0400  * mdhughes removes _
2023-07-03 15:23:54 -0400 < zzz> what's the source of documentation for schez scheme's `match` ?
2023-07-03 15:25:02 -0400 < wasamasa> I'd expect it to be this: https://www.semanticscholar.org/paper/Pattern-Matching-for-Scheme-Wright/6c64e9a13dae3c4cd6f4889c6fd45f2154e70d5c?p2df
2023-07-03 15:25:03 -0400 < rudybot> https://teensy.info/KIqENaKOXP
2023-07-03 15:35:12 -0400 < dpk> {} for lambda would cross the lexical/semantic barrier
2023-07-03 15:35:40 -0400 < dpk> the reader could not return an actual lambda from it, it could at most expand it into (lambda (a b) ...)
2023-07-03 15:35:48 -0400 < dpk> and that using the symbol lambda, not the hygienic identifier
2023-07-03 15:35:49 -0400 < Oxyd> Yeah, same as with '.
2023-07-03 15:35:53 -0400 < dpk> like ', as Oxyd says
2023-07-03 15:37:16 -0400 < dpk> adding λ as an alias for lambda would achieve almost identical typing speed efficiencies (assuming you have a key binding for it, which most editors/OSes should make reasonably easy to add) and space efficiencies
2023-07-03 15:37:47 -0400 < sham1> I don't personally like {} for lambda
2023-07-03 15:38:01 -0400 < dpk> we should be very careful imo about using up additional non-identifier characters for lexical syntax
2023-07-03 15:38:14 -0400 < dpk> R6RS has already squandered our ability to do anything useful with []
2023-07-03 15:38:15 -0400 < sham1> ' for quote makes sense
2023-07-03 15:39:02 -0400 < dpk> (that said, we should also be more careful about adding more functionality to the # lexical syntax, but that ship sailed the moment we adopted SRFI 160 …)
2023-07-03 15:42:07 -0400 < dpk> Chibi uses {} for records, which can sort of be round-tripped, but you can only safely read them back in within the same session they were written out, because each record type is given an incrementing number in the order they were defined and that's used by the reader to know which record type to instantiate and how to fill the fields in
2023-07-03 15:42:34 -0400 < dpk> theoretically if Chibi had R6RS-style uids for record types that could be fixed, but i won't hold my breath waiting for Alex to add those
2023-07-03 15:43:51 -0400 < dpk> (the other thing is that Chibi has three implementations of a Scheme reader for no particularly good reason, and i bet not all three of them support this either)
2023-07-03 15:45:47 -0400 < aeth> the problem with wasting []s is you waste them
2023-07-03 15:45:57 -0400 < aeth> personally, I'd use {}s for hash tables if I used them
2023-07-03 15:46:20 -0400 < aeth> and then if you then used []s for vectors you'd get something that's almost like a comma-less JSON
2023-07-03 15:48:25 -0400 < Zipheir> Maybe someone could devise a "fancy" expression language that could be expanded to S-exps...
2023-07-03 15:49:29 -0400 < Zipheir> Wisp is an example.
2023-07-03 15:49:51 -0400 < dpk> i would still like to add readtables to Chibi to fix the three-different-reader-implementations situation
2023-07-03 15:50:40 -0400 < sham1> I personally wouldn't like {} for hashtables, because then you're adding lexical syntax for a specific library into the core language
2023-07-03 15:51:58 -0400 < dpk> well, we have hash tables in the large language (SRFI 125), so that's no more of an issue than the zoo of SRFI 160 lexical syntaxes. (i still want to kill off hash tables in Large and only have SRFI 146 persistent mappings, but i think i'm alone there)
2023-07-03 15:52:09 -0400 < Zipheir> Yeah. I like chibi's idea of using them for records; at least they're "core".
2023-07-03 15:53:12 -0400 < Zipheir> But I would like as little syntactic sugar in the reports as possible.
2023-07-03 15:53:33 -0400 < sham1> Yes, hashtables are in the large language, but it'd still feel weird for the lexical syntax to be for (scheme hash-table) or whatever the name is. Or the 146 mapping, or what have you
2023-07-03 15:53:44 -0400 < Zipheir> You can always write a preprocessor (a forgotten art) if you want fancy lexical syntax.
2023-07-03 15:53:54 -0400 < sham1> At least an alist, so {a b c d} => ((a . b) (c . d)) would be core
2023-07-03 15:54:13 -0400 < dpk> yeah, the other problem there is that hash tables in Large inherently are associated with comparators, which can't be serialized because they involve procedures
2023-07-03 15:54:20 -0400 < sham1> Right
2023-07-03 15:54:38 -0400 < dpk> so you could have reader syntax for eq?, eqv?, equal? hashtables but for my-wonderful-comparator hash tables
2023-07-03 15:54:40 -0400 < sham1> Although isn't that also the case with the 146 mappings?
2023-07-03 15:54:43 -0400 < dpk> yes
2023-07-03 15:54:51 -0400 < dpk> *but not for
2023-07-03 15:54:57 -0400 < Zipheir> Syntax for dictionary types is hard.
2023-07-03 15:55:32 -0400 < sham1> For flexible dictionary types. Python gets away with a dictionary type but that's because it's not like at all customisable as such. Whereas we have comparators, they have __eq__ and whatnot
2023-07-03 15:55:38 -0400 < sham1> Like as object properties
2023-07-03 15:55:57 -0400 < sham1> Honestly, what I'd do with {} is we adopt readtables and thus reader macros, and reserve {} for user-defined stuff
2023-07-03 15:56:12 -0400 < dpk> well, reader macros have phasing issues
2023-07-03 15:56:26 -0400 < dpk> i can add them to Chibi because Chibi's approach to phasing is basically ‘whatever’
2023-07-03 15:56:36 -0400 < dpk> AOT compilers will have a hard time with them
2023-07-03 15:57:15 -0400 < sham1> We could also just say that {} as-is are not proper lexical syntax
2023-07-03 15:57:25 -0400 < dpk> that's the current situation
2023-07-03 15:57:28 -0400 < dpk> de facto
2023-07-03 15:57:38 -0400 < sham1> So we could make it de jure
2023-07-03 15:58:05 -0400 < Zipheir> de report. There is no 'jure' in Scheme.
2023-07-03 15:58:20 -0400 < dpk> well, arguably it's the current situation de jure as well. we don't currently *explicitly* say that implementations can do whatever they want with them, but since we also don't define what they should do with them, implementations can do whatever
2023-07-03 15:58:29 -0400 < sham1> [] are already set in stone for R7RS-large because it wants to be backwards compatible with R6RS
2023-07-03 15:58:36 -0400 < dpk> we could guarantee that ‘no future report will add functionality for {} …’ but that would probably be silly
2023-07-03 15:58:56 -0400 < Zipheir> sham1: Has that been confirmed by vote?
2023-07-03 15:59:07 -0400 < dpk> sham1: well, we don't have to support them for R7RS libraries and programs. all we have to do it make sure they work when you say #!r6rs
2023-07-03 15:59:24 -0400 < dpk> but having them mean one thing in one place and another thing in another would be bad
2023-07-03 16:01:51 -0400 < sham1> Zipheir: technically that hasn't been voted on, but that's the sentiment I'm getting, at least from Marc and maybe John
2023-07-03 16:02:10 -0400 < sham1> Definitely Marc
2023-07-03 16:02:47 -0400 < dpk> arguably it would be better to have them not work at all when #!r6rs mode is off, in order to wean programmers off them and let R8RS (which i remain convinced will never happen, but let's keep that possibility open) do something more useful with them if it wants
2023-07-03 16:03:12 -0400 < dpk> yes, there is consensus among the chairs that R7RS and R6RS program and library interoperation should be possible
2023-07-03 16:03:44 -0400 < sham1> That'd also work for me. Especially if implementations have readtables then #!r7rs and #!r6rs would be just a matter of switching the base readtable
2023-07-03 16:03:46 -0400 < dpk> that doesn't necessarily mean that an R7RS library/program will work if you drop it into R6RS or vice versa
2023-07-03 16:04:41 -0400 < sham1> I personally do like [] for the distinctiveness but I understand why they might not be as well-liked
2023-07-03 16:04:57 -0400 < dpk> nor, in fact, that R7RS implementations should be required to support all of the R6RS standard library, say, but an implementation which supports both and allows interoperation should be possible
2023-07-03 16:05:14 -0400 < dpk> this means R7RS will adopt the R6RS condition type hierarchy, for example
2023-07-03 16:05:35 -0400 < dpk> but it's not *too* strong a restriction on what we can do
2023-07-03 16:05:40 -0400 < Zipheir> I guess that's fine, unless you're trying to use a library from some odd R7RS-small+ implementation that repurposes [].
2023-07-03 16:05:57 -0400 < sham1> R7RS is also adopting other conveniences like syntax-case and related things outside of R6 like with-ellipsis
2023-07-03 16:06:27 -0400 < dpk> well, if you're trying to use a non-portable library to start with, that's probably not our problem :D
2023-07-03 16:06:48 -0400 < Zipheir> sham1: I second/third/... the sentiments. The R6/R7 schism was very unfortunate.
2023-07-03 16:06:54 -0400 < sham1> Yes. We only write _standard_ scheme*
2023-07-03 16:07:00 -0400 < sham1> *: for some definition of standard
2023-07-03 16:07:30 -0400 < Zipheir> Well, there's room for R7RS-large subset implementations.
2023-07-03 16:07:58 -0400 < sham1> Zipheir: I also agree with it although I don't know whether this'd actually help the schism
2023-07-03 16:08:02 -0400 < Zipheir> At least, I hope there is. Requiring full conformance was a big mistake of R6, IMHO.
2023-07-03 16:08:15 -0400 < dpk> i think we will probably also adopt the remaining procedures from the low-level macro system appendix to the R4RS (mainly unwrap, which Racket and Gerbil call syntax-e, and which addresses the concern of some anti-syntax-case people that the syntax-case pattern matcher is the only way to destructure these weird ‘syntax object’ things)
2023-07-03 16:09:08 -0400 < dpk> (in practice, i don't think these people want to write macros without pattern matching nearly as much as they claim they do, but if they insist …)
2023-07-03 16:09:09 -0400 < sham1> Zipheir: I remember reading either on codeberg or somewhere else that John is also thinking about full compliance for R7-large, which I'd say would be a mistake
2023-07-03 16:09:25 -0400 < dpk> the compliance story for R7RS Large is not yet decided
2023-07-03 16:09:52 -0400 < dpk> Marc's proposal is to have two ‘modes’, strict and fast
2023-07-03 16:10:04 -0400 < sham1> dpk: but they already have syntax->datum while syntax-e/unwrap would only really help with one level of the thing and things like lists might be a problem
2023-07-03 16:10:17 -0400 < dpk> fast would not necessarily be fast
2023-07-03 16:10:26 -0400 < sham1> Like whether the cdr of a syntax list would be a syntax object or a normal paqir
2023-07-03 16:10:30 -0400 < sham1> Or null
2023-07-03 16:10:38 -0400 < dpk> Chibi would be a ‘fast’ implementation because it probably wouldn't fulfill all strict error reporting conditions, for example
2023-07-03 16:10:44 -0400 < dpk> even though Chibi is s l o w
2023-07-03 16:10:53 -0400 < dpk> but what these two modes mean in practice is not entirely clear to me
2023-07-03 16:10:59 -0400 < Zipheir> Requiring full compliance for R7RS-large, with its massive pile of libraries, would be madness.
2023-07-03 16:11:19 -0400 < dpk> Zipheir: well, that's the genius of the Foundation/Batteries split!
2023-07-03 16:11:24 -0400 < Zipheir> I hope so.
2023-07-03 16:11:45 -0400 < sham1> I'd think that a better dichotomy for R7 implementations would be like in many other languages you have a release and a debug build
2023-07-03 16:11:56 -0400 < dpk> the plan is, if the implementors do all of the (larger than small, about the same size as R6RS core) Foundations stuff, they can use sample implementations for the Batteries and get all of that for free
2023-07-03 16:11:57 -0400 < sham1> The "strict" one would be the mode that helps with debugging while the release is, well, release
2023-07-03 16:12:56 -0400 < sham1> For example for a fast release build you could do dastardly things and disable things like full tail calls which might help Kawa
2023-07-03 16:12:59 -0400 < Zipheir> dpk: Which, IIUC, has always been the basic plan for R7RS-large. Except that, now, Foundations is intended to replace R7RS-small as R7RS-medium, I suppose.
2023-07-03 16:13:10 -0400 < dpk> (they might be able to get better performance on their particular implementation by re-implementing or tuning certain Batteries libraries, but the sample implementations would just work)
2023-07-03 16:13:30 -0400 < sham1> Yeah, the Batteries don't need to be fast but they need to be correct
2023-07-03 16:14:15 -0400 < dpk> anyway, i wanted to write a job application this evening and you're all distracting me. yes, it's all your fault, and not the mind-numbing tedium of applying for a job in itself. i'm blaming all of you
2023-07-03 16:14:17 -0400 < sham1> I'd also like to point out that the Environment committee is still just a potted plant and a sign saying "under construction"
2023-07-03 16:14:25 -0400  * dpk vanishes in a puff of trying-to-get-stuff-done
2023-07-03 16:14:29 -0400 < sham1> gl
2023-07-03 16:14:30 -0400 < Zipheir> dpk: Good luck.
2023-07-03 16:15:02 -0400 < zzz> does importing rnrs add anything of value to chez's default environment?
2023-07-03 16:15:29 -0400 < Zipheir> I wonder if the overall effect is going to be that the R6 implementations stay with R6 and everyone else does whatever the hell they want.
2023-07-03 16:16:04 -0400 < Zipheir> zzz: You mean (rnrs base (6))?
2023-07-03 16:16:11 -0400 < dpk> yeah, one of my major concerns is that we don't yet have clear buy-in for the Foundations from any existing implementation …
2023-07-03 16:16:47 -0400 < dpk> Marc has tried to get Dybvig interested in adding it to Chez, i think, but Dybvig still thinks of R7RS as a reactionary anti-R6RS effort afaict
2023-07-03 16:17:21 -0400 < Zipheir> Hmm.
2023-07-03 16:17:50 -0400 < Zipheir> zzz: I'm not sure if you have to import the base library. I imagine it's available by default in Chez.
2023-07-03 16:18:04 -0400 < zzz> i don't know
2023-07-03 16:19:03 -0400 < dpk> the REPL in Chez starts with the (chezscheme) library imported, iirc
2023-07-03 16:19:11 -0400 < dpk> though i'm not sure exactly what's in it
2023-07-03 16:19:19 -0400 < dpk> check the relevant edition of CSUG
2023-07-03 16:20:02 -0400 < zzz> The default interaction environment used for any code that occurs outside of an RNRS top-level program or library (including such code typed at a prompt or loaded from a file) contains all of the bindings of the (chezscheme) library (or scheme module, which exports the same set of bindings). This set contains a number of bindings that are not in the RNRS libraries. It also contains a number of bindings that
2023-07-03 16:20:08 -0400 < zzz> extend the RNRS counterparts in some way and are thus not strictly compatible with the RNRS bindings for the same identifiers. To replace these with bindings strictly compatible with RNRS, simply import the rnrs libraries into the interaction environment by typing ...
2023-07-03 16:20:20 -0400 < dpk> a program or library, of course, starts with absolutely nothing imported. you should probably import the rnrs versions of things there unless you know you want something that only Chez supports
2023-07-03 16:21:56 -0400 < zzz> ok so now i want to use `match`. is there a canonical match library? where can i find stuff like this?
2023-07-03 16:23:08 -0400 < Zipheir> zzz: There is no canonical implementation of the WCS matcher for Chez. If you want basic pattern matching, you can grab Oleg Kiselyov's pmatch https://github.com/webyrd/quines/blob/master/pmatch.scm
2023-07-03 16:23:43 -0400 < dpk> i think MNW's list-case has an R6RS implementation?
2023-07-03 16:23:49 -0400 < dpk> actually i'm not sure it's called list-case
2023-07-03 16:23:51 -0400 < dpk> hang on
2023-07-03 16:23:52 -0400 < Zipheir> There's that, too.
2023-07-03 16:24:11 -0400 < dpk> yes https://srfi.schemers.org/srfi-239/srfi-239.html
2023-07-03 16:24:18 -0400 < dpk> https://github.com/scheme-requests-for-implementation/srfi-239/tree/master/lib
2023-07-03 16:28:14 -0400 < zzz> what is WCS?
2023-07-03 16:31:14 -0400 < Zipheir> The "Wright-Cartwright-Shinn" pattern-matcher. It's what people usually think of when they say "match" in Scheme.
2023-07-03 16:31:49 -0400 < Zipheir> zzz: There was an attempt to SRFIfy it. https://srfi.schemers.org/srfi-204/srfi-204.html
2023-07-03 16:33:34 -0400 < Zipheir> Hmm. I don't think there was anything seriously deficient in that SRFI. Maybe I should resurrect it.
2023-07-03 16:34:09 -0400 < Zipheir> Wow, it did get pretty complicated, though.
2023-07-03 16:34:32 -0400 < dpk> yeah, it's badly designed imo
2023-07-03 16:34:44 -0400 < dpk> start by cutting out all the non-portable features, i'd say
2023-07-03 16:35:19 -0400 < zzz> i see
2023-07-03 16:35:32 -0400 < Zipheir> dpk: I think I'd have to. I don't understand some of these features at all.
2023-07-03 16:36:37 -0400 < Zipheir> I'll give it a shot.
2023-07-03 16:55:36 -0400 < jcowan> Zipheir: I have most of it done, I just never wrapped it up
2023-07-03 16:56:22 -0400 < Zipheir> Well, that's good.
2023-07-03 17:00:12 -0400 < jcowan> I have to post it from my other laptop
2023-07-03 17:00:52 -0400 < jcowan> but I don't know where its power cord is
2023-07-03 17:29:31 -0400 < mwnaylor> Are there emacs snippets for the scheme family of languages?
2023-07-03 19:09:00 -0400 < zzz> why does `(fold-right (lambda (x y) (and x y)) #t '(#t #t #t))` work and `(fold-right and #t '(#t #t #t))` throws an exception (invalid syntax and)?
2023-07-03 19:36:03 -0400 < Zipheir> zzz: 'and' is syntax. It's not a procedure.
2023-07-03 19:37:12 -0400 < Zipheir> zzz: Try to write a procedure 'and-proc' such that (and-proc #f (run-forever)) returns.
2023-07-03 20:18:25 -0400 < zzz> that's surprising. any reason it's not a normal proc?
2023-07-03 20:25:07 -0400 < Zipheir> zzz: Try to write 'and-proc', as I suggested.
2023-07-03 20:25:42 -0400 < Zipheir> It's easy with lazy evaluation, but we are strict here.
2023-07-03 20:36:08 -0400 < zzz> (define and-proc (lambda (x y) (if x y #f)))
2023-07-03 20:36:54 -0400 < zzz> (fold-left and-proc #t '(#t #t #t)) => #t
2023-07-03 20:37:00 -0400 < zzz> (fold-left and-proc #t '(#t #f #t)) => #f
2023-07-03 20:37:32 -0400 < Zipheir> zzz: That's fine for higher-order procedures. However, define run-forever to be an infinite loop. Then (and #f (run-forever)) returns #f, but your and-proc will go off the rails. Why?
2023-07-03 20:38:07 -0400 < zzz> oh i see
2023-07-03 20:46:21 -0400 < zzz> so (if p x y) will always evaluate x?
2023-07-03 21:25:20 -0400 < zzz> hm... no
2023-07-03 21:33:40 -0400 < Zipheir> Indeed, 'if' is another one that can't be implemented as a procedure if it's going to have the right semantics.
2023-07-03 21:34:06 -0400 < Zipheir> ('and' and 'or' are usually just macros around 'if'.)
2023-07-03 21:35:28 -0400 < Zipheir> The 'if' semantics require a specific order of evaluation: https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%_sec_4.1.5
2023-07-03 21:36:08 -0400 < Zipheir> Whereas procedure application always evaluates the arguments before the procedure body.
2023-07-03 21:57:40 -0400 < zzz> got it. i have some reading to do
--- Day changed Tue Jul 04 2023
2023-07-04 04:22:35 -0400 < amirouche> [] is also used in skribe syntax
2023-07-04 04:23:29 -0400 < amirouche> hey zzz I think you are new around here?
2023-07-04 04:23:33 -0400 < amirouche> welcome!
2023-07-04 04:32:22 -0400 < sham1> Well things like Racket's Scribble shouldn't affect [] at all because that's just a different language
2023-07-04 06:37:23 -0400 < zzz> ty amirouche i'm just trying to learn scheme
2023-07-04 06:37:36 -0400 < zzz> it's more confusing than i expected
2023-07-04 06:37:45 -0400 < ecraven> ;) what confuses you?
2023-07-04 06:40:52 -0400 < zzz> unexpectedly i'm having no trouble with functional programming concepts nor with the parenthesis which are advertized as common obstacles
2023-07-04 06:44:06 -0400 < ecraven> ;) the parentheses are half as bad, just use a proper editor that can indent correctly, look and indentation and ignore the parens
2023-07-04 06:44:46 -0400 < zzz> but am having trouble with the complications, exceptions, dialects/variants and (relative) lack of resources
2023-07-04 06:45:04 -0400 < ecraven> what are your goals and motivations for learning Scheme?
2023-07-04 06:48:07 -0400 < zzz> the simple and uniform syntax, homoiconicity etc., the "learning it made me a better programmer" part of the experience. the conceptual purity of it comparing to the mess most other popular languages are
2023-07-04 06:48:44 -0400 < ecraven> then may I suggest looking into Structure and Implementation of Programming Languages, the first few chapters should run on *any* implementation of Scheme, I believe
2023-07-04 06:49:11 -0400 < zzz> ecraven: thanks! i'm definetely going to check it out
2023-07-04 06:49:21 -0400 < ecraven> a great book, also available online for free
2023-07-04 06:49:43 -0400 < ecraven> there are others as well, of course ;)
2023-07-04 06:50:02 -0400 < ecraven> but that one, imvho, is one of the best
2023-07-04 06:52:58 -0400 < zzz> can't find it with that exact same title
2023-07-04 06:53:09 -0400 < ecraven> ah, sorry, complete thinko
2023-07-04 06:53:26 -0400 < ecraven> https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
2023-07-04 06:53:44 -0400 < ecraven> I think this is the online version https://xuanji.appspot.com/isicp/
2023-07-04 06:54:05 -0400 < zzz> got the epub! thanks
2023-07-04 07:30:10 -0400 < rgherdt> zzz: also take a look at the video lectures based on the book: http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
2023-07-04 07:32:17 -0400 < cow_2001> oooh
2023-07-04 09:05:51 -0400 < zzz> rgherdt: ha! i have this tab open since yesterday -> https://www.youtube.com/playlist?list=PLE18841CABEA24090
2023-07-04 09:51:54 -0400 < mdhughes> Notably, there's now good PDFs of SICP: https://archive.org/details/sicp_20211010
2023-07-04 09:52:13 -0400 < mdhughes> And the lectures are on archive, too: https://archive.org/details/mit_ocw_sicp?sort=titleSorter
2023-07-04 10:54:44 -0400 < dpk> i've written a talk called ‘syntax-case for a hostile audience’ which explains how to use syntax object-based procedural macros if you have explicit renaming or implicit renaming brain
2023-07-04 10:54:58 -0400 < dpk> i actually intended to give this talk earlier this year, but forgot to sign up for the conference
2023-07-04 10:55:08 -0400 < dpk> so i'm thinking i'll just record it and put it on YT or something
2023-07-04 12:32:26 -0400 < Zipheir> "syntax-case for the unconvinced"
2023-07-04 12:35:04 -0400 < Zipheir> Tell them "it's just like a monad". I'm sure that explanation would appeal to the kind of people who hate syntax case. :)
2023-07-04 12:36:08 -0400 < Zipheir> (I'm only half-joking. If you know some monadic programming, syntax-case macros look rather familiar.)
2023-07-04 12:37:59 -0400 < sham1> So syntax-case is a burrito
2023-07-04 12:49:29 -0400 < Zipheir> It needs to be looked into more carefully. #' is very much like 'pure', but I don't know what 'join' on syntax objects would be.
2023-07-04 12:50:00 -0400 < sham1> How about bind
2023-07-04 12:51:57 -0400 < Zipheir> Oh, 'bind' is inessential. If you have pure & join or definitions for Kleisli composition, you can derive 'bind' for free.
2023-07-04 12:53:00 -0400 < sham1> But as Haskell has shown us, sometimes bind is easier to do, and you can derive join for free as well if you have pure and bind
2023-07-04 12:53:46 -0400 < Zipheir> True.
2023-07-04 12:55:59 -0400 < Zipheir> (lambda (x f) (f (syntax->datum x))) has a very bind-y feel to it, assuming f returns a syntax object.
2023-07-04 16:27:46 -0400 < amirouche> epub ftw!
2023-07-04 16:28:46 -0400 < amirouche> I read the last essay of pg with epub, the essay is very good imo
2023-07-04 16:29:03 -0400 < amirouche> And I may revisit bel for that reason
2023-07-04 16:29:19 -0400 < amirouche> when I am president of UN
2023-07-04 16:36:10 -0400 < dpk> https://ideolalia.com/essays/thought-leaders-and-chicken-sexers.html is probably the definitive deconstruction of the Paul Graham mindset
2023-07-04 16:37:33 -0400 < sham1> The title alone is intriguing
2023-07-04 16:42:56 -0400 < dpk> or perhaps more charitably, Mycroft Holmes in the words of Sherlock:
2023-07-04 16:43:02 -0400 < dpk> > he has no ambition and no energy. He will not even go out of his way to verify his own solutions, and would rather be considered wrong than take the trouble to prove himself right. Again and again I have taken a problem to him, and have received an explanation which has afterwards proved to be the correct one. And yet he was absolutely incapable of working out the practical points.
2023-07-04 18:02:14 -0400 < lechner> Hi, sorry about a beginner question. How do I evaluate a quoted sexp, please?
2023-07-04 18:02:41 -0400 < lechner> is it 'read'?
2023-07-04 18:08:41 -0400 < Zipheir> lechner: eval
2023-07-04 18:08:53 -0400 < Zipheir> But beware of eval!
2023-07-04 18:11:10 -0400 < lechner> do alternatives exist?
2023-07-04 18:14:42 -0400 < Zambyte> lechner: What features do you want / not want from eval?
2023-07-04 18:16:19 -0400 < Zipheir> lechner: The dangers are inherent in evaluating an arbitrary S-exp. You can mitigate them a bit by passing an environment to eval.
2023-07-04 18:16:39 -0400 < Zipheir> See e.g. https://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-17.html#node_idx_1266
2023-07-04 18:20:59 -0400 < Zambyte> At least R5RS and up requires an environment to evaluate in - so it's not really an option to mitigate the dangers (at least by the standards)
2023-07-04 18:28:08 -0400 < Zipheir> The amount of safety depends on what environment you pass, I guess.
2023-07-04 18:43:36 -0400 < mwnaylor> Is there place where I can download SRFIs? I am exploring Scheme (Chicken dialect) and need a local copy of the module docmumentation. I don't always have access to the internet with my laptop.
2023-07-04 18:51:55 -0400 < lechner> mwnaylor / there are PDFs like      https://srfi.schemers.org/srfi-67/srfi-67.pdf
2023-07-04 18:55:36 -0400 < lechner> Zipheir / Zambyte / As an exploration, I am rewriting a logic resembling 'make' in Scheme and currently specify recipes via quoted sexps.
2023-07-04 18:55:42 -0400 < Zambyte> It seems like that is not included for all SRFIs (I tried that for SRFI-111 and it didn't exist). For those that don't have the PDF, you could clone the git repo for them like this https://github.com/scheme-requests-for-implementation/srfi-111
2023-07-04 18:56:23 -0400 < Zambyte> lechner: so you want to read build targets from a file and evaluate them?
2023-07-04 18:57:57 -0400 < Zambyte> In that case you wouldn't have to quote them - as read returns an S-exp directly
2023-07-04 18:58:11 -0400 < Zambyte> then you could pass that to eval with an environment that makes sense for your application
2023-07-04 19:12:51 -0400 < Zipheir> mwnaylor: Every SRFI has a git repository under https://github.com/scheme-requests-for-implementation
2023-07-04 19:13:32 -0400 < skeemer> how do srfi work? i am using chicken... and i thought that they were extending the basic scheme language by adding functionslities
2023-07-04 19:13:51 -0400 < Zipheir> mwnaylor: It should work to clone github.com/scheme-requests-for-implementation/srfi-<number> in every case.
2023-07-04 19:14:00 -0400 < skeemer> and i expected that in order to add functionality from a certain srfi i would have done something like (import srfi-5) or something like that
2023-07-04 19:14:09 -0400 < Zipheir> skeemer: Pretty much, yes.
2023-07-04 19:14:21 -0400 < skeemer> but actually i saw that in chicken scheme many functionalities are already in the language without needing to include them
2023-07-04 19:14:22 -0400 < skeemer> why ?
2023-07-04 19:14:23 -0400 < Zipheir> skeemer: You'll have to install the library first.
2023-07-04 19:14:31 -0400 < skeemer> t.ex. srfi-1 and srfi-0
2023-07-04 19:14:49 -0400 < skeemer> srfi-0 is about cond-expand and it is built in without needing to import anything
2023-07-04 19:14:52 -0400 < skeemer> why is that ?
2023-07-04 19:15:06 -0400 < Zipheir> skeemer: Some people build SRFIs into the implementation (cond-expand *has* to be built in).
2023-07-04 19:15:17 -0400 < Zipheir> skeemer: cond-expand is meta-Scheme.
2023-07-04 19:15:54 -0400 < skeemer> how do i know which srfi are built in in the implementation and which i can import with an (import) ?
2023-07-04 19:16:15 -0400 < skeemer> i mean also this one https://srfi.schemers.org/srfi-23/srfi-23.html seems built in
2023-07-04 19:16:18 -0400 < skeemer> is the error directive
2023-07-04 19:16:27 -0400 < Zipheir> skeemer: Read http://wiki.call-cc.org/man/5/Included%20modules
2023-07-04 19:17:27 -0400 < Zipheir> IIRC, Chicken only imports (scheme) and (chicken base) by default.
2023-07-04 19:17:50 -0400 < skeemer> Zipheir, ok but i see no mention to srfi here
2023-07-04 19:17:56 -0400 < skeemer> what is scheme and what is chicken base ?
2023-07-04 19:18:00 -0400 < skeemer> which srfi are imported ?
2023-07-04 19:18:49 -0400 < Zipheir> (scheme) is just the basic R5RS definitions. (chicken base) provides CHICKEN's basic extensions to that, and a number of random helpful things.
2023-07-04 19:19:16 -0400 < Zipheir> skeemer: No SRFIs are imported by default. Most are eggs; I think (srfi 4) is the exception.
2023-07-04 19:19:26 -0400 < lechner> Zambyte / that's an interesting thought! For now, I am just playing around with thirty years of make frustrations
2023-07-04 19:19:37 -0400 < Zipheir> Well, (chicken condition) is basically SRFI 35.
2023-07-04 19:20:14 -0400 < Zipheir> skeemer: Even the ubiquitous SRFI 1 has to built and imported.
2023-07-04 19:20:17 -0400 < skeemer> Zipheir what is the difference between this: (import scheme chicken.format chicken.process-context) and this  (import scheme (chicken base))
2023-07-04 19:20:21 -0400 < Zipheir> *has to be built
2023-07-04 19:20:28 -0400 < skeemer> i mean why in the other one we have another level of indentation
2023-07-04 19:20:46 -0400 < Zipheir> skeemer: Because CHICKEN only recently started supporting names-as-lists.
2023-07-04 19:20:56 -0400 < skeemer> Zipheir, we have to explictly importing srfi-1?
2023-07-04 19:21:00 -0400 < Zipheir> Yes.
2023-07-04 19:21:12 -0400 < skeemer> ok so i am still confused, how do i know which ones are built in and which i have to explicitly import ?
2023-07-04 19:21:51 -0400 < Zipheir> skeemer: Again, CHICKEN doesn't import anything by default except scheme and (chicken base).
2023-07-04 19:22:22 -0400 < Zipheir> I don't know if csi provides a way to list all current imports.
2023-07-04 19:22:48 -0400 < Zipheir> skeemer: You may want to look at http://wiki.call-cc.org/man/5/Using%20the%20interpreter
2023-07-04 19:25:45 -0400 < skeemer> Zipheir, yeah but the question is what srfi does "scheme" and "chicken base" include
2023-07-04 19:27:24 -0400 < Zipheir> skeemer: They don't include any SRFI "submodules". (chicken base) provides some things described by SRFIs, like case-lambda (SRFI 16). You can look at the docs: https://wiki.call-cc.org/man/5/Module%20(chicken%20base)
2023-07-04 19:28:03 -0400 < Zipheir> There is also some overlap in functionality. (chicken base) has 'foldl' and 'foldr', but they're quite different from SRFI 1's 'fold' and 'fold-right'.
2023-07-04 19:28:20 -0400 < skeemer> Zipheir, even if they don't include explicitly submodules mentioning srfi, they implement some of the SRFI as you said
2023-07-04 19:28:25 -0400 < Zipheir> Yes.
2023-07-04 19:28:36 -0400 < skeemer> so somewhere there should be written which srfi are implemented and which have not been implemented right ?
2023-07-04 19:29:16 -0400 < Zipheir> skeemer: Take a look at https://wiki.call-cc.org/supported-standards
2023-07-04 19:30:06 -0400 < siiky[m]> https://wiki.call-cc.org/man/5/Extensions%20to%20the%20standard#cond-expand
2023-07-04 19:31:17 -0400 < skeemer> ok and these are contained in the "scheme" module right?
2023-07-04 19:31:22 -0400 < skeemer> or both scheme/chicken base
2023-07-04 19:32:36 -0400 < Zipheir> I think most of what appears in https://wiki.call-cc.org/supported-standards#srfis is implemented above the module level. You can't import cond-expand or multi-line comments, for example.
2023-07-04 19:33:08 -0400 < Zipheir> Although 'receive' is definitely from (chicken base). It's not perfect documentation.
2023-07-04 19:33:58 -0400 < skeemer> Zipheir, thanks
2023-07-04 19:34:07 -0400 < siiky[m]> the SRFI links in that "supported standards" page link to the corresponding CHICKEN modules (e.g. SRFI 8 (receive) links to (chicken base))
2023-07-04 19:34:08 -0400 < skeemer> also i still don't understand the syntax of import in chicken
2023-07-04 19:34:24 -0400 < skeemer> so (import scheme) and (import (chicken io))
2023-07-04 19:34:28 -0400 < Zipheir> siiky[m]: Ah, true.
2023-07-04 19:34:54 -0400 < Zipheir> skeemer: Yes. You can always wrap the single-symbol library names in parens, e.g. (import (scheme)), if you like.
2023-07-04 19:35:35 -0400 < Zipheir> Perhaps more confusingly, (import (srfi n)) and (import srfi-n) are equivalent in CHICKEN 5.
2023-07-04 19:35:51 -0400 < Zipheir> (But *not* srfi.n)
2023-07-04 19:36:15 -0400 < siiky[m]> those are implementation details I belive
2023-07-04 19:36:16 -0400 < skeemer> Zipheir, ok but then why would one do something like this ? " (import scheme (chicken base))"
2023-07-04 19:36:30 -0400 < siiky[m]> same as (import (chicken base)) being the same as (import chicken.base)
2023-07-04 19:36:30 -0400 < skeemer> why scheme is without parens and chicken and base under the same parents?
2023-07-04 19:36:55 -0400 < skeemer> siiky[m], ohh ok
2023-07-04 19:37:08 -0400 < Zipheir> skeemer: Library names are S-expressions. What is an S-expression?
2023-07-04 19:37:44 -0400 < skeemer> so (import scheme (chicken io base)) means import scheme, import chicken.io.base ?
2023-07-04 19:38:19 -0400 < Zipheir> Forget the periods. That's just old CHICKEN compatibility stuff.
2023-07-04 19:38:26 -0400 < skeemer> so one could also do (import scheme (chicken io) (chicken xyz))
2023-07-04 19:38:41 -0400 < skeemer> which would mean import scheme, import chicken.io and import chicken.xyz
2023-07-04 19:38:47 -0400 < Zipheir> (chicken io base) and (chicken library full of important stuff) are both valid names.
2023-07-04 19:38:52 -0400 < skeemer> now i am using the dot as a kind of python/java way to mention the libs
2023-07-04 19:39:33 -0400 < Zipheir> If the dotted names feel right, you can use them--in CHICKEN, at least.
2023-07-04 19:39:43 -0400 < skeemer> yes but (chicken io base) refers to the module base contained in the module io contained in the module chicken so it is the equivalent of java chicken.io.base
2023-07-04 19:39:47 -0400 < skeemer> correct me if i am wrong
2023-07-04 19:39:52 -0400 < skeemer> i am not keen on the dot syntax
2023-07-04 19:39:59 -0400 < skeemer> just trying to understand the logic of importing
2023-07-04 19:40:05 -0400 < skeemer> in chicken since i am a newbie
2023-07-04 19:40:07 -0400 < skeemer> and reading TLS
2023-07-04 19:40:13 -0400 < skeemer> but no import up to now
2023-07-04 19:40:22 -0400 < Zipheir> "(chicken io base) refers to the module base contained in the module io ...": Not necessarily.
2023-07-04 19:40:58 -0400 < Zipheir> CHICKEN is an R5RS+ implementation, so its module system isn't necessarily going to conform to R6RS or R7RS.
2023-07-04 19:41:26 -0400 < skeemer> ohh ok now i am confused again ahaha
2023-07-04 19:41:29 -0400 < skeemer> i thought i understood
2023-07-04 19:41:52 -0400 < Zipheir> skeemer: According to R7RS-small, library names are just names. They don't necessarily indicate a library hierarchy.
2023-07-04 19:42:08 -0400 < siiky[m]> I think Zipheir means that chicken.io.base is not necessarily a submodule of chicken.io; it's just a name
2023-07-04 19:42:25 -0400 < siiky[m]> (but I'm also not sure about that xP)
2023-07-04 19:42:29 -0400 < skeemer> ok ok
2023-07-04 19:42:29 -0400 < Zipheir> Yes.
2023-07-04 19:42:55 -0400 < skeemer> so i can basically name my module (x y z randommodule)
2023-07-04 19:43:02 -0400 < Zipheir> Yes.
2023-07-04 19:43:07 -0400 < skeemer> and this does not mean it has to be a submodule of z, y, x
2023-07-04 19:43:17 -0400 < Zipheir> (scheme ...) and (srfi ...) names are reserved per R7RS-small.
2023-07-04 19:43:18 -0400 < siiky[m]> and just to avoid possible future confusion, because I don't know where/how you came up with chicken.io.base: there are the (chicken io) and (chicken base) modules, but there's no (chicken io base) module
2023-07-04 19:43:22 -0400 < Zipheir> Otherwise it's up to you.
2023-07-04 19:43:29 -0400 < skeemer> ok but what's the best practice here ? i mean i still guess that we want to keep a kind of hierarchy anyway when we write to keep thing sclean
2023-07-04 19:43:55 -0400 < Zipheir> Oh, I absolutely agree.
2023-07-04 19:43:58 -0400 < skeemer> siiky[m], yeah i know sorry it waas just for the sake of the example
2023-07-04 19:44:14 -0400 < skeemer> ok Zipheir thanks
2023-07-04 19:44:40 -0400 < skeemer> so i wonder why designers did not enforce this thing about submodules, but anyway good enough at least now i have a basic idea
2023-07-04 19:44:46 -0400 < siiky[m]> my best practice with best practices is to ignore best practices :p
2023-07-04 19:44:47 -0400 < skeemer> thanks a lot for your help
2023-07-04 19:44:52 -0400 < Zipheir> skeemer: Note that R6RS has a much more detailed spec for libraries. https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_chap_7
2023-07-04 19:45:20 -0400 < skeemer> Zipheir, i don't know what's the relation between RxRS and srfi still
2023-07-04 19:45:32 -0400 < skeemer> i don't have a precise idea about what an RxRS is
2023-07-04 19:45:32 -0400 < Zipheir> It's worse than that with CHICKEN, where you can't really have private submodules of public libraries.
2023-07-04 19:45:41 -0400 < skeemer> i am reading TLS and these things are not mentioned
2023-07-04 19:45:55 -0400 < skeemer> Zipheir, which scheme implementation do you use ?
2023-07-04 19:45:59 -0400 < Zipheir> skeemer: The RnRS reports are the closest thing Scheme has to standards.
2023-07-04 19:46:01 -0400 < skeemer> just out of curiosity
2023-07-04 19:46:19 -0400 < siiky[m]> I think of Scheme modules as Elixir modules, they're just a name, the hierarchy is an illusion and not enforced by the compiler/VM
2023-07-04 19:46:23 -0400 < skeemer> Zipheir, i thought srfi were standards also but for extended functionality
2023-07-04 19:46:28 -0400 < Zipheir> CHICKEN or Chez. CHICKEN's still got some of the best library support.
2023-07-04 19:46:40 -0400 < skeemer> ohh ok so RxRS defines the "common functionality" while srfi the extra on top of that right ?
2023-07-04 19:46:49 -0400 < Zipheir> skeemer: SRFIs aren't standards. They're like RFCs.
2023-07-04 19:47:04 -0400 < skeemer> Zipheir, ok but what's the relationship ?
2023-07-04 19:47:20 -0400 < skeemer> so srfi are an extension on top of the RxRS standards?
2023-07-04 19:47:23 -0400 < Zipheir> Yes.
2023-07-04 19:47:34 -0400 < skeemer> and what standard should i try to use nowadays ?
2023-07-04 19:47:39 -0400 < skeemer> the latest ?
2023-07-04 19:47:46 -0400 < Zipheir> Some are portable to any of the RnRS standards, but others extend a specific RnRS.
2023-07-04 19:48:00 -0400 < skeemer> Zipheir, ohh ok useful to know
2023-07-04 19:48:10 -0400 < skeemer> is there any book which explains these things about scheme ?
2023-07-04 19:48:18 -0400 < Zipheir> skeemer: That's a controversial question :) R6RS and R7RS different camps, but they may be reuniting.
2023-07-04 19:48:19 -0400 < skeemer> since TLS focuses more on concepts than Scheme per se
2023-07-04 19:48:37 -0400 < Zipheir> *are different camps
2023-07-04 19:48:49 -0400 < skeemer> Zipheir, how reuniting ?
2023-07-04 19:49:15 -0400 < Zipheir> skeemer: This is an OK summary of what happened with the standards https://en.wikipedia.org/wiki/Scheme_(programming_language)#History
2023-07-04 19:50:17 -0400 < Zipheir> skeemer: The current goal is to make R7RS compatible with R6RS.
2023-07-04 19:50:17 -0400 < skeemer> Zipheir, what do you use with chez for installing packages ? Akku ?
2023-07-04 19:51:13 -0400 < Zipheir> skeemer: I've been doing it manually, cloning libraries into a lib/chez directory. It's not optimal.
2023-07-04 19:51:46 -0400 < skeemer> Zipheir, this is something i always wondered, same thing with gambit or gerbil i wanted to try theme
2023-07-04 19:52:04 -0400 < skeemer> but it's discouraging that they don't have good tools for package management
2023-07-04 19:52:27 -0400 < Zipheir> Yeah, it's a general problem with Scheme implementations.
2023-07-04 19:53:15 -0400 < Zipheir> But, as you saw, with library names so up in the air, we're a long way from a standard Scheme package manager.
2023-07-04 19:54:14 -0400 < Zipheir> Well, Lassi has been working on a portable tool for importing SRFI implementations: https://github.com/scheme-requests-for-implementation/srfi-common/tree/master/srfi-tools
2023-07-04 19:55:30 -0400 < Zipheir> At least we're getting to the point where most Schemes *have* modules/libraries. The exceptions are some of the R5RS impls.
2023-07-04 19:55:51 -0400 < Zipheir> And R4RS. Can't forget s9fes!
2023-07-04 19:56:13 -0400 < skeemer> what is s9fes?
2023-07-04 19:56:34 -0400 < skeemer> Zipheir, if somebody would like to start implementing real stuff which scheme implementation would you recommend ?
2023-07-04 19:58:13 -0400 < Zipheir> Dodging the question of what "real stuff" is, I'd say Racket, Chez (with chez-srfi and thunderchez), Guile, or CHICKEN, in no order.
2023-07-04 19:59:00 -0400 < Zipheir> Oh, s9fes is a small interpreter-only implementation. In terms of programming style, at least, it may be about the best interpreter out there.
2023-07-04 19:59:02 -0400 < skeemer> Zipheir, well racket is not really a scheme right
2023-07-04 19:59:29 -0400 < skeemer> what makes s9fes so special?
2023-07-04 19:59:37 -0400 < Zipheir> With #!r6rs it is.
2023-07-04 20:00:19 -0400 < Zipheir> s9fes is very simple and cleanly written: http://www.t3x.org/s9fes/
2023-07-04 20:00:39 -0400 < Zipheir> Well, "simple" for a working R4RS Scheme interpreter.
2023-07-04 20:02:22 -0400 < skeemer> Zipheir, thanks for all the useful info
2023-07-04 20:02:31 -0400 < Zipheir> It's probably most interesting as an educational example, since it lacks modules and hygienic macros.
2023-07-04 20:02:50 -0400 < skeemer> my plan now is to finish TLS i am half way through it
2023-07-04 20:02:56 -0400 < skeemer> then i will do the seasoned schemer
2023-07-04 20:03:00 -0400 < skeemer> and then the reasoned schemer
2023-07-04 20:03:05 -0400 < skeemer> that's the plan
2023-07-04 20:03:16 -0400 < Zipheir> Cool. The Reasoned Schemer is my favorite.
2023-07-04 20:10:31 -0400 < skeemer> really?
2023-07-04 20:10:34 -0400 < skeemer> why?
2023-07-04 20:10:56 -0400 < skeemer> i am excited for the The Little Learner
2023-07-04 20:11:09 -0400 < skeemer> would like to do something with machine learning in scheme
2023-07-04 20:12:01 -0400 < skeemer> also i considered that in case i get bored with scheme lack of ecosystem, the skills from The Little Schemer series should be transferable to clojure and common lisp right ?
2023-07-04 20:12:35 -0400 < Zipheir> TRS is the most elegant book on logic programming I've seen.
2023-07-04 20:12:44 -0400 < skeemer> how cool
2023-07-04 20:12:52 -0400 < skeemer> logic programming so stuff like prolog right?
2023-07-04 20:12:53 -0400 < Zipheir> Skills always transfer.
2023-07-04 20:13:12 -0400 < Zipheir> Yes. miniKanren has most of the good stuff from Prolog (no cut, fortunately).
2023-07-04 20:15:39 -0400 < skeemer> what do you mean by "no cut" ?
2023-07-04 20:17:22 -0400 < Zipheir> It's a long story if you haven't done some logic programming already. Cut is a side-effecting operator that makes a logic program illogical, you might say.
2023-07-04 20:18:08 -0400 < Zipheir> It's just about essential to practical Prolog programming, but more recent logic languages have ways around it.
2023-07-04 20:18:38 -0400 < Zipheir> miniKanren's 'conda' is an example. But anyway.
2023-07-04 20:30:08 -0400 -!- HerlockSholmes0 is now known as HerlockSholmes
2023-07-04 20:30:29 -0400 -!- brettgilio9 is now known as brettgilio
2023-07-04 21:06:54 -0400 < mwnaylor>  Zipheir: I'll look into the cloning. Seems a bit of work, but I guess I only need to clone the ones that the Chicken Manual reports as being implemented.
2023-07-04 21:17:40 -0400 < Zipheir> mwnaylor: If those are all you need, you could set up chicken-doc. https://api.call-cc.org/5/doc/chicken-doc  I found it a bit difficult to keep updated.
--- Day changed Wed Jul 05 2023
2023-07-05 04:35:22 -0400 < skeemer> what is the advantage of having symbols wrt only strings?
2023-07-05 04:36:10 -0400 < ecraven> two symbols that are written the same way are always identical
2023-07-05 04:38:56 -0400 < sham1> You *could* make it so that strings are also interned, although since symbols are usually short while strings can become as big as they wish, they're usually better off interned. And of course strings are mutable
2023-07-05 04:40:16 -0400 < ecraven> in Scheme, that's about the only difference.. in other Lisps, things are more complicated
2023-07-05 04:41:16 -0400 < wasamasa> symbols allow you to refer to identifiers/names
2023-07-05 04:45:02 -0400 < wasamasa> this is a pretty important part of SICP, to do symbolic computation
2023-07-05 04:45:39 -0400 < ecraven> wasamasa: but if strings were interned and immutable, as sham1 says, there'd be close to no difference, right?
2023-07-05 04:45:48 -0400 < wasamasa> welcome to picolisp
2023-07-05 04:46:01 -0400 < wasamasa> and lua I guess
2023-07-05 04:46:15 -0400 < sham1> Well, you'd need some kind of a conceptual differentiation at least if you do (read) because of course a string would correspond to a string literal
2023-07-05 04:46:51 -0400 < wasamasa> > PicoLisp has no special string type. Instead, symbols are used. Syntactically, "transient" symbols resemble strings in other languages. Also, there is no separate character type. Instead, characters are represented by strings of length 1 (using 1 .. 3 bytes (UTF-8)).
2023-07-05 04:46:52 -0400 < ecraven> just read everything as a string, and only print things that won't print nicely as symbols as strings :P
2023-07-05 04:47:13 -0400 < ecraven> 3 bytes is not enough though.
2023-07-05 04:47:38 -0400 < sham1> Maybe 1 .. 3 in this case is over-exclusive
2023-07-05 04:47:43 -0400 < sham1> So it also includes 4
2023-07-05 04:47:45 -0400 < wasamasa> interestingly enough this means that in picolisp, strings can be chopped up with list processing procedures
2023-07-05 04:48:08 -0400 < wasamasa> the picolisp people explicitly embrace hacks
2023-07-05 04:48:20 -0400 < wasamasa> if you hold it wrong, you cut yourself
2023-07-05 04:48:29 -0400 < wasamasa> segfaults are not considered bugs
2023-07-05 04:48:34 -0400 < sham1> Well the implementation is smol
2023-07-05 04:49:11 -0400 < wasamasa> fast, too
2023-07-05 04:49:14 -0400 < wasamasa> there's like, 3 types
2023-07-05 04:49:31 -0400 < wasamasa> fixnum, symbol, cons
2023-07-05 04:50:04 -0400 < sham1> Do they use the symbol nil to designate the end of a list
2023-07-05 04:50:30 -0400 < wasamasa> of course
2023-07-05 04:50:51 -0400 < sham1> And is that also the falsy value?
2023-07-05 04:50:53 -0400 < wasamasa> yes
2023-07-05 04:50:57 -0400 < sham1> hm
2023-07-05 04:51:04 -0400 < sham1> Makes sense
2023-07-05 04:51:19 -0400 < wasamasa> the author does consider some scheme things unnecessary and inefficient to implement in an interpreter-only design
2023-07-05 04:51:31 -0400 < sham1> Macros probably
2023-07-05 04:51:34 -0400 < wasamasa> like tail recursion for example or actual closures
2023-07-05 04:51:38 -0400 < sham1> Or at least hygiene
2023-07-05 04:51:40 -0400 < wasamasa> instead of macros, there's fexprs
2023-07-05 04:51:44 -0400 < sham1> ew
2023-07-05 04:52:05 -0400 < wasamasa> closures can be faked in both immutable and mutable versions
2023-07-05 07:12:18 -0400 < skeemer> people is there anything in chicken as "check-expect" i want to do simple tests
2023-07-05 07:12:53 -0400 < rgherdt> skeemer: http://wiki.call-cc.org/eggref/5/test
2023-07-05 07:12:59 -0400 < skeemer> also can i insert tests in the same file i am developing the functions ?
2023-07-05 07:13:02 -0400 < skeemer> like in racket ?
2023-07-05 07:15:32 -0400 < rgherdt> good point, I never tried, but I guess it should work. It's not usual though, tests in chicken are conventionally in a separate tests/run.scm
2023-07-05 07:15:55 -0400 < rgherdt> for chicken related questions I suggest you asking at #chicken
2023-07-05 07:16:53 -0400 < rgherdt> a portable test suite is offered by srfi-64
2023-07-05 09:03:07 -0400 < skeemer> rgherdt, i tried the link you sent but i have an error when i try to import test
2023-07-05 09:03:28 -0400 < skeemer> => Error: (import) "during expansion of (import ...) - cannot import from undefined module": (test)
2023-07-05 09:03:35 -0400 < skeemer> i am using geiser
2023-07-05 09:09:02 -0400 < rgherdt> did you install the corresponding egg?
2023-07-05 09:09:21 -0400 < rgherdt> chicken-install test
2023-07-05 11:08:27 -0400 < dpk> jcowan: more precedent for exposing SRFI 115 internals https://blog.burntsushi.net/regex-internals/
2023-07-05 11:21:49 -0400 < jackdaniel> is there a comprehensive comparison of different scheme standard versions and a cross section that enlists support among implementations?
2023-07-05 11:27:47 -0400 < wasamasa> jcowan: what happened to your scheme survey tables, did you move them off bitbucket to some new home?
2023-07-05 11:28:02 -0400 < wasamasa> jackdaniel: ^ could actually fulfill that need, otherwise the scheme wiki
2023-07-05 11:30:01 -0400 < jackdaniel> I see, thanks
2023-07-05 11:31:04 -0400 < wasamasa> there is this website for SRFI support across implementations: https://docs.scheme.org/srfi/support/
2023-07-05 11:32:56 -0400 < jackdaniel> srfi are proposals for inclusions in the r7rs?
2023-07-05 11:32:56 -0400 < wasamasa> http://community.schemewiki.org/?scheme-faq-standards#implementations has a list of implementations and whether they support r7rs
2023-07-05 11:33:04 -0400 < wasamasa> no, they're like CDRs
2023-07-05 11:34:27 -0400 < wasamasa> proposals for implementation
2023-07-05 11:40:55 -0400 < jackdaniel> I see
2023-07-05 11:43:52 -0400 < jackdaniel> the last link (the FAQ, hah!) has nice answers for a few next questions I had
2023-07-05 11:43:59 -0400 < jackdaniel> so doubly thanks :)
2023-07-05 11:48:42 -0400 < Zipheir> jackdaniel: Take a look at the SRFI About page, too. https://srfi.schemers.org/about.html
2023-07-05 12:03:28 -0400 < lechner> Hi, which popular Scheme implementations have the best and worst error reporting, respectively, please?
2023-07-05 12:04:04 -0400 < wasamasa> stalin is the worst for sure, best, no idea
2023-07-05 12:04:26 -0400 < dpk> all of them are pretty terrible, to be honest
2023-07-05 12:04:39 -0400 < wasamasa> yeah, but stalin's fuck-up procedure takes the cake
2023-07-05 12:05:21 -0400 < wasamasa> granted, I do like the idea for assertions, but not for error reporting in general
2023-07-05 12:07:30 -0400 < wasamasa> oh wait, you said popular
2023-07-05 12:07:38 -0400 < wasamasa> I really hate guile's error reporting
2023-07-05 12:07:43 -0400 < lechner> me too
2023-07-05 12:08:01 -0400 < lechner> is there one that's better, though?
2023-07-05 12:08:55 -0400 < wasamasa> I mostly use CHICKEN and while I do not like the idea of a fixed-size call trace, I at least don't see useless innards in them
2023-07-05 12:08:59 -0400 < wasamasa> so that's an improvement
2023-07-05 12:09:55 -0400 < wasamasa> kawa's backtraces are kinda reminiscent of clojure in terms of verbosity and innards showing up
2023-07-05 12:10:09 -0400 < wasamasa> still found them easier to figure out than with guile
2023-07-05 12:10:43 -0400 < lechner> okay, thanks!
2023-07-05 12:10:59 -0400 < wasamasa> cannot really comment on the rest of the bunch
2023-07-05 12:11:21 -0400 < wasamasa> but you'll do yourself a favor by writing code that doesn't use lists for literally anything
2023-07-05 12:11:36 -0400 < wasamasa> and adding assertions for invariants
2023-07-05 12:11:51 -0400 < lechner> isn't the issue more with quoting. i thought that's why there are no line numbers
2023-07-05 12:12:10 -0400 < wasamasa> racket does actually get line numbers right
2023-07-05 12:12:20 -0400 < lechner> that's good
2023-07-05 12:12:35 -0400 < wasamasa> it's a non-trivial problem in a language with macros
2023-07-05 12:12:47 -0400 < lechner> yeah, i get it
2023-07-05 12:13:03 -0400 < lechner> but otherwise scheme is pretty simple, isn't it?
2023-07-05 12:13:13 -0400 < lechner> to implement, that is
2023-07-05 12:13:28 -0400 < wasamasa> in comparison with what?
2023-07-05 12:13:39 -0400 < wasamasa> and what subset?
2023-07-05 12:13:47 -0400 < lechner> rust or so
2023-07-05 12:14:10 -0400 < wasamasa> well, yeah, but with rust there is one blessed implementation and lots of people working on the hard parts (such as error reporting)
2023-07-05 12:14:23 -0400 < lechner> okay, thanks!
2023-07-05 12:15:03 -0400 < lechner> Hi, is     (apply func A B list)      the same as       (apply func (cons* A B list))     ?
2023-07-05 12:15:11 -0400 < lechner> list being a list
2023-07-05 12:15:50 -0400 < lechner> more like     (apply func A B '(C D))      the same as       (apply func (cons* A B '(C D)))     ?
2023-07-05 12:16:13 -0400 < lechner> and that would be in Guile, with cons*
2023-07-05 12:17:43 -0400 < Zambyte> lechner: yes
2023-07-05 12:18:54 -0400 < lechner> thanks!
2023-07-05 12:21:19 -0400 < Zambyte> To be clear, the way that R7RS puts it is as follows: (apply proc arg1 ... args) - The apply procedure calls proc with the elements of the list (append (list arg1 ...) args) as the actual arguments.
2023-07-05 12:21:30 -0400 < Zambyte> Which is basically what you described :)
2023-07-05 12:22:10 -0400 < lechner> Okay, thanks! It does not look that intuitive the first time around, but makes sense
2023-07-05 12:24:09 -0400 < lechner> Okay, here is another question that may invite some disagreement. Which free software implementation of Scheme, please, is the most user-friendly for people starting out. I don't mean REPL or graphical environment, I just meant in terms of quirks or warts (including poor error reporting)
2023-07-05 12:24:26 -0400 < wasamasa> racket
2023-07-05 12:24:29 -0400 < Zipheir> cons* isn't in the reports (it's from SRFI 1), so that's the clearest standard way to express it.
2023-07-05 12:24:45 -0400 < Zipheir> Probably Racket, indeed.
2023-07-05 12:25:05 -0400 < wasamasa> for starters, it works on windows out of the box
2023-07-05 12:25:14 -0400 < lechner> okay, thanks
2023-07-05 12:25:22 -0400 < lechner> is there a build system written in scheme?
2023-07-05 12:25:30 -0400 < wasamasa> several probably
2023-07-05 12:26:04 -0400 < wasamasa> I remember porting the make egg to C5 and discovering it was probably a waste of time (due to the declarative build system obsoleting it essentially)
2023-07-05 12:26:22 -0400 < lechner> which declarative build system, please?
2023-07-05 12:26:37 -0400 < wasamasa> https://wiki.call-cc.org/man/5/Egg%20specification%20format
2023-07-05 12:27:21 -0400 < Zambyte> lechner: My approach for quality error reporting is to target R7RS as much as I can, and break non-standard code into separate libraries. That way I can try different implementations and get the same error reported many different ways
2023-07-05 12:27:22 -0400 < Zipheir> make
2023-07-05 12:27:25 -0400 < wasamasa> in C4, eggs used to do things in a procedural style, which gave great flexibility
2023-07-05 12:27:54 -0400 < wasamasa> as of C5, this was revamped to a declarative system that handles tricky stuff like cross-compilation and static linking automatically
2023-07-05 12:27:57 -0400 < Zipheir> lechner: Don't take anyone's word for it. You'll have to try things and see what you like.
2023-07-05 12:28:24 -0400 < wasamasa> but I do recall a previous discussion with lechner where the expectation was that "a build system" means a general-purpose one
2023-07-05 12:28:41 -0400 < Zambyte> I usually target some mix of Guile, Kawa, Gauche, Chibi, Cyclone, etc :P
2023-07-05 12:28:57 -0400 < lechner> wasamasa / you have amazing memory!
2023-07-05 12:29:01 -0400 < lechner> actually, i do not mean build system for scheme. i mean rewriting autoconf and friends in Scheme instead of M4
2023-07-05 12:29:21 -0400 < Zipheir> Who needs that? We have autotools.
2023-07-05 12:29:24 -0400 < wasamasa> I mean, if you're into masochism
2023-07-05 12:29:26 -0400 < wasamasa> why not
2023-07-05 12:29:30 -0400 < wasamasa> knock yourself out
2023-07-05 12:29:40 -0400 < Zipheir> They're ugly, but they work. Putting them into Scheme wouldn't make them any less ugly.
2023-07-05 12:29:53 -0400 < wasamasa> yeah, they're ugly because of inherent complexity
2023-07-05 12:30:04 -0400 < wasamasa> and most devs do not really understand them and the problems they solve
2023-07-05 12:30:21 -0400 < wasamasa> parallel make builds breaking would be an example
2023-07-05 12:31:19 -0400 < wasamasa> lol: https://github.com/spk121/potato-make
2023-07-05 12:31:45 -0400 < wasamasa> I guess this is the equivalent of using POSIX make, but in s-expression form
2023-07-05 12:36:59 -0400 < lechner> with Linux dominating in its space, i am not sure we still need the full autoconf suite, but we may have reached the end of M4's road. many people are still on 2.69, which came out eleven years ago. even the maintainers have trouble with underquoting     https://developers.redhat.com/blog/2023/02/23/autoconf-272-broke-my-build-how-do-i-fix-it
2023-07-05 12:38:22 -0400 < wasamasa> I guess http://www.laputan.org/mud/mud.html#Reconstruction applies
2023-07-05 12:38:24 -0400 < lechner> wasamasa / thanks for the pointer to potato-make
2023-07-05 12:40:38 -0400 < jcowan> wasamasa: Yes, docs.schemers.org/surveys is derived from my surveys
2023-07-05 12:41:06 -0400 < wasamasa> ah, thanks
2023-07-05 12:42:06 -0400 < lechner> Hi, do any Scheme implementations compile to WASM (aside from Guile, which is pending via Hoot)?
2023-07-05 12:43:05 -0400 < wasamasa> jcowan: do you take any contributions, like a survey for implemented standards?
2023-07-05 12:44:18 -0400 < jcowan> I would, except that Lassi designed the process that builds the HTML out of github, and he didn't explain to me how to do it (or I have forgotten, whichever)
2023-07-05 12:44:28 -0400 < wasamasa> hah
2023-07-05 12:45:01 -0400 < wasamasa> so I guess it involves this repo: https://github.com/schemedoc/surveys
2023-07-05 12:45:12 -0400 < jcowan> lechner: Some of the advice in http://wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations is dated (be sure to read the comments too) but it gives you a good idea of the way in which Schemes differ
2023-07-05 12:47:58 -0400 < lechner> jcowan / funny, i was just reading that
2023-07-05 12:48:01 -0400 < lechner> thanks
2023-07-05 12:48:39 -0400 < lechner> it also explains the relative silence, some daring individuals aside, in response to my questions!
2023-07-05 12:51:18 -0400 < jcowan> jackdaniel: Yes and no. The current R7RS-large development process piggybacks off the SRFI process, but not all SRFIs are targeted to the RnRS standards
2023-07-05 13:52:53 -0400 < jackdaniel> uh, after reading this opinionated guide to scheme I'm afraid to speak up! :)
2023-07-05 13:53:40 -0400 < jackdaniel> I'm thinking about making a scheme frontend to ecl compiler after its (the compiler) refactor as a validation step, but I'll probably limit myself to r5rs
2023-07-05 13:54:52 -0400 < jackdaniel> (if not something even smaller)
2023-07-05 13:57:36 -0400 < sham1> That does sound reasonable
2023-07-05 14:01:06 -0400 < lechner> Hi, which style is better, please?       (append (list A B) items more-items)     or     (cons* A B (append items more-items))
2023-07-05 14:04:29 -0400 < Zipheir> I prefer the first, since at least some people won't know what cons* is.
2023-07-05 14:08:25 -0400 < wasamasa> pretty much that
2023-07-05 14:08:36 -0400 < jcowan> lechner: I agree, even though using append will end up copying (list A B) whereas cons* will not, but the cost of that garbage is tiny.
2023-07-05 14:10:25 -0400 < sham1> 9/10 times you should go with the obvious code
2023-07-05 14:10:27 -0400 < sham1> Append here is obvious
2023-07-05 14:11:54 -0400 < Zipheir> jcowan: cons* will probably build an args list, then copy it cons by cons. So I think the amount of garbage will be the same. You may be right, though.
2023-07-05 14:12:20 -0400 < jcowan> jackdaniel: A Scheme on top of ECL would be awesome.  What would you do about proper tail calling?  There are a variety of strategies (Cheney on the MTA, e.g.) or you could make ECL do proper tail calling in general.
2023-07-05 14:13:47 -0400 < sham1> Scheme-on-CL would be nice in general
2023-07-05 14:15:25 -0400 < jcowan> An advantage of that would be that you would get interoperation between Scheme and CL procedures for free.  Airship Scheme has to shim every CL function that Scheme user code wants to call.
2023-07-05 14:17:17 -0400 < sham1> Another hurdle other than proper tail calls would be first-class continuations.
2023-07-05 14:17:58 -0400 < jcowan> But on top of CMUCL, SBCL, CCL, Allegro, LW, you get proper tail callng for free.
2023-07-05 14:17:59 -0400 < sham1> Like you can translate Scheme into CPS, but how about when you call a CL procedure? Like would you just have to do what chicken does and just use a smaller stack
2023-07-05 14:18:10 -0400 < sham1> s/CL procedure/CL function/
2023-07-05 14:18:17 -0400 < jcowan> Hence Airship Scheme's shims
2023-07-05 14:18:39 -0400 < sham1> Right
2023-07-05 14:21:26 -0400 < jcowan> https://www.r6rs.org/final/html/r6rs-app/r6rs-app-Z-H-5.html#node_chap_C is non-normative but gives rules for using [] which I think Racket code normally uses
2023-07-05 14:22:04 -0400 < sham1> I like that style. Although it's probably because I've also been exposed to it and anything else would probably feel strange
2023-07-05 14:22:57 -0400 < jcowan> Also, square brackets were not removed from R7RS, they were rather not added to R5RS because nobody provided a rationale for doing so other than compatibility with R6RS, which was not a concern for R7RS-small.
2023-07-05 14:23:41 -0400 < jcowan> (This is a generic answer for "Why isn't feature X in R7RS-small?)
2023-07-05 14:25:30 -0400 < jcowan> Zipheir: I don't know what you mean by "private modules" in R6RS; I don't think there is any such thing.
2023-07-05 14:29:06 -0400 < Zipheir> jcowan: I think I was referring to CHICKEN.
2023-07-05 14:29:43 -0400 < jackdaniel> jcowan: ecl puts tail calls in the right place, so if the underlying c compiler can do tail calls (and gcc and clang do), then tail call is achieved
2023-07-05 14:30:27 -0400 < Zipheir> I've had a very hard time writing CHICKEN libraries with private submodules, since they have to be visible after installation to be imported.
2023-07-05 14:31:10 -0400 < Zipheir> Back in a bit.
2023-07-05 14:40:48 -0400 < rgherdt> jackdaniel: I guess gcc and clang only apply TCO to self-calls, right?
2023-07-05 14:40:54 -0400 < jcowan> jackdaniel: Unless things have changed, GCC/Clang/Intel support only tail calls that have similar signatures (same return type, same number of bytes for all arguments).  Maybe the code ECL generates always satisfies these conditions.
2023-07-05 14:42:36 -0400 < jackdaniel> rgherdt: ecl optimizes self-calls locally, so that's not a concern whatsoever
2023-07-05 14:43:15 -0400 < jackdaniel> gcc optimizes sibling calls too I think, but I'm not certain. I think that it is on -O1 and higher
2023-07-05 14:43:58 -0400 < jackdaniel> as of clang, it is disabled by default, but there is an attribute _musttailcall_ or something (which is ostensibly not used by ecl, it might in the future :)
2023-07-05 14:44:41 -0400 < rgherdt> cool
2023-07-05 14:44:46 -0400 < jackdaniel> and yeah, the number of arguments must be the same I think
2023-07-05 14:45:06 -0400 < jackdaniel> (and that condition is *not* fullfilled by ecl in general)
2023-07-05 14:45:57 -0400 < jackdaniel> either way, I'm not going to work hard on supporting things that are unfeasible, for me it is mostly a cool hack / validation step
2023-07-05 14:45:57 -0400 < lechner> Zipheir / wasamasa / jcowan / sham1 / thanks!
2023-07-05 15:00:03 -0400 < jcowan> So it would be a NQScheme implementation.  What about sham1's point about first-class continuations?
2023-07-05 15:03:41 -0400 < jackdaniel> I don't think that call/cc would fit nice with ecl runtime. as of continuations with dynamic extent they are kind of implemented (common lisp requires them)
2023-07-05 15:03:59 -0400 < jackdaniel> s/kind of//
2023-07-05 15:15:39 -0400  * jcowan nods
2023-07-05 15:16:53 -0400 < jcowan> I wrote an implementation of T (a Scheme dialecdt with some interesting features) on top of CL, long ago
2023-07-05 15:17:15 -0400 < jcowan> I too punted on recursion and continuation
2023-07-05 15:18:52 -0400 < ecraven> T's object is nice :D
2023-07-05 15:23:45 -0400 < jcowan> Yes
--- Day changed Thu Jul 06 2023
2023-07-06 03:54:22 -0400 < wasamasa> jackdaniel: https://github.com/schemedoc/surveys/pull/45
2023-07-06 03:55:06 -0400 < wasamasa> jackdaniel: putting this list together was interesting, I didn't expect so much stuff to support r7rs or at least a useful subset
2023-07-06 03:55:08 -0400 < jackdaniel> wasamasa: cool!
2023-07-06 03:55:30 -0400 < wasamasa> it's as if all the implementations try to go towards r7rs
2023-07-06 03:55:46 -0400 < jackdaniel> that kind of makes sense, it is like cltl2 -> ansi cl migration at the time
2023-07-06 03:55:47 -0400 < wasamasa> even CHICKEN is considering to have r7rs support in core for the upcoming major release
2023-07-06 03:56:04 -0400 < Franciman> r7rs or r7rs-small?
2023-07-06 03:56:04 -0400 < wasamasa> last time I seriously wrote r7rs was a while ago and I ended up picking 7 implementations to target
2023-07-06 03:56:25 -0400 < wasamasa> I mean, it doesn't really matter, r7rs-large is just SRFIs on top of r7rs-small
2023-07-06 03:56:34 -0400 < Franciman> that's true
2023-07-06 03:56:35 -0400 < wasamasa> so that distinction would end up being the SRFI table
2023-07-06 03:57:44 -0400 < wasamasa> what I didn't distinguish here was whether they properly support r7rs libraries
2023-07-06 03:57:52 -0400 < wasamasa> a bunch of implementations punt on this
2023-07-06 03:58:06 -0400 < wasamasa> so you'd end up not supporting projects split into modules
2023-07-06 03:59:48 -0400 < wasamasa> another surprise was mit-scheme supporting r4rs as in the IEEE standard
2023-07-06 04:04:04 -0400 < jackdaniel> jcowan: on the bright side I plan to support "hygienic" macros and numeric tower (the latter comes for free of course)
2023-07-06 04:08:48 -0400 < jackdaniel> s/plan/want/
2023-07-06 05:17:00 -0400 < dpk> wasamasa: do you have a source for that? are they going to adopt syntax-case?
2023-07-06 06:10:43 -0400 < wasamasa> this is about obsoleting the r7rs egg, so r7rs-small only
2023-07-06 06:11:52 -0400 < wasamasa> syntax-case is unlikely to happen due to the opposition to r6rs in general (which seems to be a political thing really) and considering that even small fixes to alexpander are not happening at the moment (I handed in a bug a while ago for a very prevalent chibi library in snow and it's still not fixed), syntax-case won't go through at all unless someone™ is willing to maintain the macro bits of the system
2023-07-06 06:21:01 -0400 < wasamasa> jackdaniel: now it lives on https://docs.scheme.org/surveys/rnrs-support/
2023-07-06 06:28:23 -0400 < wasamasa> dpk: ~/irc/libera/#chicken/2023-06-27.log:[11:21:46] <Bunny351> here a wild, badly thought out idea: how about making C6 R7RS compliant?
2023-07-06 06:29:11 -0400 < wasamasa> dpk: the reason this is coming up is due to the utf8 rework and r7rs procedure names have been chosen for dealing with bytes
2023-07-06 06:35:02 -0400 < dpk> right, okay
2023-07-06 06:35:10 -0400 < sham1> I've finally gotten enough motivation to actually write the more general port property thing. Of course the caveat applies that this is very early stages: https://codeberg.org/sham1/pre-srfi/src/branch/main/port-properties.md
2023-07-06 06:36:07 -0400 < dpk> what's the benefit of this vs just defining procedures port-filename, port-transcoder etc?
2023-07-06 06:36:22 -0400 < dpk> oh
2023-07-06 06:36:26 -0400  * dpk actually reads the last paragraph
2023-07-06 06:36:46 -0400 < wasamasa> I realized I should add more scheme implementations from r7rs-benchmarks to the survey thing and now I'm scratching my head which scheme standard femtolisp even targets
2023-07-06 06:36:54 -0400 < wasamasa> it claims it's a lisp and so far it looks like r5rs
2023-07-06 06:36:56 -0400 < dpk> none, i think
2023-07-06 06:37:01 -0400 < dpk> maybe R5RS
2023-07-06 06:37:17 -0400 < wasamasa> maybe it's like s9fes and actually r4rs
2023-07-06 06:37:26 -0400 < dpk> but i think it falls in the category of Scheme-a-likes which don't really care about RnRS compliance
2023-07-06 06:37:32 -0400 < wasamasa> well yeah
2023-07-06 06:37:41 -0400 < dpk> it does support syntax-case though
2023-07-06 06:37:49 -0400 < dpk> because syntax-case is ballin'
2023-07-06 06:37:55 -0400 < wasamasa> yes, that threw me off a bit
2023-07-06 06:38:24 -0400 < wasamasa> is there any syntax-rules or are macros solved via preprocessing?
2023-07-06 06:38:29 -0400 < sham1> dpk: you could have `port-transcoder` and such as shorthands for the `port-property-ref` but as said, you should be allowed to have custom ports with custom properties
2023-07-06 06:41:08 -0400 < wasamasa> ok, so psyntax implements syntax-rules and lib/lazy.scm actually uses syntax-rules
2023-07-06 06:41:28 -0400 < dpk> yes, syntax-rules is a trivial layer on top of syntax-case
2023-07-06 06:42:50 -0400 < wasamasa> there's no sight of call/cc
2023-07-06 06:43:24 -0400 < wasamasa> it's really weird, it attempts to implement just enough r5rs to run psyntax
2023-07-06 09:27:03 -0400 < sham1> How is one supposed to actually use SRFI 64
2023-07-06 09:27:21 -0400 < sham1> I want to be able to write tests for my stuff, but I just can't figure out this thing
2023-07-06 10:20:38 -0400 < flatwhatson> sham1: here's an example: https://notabug.org/flatwhatson/guile-gemini/src/main/test/gemini/request.scm
2023-07-06 10:21:32 -0400 < flatwhatson> you can just run a test file as a script, srfi-64 specifies a default test runner
2023-07-06 10:22:32 -0400 < sham1> Right, and how would a custom test runner work
2023-07-06 10:25:09 -0400 < flatwhatson> you implement the runner callback functions and set the runner before running the tests
2023-07-06 10:25:20 -0400 < flatwhatson> those callbacks are well described in the srfi document
2023-07-06 10:26:00 -0400 < sham1> Yes they are, it's just that it feels a bit strange coming from other languages and testing frameworks there
2023-07-06 10:28:10 -0400 < flatwhatson> i mean there are a *lot* of strange test frameworks out there
2023-07-06 10:29:07 -0400 < flatwhatson> srfi 64 is pretty straightforward?
2023-07-06 10:51:32 -0400 < wasamasa> what if everyone just uses the default test runner, lol
2023-07-06 10:51:47 -0400 < wasamasa> there is an example in the SRFI document, too
2023-07-06 10:53:22 -0400 < wasamasa> both of a test suite and a custom test runner
2023-07-06 10:57:05 -0400 < jcowan> Chicken and Chibi use the same test framework, related to but not identical with SRFI 64, but their test runners look quite different.
2023-07-06 10:57:33 -0400 < jcowan> Keeping the test runner separate would allow someone to write a GUI test runner
2023-07-06 10:59:17 -0400 < jcowan> wasamasa: Technically that is true; however it does not mean that you can implement R7-large by adding *portable* SRFIs to R7-small. The "Committee F" aka "Foundation" features are not portably implementable.
2023-07-06 10:59:36 -0400 < jcowan> ditto "Committee E" which is about the environment
2023-07-06 10:59:51 -0400 < jcowan> and mostly involves R6RS I/O
2023-07-06 13:46:55 -0400 < mdhughes> sham1: I made a new runner for SRFI-64: https://mdhughes.tech/2020/02/27/scheme-test-unit/
2023-07-06 13:48:43 -0400 < sham1> I've thought about just writing my own runner that uses the TAP testing protocol since alternatives like JUnit XML output seem quite daunting
2023-07-06 14:21:46 -0400 < amirouche> yet another runner :)
2023-07-06 14:26:30 -0400 < sham1> Or maybe the Open Test Reporting format. That also looks interesting
2023-07-06 14:32:00 -0400 < Zipheir> sham1: Do you have a link for that? DDG gives unrelated results.
2023-07-06 14:33:06 -0400 < sham1> https://github.com/ota4j-team/open-test-reporting Apparently a format related to JUnit
2023-07-06 14:41:44 -0400 < Zipheir> sham1: Thanks.
2023-07-06 14:44:20 -0400 < Zipheir> They're certainly right about XML being more schema-tizable than JSON, IMO. It probably wouldn't be too hard to have SRFI 64 wrapper that generates this as SXML.
2023-07-06 14:44:33 -0400 < Zipheir> s/have/write a/
2023-07-06 15:10:10 -0400 < Zipheir> Not a wrapper, but something compatible with SRFI 64, at least.
2023-07-06 15:11:10 -0400 < sham1> I could write TAP at the very least. Would be useful for example with Github CI
2023-07-06 15:11:54 -0400 < sham1> There's also apparently CI for Codeberg which is useful
2023-07-06 15:42:24 -0400 < lechner> Hi, is there any way to use SRFI-16's operator <> for "Specializing parameters without currying" with keyword parameters declared via #:key?
2023-07-06 15:48:16 -0400 < Zipheir> lechner: You mean something like (cut foo #:some-key <> ...) ? That should work.
2023-07-06 15:48:36 -0400 < Zipheir> For the record, cut's from SRFI 26, not 16.
2023-07-06 15:49:03 -0400 < Zipheir> In fact, that's a good use of cut.
2023-07-06 16:20:31 -0400 < wasamasa> given that cut is syntax, I'd expect it to work
2023-07-06 16:23:55 -0400 < lechner> Zipheir / wasamasa / Sorry about the typo, and thanks!
2023-07-06 16:25:10 -0400 < lechner> Hi, can 'member' or 'any' be used to determine if a string, in its entirety, is present in a list of strings?
2023-07-06 16:25:42 -0400 < wasamasa> for this, you'd need to look which equality predicate they use and if it works on strings, then yes
2023-07-06 16:26:01 -0400 < sham1> You can specify the equality predicate
2023-07-06 16:26:28 -0400 < wasamasa> ah, for SRFI-1 member, I see
2023-07-06 16:26:44 -0400 < sham1> Also R7RS-small member, which is probably the same one
2023-07-06 16:26:54 -0400 < lechner> or should I use 'find'?
2023-07-06 16:27:00 -0400 < wasamasa> yeah, I'm used to R5RS member which doesn't provide this
2023-07-06 16:27:34 -0400 < wasamasa> well, "equality predicate" is a misnomer
2023-07-06 16:28:19 -0400 < sham1> Well yeah, technically doesn't need to be strictly equality, but it helps
2023-07-06 16:28:27 -0400 < wasamasa> `any' takes a predicate (procedure returning #t/#f), whereas `member' takes an equality procedure (which compares two objects)
2023-07-06 16:28:51 -0400 < Zipheir> 'member' uses 'equal?' by default.
2023-07-06 16:29:12 -0400 < Zipheir> I would use 'member', since it's been standard for ever.
2023-07-06 16:30:39 -0400 < Zipheir> wasamasa: member takes a comparison proc. in SRFI 1 or R7RS, but not in any previous report.
2023-07-06 16:31:31 -0400 < wasamasa> the difference between `any' and `find' is what they return, you'll want `find' to return the item, whereas `any' returns the result of the predicate
2023-07-06 16:32:13 -0400 < sham1> Zipheir: btw, have you yet looked at the port properties?
2023-07-06 16:32:18 -0400 < Zipheir> Yes, 'find' is a better fit. But (and (member my-string lis) #t) is just fine, I think.
2023-07-06 16:32:53 -0400 < Zipheir> sham1: Not since you mentioned it last. I liked the first draft.
2023-07-06 16:33:29 -0400 < sham1> Yeah, the one with port-properties-ref? Yeah, I feel it should work fine
2023-07-06 16:34:30 -0400 < Zipheir> sham1: Ah, I haven't seen some of this.
2023-07-06 16:34:47 -0400 < sham1> Yeah, I changed the filename thing into a more general thing
2023-07-06 16:34:56 -0400 < Zipheir> I think that's for the best.
2023-07-06 16:35:01 -0400 < sham1> https://codeberg.org/sham1/pre-srfi/src/branch/main/port-properties.md
2023-07-06 16:35:23 -0400 < Zipheir> I guess the one question now is what kind of sample implementation it could have.
2023-07-06 16:37:20 -0400 < sham1> A sample implementation would either have to get very deep in the guts of an existing implementation, or basically just wrap every single procedure that uses ports
2023-07-06 16:38:28 -0400 < Zipheir> Yeah. I think Arthur might agree in this case that a sample implementation would be impractical.
2023-07-06 16:39:09 -0400 < Zipheir> But you might be able to do a non-portable implementation for a Scheme with custom ports.
2023-07-06 16:39:30 -0400 < sham1> Well you'd somehow have to associate data with the port
2023-07-06 16:39:44 -0400 < sham1> Either via some kind of weird eq-hashtable or something like that, or just putting the data into the port
2023-07-06 16:41:23 -0400 < Zipheir> It could be very basic.
2023-07-06 16:42:32 -0400 < Zipheir> jcowan: What do you think of the prospects for a port-properties sample implementation, oh CCBW?
2023-07-06 16:44:59 -0400 < Zipheir> wasamasa: How hard would it be to add custom properties to CHICKEN ports?
2023-07-06 16:45:32 -0400 < wasamasa> good question, I occasionally look at custom ports and people write really ugly code reaching deep into the guts
2023-07-06 16:46:10 -0400 < wasamasa> from what I understand, ports are internally record-like objects with a fixed amount of slots and some of them can be used for custom stuff
2023-07-06 16:46:26 -0400 < Zipheir> Right.
2023-07-06 16:46:32 -0400 < sham1> Well one could just put a hashmap into one of the slots
2023-07-06 16:46:56 -0400 < wasamasa> the problem with reaching deep into the guts is that after every major release, you need to rework your code again
2023-07-06 16:47:01 -0400 < dpk> jcowan: i still hope (chibi test) gets SRFI'd at some point as a reduced/improved SRFI 64
2023-07-06 16:47:08 -0400 < dpk> SRFI 64 has Java brain
2023-07-06 16:47:20 -0400 < wasamasa> hahaha
2023-07-06 16:47:22 -0400 < sham1> Clearly not enough Java brain for me, I don't understand it
2023-07-06 16:47:28 -0400 < wasamasa> yeah, SRFI-64 feels a bit overdesigned
2023-07-06 16:47:31 -0400 < Zipheir> wasamasa: Yes, but it's just a sample implementation. It can be frozen in time for CHICKEN 5.
2023-07-06 16:47:35 -0400 < sham1> It's weird and requires weird file stuff
2023-07-06 16:47:45 -0400 < sham1> Like you need different files for various test things
2023-07-06 16:48:00 -0400 < dpk> also, arguably, too much Scheme brain (see ‘If Scheme were like Scheme’)
2023-07-06 16:48:12 -0400 < dpk> (https://arcanesentiment.blogspot.com/2015/01/if-scheme-were-like-scheme.html)
2023-07-06 16:49:00 -0400 < Zipheir> There's SRFI 78.
2023-07-06 16:49:17 -0400 < Zipheir> 64 is clearly the most popular design, though.
2023-07-06 16:49:49 -0400 < wasamasa> Zipheir: there are some special port types, like sockets, which do use these internals, so I'm not sure a generic solution is possible (unless you do something like betting on some other internals thing like tagged procedures)
2023-07-06 16:50:24 -0400 < sham1> No matter what kind of a test harness and support library we end up with, it needs to a) become a part of the Batteries and b) become encouraged in the community, because testing is useful and I'd even say necessary, although things like TDD can be contentious issues
2023-07-06 16:50:42 -0400 < Zipheir> wasamasa: Hmm, yeah.
2023-07-06 16:51:05 -0400 < sham1> Ideally Batteries and even things like Foundations should have standard tests if at all feasible for any given part
2023-07-06 16:51:26 -0400 < Zipheir> Well, the SRFIs should already have tests.
2023-07-06 16:53:37 -0400 < Zipheir> sham1: Port properties might be one of those "last resort" SRFIs with only a sketch implementation.
2023-07-06 16:54:20 -0400 < Zipheir> Though it's easy to implement if you have access to the guts of the port type.
2023-07-06 16:54:31 -0400 < sham1> Yeah, there's no real feasible way to make it at all portable, it's such a fundamental thing
2023-07-06 16:54:49 -0400 < sham1> Although I finally found use for Maybe
2023-07-06 16:56:02 -0400 < Zipheir> I think it's a good use for Maybe, though some may complain.
2023-07-06 16:56:15 -0400  * dpk complains, predictably ;-)
2023-07-06 16:56:31 -0400 < Zipheir> dpk: What would *you* use?
2023-07-06 16:56:33 -0400 < sham1> I couldn't think of a better interface
2023-07-06 16:56:58 -0400 < dpk> a default argument
2023-07-06 16:57:09 -0400 < Zipheir> The alternatives are (1) value-or-#f, (2) a default value, or (3) a failure continuation.
2023-07-06 16:57:20 -0400 < dpk> that is what mnw plans for identifier properties
2023-07-06 16:57:22 -0400 < Zipheir> Or (4) an exception.
2023-07-06 16:57:35 -0400 < Zipheir> I think defaults are rather clumsy.
2023-07-06 16:57:55 -0400 < Zipheir> They also don't solve the problem of giving a unique failure value.
2023-07-06 16:58:07 -0400 < Zipheir> Actually, that's my main complaint.
2023-07-06 16:58:10 -0400 < sham1> And I think that while value-or-#f would work for some things, I don't think it's necessarily robust
2023-07-06 16:58:17 -0400 < Zipheir> Definitely not.
2023-07-06 16:59:37 -0400 < Zipheir> If you want to know for sure whether 'proc' failed, you have to do something like (let* ((magic (string-copy "abracadabra")) (res (proc ... magic))) (if (equal? res magic) ... ...)).
2023-07-06 16:59:56 -0400 < Zipheir> Oops, s/equal?/eq?/
2023-07-06 17:00:28 -0400 < sham1> Failure continuations would be clunky IMO. Especially since we consider that some properties we expect to fail "often", like a binary port is not gonna have a transcoder
2023-07-06 17:01:03 -0400 < dpk> the clear precedent is -ref procedures which signal an error and -ref/default procedures which take a default value to return
2023-07-06 17:01:18 -0400 < sham1> Well the name can be bikeshed
2023-07-06 17:01:29 -0400 < dpk> as committee C chair i reserve the right to put all interfaces which don't respect this precedent to a ballot
2023-07-06 17:01:51 -0400 < Zipheir> OK, Pooh-Bah.
2023-07-06 17:02:05 -0400 < sham1> Fine, I'll put it under E then /s
2023-07-06 17:02:11 -0400 < Zipheir> I agree, though. -refs should probably raise exceptions.
2023-07-06 17:02:18 -0400 < sham1> It's now an interoperability issue
2023-07-06 17:02:19 -0400 < lechner> wasamasa / sham1 / Zipheir / thanks~
2023-07-06 17:02:36 -0400 < sham1> Anyway, again, for example if we think about transcoders, missing those isn't exceptional per se
2023-07-06 17:02:43 -0400 < sham1> Or a filename
2023-07-06 17:03:49 -0400 < sham1> T'is why it's a pre-SRFI after all ;)
2023-07-06 17:03:59 -0400 < Zipheir> Of course.
2023-07-06 17:05:13 -0400 < Zipheir> If it does raise an exception, it's very easy to turn that into an Either, if you like. See the (very nice, IMO) either-guard form of 189.
2023-07-06 17:05:33 -0400 < sham1> Yeah, but I still don't necessarily agree with that interface
2023-07-06 17:06:04 -0400 < sham1> But that's again me being weird about what is and isn't "exceptional" and warrants an exception
2023-07-06 17:06:26 -0400 < Zipheir> See also 'condition-ref' in SRFI 35, which is a very similar idea. https://srfi.schemers.org/srfi-35/srfi-35.html
2023-07-06 17:07:09 -0400 < Zipheir> Agreed. There are some messy questions about what is "exceptional".
2023-07-06 17:07:24 -0400 < sham1> I could possibly go with a non-fatal condition
2023-07-06 17:08:33 -0400 < Zipheir> sham1: I think that just means it's continuable, in Scheme terms.
2023-07-06 17:08:57 -0400 < sham1> Yeah, I'm thinking like one of those not-quite-error conditions in R6RS
2023-07-06 17:09:16 -0400 < Zipheir> That's OK by me.
2023-07-06 17:09:52 -0400 < Zipheir> As long as it's not a MUST feature.
2023-07-06 17:10:03 -0400 < sham1> I suppose the most "idiomatic" way would be value-or-#f
2023-07-06 17:10:36 -0400 < Zipheir> Nah. Then you can't have #f as a property value.
2023-07-06 17:11:07 -0400 < sham1> Well you could just then make the property so that the non-presence can be interpreted as falsity
2023-07-06 17:13:41 -0400 < Zipheir> Value-or-#f has served us well, but I think you should be able to distinguish present, false properties from missing properties.
2023-07-06 17:14:24 -0400 < sham1> Yeah, value-or-#f has similar problems as for example how in Lua, there's no difference between a key not being in a table and the value associated with the key being nil
2023-07-06 17:15:25 -0400 < gwatt> sham1: not even a way to ask if the table contains the key?
2023-07-06 17:15:33 -0400 < sham1> I don't think so
2023-07-06 17:16:24 -0400 < sham1> It's especially fun with arrays, because the length of an array is defined such that the array "sequence" of a table has a length n, if the element n+1 is nil. So you can lose the tail of your array if you insert nil into the array at some point
2023-07-06 17:16:39 -0400 < sham1> And of course here we remember that Lua is 1-based
2023-07-06 17:17:26 -0400 < gwatt> can you access elements past a nil element?
2023-07-06 17:18:41 -0400 < sham1> Yes, because tables are just essentially hashmaps with also an array part
2023-07-06 17:18:45 -0400 < sham1> It's weird
2023-07-06 17:19:30 -0400 < sham1> It's also the only real data structure, so you get to know these quirks
2023-07-06 17:20:41 -0400 < Zipheir> It certainly shows the problems of making dictionaries the only structure in a language.
2023-07-06 17:21:26 -0400 < sham1> Well that wouldn't be a problem if putting a nil as the value wasn't the same as deleting the key. It'd work just fine otherwise
2023-07-06 17:22:06 -0400 < sham1> Of course it also doesn't help that if you try to access a non-existent key, you get back nil
2023-07-06 17:22:23 -0400 < sham1> It'd have to throw or they'd need something different. Also see JavaScript with null vs undefined
2023-07-06 17:22:43 -0400 < sham1> Scheme of course doesn't have this issue because for hashmaps for example, you pass a failure thunk and usually just throw
2023-07-06 17:23:34 -0400 < mfiano> such as multiple return values. Julia has the same problem with dictionaries, but for another reason. They only use a sum type in _some_ places of the standard library, and dictionary lookup is not one of them
2023-07-06 17:24:12 -0400 < mfiano> nil nil nil. even with builtin sum types, the problem still bites language designers that don't think about it properly
2023-07-06 17:26:36 -0400 < sham1> I feel that CL handles multiple return values quite nicely. I understand from a semantic standpoint why returning two values where one was expected by the receiver is not possible in Scheme, but it's also slightly tedious at points
2023-07-06 17:28:16 -0400 < sham1> For example GETHASH returns NIL for if a key was not present or if the stored value was NIL. It also returns a second value to indicate which it was, IIRC T if the key was present. If you want the information, you have to explicitly "capture" the second return by something like MULTIPLE-VALUE-BIND, but if you don't need the distinction, you can just use GETHASH as if it returns a single thing
2023-07-06 17:28:17 -0400 < mfiano> Note that, I feel multiple return values is the wrong solution for this particular problem.
2023-07-06 17:28:55 -0400 < sham1> In Scheme, for the equivalent interface you'd always need to capture both values, usually to just discard the second one
2023-07-06 17:29:24 -0400 < sham1> An in general, while I understand the rationale with that being an error in Scheme, I like the ergonomics of the CL way
2023-07-06 17:29:37 -0400 < mfiano> multiple return values are nice because they silently "fail". If the call site doesn't think about the second return value and handle it accordingly, the issue remains.
2023-07-06 17:30:03 -0400 < mfiano> nullable types are pointless otherwise (for those languages anyway)
2023-07-06 17:31:43 -0400 < shawnw> I can see arguments for both ways. We need values and ignorable-values with the latter causing common lisp style behavior for its continuation.
2023-07-06 17:34:38 -0400 < mfiano> I can too. I pefer Scheme and CL here. A language that stays out of my way, but gives me the chance to handle it properly *when* I need to think about it.
2023-07-06 17:36:47 -0400 < sham1> Having the multiple returns be first-class is nice
2023-07-06 17:36:50 -0400  * sham1 once again glairs Lua
2023-07-06 17:38:30 -0400 < sham1> glares at*
2023-07-06 17:45:32 -0400 < mfiano> I just, don't get what Julia was thinking. My guess is the dictionary API predates the `Some` type. Julia has multiple return values _and_ sum types, yet to properly check for the precense of a key, requires the `get` function will return nil if that is the key's value. It has an optional scheme-like non-present value to use in such a case, why you could throw or whatever, but the correct way is to
2023-07-06 17:45:34 -0400 < mfiano> first do an additional lookup to check if it is present with a different function, `haskey`.
2023-07-06 17:46:17 -0400 < mfiano> s/why/which/
2023-07-06 17:46:54 -0400 < mfiano> But I digress. Julia is only a Scheme behind the shroud of Algol
2023-07-06 17:48:08 -0400 < lechner> Hi, lambdas are almost like quoted sexps, right? 'write' will print a quoted sexp. How may I print the body of a lambda, please?
2023-07-06 17:51:00 -0400 < Zipheir> (write '<body of a lambda>), of course. :)
2023-07-06 17:51:09 -0400 < mfiano> lambdas are expressions that may or may not be quoted
2023-07-06 17:51:18 -0400 < mfiano> Solution. Quote what you want to treat as data
2023-07-06 17:51:21 -0400 < Zipheir> lechner: Are you talking about Scheme, or meta-Scheme?
2023-07-06 17:53:30 -0400 < lechner> For a simple reimagination of the 'make' utility, I current specify recipes as lists of thunks, i.e. lists of lambdas. How can I print a command that failed with a non-zero exit status?
2023-07-06 17:53:43 -0400 < lechner> please
2023-07-06 17:54:51 -0400 < Zipheir> You need the quoted list to do that; you can't get the representation from the interpreted/compiled procedures. It's a little hard to say more without more detail.
2023-07-06 17:55:15 -0400 < mfiano> Simple ugly solution, use quote and eval.
2023-07-06 17:55:22 -0400 < lechner> okay, thanks!
2023-07-06 17:55:23 -0400 < Zipheir> Eeech
2023-07-06 17:55:31 -0400 < lechner> no eval?
2023-07-06 17:55:43 -0400  * mfiano ephasizes the 'ugly'
2023-07-06 17:55:43 -0400 < Zipheir> Just tag the procedure with the quoted representation. That's fairly easy macrology.
2023-07-06 17:55:55 -0400 < lechner> okay
2023-07-06 17:56:01 -0400 < sham1> mfiano: you're right. It's an ugly solution
2023-07-06 17:57:27 -0400 < mfiano> I'm still a bit new to Scheme, but in CL if I ever have to use `eval`, I know I ddidn't delineate the compiler phases properly in my design.
2023-07-06 17:57:28 -0400 < lechner> How do I tag a procedure, please?
2023-07-06 17:57:33 -0400 < Zipheir> lechner: You'll have something like a tagged-procedure record that contains a procedure and its representation. You'll have to develop simple apply forms for it, etc.
2023-07-06 17:57:39 -0400 < mfiano> Bad stuff
2023-07-06 17:58:13 -0400 < lechner> okay, thanks!
2023-07-06 17:58:43 -0400 < Zipheir> lechner: So if something goes wrong when applying (tagged-procedure-procedure tproc ...), you use (tagged-procedure-quoted-body tproc) in your error message.
2023-07-06 17:59:43 -0400 < lechner> How may I turn a quoted sexp into the body of a lambda, please? (Preferably without eval.)
2023-07-06 18:00:17 -0400 < Zipheir> Macros.
2023-07-06 18:00:18 -0400 < lechner> this is for setup
2023-07-06 18:00:18 -0400 < mfiano> by using a macro which transforms that code
2023-07-06 18:00:26 -0400 < lechner> okay, thanks!
2023-07-06 18:01:05 -0400 < lechner> after all these years, i am finally happy to have a macro facility somewhere
2023-07-06 18:01:22 -0400 < Zipheir> lechner: Beware: this idea is simple enough, but working out the details may be tricky.
2023-07-06 18:01:46 -0400 < lechner> really?
2023-07-06 18:02:57 -0400 < Zipheir> Yes, because to really use your body-tagged procedures, you have to catch exceptions and re-raise them with the body details, among other things.
2023-07-06 18:04:25 -0400 < Zipheir> The tagging itself is similar to how SRFI 78 tags a test with the expression being tested: https://github.com/scheme-requests-for-implementation/srfi-78/blob/master/check.scm#L172
2023-07-06 20:08:38 -0400 < lechner> mfiano / Zipheir / The records and macro combo worked beautifully. Thanks so much!
2023-07-06 20:19:52 -0400 < Zipheir> lechner: I'm glad it worked!
--- Day changed Fri Jul 07 2023
2023-07-07 01:15:14 -0400 < lechner> Actually, the records and macros don't do exactly what I had hoped. They macro runs so early that the variables are not substituted.
2023-07-07 01:16:53 -0400 < lechner> Hi, is      (for-each (lambda (thunk) (thunk)) thunks)      the shortest way to run a list of thunks?
2023-07-07 02:04:21 -0400 < Zipheir> lechner: Probably.
2023-07-07 02:05:21 -0400 < Zipheir> You could use 'cut' and 'apply', but that's more complicated.
2023-07-07 02:06:14 -0400 < Zipheir> lechner: If you need the values of actual parameters in your quoted expression, then you're screwed unless you only pass constants.
2023-07-07 02:06:41 -0400 < Zipheir> You can't interleave macro expansion and program evaluation in Scheme.
2023-07-07 04:36:32 -0400 < amirouche> I published my hard to guess password library based on Secure Remote Password specification where the hash is blake3, and where argon2id is also used hence it is not compatibible with existing SRP that also use blake3 if any
2023-07-07 04:36:55 -0400 < amirouche> Review welcome at https://github.com/letloop/cli/pull/1758
2023-07-07 04:37:17 -0400 < amirouche> I am wondering about the procedure names
2023-07-07 04:37:54 -0400 < amirouche> I think I will alias unknown-client-check-M2? to unknown-client-check-server-proof?
2023-07-07 04:38:23 -0400 < amirouche> M2 is the variable name given to the proof the server sends to the client that the server knows the same K (shared key) than the client
2023-07-07 04:38:54 -0400 < amirouche> similarly unknown-client-K will be aliased unknown-client-shared-key
2023-07-07 04:39:29 -0400 < amirouche> Yes it is called (letloop unknown) :)
2023-07-07 10:41:39 -0400 < skeemer> how can i check if a list is made of just empty lists ?
2023-07-07 10:53:28 -0400 < skeemer> ok solved!
2023-07-07 11:01:56 -0400 < lechner> Zipheir / okay
2023-07-07 11:05:16 -0400 < lechner> Zipheir / as in    (for-each (cut apply <>) thunks)     ?
2023-07-07 11:12:37 -0400 < lechner> Hi, for my issue of printing thunks, what's the drawback of using 'eval' again, please?
2023-07-07 11:19:01 -0400 < sham1> An implementation cannot optimise, for example
2023-07-07 11:24:36 -0400 < lechner> okay, thanks!
2023-07-07 11:26:05 -0400 < Zipheir> skeemer: The most idiomatic way is (every null? list).
2023-07-07 11:27:37 -0400 < Zipheir> s/every/for-all/ if you're using the R6RS list library.
2023-07-07 11:29:24 -0400 < Zipheir> lechner: Right.
2023-07-07 11:30:58 -0400 < Zipheir> lechner: Read the spec for 'eval'. You have to get the environment right. But how will eval solve your procedure-printing problem?
2023-07-07 11:31:26 -0400 < Zipheir> I mean, the problem of printing a procedure body after parameter substitution has occurred.
2023-07-07 12:01:53 -0400 < skeemer> Zipheir, thanks!
2023-07-07 12:12:32 -0400 < rendar> pipes ares used to insert spaces inside names? e.g. (setf |x and y| 12) store 12 inside variable called "x and y" ?
2023-07-07 12:14:53 -0400 < sham1> That is indeed how you can do that. But, and this is probably going to be obvious but I'll say it anyway: don't
2023-07-07 12:16:12 -0400 < rendar> why? it's a thing that is discouraged?
2023-07-07 12:20:52 -0400 < Zipheir> setf is also not standard (or even well-known) Scheme.
2023-07-07 12:21:50 -0400 < Zipheir> rendar: Spaces in names are very rare, so your program will be harder for most programmers to read if you use a lot of names like that.
2023-07-07 12:23:26 -0400 < Zipheir> I don't think I've ever seen a |...| identifier in a Scheme program.
2023-07-07 12:31:53 -0400 < rendar> well yeah
2023-07-07 12:40:28 -0400 < skeemer> would you guys consider racket a scheme?
2023-07-07 12:40:52 -0400 < skeemer> i mean can i write RxRS with racket? or can i read the little schemer series of books with it ?
2023-07-07 12:41:15 -0400 < sham1> Scheme is just one of the languages implemented in the Racket ecosystem
2023-07-07 12:41:23 -0400 < sham1> So yes, you can
2023-07-07 12:42:02 -0400 < Zipheir> skeemer: Yes.
2023-07-07 12:42:41 -0400 < Zipheir> rudybot: ultimate programming language virus
2023-07-07 12:42:41 -0400 < rudybot> Zipheir: "Scheme occupies a unique niche. A research niche and an educational niche. It is not a language. Not R6RS, not R5RS, not R4Rs. It is an idea. Or a collection of ideas. It is a framework. It is a way of thinking. It is a mindset. All of this is embodied in an ever growing family of languages or dialects, not a single language. It is a virus. It is the ultimate programming-language virus." --Jeff Siskind
2023-07-07 12:44:05 -0400 < Zipheir> skeemer: You can use Racket as an R6RS implementation with the #!r6rs language directive.
2023-07-07 12:48:59 -0400 < sham1> And we must of course remember that Racket grew out of Scheme
2023-07-07 12:50:07 -0400 < sham1> And so many concepts (I'd even claim most) are inherited
2023-07-07 12:52:19 -0400 < Zipheir> The Racket language has gotten a lot more complicated than even R6, though.
2023-07-07 12:53:13 -0400 < Zipheir> Though it's simpler in some places, e.g. in not allowing pairs to be mutated.
2023-07-07 13:00:45 -0400 < Zipheir> skeemer: You *need* Racket to do The Little Typer or Learner. You can do the others in just about any Scheme implementation, but I think Racket may have packages to make things easier.
2023-07-07 13:05:54 -0400 < skeemer> Zipheir, why do i *need* racket for those ?
2023-07-07 13:07:47 -0400 < Zipheir> skeemer: Pie, the language used in Little Typer, is built on Typed Racket. I don't think there's an implementation in vanilla Scheme, as there is for miniKanren (the Reasoned Schemer's language).
2023-07-07 13:08:46 -0400 < Zipheir> The Little Learner uses a relatively huge Racket library: https://github.com/themetaschemer/malt  I'm not sure it could be ported to Scheme at all.
2023-07-07 13:09:19 -0400 < Zipheir> (They're pushing the "little" tag with The Little Learner. The book's also fairly massive.)
2023-07-07 13:20:03 -0400 < skeemer> Zipheir, why things are so difficult to port from racket to other schemes like chicken ?
2023-07-07 13:22:10 -0400 < Zipheir> Every portable program is the same, but every unportable program is unportable in its own way. :)
2023-07-07 13:22:29 -0400 < skeemer> Zipheir, what do you mean?
2023-07-07 13:23:40 -0400 < Zipheir> Pie relies on DrRacket for its Coq-like interactive mode, and it's written in Typed Racket. Otherwise, it could probably be implemented in, say, CHICKEN without too much trouble.
2023-07-07 13:23:58 -0400 < skeemer> Zipheir, and what makes malt difficult to port to chicken ?
2023-07-07 13:24:02 -0400 < skeemer> for example ?
2023-07-07 13:24:13 -0400 < Zipheir> malt, the Little Learner library, is much more complex. I'm not sure how many Racket features it depends on.
2023-07-07 13:25:07 -0400 < Zipheir> For one thing, it's got tons of submodules, which some Schemes have trouble with.
2023-07-07 13:25:42 -0400 < Zipheir> But it looks pretty much like standard Scheme, from a cursory glance: https://github.com/themetaschemer/malt/blob/main/nested-tensors/tensors/D-extend.rkt
2023-07-07 13:25:57 -0400 < Zipheir> Nothing special there, aside from the many Greek letters.
2023-07-07 13:26:47 -0400 < skeemer> Zipheir, it seems like using racket is a good investment
2023-07-07 13:26:52 -0400 < skeemer> instead of chicken as i am doing
2023-07-07 13:30:05 -0400 < Zipheir> You don't have to pick one, I think. I made the mistake of looking for the One True Implementation when I first started with Scheme. It took way too much time away from actually learning the language, I think.
2023-07-07 13:34:34 -0400 < Zipheir> But Racket's a good one for the Little Books and for SICP.
2023-07-07 13:37:25 -0400 < wasamasa> it's not like you have to pick one text editor for life
2023-07-07 13:37:40 -0400 < wasamasa> chances are that unless it's esoteric, you can reuse the concepts you've learned
2023-07-07 13:38:05 -0400 < wasamasa> similarly, it's not that hard to use another scheme
2023-07-07 13:38:24 -0400 < wasamasa> once you've figured out one, chances are the other one isn't that different
2023-07-07 13:48:29 -0400 < skeemer> wasamasa, yes but still it looks that people is not able to port something written in one scheme to another
2023-07-07 13:48:35 -0400 < wasamasa> they are
2023-07-07 13:49:00 -0400 < wasamasa> do not assume that because you're not capable of doing this, nobody else is :>
2023-07-07 13:51:00 -0400 < skeemer> wasamasa, so basically the community of scheme users is so small that's why portings are not done i guess
2023-07-07 13:51:23 -0400 < wasamasa> Balkanization is the term you're looking for
2023-07-07 13:52:04 -0400 < wasamasa> a lot of small states with strong opinions (and the occasional incident where people are surprised why there's strong opinions instead of a great scheme union)
2023-07-07 13:54:50 -0400 < skeemer> wasamasa, good word! I should add it to my notes cool!
2023-07-07 14:03:05 -0400 < sham1> There really are no programming languages with uniform opinions among all its users, and most often that just leads to alternative implementations. Of course, this is a thing that's not exclusive to programming, of course
2023-07-07 14:09:47 -0400 < sham1> And while some might not be fond of how balkanised the Scheme community is, I'd say that it is a strength because it lets us explore the "programming language space" far easier than if we had a single unified idea of what we are to do
2023-07-07 14:10:43 -0400 < sham1> Every small Scheme island reflects things like the authors' priorities and what they want to explore with Scheme and programming in general
2023-07-07 14:10:51 -0400 < sham1> Same principles also apply for example with Linux distros
2023-07-07 14:17:09 -0400 < Zipheir> skeemer: If you're willing to do some porting, a lot of Scheme programs are portable. By which I mean that you can't just run a CHICKEN program on Guile, but you can adapt it to work.
2023-07-07 14:17:35 -0400 < Zipheir> skeemer: There is a lot of mostly-portable Scheme. See the SRFI implementations, for example.
2023-07-07 14:18:22 -0400 < Zipheir> (A lot of the recent ones depend on syntax-case, though, which sort of leaves CHICKEN out.)
2023-07-07 14:27:17 -0400 < lechner> Zipheir / Thanks! I will share with you how it solves my problem as soon as it is usable
2023-07-07 14:28:06 -0400 < lechner> Hi, is there a way to make Guile's 'procedure-source' work with anonymous lambdas?
2023-07-07 14:29:41 -0400 < wasamasa> this almost sounds like you want to start to contribute to guile, lol
2023-07-07 14:30:13 -0400 < gwatt> lechner: probably, given that the distinction between a named lambda and anonymous lambda is nonexistant
2023-07-07 14:30:35 -0400 < sham1> Not non-existent, one can be associated a name and another cannot be
2023-07-07 14:30:47 -0400 < sham1> But yeah, that shouldn't affect this
2023-07-07 14:31:11 -0400 < sham1> Anyhow yes, contributing this to Guile, if it doesn't work, would be the best solution
2023-07-07 14:31:31 -0400 < sham1> It would improve not just Guix but also other programs
2023-07-07 14:31:37 -0400 < gwatt> sham1: that's not a distinction for the lambda itself though
2023-07-07 14:32:05 -0400 < wasamasa> looking at the source, you can probably hack around this
2023-07-07 14:33:38 -0400 < wasamasa> by using set-procedure-property! with the source symbol
2023-07-07 14:34:55 -0400 < lechner> procedure-property works great (although it isn't very interesting for anonymous thunks). unfortunately, i cannot make procedure-source work with any procedure i've tried
2023-07-07 14:36:24 -0400 < lechner> Zipheir / as for the quotes, it work like this     (lambda (quoted) (format #t "~s~%" quoted) (eval quoted (interaction-environment)))
2023-07-07 14:36:50 -0400 < Zipheir> That makes sense.
2023-07-07 14:36:58 -0400 < lechner> i quasi-quote the commands, which i can make more attractive syntactically
2023-07-07 14:37:26 -0400 < lechner> things like 'apply' show in the output, but it's a beautiful 'make' with recipes written in Scheme
2023-07-07 14:41:11 -0400 < lechner> Will things like 'setenv' carry from one 'eval' to the next, or will it effectively be like 'make' (which opens a new shell for each line)?
2023-07-07 14:42:50 -0400 < Zipheir> If (interaction-environment) just gives you the currect global store, then it should reflect changes made between evals.
2023-07-07 14:42:57 -0400 < lechner> thanks!
2023-07-07 14:43:04 -0400 < Zipheir> I don't know for sure.
2023-07-07 14:43:47 -0400 < lechner> my alternative was to rewrite system* to output the command. that looks exactly like what folks expect, except means users have to use "rm" and "cp", which seems kind of pedestrian. i still have not decided which is better
2023-07-07 14:45:00 -0400  * lechner is looking at the lambda tattoo, wondering if the world is ready
2023-07-07 14:45:15 -0400 < lechner> just kidding
2023-07-07 14:57:45 -0400 < sham1> Since we were talking about testing earlier, one of the things I've began to wonder is how we could make things like mocking more feasible
2023-07-07 14:58:56 -0400 < sham1> Because if someone has business logic that
2023-07-07 14:59:26 -0400 < sham1> If someone has business logic that requires talking to a database, it'd be nice if one could mock the access instead of needing an actual database
2023-07-07 15:01:20 -0400 < sham1> But Scheme has a problem here, because a lot of procedures are designed to be monomorphic, usually for a reason, but this also means that we couldn't use something different without changing the code we want to test; an unpleasant proposition
2023-07-07 15:04:14 -0400 < sham1> There are many ways one could approach this and I'd be interested in hearing what others here think would be the most "idiomatic" way of dealing with this. Like I feel that the business logic shouldn't make the database calls itself, but call a procedure that actually do the required queries, since the queries aren't part of the business logic
2023-07-07 15:06:11 -0400 < sham1> But now we hit the crux of the problem: how do we make sure that we can actually do this? Do we for example just pass the procedure as an argument to the business layer? If so, is it just as an argument by itself or do we for example have a record with all the procedures
2023-07-07 15:06:53 -0400 < sham1> I feel like this is a question we really need to think about if we want to ensure that people can write robust software in Scheme
2023-07-07 15:21:07 -0400 < sham1> I suppose this is more a question of how we'd expect software architecture to work in Scheme, but I do think that this is something we need to ponder as a community
2023-07-07 15:25:30 -0400 < lechner> Hi, I am probably missing some of the fine points. Mocking merely isolates the function being tested. Is Scheme different?
2023-07-07 15:35:27 -0400 < Zipheir> sham1: I think you'd have to design your "business logic" to access the database only through some easy-to-mock library.
2023-07-07 15:35:52 -0400 < Zipheir> There's no way to solve the problem if the (real) database logic is intertwined with the main program.
2023-07-07 15:36:02 -0400 < sham1> Yeah, that's what I'm also thinking. The hard part is the "easy-to-mock library" and how that looks in Scheme
2023-07-07 15:36:21 -0400 < sham1> Similar issues have been tackled elsewhere. For example in Haskell there's the Three Layered Haskell Cake
2023-07-07 15:37:21 -0400 < Zipheir> Let's say the (foo database) library exports one procedure, 'query'. Then you just need a way to switch to (foo test-database) which presumably gives you a mock version of 'query'.
2023-07-07 15:37:38 -0400 < sham1> Okay, and how do you do the switch? cond-expand?
2023-07-07 15:37:42 -0400 < Zipheir> Probably.
2023-07-07 15:38:48 -0400 < Zipheir> (cond-expand (testing (import (foo test-database) ...)) (else (import (foo database) ...)))
2023-07-07 15:39:12 -0400 < Zipheir> That doesn't seem too complicated.
2023-07-07 15:40:54 -0400 < Zipheir> It gets more complex if your libraries themselves need that kind of mocked testing.
2023-07-07 15:41:09 -0400 < gwatt> probably annoying to have to build in dependency injection to every librar you want to test though
2023-07-07 15:42:07 -0400 < Zipheir> So you'd probably only want to do than in your main executable.
2023-07-07 15:42:26 -0400 < Zipheir> But then, how do you test your database access library?
2023-07-07 15:42:26 -0400 < rgherdt> sham1: I was reading how racket does it: https://docs.racket-lang.org/mock/mock-guide.html
2023-07-07 15:42:44 -0400 < rgherdt> here procedures to be mocked are passed as arguments, as you mentioned
2023-07-07 15:43:25 -0400 < rgherdt> and mocks keep track of number of calls and so on
2023-07-07 15:44:59 -0400 < Zipheir> But then you have to pass procedures, which may be rather awkward and artificial.
2023-07-07 15:45:24 -0400 < sham1> Zipheir: Sure, but with cond-expand you're coupling your business logic with the way you are testing it. I'm more thinking of a solution like the following: <https://paste.debian.net/1285254/>
2023-07-07 15:45:30 -0400 < Zipheir> I don't know enough about testing/mocking practice to have an opinion, though.
2023-07-07 15:46:12 -0400 < sham1> Or one can pass it as individual procedures so one doesn't need to do this ((double-parenthesis-idiom))
2023-07-07 15:47:36 -0400 < sham1> Records would have to be used in lieu of interface types or typeclasses or what have you. It's what you'd do with a comparatort
2023-07-07 15:47:44 -0400 < Zipheir> sham1: My guess is that foo-database-query-customers and similar procedures would have to be "virtual methods" of the database object.
2023-07-07 15:47:57 -0400 < Zipheir> Yeah, same idea.
2023-07-07 15:48:28 -0400 < Zipheir> But that *really* complicates your main logic with testing infrastructure.
2023-07-07 15:49:12 -0400 < sham1> I also think that this would help refactoring on some cases
2023-07-07 15:49:40 -0400 < sham1> Because you're not coupled with the way a specific DB works and could change it for anything
2023-07-07 15:50:30 -0400 < gwatt> I've found that to be a myth. You're almost always coupled to how the DB works, even if you use some kind of query builder
2023-07-07 15:51:23 -0400 < Zipheir> sham1: Maybe so, but it wouldn't be good to require that kind of abstraction just to test the program.
2023-07-07 15:52:51 -0400 < sham1> Probably. Could always use something like parameters
2023-07-07 15:53:10 -0400 < sham1> Err, parameterize, so you don't even need to pass it as an explicit parameter
2023-07-07 15:53:18 -0400 < Zipheir> Then you're adding mutable global state.
2023-07-07 15:53:23 -0400 < Zipheir> Sort of.
2023-07-07 15:54:01 -0400 < Zipheir> I think modules/libraries are the best thing here. Parameterizable modules ("functors" in ML-speak) especially.
2023-07-07 15:55:41 -0400 < sham1> Hmm, gotta think about this. I'm thinking about this because... charitably I'd claim that this stuff hasn't always been the biggest priority in the Scheme community and I'd really like for that to change at least a bit
2023-07-07 15:56:48 -0400 < Zipheir> "Business logic" is just one of many things you can do with a programming language.
2023-07-07 15:57:12 -0400 < wasamasa> testing things in isolation feels so weird
2023-07-07 15:59:34 -0400 < gwatt> sham1: every once in a while the topic of "how do we make scheme attractive to more people" comes up, and I think it always misses the point. There's nothing you're going to add to scheme-the-family-of-languages that will make it more attractive. The way to attract people is to start writing cool things in scheme. If you write the kind of software that people want to use, then more people will
2023-07-07 15:59:36 -0400 < gwatt> start using scheme
2023-07-07 16:00:10 -0400 < Zipheir> It seems to me that the problem is that testing complex programs requires parameterization or some other extra layer of abstraction almost everywhere. That introduces a ton of complexity, which works against the benefits of testing.
2023-07-07 16:01:40 -0400 < sham1> I don't think that my pondering is specifically "make Scheme attractive to more people" per se
2023-07-07 16:02:17 -0400 < sham1> My thinking is more "how would I actually write that software"
2023-07-07 16:02:23 -0400 < sham1> Because honestly, I don't know
2023-07-07 16:03:40 -0400 < Zipheir> The database app, or the testing framework?
2023-07-07 16:03:52 -0400 < sham1> That example is contrived
2023-07-07 16:04:12 -0400 < Zipheir> Well, I don't know how I'd write a Web-style database app in Scheme.
2023-07-07 16:06:06 -0400 < Zipheir> The testing tools should be incredibly flexible to minimize changes to the architecture of the test-ee. Maybe that "Software Design for Flexibility" book would have some ideas.
2023-07-07 16:08:24 -0400 < sham1> These are things that are important to think about no matter if one is writing an HTTP API to be consumed by a frontend, a compiler for Scheme itself, or really any software of sufficient complexity
2023-07-07 16:12:07 -0400 < Zipheir> It's a rather different topic, but a type-checking or inferring interpreter or compiler for Scheme would be good for "robust" programs.
2023-07-07 16:12:29 -0400 < sham1> That would help
2023-07-07 16:12:46 -0400 < sham1>  Having typeclasses would make these things easier
2023-07-07 16:13:38 -0400 < sham1> And since you need some type inference to do certain kinds of optimisations, it'd be useful that way as well
2023-07-07 16:14:45 -0400 < Zipheir> Well, you'd have to jump into gradual typing, e.g. http://scheme2006.cs.uchicago.edu/13-siek.pdf
2023-07-07 16:15:56 -0400 < Zipheir> Typed Racket is probably the best existing model.
2023-07-07 16:19:58 -0400 < Zipheir> These days I'm confused when people argue typing versus testing. Typing is testing, and testing is type-checking which your compiler is too dumb for.
2023-07-07 16:24:04 -0400 < aeth> no
2023-07-07 16:24:15 -0400 < aeth> testing is "does it still break"?
2023-07-07 16:24:28 -0400 < aeth> running the compiler (which may include some type checks) is just the first stage
2023-07-07 16:24:47 -0400 < aeth> then you have to think of every other way to break it and type systems just aren't going to be enough
2023-07-07 16:25:48 -0400 < Zipheir> You haven't seen enough type systems.
2023-07-07 16:26:41 -0400 < aeth> You haven't seen enough programs.
2023-07-07 16:27:14 -0400 < aeth> Graphical (especially GPU-accelerated) and networking are probably going to be the toughest in general, including to test.
2023-07-07 16:27:32 -0400 < Zipheir> I know how big a problem we're talking about. But types, properly speaking, cover the full range of properties of a computation.
2023-07-07 16:27:55 -0400 < Zipheir> Unfortunately, we don't know how to express--let alone check--most of the properties.
2023-07-07 16:29:14 -0400 < sham1> Also you can't encode everything into types because you'll run into the Halting Problem
2023-07-07 16:29:18 -0400 < Zipheir> That's actually a real problem with sophisticated type systems (e.g. HoTT): you have to understand what you're doing.
2023-07-07 16:30:21 -0400 < Zipheir> sham1: That's sometimes a problem, which is, I guess, why languages like Idris require everything to terminate.
2023-07-07 16:30:43 -0400 < aeth> One issue with 3D acceleration is that you don't need it to be pixel perfect... you just need it to *look* correct.
2023-07-07 16:31:14 -0400 < aeth> Plenty of people are happy with upscaling so they can hit 4K/5K/8K without having the GPU to actually power it. In fact, 4k60 is still pretty hard to hit even with the top GPUs so the benchmarks almost always default to DLSS
2023-07-07 16:31:22 -0400 < Zipheir> And that's the other side of it. Sometimes the program just has to "satisfice".
2023-07-07 16:31:24 -0400 < aeth> (especially with ray tracing enabled)
2023-07-07 16:32:22 -0400 < Zipheir> Er, satisfy. That was a misuse of satisfice. Natural selection satisfices, programs satisfy.
2023-07-07 16:32:24 -0400 < aeth> and, yes, you could consider graphics as a special (pretty) case of numerical, where you just want it to be within a certain tolerance since you can't get exact
2023-07-07 16:32:49 -0400 < aeth> (I mean, portably exactly the same, anyway... which is why Scheme is right to call their flonums inexact)
2023-07-07 16:33:52 -0400 < aeth> at the very least you have x86-64, ARM (which ARM?), RISC-V... crossed with three different major GPUs (if you can call Intel major) and perhaps different behaviors across OSes let alone C compilers, etc.
2023-07-07 16:35:11 -0400 < Zipheir> I'm just saying that you can have a dependent type which "says" that a procedure invokes an effect handler which receives a login name from the user which is less than 128 characters, then returns that name as a string. It may be a pretty awful type, though.
2023-07-07 16:35:55 -0400 < Zipheir> The idea that "type" means "int, string, char" etc. is very old fashioned.
2023-07-07 16:37:11 -0400 < aeth> what's a string, is it a char*?
2023-07-07 16:37:13 -0400 < aeth> :-p
2023-07-07 16:37:26 -0400 < Zipheir> Well, that's just C barbarism. :-p
2023-07-07 17:05:02 -0400 < Zipheir> aeth: You made an interesting point about "good enough" tests. I guess that would relate to fuzzy type theory, if anyone has researched such a thing.
2023-07-07 17:08:40 -0400 < Zipheir> Hmm, no, that's entirely different.
2023-07-07 17:11:12 -0400 < wasamasa> and yet this barbarism made it into the XCB description of the X11 protocol
2023-07-07 17:11:23 -0400 < wasamasa> nobody says what a list of char is, but I'll pretend it's a C string
2023-07-07 17:11:36 -0400 < wasamasa> or a Pascal string?
2023-07-07 17:11:38 -0400 < wasamasa> I dunno really
2023-07-07 17:11:56 -0400 < wasamasa> maybe just a string
2023-07-07 20:00:23 -0400 < lechner> Hi, would Schemers get away with dropping 'quote' and simply using 'quasiquote' everywhere? I am squinting too hard
2023-07-07 20:01:36 -0400 < pony> what if you don't need quasiquote
2023-07-07 20:02:29 -0400 < lechner> i just wouldn't use any commas
2023-07-07 20:02:34 -0400 < aeth> as long as you don't unquote, quasiquote and quote are the same
2023-07-07 20:02:46 -0400 < aeth> you might be able to construct some nested quasiquotes where it changes the meaning
2023-07-07 20:02:55 -0400 < aeth> using more than one quasiquote quickly makes it unreadable, though
2023-07-07 20:03:15 -0400 < lechner> yeah, that's the one case I could potentially think of, but it seemed so unlikely
2023-07-07 20:04:27 -0400 < lechner> with my poor eye sight, I find it hard to distinguish quasiquotes from regular quotes
2023-07-07 20:05:06 -0400 < pony> oh, fair; my eyesight is bad too. I thought you were talking about the word versions.
2023-07-07 20:05:28 -0400 < lechner> no, it's the `''`'`'`''`''` business that troubles me
2023-07-07 20:05:33 -0400 < pony> hehe
2023-07-07 20:06:14 -0400 < lechner> they are so small, even different colors are unlikely to help
2023-07-07 20:06:14 -0400 < aeth> sometimes I use ` instead of ' even when I don't ,
2023-07-07 20:06:35 -0400 < aeth> because ` might change an editor's indentation because it's treating it as source code (given the use of ` in certain kinds of macros)
2023-07-07 20:10:02 -0400 < lechner> well, at least i am not alone
2023-07-07 20:17:25 -0400 < lechner> actually, i have a case where it would probably be confusing. in my reimagination of 'make' here the 'quote' here is 'quasiquoted' and is therefore evaluated later, but it would even more confusing to use 'quasiquote' as well          https://codeberg.org/lechner/bespoke/src/branch/history/examples/hello/make#L61-L65
2023-07-07 21:40:34 -0400 < Zipheir> lechner: The nice thing about quote is that you don't have to strain your eyes looking for a comma.
2023-07-07 21:41:49 -0400 < Zipheir> If you only use quasiquote, it won't be immediately clear when you're using the quasi-ness.
2023-07-07 22:25:06 -0400 < jcowan> I solve the ` vs ' problem by embiggening the font
2023-07-07 22:25:49 -0400 < jcowan> 16 pt font and 150% size
2023-07-07 23:29:27 -0400 < aeth> 'programmer fonts' might distinguish between them
2023-07-07 23:29:34 -0400 < aeth> also e.g. l vs 1 vs I
2023-07-07 23:40:33 -0400 < Zipheir> I wonder if there are any sugar-intolerant Schemers who always write out quote, quasiquote, & unquote.
2023-07-07 23:45:23 -0400 < mdhughes> My use case for the two is almost always different, quote for one symbol or short list, quasi for longer alists where I insert values. But I know I've mistyped it and not noticed before.
2023-07-07 23:45:45 -0400 < mdhughes> Probably if I was being cautious I'd write out quasiqutoe
2023-07-07 23:46:34 -0400 < mdhughes> Maybe make a macro, qq (don't cry)
--- Day changed Sat Jul 08 2023
2023-07-08 00:02:01 -0400 < klovett> Zipheir: (old news) i use |<violates symbol read but meets source domain naming conventions>| but you see the but
2023-07-08 00:11:29 -0400 < Zipheir> Haha!
2023-07-08 02:33:51 -0400 < sham1> In what source domain would that be appropriate
2023-07-08 03:15:01 -0400 < klovett> sham1: character names
2023-07-08 03:15:53 -0400 < sham1> Unicode?
2023-07-08 03:16:09 -0400 < klovett> yes
2023-07-08 11:26:18 -0400 < amirouche> :wq
2023-07-08 11:27:43 -0400 < sham1> Wrong window?
2023-07-08 12:41:36 -0400 < cow_2001> :|
2023-07-08 15:02:03 -0400 < Oxyd> Wrong editor?
2023-07-08 15:12:23 -0400 < sham1> I was intentionally not bringing that up
2023-07-08 15:19:16 -0400 < skeemer> people how can i perform effective troubleshooting with programs, coming from a python background where i have the whole stacktrace ifind it difficult in racket to just ahve generic error messages
2023-07-08 15:19:23 -0400 < skeemer> any advice?
2023-07-08 15:54:04 -0400 < Zipheir> rudybot: kernighan careful thought
2023-07-08 15:54:04 -0400 < rudybot> Zipheir: "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." --Kernighan
2023-07-08 15:54:14 -0400 < Zipheir> Sorry. I know that's not very helpful.
2023-07-08 15:55:22 -0400 < Zipheir> skeemer: If you paste the kind of thing you're having trouble, er, shooting, maybe we can give better suggestions.
2023-07-08 15:56:17 -0400 < sham1> If it's not helpful, you ain't got enough prints
2023-07-08 16:08:59 -0400 < Zipheir> There are also debuggers for most Scheme implementations.
2023-07-08 16:39:42 -0400 < rgherdt> skeemer: if you run your program by clicking on "Debug" and than on "Go", you get on the right pane stack information and local variables
2023-07-08 16:40:31 -0400 < rgherdt> you can also get a backtrace by clicking on the x's buttons on the left side of the error message
2023-07-08 16:41:25 -0400 < rgherdt> assuming you are using DrRacket
2023-07-08 16:42:26 -0400 < skeemer> rgherdt, i am using emacs with geiser
2023-07-08 16:42:37 -0400 < skeemer> is there a way to have the same info here?
2023-07-08 16:43:25 -0400 < rgherdt> hmm, I'm not sure. I did some experiments with racket-mode a while go, but couldn't get the same information. I didn't try long though
2023-07-08 16:47:45 -0400 < rgherdt> with racket-mode, by running with C-u F5 one gets the backtrace, but not the local variables
2023-07-08 17:08:46 -0400 < aeth> https://www.gnu.org/fun/jokes/ed-msg.html
2023-07-08 17:09:05 -0400 < aeth> I tried ":wq" in the only correct editor and all I got in response is "?"
2023-07-08 17:13:01 -0400 < Zipheir> "The intelligent user will usually know what went wrong."
2023-07-08 17:22:03 -0400 < jcowan> That editor does not like leading colons.  Or trailing colons.
2023-07-08 17:22:25 -0400 < jcowan> Or ascending, descending, or transverse colons, for that matter.
2023-07-08 17:35:04 -0400 < Oxyd> I, too, prefer not having ascending, descending or transverse colon on my screen.
2023-07-08 18:32:25 -0400 < Zipheir> rudybot: swat Oxyd
2023-07-08 18:32:26 -0400  * rudybot waves his Palm of Slapping® threateningly at Oxyd
2023-07-08 19:28:15 -0400 < haugh> Hello friends. Soon™ I will release a library which includes a slightly extended and heavily modified implementation of a SRFI. I'm a little unclear on the licensing for this situation. Are there any general guidelines I should read?
2023-07-08 19:30:01 -0400 < haugh> I include all Requested functions but each is my own implementation, written in the style enabled by the larger library. I have no issue including the full copyright text of the SRFI but I'd like to do it with SPDX format if acceptable.
2023-07-08 20:25:20 -0400 < jcowan> You have to preserve the original MIT copyright texts both for the SRFI and for whatever parts of the implementation you are reusing. However, you can place your work as a whole under any license you want.  As a matter of courtesy rather than law you should make clear just what you are adding and modifying in the SRFI itself.
2023-07-08 20:25:26 -0400 < jcowan> haugh: ^^
2023-07-08 20:58:04 -0400 < haugh> jcowan, so if the sample implementation contains no license information, it's covered by that of the SRFI document? I am in the process of explaining each deviation in-line and I will include a general notice at the top of the repository.
2023-07-08 20:59:36 -0400 < jcowan> Yes, the SRFI license normally covers the implementation too.  If not (as when the ipmlementation is BSD) it will say so.
2023-07-08 20:59:43 -0400 < haugh> It's one of yours, btw. I wouldn't ask you to donate your time to a review, but I will ping you when I go public, that you may bear witness to the abomination your machinations have /wrought/
2023-07-08 20:59:58 -0400 < haugh> Excellent
2023-07-08 21:00:01 -0400 < jcowan> I look forward to seeing it
2023-07-08 21:00:20 -0400 < jcowan> Which SRFI is it?
2023-07-08 21:00:43 -0400 < haugh> 235
--- Day changed Sun Jul 09 2023
2023-07-09 08:18:23 -0400 -!- dave69 is now known as dave0
2023-07-09 11:33:02 -0400 < geri> hey, how do i ignore an unbound variable error?
2023-07-09 11:33:09 -0400 < geri> using guile
2023-07-09 12:00:34 -0400 < Zipheir> geri: The standard way is to use 'guard' from (rnrs exceptions). In the REPL this still produces some extra warnings, but you do get a valid condition.
2023-07-09 12:01:10 -0400 < Zipheir> There may be some global flag that turns off unbound name warnings in general, but I can't imagine wanting to do that.
2023-07-09 12:07:49 -0400 < Zipheir> Using 'guard' to *ignore* an unbound variable is very clumsy, though. What you might want, I guess, is to treat the unbound name as a "hole" which can be filled by the exception handler. This is possible, but requires some more thought about the continuations involved.
2023-07-09 12:19:42 -0400 < geri> yeah, global would be a total overkill
2023-07-09 12:21:03 -0400 < geri> i got guix modules, some of which define both services and packages, others only have one, so the idea is to reduce boilerplate needed
2023-07-09 12:24:13 -0400 < haugh> geri, there are a few different ways to handle errors in Guile, which supports SRFI-35 conditions, try/catch, and complex exception objects based on continuations. It also has false-if-exception for that nice sunday afternoon error handling if you follow me. It sounds like you would be better served by learning the syntax systems, though. Guix' top level is pretty much all syntax, so if you want to streamline your interface with it, you'll need
2023-07-09 12:24:14 -0400 < haugh> macros.
2023-07-09 12:26:56 -0400 < geri> time for some sunday afternoon error handling B)
2023-07-09 12:27:19 -0400 < geri> oh, guess thats why guix errors tend to be so cryptic
2023-07-09 12:27:33 -0400 < geri> cause it's a lot of macros
2023-07-09 12:32:15 -0400 < geri> also thanks Zipheir haugh
2023-07-09 12:32:33 -0400 < haugh> Good luck
2023-07-09 12:33:03 -0400 < geri> thank
2023-07-09 12:50:32 -0400 < lechner> geri / you may also find this helpful     https://lepiller.eu/en/a-deep-dive-into-guix-records.html
2023-07-09 12:53:44 -0400 < Zipheir> I'm slightly surprised that unbound names raise Scheme conditions. It's a meta-Scheme error, really.
2023-07-09 12:54:05 -0400 < Zipheir> But we have set!, so the cow is out of the meta-barn.
2023-07-09 12:59:22 -0400 < lechner> For a relatively simple language, Scheme can get quite complicated. I have read this four times, and still only get about half of this article      https://en.wikipedia.org/wiki/Call-with-current-continuation
2023-07-09 13:11:35 -0400 < lechner> Hi, what does this sentence mean, please? The follow-on link is dead. "Prefer extension over embedding."     https://wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations
2023-07-09 13:12:58 -0400 < Zipheir> I think that's one of the central dogmas of OOP?
2023-07-09 13:13:46 -0400 < lechner> oh no! I'm on the other side      https://www.youtube.com/watch?v=QM1iUe6IofM
2023-07-09 13:14:52 -0400 < Zipheir> Hmm, I think it also relates to the Lisp tradition of extending the language, rather than embedding a "scripting" language as in C(++).
2023-07-09 13:15:57 -0400 < lechner> isn't that the opposite, then? ("Embedding" would then represent object encapsulation.)
2023-07-09 13:15:58 -0400 < Zipheir> Where mainstream programmers would embed Lua, say, Lispers generally extend Lisp, or implement the higher-level language within it.
2023-07-09 13:16:23 -0400 < Zipheir> I don't think so.
2023-07-09 13:16:54 -0400 < Zipheir> Embedding a language is a totally different thing from data encapsulation.
2023-07-09 13:17:11 -0400 < Zipheir> There are some interesting analogies, though.
2023-07-09 13:18:03 -0400 < lechner> You are right. The article juxtaposes Scheme with other languages
2023-07-09 13:18:15 -0400 < Zipheir> scsh is a great example of Lisp-style extension, instead of embedding.
2023-07-09 13:18:32 -0400 < Zipheir> scsh would be much weaker if it were just a Bourne shell with S-exp syntax.
2023-07-09 13:18:46 -0400 < lechner> i have been so curious about it. does anyone still use that?
2023-07-09 13:19:02 -0400 < lechner> i see
2023-07-09 13:21:30 -0400 < Zipheir> I use its process forms in CHICKEN programs: https://wiki.call-cc.org/eggref/5/scsh-process  The original scsh is in s9, I think, so I don't use it much.
2023-07-09 13:22:36 -0400 < Zipheir> Anyway, the nice thing about extending Scheme "up to" the language you want is that you can take all of Scheme with you.
2023-07-09 13:23:57 -0400 < Zipheir> "Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place." --Alan Perlis
2023-07-09 13:26:57 -0400 < geri> i'm thinking of implementing a custom way of doing modules in guix because current system hurts my eyes with the way file tree is structured
2023-07-09 13:27:05 -0400 < geri> coolest thing is nothing stops me from doing it :D
2023-07-09 13:27:54 -0400 < lechner> yeah, i am also doing a bunch of stuff on my own. it's really a great system
2023-07-09 13:30:26 -0400 < Zipheir> lechner: You might find call/cc a little easier to understand if you read about continuation-passing style first.
2023-07-09 13:34:08 -0400 < Zipheir> lechner: Matt Might has an OK intro: https://matt.might.net/articles/by-example-continuation-passing-style/
2023-07-09 13:35:10 -0400 < lechner> yeah, i read all about CPS when learned about Haskell's monads but have yet to see the connection to call/cc. thanks for the article referece
2023-07-09 13:36:25 -0400 < Zipheir> lechner: You can think of Scheme as being in "implicit" CPS. Every expression has a continuation that expects that expression's value. Using call/cc gives you that continuation.
2023-07-09 13:37:23 -0400 < Zipheir> Well, I guess it's slightly more complex since you get the continuation of the call/cc expression, not the body. But the idea's the same.
2023-07-09 13:38:24 -0400 < Zipheir> Maybe the best way to understand call/cc (or letcc) is to implement it.
2023-07-09 13:49:31 -0400 < lechner> it took me a year to understand the power of lambdas (or so I thought). it's really an amazing way to program
2023-07-09 13:53:32 -0400 < geri> i only understand using lambdas in higher order functions, care to share your perspective?
2023-07-09 13:55:51 -0400 < Zipheir> I'm also curious as to what lechner means.
2023-07-09 13:57:09 -0400 < geri> i know you can implement most/all of lisp in lambdas, but it's a little too high level for me
2023-07-09 13:57:48 -0400 < Zipheir> You can implement the universe (of computable functions) with lambda.
2023-07-09 13:58:13 -0400 < geri> yeah but can't you do that with named functions too?
2023-07-09 13:58:29 -0400 < Zipheir> Of course, but naming is extraneous.
2023-07-09 13:58:37 -0400 < geri> xd
2023-07-09 13:59:28 -0400 < geri> i like the way scheme does functions
2023-07-09 13:59:30 -0400 < Zipheir> All you need is the λ-calculus grammar and the α, β, and η reductions.
2023-07-09 14:00:07 -0400 < Zipheir> Yeah, yeah, the simple untyped calculus is ultimately self-contradictory, but it's the idea that counts.
2023-07-09 14:01:00 -0400 < Zipheir> geri: Strictly speaking, Scheme doesn't do functions, but procedures.
2023-07-09 14:02:04 -0400 < geri> is it only because the word "function" is so overloaded?
2023-07-09 14:02:15 -0400 < geri> gotta love me some dysfunctional programming
2023-07-09 14:02:59 -0400 < lechner> i meant the lambda calculus, i.e. the AND and OR here, as well as the Y combinator touched upon briefly     https://youtu.be/eis11j_iGMs?t=612
2023-07-09 14:03:18 -0400 < Zipheir> geri: Aside from rarely being mathematical functions, procedures can have side effects.
2023-07-09 14:03:35 -0400 < Zipheir> lechner: Absolutely.
2023-07-09 14:04:46 -0400 < geri> i mean, "functions" in (almost) every other programming language can do side effects as well
2023-07-09 14:05:00 -0400 < geri> that said it really is an unfortunate naming convention
2023-07-09 14:05:11 -0400 < Zipheir> lechner: Not to start a YouTube party, but Phil Wadler's talk about λ calculus (among other things) is very funny and interesting https://www.youtube.com/watch?v=IOiZatlZtGU
2023-07-09 14:05:33 -0400 < Zipheir> geri: Yeah.
2023-07-09 14:07:28 -0400 < Zipheir> Even the hardcore "functional" languages abuse the term: There's no way a Haskell procedure of type () -> IO a is a function.
2023-07-09 14:08:13 -0400 < Zipheir> Er, that would just be IO a. Anything involving IO, of course.
2023-07-09 14:08:39 -0400 < geri> i don't know any haskell, but sounds funny
2023-07-09 14:10:57 -0400 < lechner> geri / Zipheir / i think you are discussing the "pure" paradigm?       https://www.youtube.com/watch?v=iSmkqocn0oQ
2023-07-09 14:12:08 -0400 < lechner> sorry  about adding more youtube. we should at least switch to    https://invidious.io/
2023-07-09 14:13:09 -0400 < Zipheir> Is that Simon Peyton Jones talking about Haskell in an airport?
2023-07-09 14:13:55 -0400 < Zipheir> lechner: Thanks for the link. I didn't know about Invidious. I can't stand all of YouTube's tracking junk.
2023-07-09 14:16:04 -0400 < geri> it's a shame that one of the most useful web platforms is absolutely proprietary
2023-07-09 14:17:03 -0400 < lechner> if you even need a channel bot, i have been thinking about one that replaces youtube links with invidious in addition to some other services here     https://codeberg.org/lechner/guix-helper-bot/src/branch/history/scm/guix-helper-bot.scm
2023-07-09 14:17:08 -0400 < lechner> ever
2023-07-09 14:26:19 -0400 < lechner> one can get the best invidious instance via their search API       https://docs.invidious.io/search-filters/    and      https://github.com/iv-org/invidious/issues/1061
2023-07-09 14:27:23 -0400 < Zipheir> lechner: Thanks.
2023-07-09 14:28:05 -0400 < geri> is (define (main . args) ...) syntax a part of RXRS?
2023-07-09 14:29:03 -0400 < lechner> sorry, that's above my pay grade
2023-07-09 14:29:42 -0400 < lechner> credit for the invidious idea goes to whereiseveryone, tbw
2023-07-09 14:29:45 -0400 < lechner> btw
2023-07-09 14:30:06 -0400 < sham1> geri: there's an SRFI that gives you that
2023-07-09 14:31:23 -0400 < Zipheir> geri: That's R7RS syntax. I have to check whether R6 has it.
2023-07-09 14:32:06 -0400 < geri> aighty
2023-07-09 14:32:12 -0400 < Zipheir> Oh, it's been around since at least R5RS.
2023-07-09 14:32:47 -0400 < Zipheir> Here it is in R4, even: https://people.csail.mit.edu/jaffer/r4rs_7.html#SEC41
2023-07-09 14:36:24 -0400 < geri> i'm also curious - what's the current situation with portability across implementations?
2023-07-09 14:37:39 -0400 < Zipheir> Complicated, but not as bad as the rumors say. You can port things between implementations with some effort, depending on dependencies.
2023-07-09 14:38:45 -0400 < lechner> fibers?
2023-07-09 14:38:49 -0400 < Zipheir> Many SRFI and similar libraries are completely portable. OTOH, bindings for external libraries are usually non-portable.
2023-07-09 14:40:11 -0400 < geri> thankfully at least it's not that all libraries are unportable
2023-07-09 14:41:46 -0400 < geri> i've only ever had used guile so far, but this use case is really not portable anyway so i can use all the libraries i want
2023-07-09 14:42:10 -0400 < Zipheir> OK.
2023-07-09 14:42:16 -0400 < lechner> geri / your guix efforts, or are you writing something else?
2023-07-09 14:43:18 -0400 < geri> i use emacs lisp just for configurations, guile just for guix and used common lisp for memes like writing a cli chess game
2023-07-09 14:43:49 -0400 < geri> i feel like a big boy :D
2023-07-09 15:16:39 -0400 < geri> is accumulating data in closures considered functional or is it side effects?
2023-07-09 15:34:33 -0400 < Zipheir> geri: Accumulating is "functional".
2023-07-09 15:34:58 -0400 < geri> aighty
2023-07-09 15:35:25 -0400 < geri> found my first use case for closures just now
2023-07-09 15:44:21 -0400 < Zipheir> But that "pure functional" language can be misleading. In some models, memory access is seen as an effect, so closure allocation (or reference, depending on scoping discipline) might be effectful.
2023-07-09 15:44:31 -0400 < Zipheir> s/scoping/binding/
2023-07-09 15:45:53 -0400 < Zipheir> That's not important for mundane purposes, but I recommend keeping in mind that an "effect" is not very well defined.
2023-07-09 15:46:50 -0400 < geri> oki, thanks
2023-07-09 15:49:12 -0400 < dinomug> Mostly a side effect is considered undefined behavior.
2023-07-09 15:56:52 -0400 < Zipheir> What?
2023-07-09 15:57:30 -0400 < Zipheir> vector-set! has side effects, and they're as defined as anything in the Scheme semantics.
2023-07-09 15:58:26 -0400 < jcowan> lechner: see https://wiki.c2.com/?EmbedVsExtend
2023-07-09 16:03:58 -0400 < Zipheir> jcowan: Thanks.
2023-07-09 16:08:52 -0400 < Zipheir> The argument seems a bit incoherent. Anyone who uses an extension would, by this logic, be "embedding it", since they now depend on it.
2023-07-09 16:09:59 -0400 < Zipheir> The CLI is a poor example, since every shell script "embeds" dozens of other programs and breaks without them.
2023-07-09 16:15:37 -0400 < Zipheir> The two ideas seem intertwined, unless you never write embeddable extensions.
2023-07-09 16:15:46 -0400 < skeemer> can somebody help me understanding a bit of The Little Schemer ? Page 138, last question, it talks about collectors and then says collector is sometimes called "continuation"
2023-07-09 16:16:09 -0400 < skeemer> but i am confused, what's the pupose of that ? i can't understand the function multirember&co
2023-07-09 16:16:14 -0400 < skeemer> can somebody help me?
2023-07-09 16:16:33 -0400  * Zipheir grabs his copy.
2023-07-09 16:18:54 -0400 < Zipheir> skeemer: *col* is the continuation of multirember&co: it accepts whatever values it produces.
2023-07-09 16:19:23 -0400 < Zipheir> skeemer: This is because multirember&co produces two values, and The Little Schemer doesn't use 'values'.
2023-07-09 16:25:17 -0400 < skeemer> Zipheir, i don't know what a continuation is
2023-07-09 16:25:19 -0400 < Zipheir> As for the CPS pattern here, consider that this is a kind of 'length': (define (length-cps lis k) (if (null? lis) (k 0) (length-cps (cdr lis) (lambda (len*) (k (+ len* 1))))))
2023-07-09 16:25:30 -0400 < skeemer> what does it mean "it accepts whatever values it produces"
2023-07-09 16:25:34 -0400 < skeemer> i am more confused
2023-07-09 16:25:40 -0400 < skeemer> what is CPS
2023-07-09 16:25:41 -0400 < skeemer> ahahah
2023-07-09 16:25:45 -0400 < Zipheir> A 'continuation' here just means a procedure.
2023-07-09 16:25:53 -0400 < skeemer> why it's called like that?
2023-07-09 16:25:54 -0400 < skeemer> then
2023-07-09 16:25:57 -0400 < skeemer> what is CPS
2023-07-09 16:26:08 -0400 < Zipheir> Continuation-passing style.
2023-07-09 16:26:48 -0400 < Zipheir> skeemer: Let's say you want to write a procedure that returns two values, and you don't have multi-valued procedures. What's one way to do it?
2023-07-09 16:28:33 -0400 < skeemer> Zipheir, what does it mean multi-valued procedures?
2023-07-09 16:28:40 -0400 < skeemer> procedures who can return multiple values?
2023-07-09 16:28:42 -0400 < Zipheir> Right.
2023-07-09 16:28:44 -0400 < skeemer> i would just return a list
2023-07-09 16:28:45 -0400 < skeemer> or a pair
2023-07-09 16:29:06 -0400 < skeemer> what's the problem with that
2023-07-09 16:29:07 -0400 < Zipheir> Well, yes, of course. :)  But there's another way.
2023-07-09 16:29:25 -0400 < Zipheir> Let's say you're *terrified* of unneeded consing. :)
2023-07-09 16:29:59 -0400 < Zipheir> Which is the way multirember&co does it.
2023-07-09 16:30:54 -0400 < Zipheir> Note that it never returns anything. Instead, multirember&co always invokes the procedure argument *col* on some values.
2023-07-09 16:32:04 -0400 < Zipheir> The recursion is a little bit complicated, but the book does walk you through it (pages 139 & 140)
2023-07-09 16:33:13 -0400 < lechner> jcowan / thanks!
2023-07-09 16:34:58 -0400 < Zipheir> skeemer: So the book uses, for *col*, the function a-friend, which is basically (lambda (x y) (null? y)). It "accepts" the two values x and y from multirember&co and says whether the second was ().
2023-07-09 16:35:51 -0400 < geri> gtg, have nice rest of the day everyone
2023-07-09 16:36:01 -0400 < Zipheir> geri: Bye, thanks for chatting. :)
2023-07-09 16:36:06 -0400 < geri> )
2023-07-09 16:36:14 -0400 < lechner> bye
2023-07-09 16:37:01 -0400 < Zipheir> skeemer: If you instead passed 'list' as *col*, you'd get back a two-list containing multirember&co's results. Does this make any sense?
2023-07-09 16:51:32 -0400 < skeemer> Zipheir, okj hold on i am going to re-read maybe slower and with a piece of paper
2023-07-09 16:51:39 -0400 < skeemer> i guess i am reaching the hard part of the book
2023-07-09 16:51:46 -0400 < skeemer> i guess the last pages will be hell on earth
2023-07-09 16:52:05 -0400 < Zipheir> The hard chapter is "... and again and again ...", IIRC
2023-07-09 16:52:20 -0400 < skeemer> Zipheir, you mean chapter 9 ?
2023-07-09 16:52:25 -0400 < skeemer> wow this is intimidating
2023-07-09 16:52:39 -0400 < skeemer> i don't know how i will be able to read The Seasoned Schemer after this
2023-07-09 16:53:18 -0400 < Zipheir> Yes, chapter 9 is where the lambdas really start propagating.
2023-07-09 16:54:30 -0400 < skeemer> oh god
2023-07-09 16:54:45 -0400 < skeemer> and then the seasoned schemer is even more complex i guess
2023-07-09 16:54:50 -0400 < Zipheir> It is not the friendliest introduction to the Y combinator. Michaelson's book presents it better, IMO.
2023-07-09 16:54:58 -0400 < Zipheir> Seasoned is not nearly as hard.
2023-07-09 16:55:44 -0400 < Zipheir> The only tricky thing I remember from that book is letcc (AKA call/cc with a little syntactic sugar).
2023-07-09 16:55:54 -0400 < skeemer> Who is Michaelson's book ?
2023-07-09 16:56:14 -0400 < Zipheir> This one: https://www.amazon.com/Introduction-Functional-Programming-Calculus-Mathematics/dp/0486478831
2023-07-09 16:56:43 -0400 < Zipheir> Also here https://www.cs.rochester.edu/~brown/173/readings/LCBook.pdf
2023-07-09 16:57:55 -0400 < Zipheir> Hmm, there used to be a nicer PDF. Anyway, it's a good book.
2023-07-09 16:58:59 -0400 < Zipheir> skeemer: Chapter 9 can be summed up by saying: You can implement recursion with only lambda. In particular, you don't need to name anything.
2023-07-09 16:59:25 -0400 < Zipheir> "How" is very fascinating.
2023-07-09 17:01:05 -0400 < dinomug> Great, never heard of that book, thanks for sharing :)
2023-07-09 17:04:40 -0400 < Zipheir> It's been reprinted by Dover, so it's fairly inexpensive.
2023-07-09 17:10:31 -0400 < lechner> Zipheir / Thanks! Together with the Wadler video from earlier, that's the second reference connecting the lambda calculus to the incompleteness theorems. That connection, which I had not explored previously, helped me rationalize my own fascination with the lambda calculus and provided some closure after leaving science over Goedel many years ago
2023-07-09 17:18:48 -0400 < Zipheir> lechner: Sounds like an interesting story. I'm glad you liked the video. :)
2023-07-09 17:20:06 -0400 < lechner> yeah, saved by Scheme!
2023-07-09 17:20:20 -0400 < skeemer> what video??
2023-07-09 17:20:36 -0400 < Zipheir> "It's like busses! You want 2000 years for a definition of effective computability, and then three come along at once." (My favorite quote from the Wadler lecture)
2023-07-09 17:21:01 -0400 < lechner> skeemer / today 11:05 Pacific
2023-07-09 17:21:16 -0400 < Zipheir> skeemer: https://www.youtube.com/watch?v=IOiZatlZtGU  It's hilarious, actually.
2023-07-09 17:22:04 -0400 < skeemer> tack!
2023-07-09 17:22:42 -0400 < lechner> i knew some swedish once!
2023-07-09 17:22:50 -0400 < lechner> here is the invidious link    https://yewtu.be/watch?v=IOiZatlZtGU
2023-07-09 17:23:19 -0400 < Zipheir> lechner: Thanks. That works nicely for me.
2023-07-09 18:34:39 -0400 < skeemer> Zipheir, this is starting to be mindblowing already
2023-07-09 18:34:44 -0400 < skeemer> wow
2023-07-09 18:34:51 -0400 < skeemer> i found this... https://web.archive.org/web/20201109005927/http://www.michaelharrison.ws/weblog/2007/08/unpacking-multiremberco-from-tls/
2023-07-09 18:34:52 -0400 < rudybot> https://teensy.info/1krV8OB4uB
2023-07-09 18:35:50 -0400 < skeemer> i am starting to understand now but i lack  the ability of reasoning with such functions i guess now
2023-07-09 18:42:15 -0400 < Zipheir> skeemer: Looks helpful!
2023-07-09 18:42:47 -0400 < skeemer> Zipheir, actually i was trying to follow step by step
2023-07-09 18:43:03 -0400 < skeemer> but i have a problem when i try to create helper functions called when-differ, when-match
2023-07-09 18:43:13 -0400 < skeemer> and put them in the function multirember&co instead of the lambdas
2023-07-09 18:43:33 -0400 < skeemer> i have an arity-mismatch issue
2023-07-09 18:43:39 -0400 < skeemer> do you know how can i fix it ?
2023-07-09 18:44:05 -0400 < Zipheir> skeemer: Can you paste it?
2023-07-09 18:44:08 -0400 < skeemer> yes
2023-07-09 18:44:14 -0400 < skeemer> actually is the same code of the link
2023-07-09 18:44:32 -0400 < skeemer> take the definition of multirember&co which has when-match and when-differ functions
2023-07-09 18:44:47 -0400 < skeemer> and remember to copy paste also the when-match when-differ
2023-07-09 18:44:54 -0400 < skeemer> wait let me see if i can do it for you
2023-07-09 18:45:34 -0400 < skeemer> Zipheir, here you are https://bpa.st/ACNUW
2023-07-09 18:46:20 -0400 < skeemer> Zipheir, i will also send you the working example with the lambda expressions instead of the helper functions
2023-07-09 18:46:20 -0400 < skeemer> https://bpa.st/OUBCC
2023-07-09 18:46:26 -0400 < Zipheir> Looks good.
2023-07-09 18:46:28 -0400 < skeemer> in each snippet you have test cases
2023-07-09 18:46:52 -0400 < Zipheir> Splitting out the cases does make it a little easier to read.
2023-07-09 18:47:10 -0400 < skeemer> Zipheir, yes indeed but... it gives me an arity mismatch
2023-07-09 18:47:39 -0400 < skeemer> it says expected 2 and given 0
2023-07-09 18:47:59 -0400 < Zipheir> skeemer: What's the difference between when-differ and (when-differ)?
2023-07-09 18:48:10 -0400 < skeemer> ohh right
2023-07-09 18:48:39 -0400 < Zipheir> Yeah, you don't want to apply the procedure.
2023-07-09 18:48:56 -0400 < skeemer> yes
2023-07-09 18:49:00 -0400 < skeemer> hold on another issue now
2023-07-09 18:49:07 -0400 < Zipheir> You have another problem, though: *col* isn't defined in the helper functions.
2023-07-09 18:49:09 -0400 < skeemer> it says col is undefined
2023-07-09 18:49:15 -0400 < Zipheir> Right.
2023-07-09 18:49:17 -0400 < skeemer> exactly
2023-07-09 18:49:55 -0400 < skeemer> how do i solve this actually ?
2023-07-09 18:49:56 -0400 < skeemer> Zipheir,
2023-07-09 18:50:24 -0400 < Zipheir> This is where the original version is easier to understand.
2023-07-09 18:50:37 -0400 < Zipheir> To use the helper functions, you're going to have to pass them *col*.
2023-07-09 18:51:11 -0400 < Zipheir> And they're going to have to return new collectors. In other words, they'll have to be curried.
2023-07-09 18:51:29 -0400 < Zipheir> Hmm, I wonder if that blog post does that.
2023-07-09 18:52:23 -0400 < skeemer> Zipheir, the blog post does not do that
2023-07-09 18:52:36 -0400 < skeemer> and some snippets of code have issues like then one youspotted with parenthesis
2023-07-09 18:52:42 -0400 < skeemer> from my side it was a copy paste
2023-07-09 18:53:07 -0400 < Zipheir> I don't know how they solve it, then.
2023-07-09 18:53:41 -0400 < skeemer> probably the example is more to show the concept than having working code
2023-07-09 18:53:52 -0400 < skeemer> but how would you solve it if you had to modify that code?
2023-07-09 18:54:01 -0400 < Zipheir> I'm going to paste it, one second.
2023-07-09 18:54:07 -0400 < skeemer> i mean if i pass col to the helper functions, how do i modify accordingly  ?
2023-07-09 18:54:09 -0400 < skeemer> thanks a lot
2023-07-09 18:56:07 -0400 < Zipheir> Hmm, they also forgot to pass *lat* to the helpers.
2023-07-09 18:57:38 -0400 < Zipheir> skeemer: http://ix.io/4Acb  Fixed.
2023-07-09 18:57:58 -0400 < Zipheir> I still think the version from the book is a lot clearer.
2023-07-09 19:01:07 -0400 < Zipheir> skeemer: It might help to try to write 'list-copy' in the same style. In fact, I wish the Little Schemer had a simple example like that first.
2023-07-09 19:01:23 -0400 < skeemer> list-copy ?
2023-07-09 19:01:29 -0400 < skeemer> what do you mean?
2023-07-09 19:01:55 -0400 < Zipheir> e.g. (list-copy&co lat col) which just copies every cons of lat and calls col on it.
2023-07-09 19:02:29 -0400 < Zipheir> It's nearly trivial in direct style: (define (list-copy lis) (if (null? lis) '() (cons (car lis) (list-copy (cdr lis)))))
2023-07-09 19:02:55 -0400 < skeemer> Zipheir, thanks for your fix i love it!
2023-07-09 19:03:10 -0400 < skeemer> Zipheir, ok i will try your other example
2023-07-09 19:04:07 -0400 < Zipheir> The skeleton is (define (list-copy&co lat col) (if (null? lat) (col ...) (list-copy&co (cdr lat) (lambda ...))))
2023-07-09 19:04:34 -0400 < Zipheir> It's the same idea as in multirember&co.
2023-07-09 19:05:09 -0400 < skeemer> sorry can you write the full example?
2023-07-09 19:05:47 -0400 < skeemer> Zipheir, do you have a blog/website by any chance ? or some software you wrote? i would follow it really gladly
2023-07-09 19:08:14 -0400 < Zipheir> skeemer: You can look at my github page; I've done a number of SRFI implementations. https://github.com/Zipheir?tab=repositories
2023-07-09 19:09:44 -0400 < Zipheir> skeemer: That reminds me, there's a hairier but similar procedure in the SRFI 224 sample implementation https://github.com/Zipheir/integer-map/blob/master/trie.scm#L122
2023-07-09 19:11:42 -0400 < Zipheir> That's building tries instead of lists, but it does it by the same procedure-passing recursive strategy.
2023-07-09 19:12:00 -0400 < skeemer> Zipheir, i don't understand how can you become efficient at reading such code
2023-07-09 19:14:44 -0400 < Zipheir> skeemer: I guess you start by reading The Little Schemer. :) The patterns become more familiar, but I still have trouble understand the recursion patterns on unusual structures.
2023-07-09 19:15:04 -0400 < Zipheir> skeemer: Also, you graduate to folds.
2023-07-09 19:15:15 -0400 < Zipheir> maps, unfolds, etc.
2023-07-09 19:15:30 -0400 < skeemer> Zipheir, for which scheme implementation did you implement your srfi ?
2023-07-09 19:15:44 -0400 < skeemer> ok i don't know what folds are
2023-07-09 19:16:01 -0400 < skeemer> maps i guess like the map in map,reduce
2023-07-09 19:16:37 -0400 < Zipheir> The full SRFI impl. should be portable to anything R[67]RS with minor changes https://github.com/scheme-requests-for-implementation/srfi-224
2023-07-09 19:16:55 -0400 < Zipheir> Map/reduce is a similar idea, yeah.
2023-07-09 19:17:43 -0400 < Zipheir> Folds capture the common recursive patterns for structures. 95% of what happens in The Little Schemer is just a right fold of some sort.
2023-07-09 19:18:20 -0400 < Zipheir> skeemer: https://srfi.schemers.org/srfi-1/srfi-1.html#FoldUnfoldMap
2023-07-09 19:19:24 -0400 < skeemer> Zipheir, wooow ahaha ok i didn't know that
2023-07-09 19:20:21 -0400 < Zipheir> There are some famous simple examples, like summing a list of numbers: (fold + 0 list-of-numbers)
2023-07-09 19:21:03 -0400 < Zipheir> Concatenating a list of lists: (fold-right append '() list-of-lists), etc.
2023-07-09 19:21:06 -0400 < skeemer> i read that, it's beautiful
2023-07-09 19:21:33 -0400 < skeemer> Zipheir, i am still sytuck on the copylist&co example
2023-07-09 19:21:37 -0400 < skeemer> trying to write it
2023-07-09 19:22:21 -0400 < Zipheir> OK, sorry, I'll stop distracting you.
2023-07-09 19:23:19 -0400 < skeemer> no no it was not that :)
2023-07-09 19:23:33 -0400 < skeemer> actually it was jsut to say that i am trying to write it and i may need some help probably
2023-07-09 19:23:53 -0400 < Zipheir> No problem.
2023-07-09 19:24:10 -0400 < skeemer> i am still confused by this simple example
2023-07-09 19:24:18 -0400 < Zipheir> Did you figure out the base case?
2023-07-09 19:25:06 -0400 < skeemer> yes
2023-07-09 19:25:16 -0400 < skeemer>  [(null? lat) (col '())]
2023-07-09 19:25:31 -0400 < skeemer> since in the last example we were kind of copying two lists now just one
2023-07-09 19:25:49 -0400 < Zipheir> Right.
2023-07-09 19:26:49 -0400 < Zipheir> So the recursive case is (listcopy&co (cdr lis) col*), where col* is what you have to figure out.
2023-07-09 19:27:49 -0400 < skeemer> i thought it was just a matter of copying the helper function you wrote
2023-07-09 19:29:01 -0400 < skeemer> i mean is there a strategy/recipe to reason with these things?
2023-07-09 19:29:08 -0400 < Zipheir> I'm just calling it col* to give it a name. The basic thing to notice is that col* must be List -> List (i.e. it takes a list and returns one).
2023-07-09 19:29:29 -0400 < Zipheir> Always try to work out the types first, I think.
2023-07-09 19:29:38 -0400 < skeemer> and are these mechanisms actually just a way to use lambda functions to return multiple return values?
2023-07-09 19:30:07 -0400 < Zipheir> That's one way to use them.
2023-07-09 19:30:22 -0400 < Zipheir> But you don't need that trick in standard Scheme, since we have multiple values.
2023-07-09 19:30:25 -0400 < skeemer> what are other ways ?
2023-07-09 19:31:58 -0400 < Zipheir> There are many, many applications, especially in compilers and interpreters.
2023-07-09 19:32:24 -0400 < Zipheir> This is the tip of the CPS iceberg, and CPS, as Will Byrd says, "is the gateway drug of program transformation".
2023-07-09 19:36:15 -0400 < skeemer> ahahah
2023-07-09 19:36:26 -0400 < skeemer> ok i did it i guess can you double check it ?
2023-07-09 19:36:31 -0400 < Zipheir> Sure.
2023-07-09 19:36:36 -0400 < skeemer> but i tried to reason depending on what i knew in the other example
2023-07-09 19:37:07 -0400 < skeemer> https://bpa.st/DKVFE Zipheir
2023-07-09 19:37:45 -0400 < Zipheir> Exactly. Can you condense it into one procedure now?
2023-07-09 19:38:10 -0400 < skeemer> you mean without the helper function ?
2023-07-09 19:39:21 -0400 < Zipheir> Right.
2023-07-09 19:39:32 -0400 < skeemer> i mean it's pretty straightforward i would say
2023-07-09 19:39:54 -0400 < skeemer> i mean i am still not 100 percent sure of what i am doing, like i probably need other exercises on these things
2023-07-09 19:40:00 -0400 < skeemer> is this a continuation then?
2023-07-09 19:40:13 -0400 < skeemer> what defines a continuation?
2023-07-09 19:40:20 -0400 < Zipheir> col is a continuation, yes.
2023-07-09 19:40:29 -0400 < skeemer> what characterizes a continuation
2023-07-09 19:40:32 -0400 < Zipheir> In Scheme, a continuation is indistinguishable from a procedure.
2023-07-09 19:40:48 -0400 < skeemer> ok but in general i mean
2023-07-09 19:40:56 -0400 < Zipheir> A continuation is "the future of a computation".
2023-07-09 19:41:09 -0400 < skeemer> ahahah oh my god :)
2023-07-09 19:41:29 -0400 < skeemer> how should i think when i design a procedureusinga a computation ?
2023-07-09 19:41:42 -0400 < skeemer> or when can i get exercises on continuations to write so that i can understand better ?
2023-07-09 19:41:48 -0400 < Zipheir> Maybe it sounds less magical to say that it's the thing that's expecting the result of a computation.
2023-07-09 19:42:04 -0400 < zzz> skeemer: do you have a current understanding of what a continuation is?
2023-07-09 19:42:10 -0400 < Zipheir> The Seasoned Schemer covers them a bit more.
2023-07-09 19:42:36 -0400 < skeemer> zzz, no that's what i am trying to understand
2023-07-09 19:42:41 -0400 < Zipheir> See also https://en.wikipedia.org/wiki/Continuation#First-class_continuations
2023-07-09 19:42:57 -0400 < skeemer> i knew it was the mechanism through which exception mechanisms are built
2023-07-09 19:43:01 -0400 < skeemer> or something like that
2023-07-09 19:43:08 -0400 < Zipheir> I like the example from the Perl list on the WP page.
2023-07-09 19:46:05 -0400 < skeemer> ok so i guess call/cc in scheme is some sintactic sugar for what i am writing now
2023-07-09 19:46:12 -0400 < Zipheir> skeemer: Incidentally, one other reason to write list-copy that way is that it's tail-recursive.
2023-07-09 19:46:54 -0400 < Zipheir> (The result is accumulated in the collector, and not on "the stack".)
2023-07-09 19:47:33 -0400 < Zipheir> call/cc is a bit more magical.
2023-07-09 20:30:05 -0400 < skeemer> Zipheir, i was wondering, how do can i identify a function using a collector/continuation?
2023-07-09 20:30:21 -0400 < skeemer> i mean does this happen when in the base case we call the continuation function?
2023-07-09 20:32:57 -0400 < Zipheir> I'm not sure what you mean by "identify".
2023-07-09 20:33:41 -0400 < Zipheir> The Little Schemer gives them names ending in -&co, but that's hardly a universal practice. Usually, they're procedures that take an extra procedure argument.
2023-07-09 21:17:54 -0400 < zzz> there was a talk showing the relationship between continuations and scope with live programming in lisp iirc but my memory fails me
2023-07-09 21:18:22 -0400 < zzz> which served as a great intro to what continuations are
2023-07-09 21:28:16 -0400 < skeemer> Zipheir, ok but a function which just takes another function as an argument can be also other things
2023-07-09 21:28:21 -0400 < skeemer> it is not necessarily a continuation
2023-07-09 21:28:39 -0400 < skeemer> so my point was, if i am reading some code, how can i identify the usage of a continuation?
2023-07-09 22:15:00 -0400 < Zipheir> skeemer: There's no general way to tell without reading through the code carefully. A continuation-passing procedure never returns (it always tail-calls its continuation), but you have to look carefully to see *that*, as well.
2023-07-09 22:16:22 -0400 < Zipheir> This is why good comments are important.
2023-07-09 22:21:07 -0400 < skeemer> Zipheir, ok i have another doubt
2023-07-09 22:21:12 -0400 < skeemer> i went on with the book
2023-07-09 22:21:28 -0400 < skeemer> and it's quite satisfying since it looks like i am understanding how to build code using collectors/continuations
2023-07-09 22:21:50 -0400 < skeemer> but at page 143, i built multiinsertLR&co
2023-07-09 22:22:11 -0400 < skeemer> and i don't know why inboth my implementation and the one in the book the result is a pair where i would expect just a number
2023-07-09 22:22:56 -0400 < skeemer> Zipheir, this is the working code snippet  https://bpa.st/S3JAE
2023-07-09 22:23:17 -0400  * Zipheir looks.
2023-07-09 22:23:21 -0400 < skeemer> can you help me understand why the evaluation of the result is a pair when i just expcted a number ?
2023-07-09 22:24:02 -0400 < skeemer> so my idea was, in the collector function, res is the resulting list, c1 is the first counter and c2 is the second counter
2023-07-09 22:24:23 -0400 < skeemer> so when i ask about c1 i would expect just a number, so the number of times something has been inserted on the left
2023-07-09 22:25:03 -0400 < skeemer> but I get a pair, where te first element is the result "res" and the second number is the expected number, so i get ( res . c1 ) instead of just c1
2023-07-09 22:25:26 -0400 < Zipheir> Yes, c1 should be a number.
2023-07-09 22:25:46 -0400 < Zipheir> Looks like there's a rogue 'cons' somewhere.
2023-07-09 22:26:08 -0400 < skeemer> Zipheir, this is the book solution actually
2023-07-09 22:26:14 -0400 < skeemer> my implementation had the same problem
2023-07-09 22:26:17 -0400 < skeemer> anyway
2023-07-09 22:28:30 -0400 < skeemer> hold on
2023-07-09 22:28:33 -0400 < skeemer> it works!
2023-07-09 22:28:46 -0400 < skeemer> i don't know what i changed but it works actually it is the same code
2023-07-09 22:28:54 -0400 < skeemer> :( i don't know what was the problem then
2023-07-09 22:29:19 -0400 < Zipheir> Yeah, I just ran it with no issue.
2023-07-09 22:29:57 -0400 < Zipheir> (multiinsertLR&co2 'f 'tl 'tr '(tl a tr tr) list) => ((f tl a tr f tr f) 1 2) as expected.
2023-07-09 22:30:06 -0400 < skeemer> Zipheir, ok sorry on the same track.. then, what's the issue with my implementation which actually gives the problem described above
2023-07-09 22:30:16 -0400 < skeemer> i am about to send you the snippet
2023-07-09 22:30:42 -0400 < skeemer> https://bpa.st/2OIAO
2023-07-09 22:30:45 -0400 < skeemer> here it is
2023-07-09 22:30:58 -0400  * Zipheir looks
2023-07-09 22:31:18 -0400 < skeemer> basically instead of putting the construction of the list inside the collector i have it outside, and it works... it's just that i have a pair at the end for some reason
2023-07-09 22:31:33 -0400 < Zipheir> Ah, this mixes CPS and direct recursion. That's likely the problem.
2023-07-09 22:32:10 -0400 < Zipheir> skeemer: It breaks the cardinal rule of collector procedures: Never return anything.
2023-07-09 22:32:56 -0400 < skeemer> Zipheir, actually i don't see a big difference
2023-07-09 22:33:15 -0400 < Zipheir> skeemer: Try walking through what happens with (multiinsertLR&co2 'f 'tl 'tr '(tl))
2023-07-09 22:33:38 -0400 < Zipheir> You can use the fudge toppings. I just wrote it that way for brevity.
2023-07-09 22:33:40 -0400 < skeemer> Zipheir, you lack an argument there
2023-07-09 22:33:44 -0400 < skeemer> the lambda
2023-07-09 22:33:45 -0400 < Zipheir> Indeed.
2023-07-09 22:33:59 -0400 < Zipheir> (lambda (res c1 c2) c1), as in the example.
2023-07-09 22:34:27 -0400 < skeemer> you mean with my implementation or the right TLS one?
2023-07-09 22:34:27 -0400 < Zipheir> In particular, what happens to the result of (col '() 0 0)?
2023-07-09 22:34:48 -0400 < Zipheir> Your implementation.
2023-07-09 22:36:37 -0400 < skeemer> Zipheir, again, i have the right result but just some pairs instead of numbers
2023-07-09 22:36:55 -0400 < skeemer> the pairs contain the right resulting list . the number i expect
2023-07-09 22:37:20 -0400 < Zipheir> But the implementation is still broken.
2023-07-09 22:37:21 -0400 < skeemer> and if i just ask about the res, then it is completely correct
2023-07-09 22:37:29 -0400 < skeemer> sure, but i don't understand why
2023-07-09 22:37:39 -0400 < skeemer> and how to fix it by keeping my structure
2023-07-09 22:38:28 -0400 < Zipheir> The problem, again, is that it mixes collection with direct recursion.
2023-07-09 22:38:50 -0400 < skeemer> ok so are these two different styles of recursion ?
2023-07-09 22:38:57 -0400 < Zipheir> skeemer: Try this as your *col* and see the fun: (lambda (res c1 c2) (display c1)))
2023-07-09 22:39:06 -0400 < Zipheir> Oops, one too many left parens.
2023-07-09 22:40:15 -0400 < skeemer> i see something weird in the minibuffer
2023-07-09 22:41:12 -0400 < Zipheir> You'll get some output, then a value which is an improper list with #<void> or #<unspecified> in its tail.
2023-07-09 22:42:08 -0400 < skeemer> Zipheir, exactly!
2023-07-09 22:42:16 -0400 < skeemer> what does it mean?
2023-07-09 22:42:45 -0400 < skeemer> Zipheir, as a side not, are there other commonly used styles of recursion behind CPS and direct recursion?
2023-07-09 22:42:46 -0400 < Zipheir> It means you're passing values to col, then consing stuff onto whatever col returns.
2023-07-09 22:43:04 -0400 < Zipheir> There are many kinds of tree recursion.
2023-07-09 22:44:04 -0400 < Zipheir> skeemer: Compare your implementation with what the book has. You'll notice that they don't use the return value of multiinsertLR&co--because it doesn't return anything.
2023-07-09 22:44:33 -0400 < skeemer> tree recursion Zipheir  ?
2023-07-09 22:44:40 -0400 < skeemer> ohh when i call the function twice right ?
2023-07-09 22:44:54 -0400 < skeemer> where can i learn about these different styles ?
2023-07-09 22:46:02 -0400 < Zipheir> I'd recommend Bird & Wadler's classic Introduction to Functional Programming, or its recent reincarnation, Thinking Functionally.
2023-07-09 22:47:03 -0400 < Zipheir> You can find PDFs in the usual places. Bird & Wadler is totally out of print.
2023-07-09 22:48:17 -0400 < Zipheir> skeemer: One more example. What's wrong with this 'length' function: (define (length&co lis col) (if (null? lis) (col 0) (+ 1 (length&co (cdr lis) (lambda (k) (col (+ k 1)))))))
2023-07-09 22:49:24 -0400 < Zipheir> (What's wrong is that I apparently didn't understand how I wanted to recurse and did it two different ways.)
2023-07-09 22:49:33 -0400 < skeemer> Zipheir, yes i get it now, same issue, you are mixing direct recurison with CPS
2023-07-09 22:49:41 -0400 < skeemer> that (+ 1 ...
2023-07-09 22:50:22 -0400 < skeemer> in TLS there nowhere specified anyway to not mix these two types of recursion
2023-07-09 22:51:17 -0400 < Zipheir> Yeah, a warning would've been nice.
2023-07-09 22:51:44 -0400 < skeemer> looks like i have to augment the book with my notes
2023-07-09 22:51:44 -0400 < Zipheir> skeemer: I'm glad that you seem to be getting it!
2023-07-09 22:51:53 -0400 < skeemer> thanks to you Zipheir
2023-07-09 22:52:02 -0400 < skeemer> you were extremely helpful
2023-07-09 22:56:46 -0400 < skeemer> i still probably have to get why continuations are so great... i mean ok i can return multiple things, but can't i do the same with direct recursion ?
2023-07-09 22:56:50 -0400 < skeemer> i don't know actually
2023-07-09 22:57:29 -0400 < Zipheir> In standard Scheme, you can. (values a b c ...) returns all its arguments as multiple values.
2023-07-09 22:58:07 -0400 < Zipheir> You have to bind them with special forms: let-values, call-with-values, receive, etc.
2023-07-09 23:00:38 -0400 < Zipheir> e.g. 'partition' from SRFI 1 splits a list in two using a predicate: (let-values (((evens odds) (partition even? '(1 2 3 4)))) (list evens odds)) => ((2 4) (1 3))
2023-07-09 23:01:11 -0400 < Zipheir> It's a little clumsy. Many kinds of syntactic sugar for multiple values have been suggested.
--- Day changed Mon Jul 10 2023
2023-07-10 00:06:18 -0400 < skeemer> Zipheir, ok so still i don't see the big deal wiht collectors right now
2023-07-10 06:24:47 -0400 -!- karlosz_ is now known as karlosz
2023-07-10 07:31:58 -0400 -!- rgherdt_ is now known as rgherdt
2023-07-10 09:49:26 -0400 < kitzman> do generic SRFI implementations exist?
2023-07-10 09:50:39 -0400 < sham1> Reference implementations
2023-07-10 10:10:39 -0400 < gwatt> kitzman: some yes, some no. There are SRFIs that request functionality added to the base language and are not expressible as libraries. See SRFIs 88 and 119
2023-07-10 11:50:59 -0400 -!- ec_ is now known as ec
2023-07-10 12:02:36 -0400 < skeemer> Zipheir, i am back today on chapter 9
2023-07-10 12:02:38 -0400 < skeemer> halfway through it
2023-07-10 12:02:49 -0400 < skeemer> am at the hard part now i guess -.-
2023-07-10 12:05:57 -0400 < Zipheir> skeemer: Oh dear.
2023-07-10 12:08:05 -0400 < Zipheir> kitzman: Many important SRFIs (the "standard library" ones) have fully portable sample implementations. Others, as gwatt says, have to be built in. There are fewer of those in Scheme, though, because of hygienic macros.
2023-07-10 12:18:55 -0400 < kitzman> gwatt, Zipheir: is there a collection of those, such as the web, or a book?
2023-07-10 12:20:05 -0400 < Zipheir> kitzman: All of the SRFI source is on GitHub: https://github.com/orgs/scheme-requests-for-implementation/repositories
2023-07-10 12:20:43 -0400 < Zipheir> And, of course, the pretty-printed SRFI documents are here: https://srfi.schemers.org/
2023-07-10 12:23:50 -0400 < kitzman> cool nice; i'll try some of those with s9fes
2023-07-10 13:39:59 -0400 < gwatt> kitzman: You might want to try a more up-to-date scheme. S9fes is neat, but it's R4RS+some extras. I could see many srfis wanting R[567]RS
2023-07-10 13:40:31 -0400 < Zipheir> I don't think it even has syntax-rules.
2023-07-10 13:57:21 -0400 < kitzman> gwatt: i don't have many options on my current platform. femtolisp is another. it says it is 'highly compatible with Scheme'. Plus some R6RS features, and some SRFIs which require R5RS. if I can run alphakanren on femtolisp i'll go with that one
2023-07-10 14:01:39 -0400 < wasamasa> I mean, good luck
2023-07-10 14:01:52 -0400 < wasamasa> femtolisp implements a r5rs subset
2023-07-10 14:12:44 -0400 < kitzman> alphakanren or even minikanren should work; let's see
2023-07-10 14:16:25 -0400 < kitzman> maybe*
2023-07-10 14:16:57 -0400 < Zipheir> Isn't αKanren the nominal logic version of miniKanren?
2023-07-10 14:17:21 -0400 < Zipheir> Maybe there are multiple alphaKanrens...
2023-07-10 14:18:51 -0400 < lechner> Hi, is there a better way to return #t on a command that does not return anything than     (begin (load "path) #t)     ?
2023-07-10 14:20:29 -0400 < Zipheir> Nope.
2023-07-10 14:20:58 -0400 < Zipheir> At least, I can't imagine anything shorter than than.
2023-07-10 14:21:03 -0400 < Zipheir> *than that
2023-07-10 14:25:19 -0400 < Zipheir> lechner: Also, 'load' must return something. It's just that *what* is unspecified.
2023-07-10 15:13:04 -0400 < lechner> Zipheir / you mean the loaded script must return something?
2023-07-10 15:20:28 -0400 < Zipheir> No, although I guess 'load' could return a value from the loaded program. I doubt anyone does that. The reports unspecify the value of (load ...).
2023-07-10 16:44:08 -0400 < lechner> it was actually consistent what i did elsewhere, and seems to work. the quoted recipe items (which respond to the lines in a Makefile) must evaluate to #t for the build to succeed. you can seen the line just above for comparison      https://codeberg.org/lechner/bespoke/src/branch/history/scm/bespoke/rules.scm#L41
2023-07-10 16:44:12 -0400 < lechner> anyway, thanks!
2023-07-10 16:44:59 -0400 < lechner> it's used like this     https://codeberg.org/lechner/bespoke/src/branch/history/examples/submake-load/make#L29
2023-07-10 16:56:19 -0400 < Zipheir> Ah, got it.
2023-07-10 17:52:47 -0400 -!- dstein64- is now known as dstein64
2023-07-10 22:28:49 -0400 < skeemer> Zipheir, are you there  ?
2023-07-10 22:28:53 -0400 < skeemer> i read chapter 9
2023-07-10 22:28:59 -0400 < skeemer> wanted to ask you something
2023-07-10 23:33:22 -0400 < felixlechner> Hi, is there something more portable than (ice-9 getopt-long) for processing of arguments to scripts, please?
2023-07-10 23:34:09 -0400 < felixlechner> Sorry, I'm in Guile
2023-07-10 23:36:00 -0400 < flatwhatson> felixlechner: there's args-fold from srfi-37
2023-07-10 23:37:07 -0400 < flatwhatson> skeemer: it's better to just ask your question, "don't ask to ask".  irc is asynchronous, and maybe someone else could help too
2023-07-10 23:45:27 -0400 < edgar-rft> I read chapoter 9, too, but from a different book
2023-07-10 23:46:17 -0400 < edgar-rft> chapotor - is that a word at all? I meant chapter of course
2023-07-10 23:46:35 -0400 < skeemer> edgar-rft, what book ?
2023-07-10 23:49:37 -0400 < edgar-rft> skeemer: I think it was "War All the Time" from Charles Bukowsky
2023-07-10 23:54:03 -0400 < felixlechner> flatwhatson / thanks!
2023-07-10 23:57:36 -0400 < Zipheir> skeemer: What's the question?
2023-07-10 23:59:12 -0400 < skeemer> Zipheir, i mean i am not sure i was able to follow all the nitty gritty of the details, but i got the general meaning... correct me if i am wrong... the chapter starts by noticing that there are programs who never end, and there is no way to build  a function that determines if a program can end... this was quite clear, i think it is called the Halting problem iirc
2023-07-10 23:59:18 -0400 < Zipheir> skeemer: Also, you can use PRIVMSG if you have a question specifically for me.
2023-07-10 23:59:26 -0400 < skeemer> there i understood all the details
2023-07-10 23:59:54 -0400 < Zipheir> Yes.
2023-07-10 23:59:55 -0400 < skeemer> then it goes on with some kind of madness about... let's forget about "define", so if we don't have define, can we still use recursion?
--- Day changed Tue Jul 11 2023
2023-07-11 00:00:05 -0400 < Zipheir> Right.
2023-07-11 00:00:43 -0400 < Zipheir> And the answer is "yes".
2023-07-11 00:01:06 -0400 < skeemer> and it goes on showing a function to compute the length, it tries with lambda, and starts to nest lambda and you basically see that at each step you manually need to add a nested lambda if you want to be able to compute the length of longer lists,e.g., want to compute a length of a list of length 2? then you have to nest three lambdas
2023-07-11 00:01:11 -0400 < skeemer> and so on...
2023-07-11 00:01:31 -0400 < skeemer> then the question becomes how do we abstract this pattern so that we don't need to manually add lambdas...
2023-07-11 00:01:59 -0400 < skeemer> now when it comes to the steps they take to do all the abstractions, i was kind of lost to say the truth, i understand the intent and the motivation
2023-07-11 00:02:32 -0400 < skeemer> and at the end of the day anyway they come up with a peculiar function which is called Y combinator
2023-07-11 00:02:45 -0400 < skeemer> which is basically what allows us to perform recursion in computation
2023-07-11 00:03:05 -0400 < Zipheir> Because (Y f) = f (Y f)
2023-07-11 00:03:06 -0400 < skeemer> we don't need "define", we just need a Y combinator basically
2023-07-11 00:03:18 -0400 < Zipheir> Indeed so.
2023-07-11 00:03:32 -0400 < skeemer> did I get enough from that chapter?
2023-07-11 00:03:45 -0400 < skeemer> since i was a bit confused from the steps they use to derive the Y combinator
2023-07-11 00:04:00 -0400 < skeemer> so i was wondering how important those are or if i should spend more time there
2023-07-11 00:04:10 -0400 < skeemer> is chapter 10 also difficult ?
2023-07-11 00:04:11 -0400 < Zipheir> They recommend reading it twice. I had to come back to it after finishing the book.
2023-07-11 00:04:35 -0400 < Zipheir> No. Chapter 9 is more difficult than the rest of the book.
2023-07-11 00:04:40 -0400 < Zipheir> Combined!
2023-07-11 00:05:02 -0400 < skeemer> also what subfield in computer science studies these things? i mean combinators and halting problems and so on ?
2023-07-11 00:05:14 -0400 < skeemer> i mean i have read online that there are other combinators like Omega, K, I
2023-07-11 00:05:35 -0400 < skeemer> i am confused ahah i mean i guess these are building blocks to describe functional programming with lambda calculus
2023-07-11 00:05:44 -0400 < skeemer> so when we don't have a programming language right ?
2023-07-11 00:06:32 -0400 < Zipheir> Um...
2023-07-11 00:07:01 -0400 < Zipheir> Combinators and lambda calculus are basic topics in programming languages theory, but they're basic to CS as a whole.
2023-07-11 00:07:32 -0400 < Zipheir> Sure, Turing machines are better-known, but λ calculi are obviously more elegant. :-p
2023-07-11 00:07:52 -0400 < skeemer> i mean i tried to find it in programming language books and didnt find anything
2023-07-11 00:08:04 -0400 < skeemer> Essentials of Programming Languages
2023-07-11 00:08:09 -0400 < skeemer> does not mention combinators
2023-07-11 00:08:21 -0400 < Zipheir> EoPL does not go into basic theory.
2023-07-11 00:08:45 -0400 < skeemer> Zipheir, any recommendations on books that go into theory then ?
2023-07-11 00:09:47 -0400 < Zipheir> If you want to see how to implement a Scheme-ML hybrid from pure untyped λ-calculus, Michaelson's book is the best intro.
2023-07-11 00:10:54 -0400 < Zipheir> If you really want to read about λ-calculus and combinators, look at Hindley & Seldin's _Lambda Calculus and Combinators_. That one's pretty detailed.
2023-07-11 00:11:58 -0400 < skeemer> ok thanks
2023-07-11 00:12:29 -0400 < skeemer> do you still reccomend EoPL ?
2023-07-11 00:12:33 -0400 < skeemer> is it a good book ?
2023-07-11 00:12:45 -0400 < Zipheir> The most useful thing about λ-calculus for language tinkering, though, is that it's *the* minimal language. Everybody uses it (or the simply-typed version, STLC) to demo their ideas.
2023-07-11 00:13:32 -0400 < skeemer> Zipheir, ideas about what ?
2023-07-11 00:13:48 -0400 < Zipheir> Mostly yes. EoPL is a lot of fun. It doesn't get into theory, as I said.
2023-07-11 00:14:02 -0400 < skeemer> i mean is there still research done in programming languages? what's the state of the art ? or what is people trying to achieve these days ?
2023-07-11 00:14:32 -0400 < skeemer> Zipheir, ohh so many books, after this, it will be the Seasoned Schemer, then Reasoned Schemer, then HTDP, ahaha
2023-07-11 00:14:38 -0400 < Zipheir> skeemer: Programming languages. If you want to display a new type system, for example, the simplest way to do it is to define a little λ-calculus-like language using it.
2023-07-11 00:14:48 -0400 < Zipheir> Ars longa...
2023-07-11 00:15:31 -0400 < Zipheir> There's no single state of the art. There are tons of areas of research.
2023-07-11 00:16:03 -0400 < Zipheir> skeemer: Here's another one for your list. https://plfa.github.io/
2023-07-11 00:16:36 -0400 < mfiano> ACM PLDI was a week or two ago; they might have some notable "state of the art" research talks made available.
2023-07-11 00:16:39 -0400 < Zipheir> The Little Typer covers some of the same ground.
2023-07-11 00:19:17 -0400 < mfiano> https://dl.acm.org/conference/pldi
2023-07-11 00:19:22 -0400 < Zipheir> mfiano: Thanks.
2023-07-11 00:20:05 -0400 < Zipheir> I also have to (again) share one of my favorite talks on programming languages, since it's now relevant. It's Will Byrd's "The Most Beautiful Program Ever Written" https://yewtu.be/watch?v=OyfBQmvr2Hc
2023-07-11 00:20:29 -0400 < skeemer> Zipheir, ohhh my god
2023-07-11 00:20:30 -0400 < skeemer> ahahah
2023-07-11 00:20:43 -0400 < skeemer> Zipheir, i watched that talk multiple times :)
2023-07-11 00:20:47 -0400 < Zipheir> Oh, great.
2023-07-11 00:20:54 -0400 < skeemer> the environment stuff is a bit hard to understand imho
2023-07-11 00:20:57 -0400 < Zipheir> It's hilarious and very interesting.
2023-07-11 00:21:04 -0400 < mfiano> Ah, it's been a few years. I need to watch it again, thanks.
2023-07-11 00:22:13 -0400 < Zipheir> "What's another name for a list of lists? A tree! Oooh. Did you ever hear of this new-fangled thing called XML?" :)
2023-07-11 00:23:56 -0400 < Zipheir> skeemer: I've never understood the hype around HtDP. It seemed a bit pedantic when I tried it (years ago).
2023-07-11 00:24:35 -0400 < Zipheir> (Some would say that everything by Felleisen is a bit pedantic.)
2023-07-11 00:28:14 -0400 < mfiano> The only Scheme book I read and finished was a recent one, and I don't recall the name.
2023-07-11 00:31:03 -0400 < mfiano> Aha, SDfF
2023-07-11 00:32:41 -0400 < Zipheir> How was it? I've been meaning to read it since it came out.
2023-07-11 00:32:59 -0400 < mfiano> I have mixed feelings
2023-07-11 00:35:12 -0400 < mfiano> I only read it because I was interested in the constraint propagation section, and I think I read some of his papers on the subject. Really interesting stuff, btw. The book was pretty good overall, and I agree with a lot of it. I am a big fan of what I think he called "additive programming", and it was all very interesting, but I think he talks too much, and a lot of hand wavey and not very
2023-07-11 00:35:14 -0400 < mfiano> thorough on the tecnical side, though, that wasn't the book's point I suppose.
2023-07-11 00:35:56 -0400 < mfiano> I recall the introduction being overly long drawing too many parallels between software evolution and biology (iirc).
2023-07-11 00:36:24 -0400 < flatwhatson> i enjoyed that a lot, sussman is excellent at mixing concepts from multiple domains
2023-07-11 00:37:24 -0400 < flatwhatson> also the problem areas are well chosen and interesting, and the extension questions are well designed to stretch your brain
2023-07-11 00:38:14 -0400 < mfiano> Absolutely
2023-07-11 00:41:27 -0400 < skeemer> What is SDfF?
2023-07-11 00:41:30 -0400 < skeemer> mfiano,
2023-07-11 00:41:53 -0400 < skeemer> ohh software design for flexibility right
2023-07-11 00:42:05 -0400 < mfiano> Yes
2023-07-11 00:42:19 -0400 < nisstyre> flatwhatson: he is an electrical engineer by training I believe right
2023-07-11 00:43:20 -0400 < flatwhatson> professor of electrical engineering in fact
2023-07-11 00:43:26 -0400 < Zipheir> And hacker, physicist, AI guy, and watchmaker, at least.
2023-07-11 00:43:37 -0400 < mfiano> probably blacksmith, too
2023-07-11 00:44:36 -0400 < nisstyre> https://www.youtube.com/c/NielsProvos/videos if you like seeing computer scientists blacksmith stuff
2023-07-11 00:45:08 -0400 < nisstyre> I just realized he hasn't uploaded anything in a long time
2023-07-11 00:45:11 -0400 < nisstyre> wonder what happened
2023-07-11 01:13:11 -0400 < skeemer> i mean how do the concepts taught in TLS TSS and EoPL overlap with the dragon book about writing compilers?
2023-07-11 01:13:35 -0400 < nisstyre> The Little Schemer == TLS ?
2023-07-11 01:13:41 -0400 < nisstyre> I don't think they overlap much if at all
2023-07-11 01:13:50 -0400 < nisstyre> dragon book is mostly about parsers right?
2023-07-11 01:14:14 -0400 < nisstyre> and it's pretty outdated now anyway
2023-07-11 01:14:28 -0400 < nisstyre> doesn't cover PEGs, or parser combinators
2023-07-11 01:17:59 -0400 < Zipheir> Oh, they knew about LL(k) parsers. Enough to know that LALR(1) was better.
2023-07-11 01:18:48 -0400 < Zipheir> The Dragon Book has at least 3 editions. I imagine that the recent one covers a lot more than the early 70's original (which is great, too).
2023-07-11 01:19:32 -0400 < Zipheir> The section on actual compilation in the original is short and rather odd, though.
2023-07-11 01:20:52 -0400 < Zipheir> skeemer: The Little Books happily give you the job of figuring out what they mean.
2023-07-11 01:21:15 -0400 < Zipheir> You are expected to know the value of everything (and the cost of nothing).
2023-07-11 01:24:10 -0400 < Zipheir> No, not really. You're expected to meditate on these ideas until you attain enlightenment.
2023-07-11 01:27:01 -0400 < skeemer> Zipheir, ok so the Compilers book treats different topics anyways ?
2023-07-11 01:28:43 -0400 < Zipheir> Yes. I don't think any of the Little books talk about compilation at all.
2023-07-11 01:30:19 -0400 < Zipheir> SICP is a good book for a "Lisp perspective" on compilers.
2023-07-11 02:15:05 -0400 < mdhughes> I have the Dragon book 3E, and it kinda sucks, covers way too much. The old book's content is still in there, I think, but it's hard to progress thru. 2E was a near perfect book.
2023-07-11 02:30:57 -0400 < skeemer> Zipheir, i actually have a question about chapter 9...
2023-07-11 02:31:07 -0400 < skeemer> the last question is something like what is (Y Y)
2023-07-11 02:32:31 -0400 < skeemer> and then the answer is: Who knows, but it works very hard
2023-07-11 02:43:20 -0400 < Zipheir> Sure. If you run (Y Y) in a REPL, you can use that work to cook something on your CPU.
2023-07-11 02:43:34 -0400 < Zipheir> Anyway, I have to sleep. Have fun!
2023-07-11 02:51:55 -0400 < shawnw> Calling the Y combinator on itself will never end, yeah.
2023-07-11 02:52:24 -0400 < shawnw> https://stackoverflow.com/questions/76509543/what-is-y-y-the-y-combinator-applied-to-itself
2023-07-11 03:00:43 -0400 < skeemer> thanks Zipheir and shawnw
2023-07-11 10:56:05 -0400 < jcowan> skeemer: (y y) is the equivalent of (let ((loop (lambda () (loop))) (loop)), except that it doesn't bind a  name.
2023-07-11 11:24:26 -0400 < jcowan> Turing machines are clanking iron dinosaurs compared to lambda calculus
2023-07-11 14:25:27 -0400 < skeemer> thanks for the observation jcowan
2023-07-11 14:25:31 -0400 < skeemer> Zipheir, finished TLS
2023-07-11 14:26:05 -0400 < skeemer> ok chapter 10 is wasier than 9, but still i probably won't be able to re-implement the interpreter from scratch without going to look some of the snippets
2023-07-11 14:32:29 -0400 < Zipheir> skeemer: Congratulations.
2023-07-11 14:56:08 -0400 < skeemer> tahnks Zipheir
2023-07-11 14:56:12 -0400 < skeemer> i found this https://www.youtube.com/watch?v=3VQ382QG-y4
2023-07-11 14:56:30 -0400 < skeemer> it's gold for better understanding lambda calculus and my quest to get a general idea about combinators
2023-07-11 15:07:48 -0400 -!- anthk__ is now known as anthk_
2023-07-11 18:33:27 -0400 < jcowan> ooh
2023-07-11 18:34:04 -0400 < jcowan> https://files.8pit.net/edward/1.0.1/doc/ is an implementation of the standards editor in R7RS
2023-07-11 18:41:02 -0400 < flatwhatson> arthur can finally retire
2023-07-11 18:42:35 -0400 < jcowan> flatwhatson: Which Arthur?
2023-07-11 18:43:13 -0400 < flatwhatson> the SRFI editor
2023-07-11 18:46:48 -0400 < flatwhatson> edward is a nice choice of name, following edwin.  these gives a lot of good options for naming future text editor projects
2023-07-11 18:47:43 -0400 < flatwhatson> edison edgar edmund edith
2023-07-11 18:48:48 -0400 < flatwhatson> i thought "the standards editor" meant a text editor for writing latex sources for RnRS, but no, it's an "ed" clone in r7rs
2023-07-11 18:48:56 -0400 < flatwhatson> cool, but less exciting :)
2023-07-11 19:41:52 -0400 < jcowan> GNU ed man page doesn't say "ed is the standard editor"
2023-07-11 19:42:00 -0400 < jcowan> as older ed man pages did
2023-07-11 19:43:42 -0400 < aeth> and GNU ed exists with C-d (but not C-c) instead of just `q` these days
2023-07-11 19:44:05 -0400 < aeth> so one of the punchlines of https://www.gnu.org/fun/jokes/ed-msg.html doesn't work anymore
2023-07-11 19:44:09 -0400 < aeth> s/exists/exits/
2023-07-11 19:44:30 -0400 < aeth> 10 or so years ago you could actually enter all of that and it would match
2023-07-11 19:44:31 -0400 < Zipheir> It has 'wq' too.
2023-07-11 19:45:15 -0400 < Zipheir> It looks like 'edward' uses POSIX commands instead of an S-expression command language. I'm a little disappointed.
2023-07-11 19:50:34 -0400 < edgar-rft> ed cannot be used any moar to edit standards?
2023-07-11 19:53:37 -0400 < jcowan> Well, you could certainly add an S-expression command line
2023-07-11 19:56:24 -0400 < Zipheir> That's the nice thing about a Scheme ed. It's not a rigid immutable little diamond.
2023-07-11 19:56:50 -0400 < Zipheir> But how well does it handle Unicode, I wonder...
2023-07-11 19:58:19 -0400 < jcowan> No idea
2023-07-11 19:58:35 -0400 < ober> gerbil...
2023-07-11 19:58:39 -0400 < jcowan> It woud be easy to add (import utf8) if not already there
2023-07-11 20:03:11 -0400 < edgar-rft> time for r7rs-utf8
2023-07-11 20:20:25 -0400 < jcowan> Chicken 6 will finally be UTF-8
2023-07-11 20:35:30 -0400 < felixlechner> Hi, in Guile's (ice-9 getopt-long) how may I specify a 'predicate' please? Something like    (predicate string->number)    gives me     ice-9/getopt-long.scm:209:28: Wrong type to apply: string->number    Thanks!
2023-07-11 20:39:50 -0400 < felixlechner> nvm, i had to quasiquote the whole grammar and then unquote the predicate function!
2023-07-11 23:09:45 -0400 < mdhughes> I prefer the original: https://archive.org/details/softwaretoolsinp00kern/page/168/mode/2up
2023-07-11 23:10:27 -0400 < mdhughes> But if I was gonna rewrite it in Scheme, I'd do all the extensions in Scheme, obvs. Like an emacs with a nicer interface.
2023-07-11 23:12:14 -0400 < mdhughes> > A warning: edit is a big program; at 950 lines (excluding contributions from translit, find and change), it is 50% bigger than anything else in this book.
2023-07-11 23:23:46 -0400 < Zipheir> Software Tools is a great book.
2023-07-11 23:27:08 -0400 < Zipheir> That, K & R, and TUPE are the Kernighan classics. I guess _The Elements of Programming Style_ belongs on the list, too, but it's ancient history at this point.
2023-07-11 23:27:53 -0400 < mfiano> Did it age well?
2023-07-11 23:27:55 -0400 < Zipheir> Oh, and the AWK book.
2023-07-11 23:28:26 -0400 < Zipheir> Not really. The ugly programming of today is very different from the ugly programming of the early 70s.
2023-07-11 23:28:51 -0400 < mfiano> Reading the description about the new structured programming technique using a Fortran dialect is a little off-putting I will admit :)
2023-07-11 23:29:08 -0400 < Zipheir> Yeah.
2023-07-11 23:29:47 -0400 < Zipheir> Reading the examples will give you an appreciation for that new-fangled structured programming stuff.
2023-07-11 23:34:29 -0400 < Zipheir> Maybe it was snake-oil for some people, but it was better than the rats-nests of GOTOs that were apparently common in mainstream programs at the time.
2023-07-11 23:37:46 -0400 < klovett> @ USF ~1980 Intel tools people gave a talk (we used PL/M-8x) - told a story of a fighter's fire-control as linear w/ gotos, a realtime rats nest
2023-07-11 23:38:23 -0400 < klovett> (they were helping to debug - no, i do not know who was the vendor)
2023-07-11 23:42:47 -0400 < Zipheir> Wow.
2023-07-11 23:48:32 -0400 < klovett> ah, the good old days, when the 1st stmt was DECLARE DCL LITERALLY 'DECLARE';
--- Day changed Wed Jul 12 2023
2023-07-12 00:06:58 -0400 < mdhughes> Also, exciting news, there's a new Awk book coming out! https://awk.dev
2023-07-12 00:13:21 -0400 < Zipheir> That's a surprise.
2023-07-12 00:14:21 -0400 < Zipheir> "The AWK Programming Language, Second Edition ... The book will be available by the end of September." !!
2023-07-12 00:15:55 -0400 < Zipheir> I'm slightly skeptical. I can't find mention of a new edition anywhere else.
2023-07-12 00:16:05 -0400 < mdhughes> My late-year slate is AWK book, and new Murderbot.
2023-07-12 00:16:30 -0400 < mdhughes> BWK's mentioned it elsewhere, too, but that's his site.
2023-07-12 00:16:44 -0400 < Zipheir> Well, it certainly looks like his kind of site.
2023-07-12 00:16:53 -0400 < Zipheir> Exciting.
2023-07-12 00:20:31 -0400 < felixlechner> Hi, what's a way to do a       (for-each function items)     but stop as soon as    (function item)     returns #f, please?
2023-07-12 00:22:00 -0400 < flatwhatson> one way is (all function items)
2023-07-12 00:22:59 -0400 < flatwhatson> sorry, it's (every function items)
2023-07-12 00:23:50 -0400 < mfiano> I always mix that up.
2023-07-12 00:24:43 -0400 < flatwhatson> i associate "any" with "all", and "some" with "every", but srfi-1 mixes it up
2023-07-12 00:24:54 -0400 < mfiano> CL has `every`, but `any` is `some`. Most other languages I've used use `all` for `every`. Sometimes I wish we could just use binary instead of overloading terms :)
2023-07-12 00:25:44 -0400 < felixlechner> flatwhatson / mfiano / thanks so much!
2023-07-12 00:30:16 -0400 < felixlechner> Is it possible, in Guile, to used named arguments (specified via #:key) with anonymous lambdas?
2023-07-12 00:30:40 -0400 < flatwhatson> yes, use lamba* (and read the manual!)
2023-07-12 00:30:52 -0400 < felixlechner> yeah, i just remembered it. sorry
2023-07-12 00:30:58 -0400 < felixlechner> never used lambda* before
2023-07-12 00:37:18 -0400 < felixlechner> Hi, can this be curried in Scheme, please?   (lambda (file) (not (file-exists? file)))
2023-07-12 00:40:05 -0400 < Zipheir> felixlechner: What do you mean?
2023-07-12 00:40:44 -0400 < Zipheir> You mean, written without the argument? cut doesn't work here, since the argument would be nested.
2023-07-12 00:40:56 -0400 < Zipheir> (A big drawback of cut, BTW.)
2023-07-12 00:40:57 -0400 < felixlechner> something like     (filter (curry not file-exists?) files)
2023-07-12 00:41:09 -0400 < Zipheir> Oh, composed.
2023-07-12 00:41:14 -0400 < felixlechner> sorry
2023-07-12 00:41:19 -0400 < Zipheir> That's composition, not currying.
2023-07-12 00:41:28 -0400 < Zipheir> Does Guile have 'compose'?
2023-07-12 00:41:31 -0400 < flatwhatson> yes
2023-07-12 00:41:35 -0400 < felixlechner> okay, i'm obviously confused
2023-07-12 00:41:49 -0400 < Zipheir> Yeah, (compose not file-exists?)
2023-07-12 00:43:01 -0400 < Zipheir> It's easy to get the confused in the unary case.
2023-07-12 00:43:05 -0400 < Zipheir> *get them
2023-07-12 00:44:34 -0400 < felixlechner> Zipheir / flatwhatson / thanks so much!
2023-07-12 00:45:14 -0400 < felixlechner> Hi, is it better style in Scheme to work with false return values or with exceptions, please? The latter seems to incur fewer indentations
2023-07-12 00:50:33 -0400 < flatwhatson> good practice in any language is to save exceptions for exceptional circumstances
2023-07-12 00:50:42 -0400 < Zipheir> There are more options. You can also pass/return default values or pass "failure" continuations.
2023-07-12 00:51:14 -0400 < Zipheir> felixlechner: The big problem with returning #f on failure is that you can never return it on success.
2023-07-12 00:52:06 -0400 < Zipheir> felixlechner: You can also use Maybe and Either https://srfi.schemers.org/srfi-189/srfi-189.html
2023-07-12 00:52:21 -0400 < felixlechner> okay, that's interesting
2023-07-12 00:52:23 -0400 < flatwhatson> ergonomically, i find #f for failure most often convenient.  i use (and ...) for flow control quite a bit.
2023-07-12 00:53:38 -0400 < felixlechner> yeah, i think it will work in my case also but let me work some more on this before making a decision. i will likely seek input on this rewrite of make (and partially, automake) in the near future
2023-07-12 01:01:10 -0400 < mdhughes> For processing a list of stuff, I usually either use call/cc, or return an (eof-object) shibboleth (sometimes make my own, but you can just use eof-object if you're lazy)
2023-07-12 01:02:26 -0400 < Zipheir> (nothing)
2023-07-12 01:04:20 -0400 < jcowan> Zipheir: Indeed, I was one of the rats in question, and TEoPS, along with Dijkstra, made a convert of me
2023-07-12 01:05:20 -0400 < jcowan> JS:TGP is a kind of descendant
2023-07-12 01:07:20 -0400 < Zipheir> Another descendent, maybe even a sort of second edition to TEoPS, is https://www.amazon.com/Practice-Programming-Addison-Wesley-Professional-Computing/dp/020161586X
2023-07-12 01:08:16 -0400 < Zipheir> It includes one of my favorite quotes about C: "C is a razor-sharp tool. You can use it to make an efficient program or a bloody mess."
2023-07-12 01:09:23 -0400 < felixlechner> Hi, how do I declare a procedure with a default return value, please?
2023-07-12 01:10:30 -0400 < Zipheir> The same way you define any procedure. At least, in standard Scheme.
2023-07-12 01:12:41 -0400 < aeth> I thought C# was the sharp one?
2023-07-12 01:12:48 -0400 < aeth> or I guess C♯
2023-07-12 01:13:09 -0400 < Zipheir> felixlechner: Ah, wait, I forgot an important distinction. To return a default value, you must use something known as a conditional!
2023-07-12 01:14:08 -0400 < aeth> ironically C♯ is easier to type on Linux than Windows because on Linux that's just AltGr # # if you have the compose key on (and it's so intuitive I just guessed it'd work) and the Windows way to unicode is afaik more convoluted
2023-07-12 01:14:28 -0400 < Zipheir> aeth: We're still waiting on C𝄪.
2023-07-12 01:14:42 -0400 < _________> C³³
2023-07-12 01:14:46 -0400 < _________> doesn't work
2023-07-12 01:14:54 -0400 < Zipheir> The B language was C♭, enharmonically speaking.
2023-07-12 01:15:01 -0400 < aeth> ℂ
2023-07-12 01:15:14 -0400 < aeth> My programming language is going to be called ℂ
2023-07-12 01:15:26 -0400 < _________> so complex it's complex :)
2023-07-12 01:16:32 -0400 < aeth> better than the ¢ programming language
2023-07-12 01:16:43 -0400 < mdhughes> The correct name for it is cocktothorpe.
2023-07-12 01:17:08 -0400 < aeth> mdhughes: but that's already confusingly similar to another programming language, Coq
2023-07-12 01:17:25 -0400 < aeth> whereas ℂ avoids that confusion
2023-07-12 01:17:59 -0400 < mdhughes> I'd pronounce "coq" more like "coke".
2023-07-12 01:18:14 -0400 < flatwhatson> felixlechner: (and (operation-which-might-return-false) default-value)
2023-07-12 01:19:34 -0400 < felixlechner> flatwhatson / thanks!
2023-07-12 01:19:46 -0400 < felixlechner> on the topic of C, I think it went flat on its own
2023-07-12 07:31:27 -0400 < ecraven> wow, ical is *really* a giant steaming pile of .. whatever
2023-07-12 08:12:46 -0400 < felixlechner> Hi, how may I store (or retrieve) multiple values with the same key from an alist, please? 'assoc-ref' only returns one entry. Should I be storing lists, instead? Am I using the wrong data structure altogether? Thanks!
2023-07-12 08:15:26 -0400 < mfiano> That is one way. It's hard to say which data structure is correct for all of your intended use cases.
2023-07-12 08:22:37 -0400 < ecraven> I was pondering a question today: if you have an alist of settings, how do you find out and report whether all of them are actually used.. (to find things like typos in setting names)
2023-07-12 08:23:01 -0400 < ecraven> felixlechner: the simplest way is to store not one value under each key, but a list
2023-07-12 08:29:41 -0400 < felixlechner> ecraven / thanks!
2023-07-12 08:29:51 -0400 < felixlechner> mfiano / thanks!
2023-07-12 08:31:02 -0400 < felixlechner> ecraven / as for you own question, can you just enumerate the keys via 'first'?    https://codeberg.org/lechner/bespoke/src/commit/d8cc774f4f7951ddc0d0482f7bd57c4eda479262/scm/bespoke/make.scm#L190
2023-07-12 08:31:03 -0400 < rudybot> https://teensy.info/6C9i9hzANG
2023-07-12 08:49:26 -0400 < ecraven> felixlechner: indeed, but what is a good "architecture" to keep track of *which* of these fields are actually accessed and used in a codebase, and which are mistyped or obsolete?
2023-07-12 09:20:32 -0400 < felixlechner> felixlechner / all my keys come from elsewhere, but maybe using constants could help in your case
2023-07-12 10:09:19 -0400 < felixlechner> Hi, is this the easiest way to enumerate all keys in a hash table, please?      (hash-for-each (lambda (key value) key) table)
2023-07-12 10:18:21 -0400 < ecraven> which scheme implementation?
2023-07-12 10:18:29 -0400 < ecraven> you might have `hash-table-keys'
2023-07-12 10:30:06 -0400 < felixlechner> ecraven / yeah, I'm not sure Guile has that
2023-07-12 10:35:41 -0400 < flatwhatson> felixlechner: guile has srfi-69 which provides hash-table-keys
2023-07-12 10:36:21 -0400 < felixlechner> flatwhatson / thanks! for some reason it did not show up in the manual when i looked
2023-07-12 16:20:38 -0400 < amirouche> Zipheir: I have a SRFI-224 (fxmapping) with test coverage if you want (also a couple of eqv / equal mistakes)
2023-07-12 16:20:59 -0400 < amirouche> that should prolly go into SRFI org at some point
2023-07-12 16:24:23 -0400 < Zipheir> amirouche: Thanks! Link?
2023-07-12 16:30:20 -0400 < amirouche> coverage at https://github.com/letloop/cli/pull/1819#issuecomment-1633171662
2023-07-12 16:30:37 -0400 < amirouche> a couple of s/eqv/equal/
2023-07-12 16:30:39 -0400 < amirouche> https://github.com/letloop/cli/pull/1819/commits/217d7af37d946fd8328a60c0bdfe84b3f0d83112
2023-07-12 16:30:52 -0400 < amirouche> dead code is gray
2023-07-12 16:38:53 -0400 < Zipheir> amirouche: Thanks very much.
2023-07-12 16:41:08 -0400 < Zipheir> amirouche: What tool did you use to do the coverage analysis? I'd like to see people do this with other SRFIs.
2023-07-12 19:32:30 -0400 -!- Netsplit *.net <-> *.split quits: HerlockSholmes, lloda, weinholt, krjst, hexology, polyrob, sham1, kitzman, gwatt
2023-07-12 19:32:30 -0400 -!- HerlockSholmes2 is now known as HerlockSholmes
2023-07-12 20:27:07 -0400 -!- Netsplit over, joins: polyrob
2023-07-12 21:10:02 -0400 -!- hexology- is now known as hexology
--- Day changed Thu Jul 13 2023
2023-07-13 00:03:10 -0400 -!- sham1_ is now known as sham1
2023-07-13 01:06:17 -0400 < amirouche> Zipheir: I use: letloop check lib lib/srfi/srfi-224.scm
2023-07-13 01:49:12 -0400 < Zipheir> amirouche: Thanks. As I said, more SRFIs should use this.
2023-07-13 01:50:07 -0400 < Zipheir> My guess is that most of the sample implementations have minimal test coverage. (I'm sure some of mine do.)
2023-07-13 01:59:24 -0400 < mdhughes> Haven't had time to watch it yet, but video on building software in Gerbil: https://www.youtube.com/watch?v=wXZcEuhhGZ0
2023-07-13 04:03:09 -0400 < wasamasa> mdhughes: I've finally caved in and taken a screenshot of that one quote in Snow Crash to reference on IRC whenever the appropriate moment comes
2023-07-13 04:12:18 -0400 < shawnw> Which quote? It has so many.
2023-07-13 04:18:47 -0400 < wasamasa> https://x32.be/snowcrash.png
2023-07-13 04:19:03 -0400 < wasamasa> mdhughes sometimes posts it on fedi
2023-07-13 04:19:51 -0400 < mdhughes> I have one of those conversations every week or two.
2023-07-13 04:20:51 -0400 < wasamasa> it's not that often for me, but yeah, paranoid schizophrenics do show up on #security every now and then
2023-07-13 09:00:09 -0400 < Zipheir> That screenshot reminds me: Does anyone know a program for displaying a Unicode text file in a proportional font? Sometimes reading books in monospace gets a little tiring.
2023-07-13 09:17:01 -0400 < mdhughes> Have you heard of these things called "word processors"?
2023-07-13 09:17:58 -0400 < mdhughes> Not just facetiously, I use TextEdit.app all the time to make images of text, which I then post with alt text of the text.
2023-07-13 09:19:39 -0400 < Zipheir> Huh.
2023-07-13 09:20:21 -0400 < Zipheir> I'm on Slackware. I'd rather not deal with the LibreOffice mess, but I guess compiling Abiword wouldn't be to bad.
2023-07-13 09:20:22 -0400 < Zipheir> *too
2023-07-13 09:21:10 -0400 < mdhughes> I hear with some effort you can get a font other than Univers on linux these days. Good luck!
2023-07-13 09:22:00 -0400 < Zipheir> Hah. The DejaVu fonts have been around forever at this point, with unparalleled Unicode support.
2023-07-13 09:22:27 -0400 < Zipheir> I do miss those bitmap Adobe fonts, though.
2023-07-13 09:22:30 -0400 < mdhughes> But I do appreciate another Slackware user; that's what I started with, installed from floppies. I see every so often it gets an update.
2023-07-13 09:22:52 -0400 < Zipheir> Awesome.
2023-07-13 09:23:07 -0400 < mdhughes> Not that I ever touch linux now. Mac for show, FreeBSD for pro.
2023-07-13 09:27:21 -0400 < dpk> what's the least worst Linux distribution these days?
2023-07-13 09:28:22 -0400 < Zipheir> Slackware, I'd say.
2023-07-13 09:28:45 -0400 < dpk> i set up a server with Void recently and i liked that the init system is based on djb's daemontools, but it's also very much a do-it-yourself distribution for everything
2023-07-13 09:28:46 -0400 < Zipheir> Alpine is getting there, but the scripting quality sucks.
2023-07-13 09:29:05 -0400 < dpk> like FreeBSD, i guess, but FreeBSD still has a lot more in the base system
2023-07-13 09:29:14 -0400 < dpk> Void doesn't even come with SSH, as i recall
2023-07-13 09:29:25 -0400 < Zipheir> Yes, Void is very nice. IIRC it can, like Alpine,  use musl.
2023-07-13 09:30:49 -0400 < Zipheir> Gentoo still seems marginally insane to me as a design for a distro.
2023-07-13 09:30:56 -0400 < dpk> it was also a new and uniquely annoying experience trying to get IPv6 working, iirc, but it was much the same with FreeBSD and i suspect the issue is somewhat intrinsic to how IPv6 is being deployed
2023-07-13 09:32:01 -0400 < dpk> (if you get one server with IPv6 from Hetzner they give you 2**64 IPv6 addresses to play with, because i guess why not, except it also means you have to pick one of those 2**64 to be the one your server actually uses)
2023-07-13 09:42:06 -0400 < wasamasa> Zipheir: Noto is another project trying to support every script out there
2023-07-13 09:44:26 -0400 < Zambyte> dpk: if you want to lean into Scheme, you could use GNU Guix :)
2023-07-13 09:45:50 -0400 < dpk> where they took all the incomprehensible C++ code in Nix and rewrote it in Scheme code that is somehow worse than the C++ code?
2023-07-13 09:47:14 -0400 < Zambyte> well alright then lol
2023-07-13 09:48:53 -0400 < Zipheir> Hah.
2023-07-13 09:50:10 -0400 < civodul> arguing on #scheme that Scheme is "worse" than C++ is intriguing
2023-07-13 09:50:24 -0400 < Zipheir> I don't think that was the argument.
2023-07-13 09:50:50 -0400 < Zipheir> I also find Guix's flavor of Scheme hard to understand.
2023-07-13 09:51:01 -0400 < civodul> oh, interesting
2023-07-13 09:51:08 -0400 < civodul> what's your Scheme background?
2023-07-13 09:51:14 -0400 < civodul> i mean which implementation?
2023-07-13 09:52:28 -0400 < Zipheir> I mainly use Chez or CHICKEN, these days.
2023-07-13 09:53:30 -0400 < Zipheir> Guile is convenient, since it supports R6RS and is installed on most Linux distros.
2023-07-13 09:54:39 -0400 < civodul> ok, i'd need to look at "typical" Chez or CHICKEN code to get a feel
2023-07-13 09:55:41 -0400 < wasamasa> "typical" is a difficult statement to make
2023-07-13 09:55:58 -0400 < civodul> well yeah
2023-07-13 09:56:05 -0400 < wasamasa> there was a user survey for CHICKEN and it revealed just how many different domains people use scheme for
2023-07-13 09:56:05 -0400 < Zipheir> I certainly don't think Guix is at all typical Scheme.
2023-07-13 09:56:17 -0400 < wasamasa> I expect it to be similar for other scheme implementations
2023-07-13 09:56:27 -0400 < wasamasa> except the very specialized ones, like armpit scheme
2023-07-13 09:57:09 -0400 < wasamasa> http://surveys.call-cc.org/state-of-chicken/2021/
2023-07-13 09:57:16 -0400 < civodul> Zipheir: are there any particular traits that look unusual to you?
2023-07-13 09:59:00 -0400 < Zipheir> All the effectful stuff file system, download, etc.
2023-07-13 09:59:04 -0400 < Zipheir> Oops.
2023-07-13 09:59:36 -0400 < Zipheir> All of the effectful stuff--file system operations, downloads, etc.--seem spread throughout the system, so it's very knotty.
2023-07-13 10:00:04 -0400 < Zipheir> I guess that's part of the problem it's trying to solve. Nix is similarly convoluted.
2023-07-13 10:00:52 -0400 < civodul> hmm ok
2023-07-13 10:01:00 -0400 < Zipheir> There's also the GNUitis. It's very complex.
2023-07-13 10:01:04 -0400 < civodul> i think those parts are a tiny fraction of the code
2023-07-13 10:01:17 -0400 < civodul> (fs ops and downloads)
2023-07-13 10:01:36 -0400 < civodul> "GNUitis", ok
2023-07-13 10:01:44 -0400 < civodul> i guess that summarizes it all
2023-07-13 10:02:52 -0400 < Zipheir> Oh, I like some GNU code just fine. diffutils, e.g., is very well-written.
2023-07-13 10:03:38 -0400 < Zipheir> But the project as a whole has a complexity problem. (Maybe telling people to use "fancy new algorithms" in their style guide was a misstep.)
2023-07-13 10:04:38 -0400 < Zipheir> Guix, at least, tries to solve a hard problem, so the complexity is understandable.
2023-07-13 10:10:46 -0400 < lockywolf> Is Linas Vepstas in this chat?
2023-07-13 10:11:01 -0400 < sham1> GNU in general seems quite convoluted at times. Wonder if a non-insignificant part of that would be because they didn't want to get sued for copying admittedly very simple interfaces back in the day
2023-07-13 10:12:40 -0400 < Zipheir> sham1: I think so. That's part of the rationale for fancy new algorithms. "Don't copy the original program, do it better."
2023-07-13 10:13:30 -0400 < Zipheir> lockywolf: If so, I don't know his nick. I haven't seen him on the SRFI lists in a while, either.
2023-07-13 10:18:15 -0400 < lockywolf> okay, mailed him
2023-07-13 10:25:35 -0400 < lockywolf> Where do guile extensions go?
2023-07-13 10:25:52 -0400 < lockywolf> Something like site-lisp in Emacs Lisp
2023-07-13 10:49:32 -0400 < anthk_> on the GNU, not actually, the keybindings of emacs were used the same on every system
2023-07-13 10:49:41 -0400 < anthk_> since ITS
2023-07-13 10:54:45 -0400 < Zipheir> Well, GNU Emacs wasn't a fresh GNU project. It started as Guy Steele's baby.
2023-07-13 10:55:22 -0400 < Zipheir> Stallman has sort of implied that he mostly rewrote it, but the evidence is lacking.
2023-07-13 10:57:09 -0400 < civodul> hm?
2023-07-13 11:09:49 -0400 < lockywolf> Is anybody using using guile-dbi?
2023-07-13 11:10:03 -0400 < lockywolf> On my machine it fails with guile: symbol lookup error: /usr/lib64/libguile-dbi.so: undefined symbol: lt_dlinit
2023-07-13 11:10:23 -0400 < lockywolf> Zipheir: Steele? Wasn't it Gosling's?
2023-07-13 11:11:59 -0400 < lockywolf> That is, (use-modules (dbi dbi)) fails with that symbol lookup error.
2023-07-13 11:12:25 -0400 < Zipheir> There's also the Gosling claim.
2023-07-13 11:12:54 -0400 < Zipheir> Daniel Weinreb: "And while I’m setting the record straight, the original (TECO-based) Emacs was created and designed by Guy L. Steele Jr. and David Moon. After they had it working, and it had become established as the standard text editor at the AI lab, Stallman took over its maintenance."
2023-07-13 11:12:54 -0400 < Zipheir> https://web.archive.org/web/20090101103828/http://danweinreb.org/blog/rebuttal-to-stallmans-story-about-the-formation-of-symbolics-and-lmi
2023-07-13 11:13:01 -0400 < rudybot> https://teensy.info/VZMvy5sagx
2023-07-13 11:13:09 -0400 < lockywolf> I am more concerned with the inability to load dbi than with whoever was the guy who wrote emacs.
2023-07-13 11:13:24 -0400 < Zipheir> lockywolf: This is a public channel.
2023-07-13 11:13:32 -0400 < lockywolf> :)
2023-07-13 11:13:42 -0400 < lockywolf> I am just saying that I am not ready to defend Gosling
2023-07-13 11:14:05 -0400 < Zipheir> Sorry to be snippy. I don't know anything about guile-dbi.
2023-07-13 11:14:18 -0400  * Zipheir makes more coffee.
2023-07-13 12:02:42 -0400 < dpk> Zipheir: really? i thought it started as a James Gosling thing but Stallman *did* rewrite it because (a) it wasn't real lisp but also (b) it turns out someone else owned the copyright and wasn't happy about Stallman doing a piracy oops
2023-07-13 12:07:44 -0400 < Zipheir> dpk: That's what Gosling says, but it seems to contradict Weinreb's story.
2023-07-13 12:09:43 -0400 < Zipheir> On that story, David Moon commented that he and Steele wrote the original Emacs, but that he was "very happy" to have Stallman take over maintenance.
2023-07-13 12:09:50 -0400 < dpk> TECO Emacs has no source code relation to several of the other Emacses including GNU Emacs
2023-07-13 12:10:09 -0400 < dpk> there were also EINE and ZWEI, the main Lisp-based Emacs before rmsmacs
2023-07-13 12:13:09 -0400 < dpk> the family tree explains https://www.jwz.org/doc/emacs-timeline.html
2023-07-13 12:13:14 -0400 < Zipheir> That I believe.
2023-07-13 12:13:29 -0400 < dpk> (huh, i thought Hemlock was based on ZWEI. apparently not)
2023-07-13 12:14:15 -0400 < dpk> recent surprising news includes: XEmacs lives – they had a new beta release recently
2023-07-13 12:14:24 -0400 < dpk> for the first time in over a decade, i think?
2023-07-13 12:15:42 -0400 < dpk> but realistically, rmsmacs got so far ahead of them in that decade that i'm not sure why anyone but the most die-hard XEmacs user would keep using it
2023-07-13 12:16:05 -0400 < Zipheir> And then there's jove.
2023-07-13 12:16:27 -0400 < dpk> rmsmacs even fixed the flickering – not by making the garbage collector faster, but by implementing double buffering. advanced late 1980s technology reaches the bowels of the unfrozen early 1980s glorified Lisp REPL
2023-07-13 12:17:19 -0400 < dpk> (i believe they are now looking at making the garbage collector faster, and put out a call for memory benchmark information from typical users. i would dig out the mailing list post but i have to run)
2023-07-13 12:18:19 -0400 < Zipheir> If the stuff people expected Emacs to run weren't so complicated, GC speed wouldn't be a problem.
2023-07-13 12:18:54 -0400 < wasamasa> https://yhetil.org/emacs-devel/83v8j6t2ib.fsf@gnu.org/
2023-07-13 12:19:00 -0400 < wasamasa> https://old.reddit.com/r/emacs/comments/14dej62/please_help_collecting_statistics_to_optimize/
2023-07-13 12:22:59 -0400 < dpk> Zipheir: i mean, it caused noticeable UI pauses back in the 1990s, aiui. and if people buy a computer with twice as much memory and a CPU that’s twice as fast, it’s not unreasonable to expect that Emacs will be able to keep twice as many buffers open
2023-07-13 12:23:26 -0400 < dpk> but when the GC is non-generational, more memory equals more GC time every time
2023-07-13 12:24:16 -0400 < Zipheir> It's not generational?
2023-07-13 12:45:37 -0400 < sham1> IIRC at least the C modules can keep arbitrary references to Emacs values
2023-07-13 12:45:46 -0400 < sham1> And I'm not sure how a generational GC would work for thst
2023-07-13 12:45:48 -0400 < sham1> That
2023-07-13 12:47:51 -0400 < dpk> Zipheir: of course it isn’t, Emacs was written in the 1980s using technology from the 1970s by a guy whose taste in good software engineering practice hasn’t advanced since the 1960:
2023-07-13 12:48:01 -0400 < dpk> *1960s
2023-07-13 12:54:01 -0400 < Zipheir> :)
2023-07-13 12:55:16 -0400 < sham1> And all because of a printer driver
2023-07-13 12:58:15 -0400 < gwatt_> dpk: *whose taste in general* hasn't advanced
2023-07-13 13:05:59 -0400 -!- gwatt_ is now known as gwatt
2023-07-13 13:18:46 -0400 < jcowan> Eh, the history of taste is one of unsystematic fluctuations.
2023-07-13 13:21:38 -0400 < jcowan> "Casual value-judgments belong not to [literary] criticism but to the history of taste, and reflect, at best, only the social and psychological compulsions which prompted their utterance. All judgments in which the values are not based on literary experience but are sentimental or derived from religious or political prejudice may be regarded as casual. Sentimental judgments are usually based either on non-existent categories or
2023-07-13 13:21:38 -0400 < jcowan> antitheses (“Shakespeare studied life, Milton books”) or on a visceral reaction to the writer’s personality. The literary chit-chat which makes the reputations of poets boom and crash in an imaginary stock exchange is pseudo-criticism. That wealthy investor Mr. Eliot, after dumping Milton on the market, is now buying him again; Donne has probably reached his peak and will begin to taper off; Tennyson may be in for a slight
2023-07-13 13:21:38 -0400 < jcowan> flutter but the Shelley stocks are still bearish. This sort of thing cannot be part of any systematic study, for a systematic study can only progress: whatever dithers or vacillates or reacts is merely leisure-class conversation."  --Northrop Frye
2023-07-13 13:30:25 -0400 < Zipheir> Very good.
2023-07-13 13:30:48 -0400 < jcowan> It would be a Good Thing to have a portable implementation of `read` based on an exposed readtable implementation
2023-07-13 13:34:26 -0400 < sham1> I wonder what the interaction between readtables and syntax objects would be
2023-07-13 13:35:18 -0400 < sham1> Like would an implementation have to expose procedures to turn datums into syntax objects for the sake of read, so things like file positions can be included, or would the readtable handler just return regular data and have the implementation wrap it
2023-07-13 13:46:43 -0400 < jcowan> The latter I think
2023-07-13 13:47:02 -0400 < jcowan> `read` has nothing to do with source code; it just reads S-expressions.
2023-07-13 13:47:50 -0400 < amirouche> sham1: GNU gets all the rage because it is in the spotlight?
2023-07-13 13:48:21 -0400 < amirouche> jcowan: I am in the mood to take notes :)
2023-07-13 13:48:45 -0400 < amirouche> Can you explain to me how do you think it is best to represent unicode points?
2023-07-13 13:48:46 -0400 < sham1> jcowan: I'm think that we probably should just bite the bullet and somehow standardise (read) but with syntax obejcts. Something like (read-syntax) which is found in many impls
2023-07-13 13:49:02 -0400 < amirouche> What si the difference between foo-remove, and foo-delete?
2023-07-13 13:49:04 -0400 < jcowan> We already have datum->syntax
2023-07-13 13:49:41 -0400 < sham1> I think that for internal representation, having the full 21-bit Unicode codepoint as a single object is very valuable, so I always just end up with 32-bit words for Unicode. For information interchange I use UTF-8
2023-07-13 13:50:54 -0400 < jcowan> amirouche: -delete gets rid of things that are the same (in the sense of the comparator) to a given object, whereas -remove gets rid of things that satisfy a given predicate
2023-07-13 13:51:42 -0400 < jcowan> sham1: You are talking about representing characters as integers?
2023-07-13 13:51:51 -0400 < jcowan> (fixnums?)
2023-07-13 13:52:09 -0400 < sham1> Well characters can be characters, but how the character object itself is implemented, I feel should be a 32-bit fixnum or similar
2023-07-13 13:52:29 -0400 < sham1> But of course in Scheme's case it'd be a disjoint type
2023-07-13 13:53:40 -0400 < sham1> O(1) indexing and IMO it's just the "correct" way to do it
2023-07-13 13:55:17 -0400 < sham1> And unless you're heap allocating characters (I sure hope not), you have the space anyhow
2023-07-13 13:57:17 -0400 < sham1> A tagged pointer will be able to house a codepoint, no matter if the pointer is 32 or 64 bits
2023-07-13 14:24:23 -0400 < jcowan> Oh, yes, absolutely.  There are only a few Lisps that don't implement characters as immediates.
2023-07-13 14:24:57 -0400 < jcowan> Interlisp may be one of them, because it uses 16-bit XCCS characters and the wordsize is also 16 bits.
2023-07-13 14:27:02 -0400 < jcowan> There are three objects sserving the function of characters in Interlisp: single-character symbols, fixnums, and opaque CL characters.  These are not interchangeable, though there are conversion functions.
2023-07-13 14:36:29 -0400 -!- ifreund_ is now known as ifreund
2023-07-13 14:42:11 -0400 -!- Netsplit *.net <-> *.split quits: fluffyballoon, nckx, zyd, sm2n, mns, jakzale, wklew, whereiseveryone, abcdw, taw10,  (+6 more, use /NETSPLIT to show all of them)
2023-07-13 14:42:11 -0400 -!- nckx_ is now known as nckx
2023-07-13 14:42:12 -0400 -!- jakzale_ is now known as jakzale
2023-07-13 14:42:12 -0400 -!- wklew_ is now known as wklew
2023-07-13 14:42:12 -0400 -!- zyd_ is now known as zyd
2023-07-13 14:42:12 -0400 -!- fluffyballoon_ is now known as fluffyballoon
2023-07-13 14:42:12 -0400 -!- abcdw_ is now known as abcdw
2023-07-13 14:42:12 -0400 -!- sm2n_ is now known as sm2n
2023-07-13 14:42:12 -0400 -!- kws_ is now known as kws
2023-07-13 14:42:18 -0400 -!- whereiseveryone_ is now known as whereiseveryone
2023-07-13 14:43:08 -0400 -!- Netsplit over, joins: taw10
2023-07-13 14:52:02 -0400 -!- buhman_ is now known as buhman
2023-07-13 15:44:03 -0400 -!- drakonis1 is now known as drakonis
2023-07-13 16:30:03 -0400 < dpk> jcowan: i still intend to replace Chibi's read with a readtable-based implementation at some point. although in C, the API could in theory be portable
2023-07-13 16:30:39 -0400 < jcowan> good
2023-07-13 16:30:54 -0400 < jcowan> one issue is what the API wil be: CL, Chicken, MIT, other?
2023-07-13 16:31:31 -0400 < dpk> we'll see when i actually get around to that. the next two weeks: no chance. the several weeks after: maybe, but i also want to relax a bit after a very stressful semester and also have other stuff (making money, sigh) on the to-do list
2023-07-13 16:31:44 -0400 < jcowan> but in this case what interests me is a Scheme implementation to be used to mess about with
2023-07-13 16:32:05 -0400 < dpk> i dunno, i haven't looked at APIs yet and was probably just going to design my own
2023-07-13 16:34:06 -0400 < dpk> (naturally i also wanted to take the opportunity to add SRFI 207 support to Chibi ;-) )
2023-07-13 16:41:32 -0400 < dpk> i could also add an ouroboros ‘for Chez compatibility’ :D
2023-07-13 16:41:39 -0400 < dpk> at the moment it's a read error in Chibi
2023-07-13 16:41:54 -0400 < jcowan> an ouroboros?
2023-07-13 16:42:13 -0400 < dpk> https://github.com/cisco/ChezScheme/issues/393
2023-07-13 16:42:46 -0400 < dpk> > It's neither a bug nor a feature...#0=#0# (which shouldn't mean anything) was just a little joke I added a long time ago for those who trip over it.
2023-07-13 16:48:03 -0400 < wasamasa> what
2023-07-13 16:49:18 -0400 < jcowan> wow
2023-07-13 16:51:59 -0400 < jcowan> "Everything backwards and upside down on Bizarro World!"
2023-07-13 16:57:52 -0400 < jcowan> Chicken API at https://wiki.call-cc.org/man/5/Module%20(chicken%20read-syntax)
2023-07-13 16:59:03 -0400 < jcowan> CL explanations and API at http://www.lispworks.com/documentation/lw71/CLHS/Body/23_.htm
2023-07-13 17:17:27 -0400 < amirouche> us
2023-07-13 17:17:40 -0400 < amirouche> oops
2023-07-13 17:17:42 -0400 < amirouche> gn
2023-07-13 18:04:28 -0400 < duncanm> does Lassi come on here ever?
2023-07-13 18:20:29 -0400 < Zipheir> duncanm: He shows up on IRC once in a while.
2023-07-13 21:10:49 -0400 < lockywolf> duncanm: I think he usually uses the nick lassik
2023-07-13 22:05:53 -0400 < Zipheir> That or 'mangol'.
2023-07-13 22:56:32 -0400 < lechner> Hi, how may I tell Emacs to open Scheme files without file extensions in scheme-mode, please? Usually, this is done on the first or second line with an annotation like -*- but Guile executables use !# in the second line. Setting "local variables" toward the end of file also does not seem to work. Thanks!
2023-07-13 22:59:18 -0400 < duncanm> thanks!
2023-07-13 23:12:56 -0400 -!- ggoes_ is now known as ggoes
2023-07-13 23:33:25 -0400 < Zambyte> lechner: Using M-x add-file-local-variable-prop-line or M-x add-file-local-variable should let you set the mode with the proper formatting
2023-07-13 23:45:29 -0400 < daviid> lechner: how about - https://paste.centos.org/view/ad19af65
--- Day changed Fri Jul 14 2023
2023-07-14 01:07:02 -0400 < lockywolf> Has anyone tried "GNU Artanis"?
2023-07-14 01:07:38 -0400 < lockywolf> I managed to compile guile-dbi, but artanis compilation fails with a wonderful error message:
2023-07-14 01:08:01 -0400 < lockywolf> ce-9/boot-9.scm:1685:16: In procedure raise-exception: Syntax error: unknown location: unexpected syntax in form ()
2023-07-14 01:08:58 -0400 < lockywolf> Unknown syntax while throwing an unknown exceptions, god knows where, god knows why.
2023-07-14 01:09:58 -0400 < lockywolf> I am thinking this might be due to my Guile not being the most recent one.
2023-07-14 01:10:11 -0400 < lockywolf> But it's just two patch versions behind.
2023-07-14 01:10:13 -0400 < lockywolf> 3.0.7
2023-07-14 01:11:16 -0400 < lechner> Zipheir / daviid / thanks! the emacs command gave me this, which seems to work      http://paste.debian.net/1285823
2023-07-14 01:16:47 -0400 < lechner> Hi, are there Vim users here, please? To also help folks like you, I'd like to add a similar annotation for Vim but I have never used that editor (and I am not having much luck searching online). Thanks!
2023-07-14 01:29:15 -0400 < shawnw> The only vim commands I know are :q and :!emacs, sorry.
2023-07-14 01:32:24 -0400 < sham1> :!emacs -nw %
2023-07-14 01:32:27 -0400 < sham1> pls
2023-07-14 01:36:06 -0400 < shawnw> What's the % do? Replaced by the current filename?
2023-07-14 01:36:21 -0400 < sham1> Yeah, it's the current buffer
2023-07-14 01:38:24 -0400 < Zipheir> It would be ; vim: <some scheme mode switch>
2023-07-14 01:38:39 -0400 < Zipheir> ; vim: syntax scheme
2023-07-14 01:38:42 -0400 < Zipheir> Maybe?
2023-07-14 01:40:35 -0400 < Zipheir> lechner: Oh, it seems to be ; vim: syntax=scheme
2023-07-14 01:40:42 -0400 < Zipheir> That works for me, at least.
2023-07-14 01:41:20 -0400 < Zipheir> Modeline syntax should really be standardized.
2023-07-14 02:07:27 -0400 < lockywolf> hehe, it actually needs guile 3.0.9
2023-07-14 02:07:53 -0400 < lockywolf> because who needs so version compatibility in the dotpatch releases? pussies
2023-07-14 02:16:12 -0400 < flatwhatson> 3.0.9 fixed a problem with reporting error locations :)
2023-07-14 02:18:24 -0400 < lockywolf> flatwhatson: so nice!
2023-07-14 02:20:00 -0400 < lockywolf> There is a Russian joke about a guy who, while driving his car, spotted a sticker on the bumper of the car ahead. And he tried to stick as close as possible to that car to see what was written on it, so close in fact, that eventually he bumped right into it and they both had to stop to call the traffic police.
2023-07-14 02:23:03 -0400 < daviid> and after the accident, they can read the sticker, it says ' !!! keep your distance !!!' :):)
2023-07-14 02:24:34 -0400 < lockywolf> daviid: precisely
2023-07-14 02:25:36 -0400 < lockywolf> Autopsy has exposed that the cause of death was autopsy.
2023-07-14 03:08:03 -0400 -!- rgherdt_ is now known as rgherdt
2023-07-14 03:08:19 -0400 < geri> hey, how does one create a hygienic macro that "maps" another macro over it's arguments in guile?
2023-07-14 03:10:43 -0400 < geri> in this case define-macro doesn't produce the needed result
2023-07-14 04:42:26 -0400 < edgar-rft> maybe it helps to apply some disinfectant
2023-07-14 05:28:08 -0400 < geri> edgar-rft: m?
2023-07-14 05:31:04 -0400 < geri> oh, that was a joke, right? :D
2023-07-14 05:42:51 -0400 < geri> how do i create a macro that takes a list of strings and returns a list of calls to another macro? :D
2023-07-14 05:44:05 -0400 < geri> wrong chat
2023-07-14 05:47:49 -0400 < rgherdt> geri: regarding your first question, do you have an example from what you are trying to do?
2023-07-14 05:49:39 -0400 < geri> i have a macro for guix to "resolve" a package - basically if it has slashes - it creates a package from a local script, if doesn't - it's treated as a specification for specification->package and otherwise just returns itself
2023-07-14 05:49:54 -0400 < geri> i don't want to call it 10 times for each script i want to install so i want a macro that'll do it for me
2023-07-14 05:52:02 -0400 < geri> i could dump all the code i have if it'll help
2023-07-14 05:58:52 -0400 < rgherdt> sure, you can use the pastebin for that. A minimal example would be best. Unfortunately I have to leave now (and I'm not really a macro guru), but I can take a look later
2023-07-14 05:59:43 -0400 < geri> https://0x0.st/Hj2Q.scm
2023-07-14 06:00:02 -0400 < geri> i've put a comment where it starts breaking
2023-07-14 06:06:08 -0400 < dpk> code-walking macros are generally not a particularly great idea
2023-07-14 06:06:18 -0400 < dpk> whether hygienic or unhygienic
2023-07-14 06:11:45 -0400 < dpk> if we had syntax-expand like Racket, it would be less bad, but i don't think you'll ever see something like that standardized
2023-07-14 06:11:50 -0400 < dpk> much as i would like to have it
2023-07-14 06:18:47 -0400 < amirouche> at last, five years in, I found an actual use for the zig zag algorithm to merge sorted lazy stream
2023-07-14 06:19:05 -0400 < amirouche> +s
2023-07-14 06:19:09 -0400 < amirouche> sorted lazy streams
2023-07-14 06:24:02 -0400  * edgar-rft sorts lazy streams so that the most lazy stream comes first
2023-07-14 06:25:19 -0400 < geri> dpk: isn't the whole idea of macros that you replace thing with another at compile time
2023-07-14 06:25:29 -0400 < geri> in cl when you expand macros it's often going to expand into more macros
2023-07-14 06:25:52 -0400 < geri> maybe i just dont understand the code-walking part
2023-07-14 12:03:58 -0400 < amirouche> I never seen code walking macros in Scheme
2023-07-14 12:04:09 -0400 < amirouche> It might related to the fact that schemers love mor to argue about what the good thing must be, instead actually build some thing
2023-07-14 12:04:53 -0400 < amirouche> when they are not actively sap the morale of their peers
2023-07-14 12:06:38 -0400 < amirouche> s/sap/sapping/
2023-07-14 12:07:42 -0400 < sham1> Wait, we do that?
2023-07-14 12:08:10 -0400 < amirouche> this is not the case of all schemers obviously
2023-07-14 12:25:17 -0400 < geri> what's code walking exactly?
2023-07-14 12:26:52 -0400 < jackdaniel> it is analyzing the list as if it were the code i.e to infer this and that from it
2023-07-14 12:27:46 -0400 < geri> oh okay
2023-07-14 12:28:08 -0400 < jackdaniel> you must understand special operators and whatnot
2023-07-14 12:29:15 -0400 < Zipheir> amirouche: Deliberating about what to build is an important step in actually building it.
2023-07-14 12:29:47 -0400 < Zipheir> jackdaniel: Special operators?
2023-07-14 12:30:56 -0400 < geri> https://gigamonkeys.com/book/the-special-operators.html
2023-07-14 12:31:08 -0400 < Zipheir> Sounds like a crime ring.
2023-07-14 12:31:08 -0400 < geri> probably this but for scheme instead
2023-07-14 12:31:20 -0400 < geri> :D Zipheir
2023-07-14 12:32:48 -0400 < Zipheir> I don't get Seibel's distinction. lambda should also be a special form by his lights, since it delays evaluation of its body.
2023-07-14 12:33:03 -0400 < Zipheir> Ahem, special operator.
2023-07-14 12:34:30 -0400 < Zipheir> Maybe the semantics of CL make it a useful distinction.
2023-07-14 12:35:06 -0400 < edgar-rft> in Common Lisp lambda is a macro, what *is* a kind of special operator
2023-07-14 12:36:17 -0400 < Zipheir> So it means the same thing that SICP does when they refer to 'special forms'--basically, anything implemented "as syntax".
2023-07-14 12:37:06 -0400 < Zipheir> (And thus something not first-class.)
2023-07-14 12:38:19 -0400 < geri> i have a macro that takes one string, do you know how could i write another one that takes a list of strings and returns a bunch of calls to the first macro that then get expanded properly? Zipheir
2023-07-14 12:38:53 -0400 < geri> define-macro doesn't wanna work :)
2023-07-14 12:40:47 -0400 < Zipheir> geri: Sure. Avoid define-macro when possible, I say.
2023-07-14 12:41:14 -0400 < geri> i feel like im only gonna avoid it because it keeps on *not* working in scheme
2023-07-14 12:41:30 -0400 < geri> at least for my use cases
2023-07-14 12:41:33 -0400 < Zipheir> geri: You can do it with syntax-rules, though it can be done more elegantly with syntax-case or other procedural macros.
2023-07-14 12:41:45 -0400 < gwatt> It sounds like what you want would be a pretty trivial syntax-rules macro
2023-07-14 12:42:10 -0400 < geri> i mean it should take a list and return a lot of calls to another macro
2023-07-14 12:42:42 -0400 < Zipheir> (define-syntax foo-all (syntax-rules () ((foo-all ()) ()) ((foo-all (x . xs)) ((foo x) . (foo-all xs))))
2023-07-14 12:43:07 -0400 < Zipheir> Where foo is your auxiliary macro. That may be right. It's been a while since I've done recursive list macros.
2023-07-14 12:43:18 -0400 < Zipheir> geri: That's the wrong way to think about it.
2023-07-14 12:43:54 -0400 < amirouche> hyperfiddle use code walking a lot
2023-07-14 12:43:55 -0400 < Zipheir> geri: You can only do this with constant lists.
2023-07-14 12:43:56 -0400 < amirouche> https://www.hyperfiddle.net/
2023-07-14 12:44:10 -0400 < gwatt> I would probably use the ... exploder instead of explicit recursion
2023-07-14 12:44:39 -0400 < Zipheir> geri: You cannot macro-expand on an arbitrary list. You'd have to operate on it procedurally.
2023-07-14 12:44:41 -0400 < gwatt> (syntax-rules () [(_ m arg* ...) (begin (m arg*) ...)])
2023-07-14 12:44:55 -0400 < Zipheir> True.
2023-07-14 12:45:01 -0400 < geri> the list is hardcoded technically speaking
2023-07-14 12:45:37 -0400 < Zipheir> In fact, there are no lists in meta-Scheme. There are (), (x . xs), and everything else.
2023-07-14 12:46:10 -0400 < Zipheir> gwatt: I always forget that that kind of ellipsis expansion works.
2023-07-14 12:46:34 -0400 < gwatt> geri: does you macro do things at expansion time? Or does it expand into scheme code that's executed at run-time?
2023-07-14 12:46:49 -0400 < amirouche> good question
2023-07-14 12:47:49 -0400 < geri> it expands into a cond call
2023-07-14 12:47:54 -0400 < geri> that gets eval'd at runtime
2023-07-14 12:48:05 -0400 < geri> Zipheir: what's meta-scheme
2023-07-14 12:48:35 -0400 < Zipheir> geri: meta-Scheme is what I'm calling the token-language handled by macros.
2023-07-14 12:49:21 -0400 < geri> tree-il?
2023-07-14 12:49:26 -0400 < Zipheir> e.g. symbol? doesn't make any sense in meta-Scheme. (Though Oleg Kiselyov figured out how to write it.)
2023-07-14 12:50:54 -0400 < Zipheir> Procedural macros implement a kind of "syntax monad" which allows you to work with the token language as Scheme.
2023-07-14 12:51:23 -0400 < Zipheir> But that only works because of the syntax->datum transformation.
2023-07-14 12:53:44 -0400 < geri> i learned about tree-il like 2 days ago
2023-07-14 12:54:44 -0400 < geri> also i found that #; comments out 1 sexp randomly and can't even find any documentation on it
2023-07-14 12:55:15 -0400 < gwatt> geri: It sounds like it might be possible to rewrite your macro as a function.
2023-07-14 12:55:16 -0400 < Zipheir> geri: https://srfi.schemers.org/srfi-62/
2023-07-14 12:55:56 -0400 < Zipheir> I'm not sure if Riastradh invented #; or if he just SRFIfied it.
2023-07-14 12:56:08 -0400 < geri> i'm coding for guix and it's only a macro because local-file fails to resolve relative paths unless it gets a string literal
2023-07-14 12:56:19 -0400 < geri> and it seems local-file is again the reason why my stuff doesn't wanna work
2023-07-14 12:57:00 -0400 < geri> local-file is syntax as well
2023-07-14 12:57:07 -0400 < Zipheir> That's quite weird, that it doesn't work except on literals.
2023-07-14 12:57:17 -0400 < geri> Zipheir: honestly this is like totally my #1 favorite qol feature in scheme
2023-07-14 12:57:28 -0400 < geri> it does work, but it fails to resolve relative paths unless its a string literal
2023-07-14 12:57:44 -0400 < geri> i should just bite the bullet and hardcode absolute paths instead, it's getting sillly
2023-07-14 12:58:16 -0400 < Zipheir> That's what I mean. I wonder why. Some weird notion of security?
2023-07-14 12:58:39 -0400 < geri> dunno
2023-07-14 12:58:45 -0400 < geri> lemme try to send link to definition
2023-07-14 12:59:27 -0400  * dpk thinks Zipheir's explanations here are confusing the matter more than helping
2023-07-14 13:00:29 -0400 < Zipheir> dpk: The matter *is* confusing. I'm just trying to make sure everyone's appropriately confused. :-)
2023-07-14 13:00:45 -0400 < geri> ))
2023-07-14 13:02:04 -0400 < geri> https://github.com/guix-mirror/guix/blob/master/guix/gexp.scm#L488
2023-07-14 13:02:39 -0400 < gwatt> Reminds of an exchange between coworkers a while ago: "Hey, I have a quick question". "I have long drawn-out answers"
2023-07-14 13:03:53 -0400 < geri> very relatable
2023-07-14 13:04:48 -0400 < sham1> If only one could have as simple answers as how simple the question is
2023-07-14 13:05:06 -0400 < Zipheir> geri: OK, this makes more sense now.
2023-07-14 13:05:17 -0400 < Zipheir> sham1: Sometime simple questions aren't.
2023-07-14 13:05:19 -0400 < dpk> maybe i should record my syntax-case talk this evening, just to show how confused Zipheir is making a quite simple issue
2023-07-14 13:05:41 -0400 < Zipheir> dpk: Hey dpk, I'm right, uh, here. No need for the third person.
2023-07-14 13:07:18 -0400 < geri> it doesn't really make sense for my bad brain :(
2023-07-14 13:08:55 -0400 < Zipheir> geri: So you're trying to expand a bunch of (local-file ...) things?
2023-07-14 13:09:00 -0400 < Zipheir> *expand to
2023-07-14 13:09:11 -0400 < geri> sec
2023-07-14 13:09:22 -0400 < geri> https://0x0.st/Hj2Q.scm
2023-07-14 13:09:26 -0400 < geri> technically yes
2023-07-14 13:10:06 -0400 < geri> w/ gwatt's syntax rule i'm getting a wrong type to apply error now xwx
2023-07-14 13:10:44 -0400 < Zipheir> Is it a list, or multiple arguments?
2023-07-14 13:11:12 -0400 < mdhughes> geri: Paths should usually be taken as arguments, environment, or config files. There is an INI file spec: https://srfi.schemers.org/srfi-233/srfi-233.html
2023-07-14 13:11:21 -0400 < rgherdt> geri: one trick I sometimes use when debugging a macro is to change it to output a quoted version of the original s-expr (or macroexpand it, depending on the features available in the implementation)
2023-07-14 13:11:33 -0400 < geri> &rest argument here Zipheir
2023-07-14 13:11:35 -0400 < Zipheir> geri: e.g. (local-files p1 p2 ...) or (local-files list-of-paths)
2023-07-14 13:11:41 -0400 < geri> rgherdt: i do that too
2023-07-14 13:11:47 -0400 < geri> local-file takes 1 argument too
2023-07-14 13:11:48 -0400 < Zipheir> Wait, rest arguments in a macro call?
2023-07-14 13:11:52 -0400 < geri> yes
2023-07-14 13:11:54 -0400 < mdhughes> But then you ask, "where do I read that INI file" and file-ception.
2023-07-14 13:11:58 -0400 < Zipheir> That doesn't make sense to me.
2023-07-14 13:12:15 -0400 < Zipheir> gwatt's syntax-rules example should work fine.
2023-07-14 13:12:54 -0400 < geri> so should the define-macro in the link
2023-07-14 13:12:59 -0400 < geri> but guix does some black magic there
2023-07-14 13:13:22 -0400 < Zipheir> Something like (define-syntax local-files (syntax-rules () ((local-files p0 ...) (begin (local-file p0) ...))))
2023-07-14 13:13:47 -0400 < geri> does the link not work?
2023-07-14 13:13:53 -0400 < Zipheir> geri: You pasted what looked like a fragment of C in a stack trace.
2023-07-14 13:14:13 -0400 < geri> too much stuff?
2023-07-14 13:14:35 -0400 < geri> oh
2023-07-14 13:14:41 -0400 < geri> it just got outdated, my bad
2023-07-14 13:14:59 -0400 < geri> huh
2023-07-14 13:15:00 -0400 < geri> or not??
2023-07-14 13:15:02 -0400 < geri> https://0x0.st/Hj2Q.scm
2023-07-14 13:15:18 -0400 < geri> tell me what it is this time
2023-07-14 13:16:31 -0400 < Zipheir> That's Scheme.
2023-07-14 13:16:35 -0400 < geri> great
2023-07-14 13:17:38 -0400 < Zipheir> I don't know how define-syntax-rule, so I'm not sure whether that makes sense.
2023-07-14 13:17:44 -0400 < geri> mdhughes: but i want paths to work relative to the source code file's location :(
2023-07-14 13:17:44 -0400 < Zipheir> *how define-syntax-rule works
2023-07-14 13:17:56 -0400 < geri> it's a shortcut for define syntax and syntax rules in one
2023-07-14 13:18:01 -0400 < geri> there's only one pattern tho
2023-07-14 13:18:56 -0400 < gwatt> geri: should your utils/resolve-package macro be checking if the spec starts with a "/" instead of if it contains a "/" ?
2023-07-14 13:19:45 -0400 < geri> no package in guix contains slashes, so if one does it's either relative or absolute path
2023-07-14 13:19:50 -0400 < geri> package name*
2023-07-14 13:19:53 -0400 < mdhughes> You can do that by just opening the file if it doesn't start with /
2023-07-14 13:21:27 -0400 < geri> problem is p much all functions that resolve path use $PWD when using relative paths in guile for some reason
2023-07-14 13:21:46 -0400 < geri> so if im in /, "./files/hello" will be /./files/hello
2023-07-14 13:21:55 -0400 < geri> if im home, it's gonna be in ~/files/hello
2023-07-14 13:22:00 -0400 < geri> which sucks
2023-07-14 13:22:01 -0400 < gwatt> I think that's pretty standard
2023-07-14 13:22:03 -0400 < mdhughes> Oh, that's correct, but you can probably parse argv(0) to get the script's location.
2023-07-14 13:22:17 -0400 < gwatt> The whole point of relative paths is that they're relative
2023-07-14 13:22:18 -0400 < Zipheir> geri: I think mixing procedural and syntax-rules macros is making a mess here.
2023-07-14 13:22:24 -0400 < mdhughes> Or if the INI file is in $HOME or whatever, you can set that path wherever you want.
2023-07-14 13:23:22 -0400 < geri> Zipheir: i could only interpret that as "put it all in one macro, dummy"
2023-07-14 13:23:38 -0400 < mdhughes> I hit that a lot, Scheme has a poorly defined environment, so "load library relative to script" is sometimes harder to do than you'd like.
2023-07-14 13:23:41 -0400 < Zipheir> geri: For example, there's no reason for utils/resolve-package to be a macro that I can see, since you call it procedurally in utils/resolve-packages.
2023-07-14 13:24:02 -0400 < geri> it's a macro because local-file breaks if it's not
2023-07-14 13:24:18 -0400 < geri> i wanted to make it a script but then it tries to resolve paths relative to $PWD and not file location
2023-07-14 13:24:24 -0400 < mdhughes> Or the Chez solution is CHEZSCHEMELIBDIRS
2023-07-14 13:24:29 -0400 < gwatt> Zipheir: local-file is a macro and changes its behavior if the path argument is a literal string
2023-07-14 13:24:31 -0400 < mdhughes> (in environment)
2023-07-14 13:24:31 -0400 < geri> wanted to make it a function*
2023-07-14 13:25:00 -0400 < Zipheir> OK, I see.
2023-07-14 13:25:11 -0400 < Zipheir> This is all very hairy.
2023-07-14 13:25:15 -0400 < geri> ikr
2023-07-14 13:25:22 -0400 < geri> time to rewrite my entire config
2023-07-14 13:25:38 -0400 < geri> mdhughes: yeah, it is way more difficult than i'd like
2023-07-14 13:25:42 -0400 < geri> time to write another srfi
2023-07-14 13:26:20 -0400 < Zipheir> dpk: See privmsg, unless you block them or something?
2023-07-14 13:27:57 -0400 < geri> let me try combining resolve-package and gwatt's syntax rule xd
2023-07-14 13:32:00 -0400 < geri> yeah nvm, i don't know where to put the ellipsis for it to work
2023-07-14 13:33:02 -0400 < geri> oh nvm, forgot to remove *
2023-07-14 13:33:03 -0400 < Zipheir> geri: I think that writing a simple version without define-macro might be a good place to start.
2023-07-14 13:33:07 -0400 < geri> if it works im gonna laugh so hard
2023-07-14 13:33:23 -0400 < Zipheir> I think it can work with just syntax-rules.
2023-07-14 13:33:46 -0400 < geri> it was all in one originally, i broke it up thinking it'd work then
2023-07-14 13:33:58 -0400 < geri> okay, it works so far, lemme make everything use this one
2023-07-14 13:36:23 -0400 < geri> yup
2023-07-14 13:36:30 -0400 < geri> it just works now XD
2023-07-14 13:36:37 -0400 < geri> don't do nested macros kids
2023-07-14 13:37:21 -0400 < geri> well, i got to learn how ellipsis work, that's epic
2023-07-14 13:37:25 -0400 < geri> thank gwatt
2023-07-14 13:37:30 -0400 < geri> Zipheir: you too
2023-07-14 13:38:27 -0400 < Zipheir> I'm glad it finally worked :)
2023-07-14 13:38:41 -0400 < geri> i've been doing it for like 3 days
2023-07-14 13:47:52 -0400 < geri> https://www.gnu.org/software/guile/manual/html_node/Syntax-Rules.html
2023-07-14 13:48:01 -0400 < geri> now i understand the first sentence B)
2023-07-14 13:49:28 -0400 < Zipheir> geri: Have you read JRM's guide? https://www.sigwinch.xyz/misc/jrms_syntax-rules_primer.txt
2023-07-14 13:50:05 -0400 < geri> no, it was notoriously difficult to find any tutorials on the matter
2023-07-14 13:50:07 -0400 < geri> at least in ddg
2023-07-14 13:50:10 -0400 < geri> thank
2023-07-14 13:51:06 -0400 < Zipheir> It's the best syntax-rules tutorial I know of.
2023-07-14 13:51:54 -0400 < geri> if you have any for syntax case, i'll take it too)
2023-07-14 13:52:29 -0400 < Zipheir> We really need one of those.
2023-07-14 13:53:26 -0400 < Zipheir> This is the closest thing I know to a syntax-case tutorial: https://cs.indiana.edu/~dyb/pubs/tr356.pdf
2023-07-14 13:53:46 -0400 < Zipheir> It's a bit dense.
2023-07-14 13:55:37 -0400 < gwatt> I think mnieper wrote some syntax-case tutorials
2023-07-14 13:55:42 -0400 < geri> 31 pages XD
2023-07-14 13:55:57 -0400 < geri> i learned today that both define-macro and syntax-rules is written with syntax-case in guile
2023-07-14 13:56:00 -0400 < geri> p interesting
2023-07-14 13:56:09 -0400 < geri> s/is/are
2023-07-14 13:56:54 -0400 < gwatt> Also, TSPL4 & CSUG I think are reasonable places to look. Dybvig gives examples of how one could implement many of the macros in R6RS & chez
2023-07-14 13:58:04 -0400 < gwatt> geri syntax-rules is actually trivial to implement in syntax-case as it's effectively syntax-case with an already quoted pattern expansion
2023-07-14 13:58:16 -0400 < Zipheir> geri: Sure. define-macro is just syntax case without airbags.
2023-07-14 13:58:24 -0400 < Zipheir> And possibly with the brakes removed.
2023-07-14 13:58:37 -0400 < geri> but you can't deny it goes fast B)
2023-07-14 13:59:07 -0400 < dpk> the R6RS spec shows how to implement both syntax-rules and define-macro (called lisp-transformer there) in relatively few lines of syntax-case code
2023-07-14 13:59:38 -0400 < dpk> geri: define-macro implemented in terms of syntax-case is very slow (quadratic expansion time)
2023-07-14 13:59:47 -0400 < Zipheir> Interesting.
2023-07-14 14:00:13 -0400 < geri> https://docs.scheme.org/guide/macros/ says a lot of implementations dont have syntax-case, which is p bizzare
2023-07-14 14:00:35 -0400 < geri> dpk: ouch
2023-07-14 14:00:39 -0400 < dpk> that's because syntax-case became a political issue
2023-07-14 14:00:57 -0400 < geri> eh
2023-07-14 14:00:58 -0400 < geri> what happen?
2023-07-14 14:01:28 -0400 < gwatt> dpk: from a Clinger talk, it sounds like at one point syntax-rules was a political issue
2023-07-14 14:01:36 -0400 < geri> gwatt: csug == chez scheme user guide?
2023-07-14 14:01:41 -0400 < gwatt> geri: yes
2023-07-14 14:01:49 -0400 < geri> aighty, thanks
2023-07-14 14:02:01 -0400 < dpk> i'll leave answering that to someone who can do it without swearing, because i am currently very frustrated at the world and recounting this argument will not help that situation
2023-07-14 14:02:18 -0400 < geri> hope you'll feel better :(
2023-07-14 14:02:21 -0400 < Zipheir> dpk: I'm sorry to hear you're frustrated.
2023-07-14 14:03:37 -0400 < Zipheir> geri: A lot of Schemers associate syntax-case with R6RS, since Kent Dybvig had a big part in both. R6RS was (and to some extent still is) very controversial.
2023-07-14 14:04:15 -0400 < geri> i remember hearing something about some implementations just skipping R6 and going straight for R7
2023-07-14 14:04:35 -0400 < Zipheir> The current project is to heal the split.
2023-07-14 14:05:08 -0400 < geri> ah
2023-07-14 14:05:31 -0400 < geri> brb in ~20
2023-07-14 14:06:05 -0400 < mdhughes> Or use R6, skip R7 and wait for R8.
2023-07-14 14:06:26 -0400 < Zipheir> syntax-case was voted into R7-large, while explicit renaming is out: https://github.com/johnwcowan/r7rs-work/blob/master/ColorDockets.md#yellow-docket-macros
2023-07-14 14:09:15 -0400 < dpk> there will be no R8RS, i can say with some certainty
2023-07-14 14:09:45 -0400 < dpk> as i said yesterday to jcowan, can you imagine someone looking at how long R7RS has taken and how much of a pain in the arse it was, and thinking, ‘yeah, let’s do that again’ ?
2023-07-14 14:10:30 -0400 < sham1> I reckon that R7-large would pretty much just be R8RS in all but name
2023-07-14 14:10:56 -0400 < Zipheir> dpk: Maybe in 25 years with a lot of new blood.
2023-07-14 14:11:47 -0400 < dpk> great, i'll note that down for my twilight years
2023-07-14 14:11:58 -0400 < Zipheir> On the question of "why are there so many editions of D&D?", Matt Colville said "Each new generation of designers wants to take a crack at it."
2023-07-14 14:12:09 -0400  * dpk sets a reminder for when she turns 50: tell young whippersnappers that making R8RS would be too much work
2023-07-14 14:13:32 -0400 < gwatt> Zipheir: at least we can all be glad that D&D no longer has a alignment languages.
2023-07-14 14:19:25 -0400 < mdhughes> I still play original D&D (Swords & Wizardry, a 0E retroclone)
2023-07-14 14:24:43 -0400 < Zipheir> At least WotC committed to keeping the earlier editions available.
2023-07-14 14:25:45 -0400 < Zipheir> But there's money to be made in new RPG editions. I can't see anyone lining up to buy copies of R8RS. :)
2023-07-14 14:27:39 -0400 < geri> i could see people lining up to get an update to their fav language though
2023-07-14 14:31:35 -0400 < geri> is there anything one could say is missing from R7RS?
2023-07-14 14:34:41 -0400 < Zipheir> geri: R7RS-small is missing a ton, intentionally. R7RS-large isn't done yet, so who knows?
2023-07-14 14:35:32 -0400 < geri> ah
2023-07-14 14:35:36 -0400 < geri> there's time to make it perfect then
2023-07-14 14:35:44 -0400 < sham1> That's the goal
2023-07-14 14:36:08 -0400 < Zipheir> Well, some would say it's been too big for perfection for a long time now.
2023-07-14 14:36:31 -0400 < geri> how long has r7rs has existed/been worked on now?
2023-07-14 14:37:15 -0400 < jackdaniel> Zipheir: any operator that does not adhere to the regular evaluation rules (loosely speaking)
2023-07-14 14:37:21 -0400 < gwatt> geri: I think the process started around 2010.
2023-07-14 14:37:28 -0400 < Zipheir> ^
2023-07-14 14:37:37 -0400 < geri> wow okay
2023-07-14 14:37:44 -0400 < Zipheir> jackdaniel: Right.
2023-07-14 14:37:48 -0400 < geri> we can expect r7rs large to be able to legally drink by the end
2023-07-14 14:37:57 -0400 < gwatt> IIRC R7RS-small was ratified in 2013
2023-07-14 14:39:08 -0400 < Zipheir> In terms of elegance and brevity, it's hard to beat R5RS. https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/
2023-07-14 14:39:20 -0400 < geri> is large version at least 4+ times larger than small?
2023-07-14 14:39:37 -0400 < Zipheir> Easily, going by included SRFI text.
2023-07-14 14:41:52 -0400 < geri> amazing
2023-07-14 14:43:13 -0400 < jrincayc> Hm, I did try to beat R5RS in elegence and brevity: https://github.com/jrincayc/r7rs-pico-spec
2023-07-14 14:43:26 -0400 < Zipheir> Yes.
2023-07-14 14:44:39 -0400 < Zipheir> geri: Vincent Manis made a LaTeX version of R7RS Red Edition, the first completed part. https://gitlab.com/vmanis/r7rs-large/-/blob/master/reports/red.pdf
2023-07-14 14:45:35 -0400 < Zipheir> Who knows what's going on now, but the original plan was to have 12 color editions.
2023-07-14 14:46:10 -0400 < Zipheir> Er, the plan on r7rs.org calls for 12 editions, some of which are colors and some of which are Greek gods. :)
2023-07-14 14:47:50 -0400 < geri> gotta gather em all
2023-07-14 14:48:02 -0400 < geri> does anyone here use termux
2023-07-14 14:48:23 -0400 < sham1> I do use termux for some things
2023-07-14 14:48:25 -0400 < Zipheir> Yes. Not for much programming, though.
2023-07-14 14:48:39 -0400 < sham1> And yeah, not for programming. Phone keyboards are painful
2023-07-14 14:48:40 -0400 < geri> is there any scheme that runs on it
2023-07-14 14:48:44 -0400 < sham1> Yes
2023-07-14 14:48:45 -0400 < Zipheir> I did manage to compile chibi-scheme on it.
2023-07-14 14:48:53 -0400 < sham1> I would imagine that guile works
2023-07-14 14:48:58 -0400 < Zipheir> There are packages for Guile and CHICKEN, IIRC.
2023-07-14 14:49:07 -0400 < geri> i type like 50 wpm on phone, but emacs kindings are a pain w/ touchscreen
2023-07-14 14:49:33 -0400 < geri> (and without it too)
2023-07-14 14:50:07 -0400 < sham1> Anyway, I'm not entire clear how the R7RS edition dockets mesh with the newer committees like Foundation and whatnot. Like what goes where
2023-07-14 14:50:33 -0400 < geri> oh hey, guile really is here
2023-07-14 14:50:36 -0400 < geri> i couldnt find it before
2023-07-14 14:51:18 -0400 < geri> great, i can test chunks of my stuff on the phone now too)
2023-07-14 14:57:25 -0400 < Zipheir> sham1: I just hope that people's votes don't get dumped.
2023-07-14 15:06:41 -0400 < geri> aighty, i gotta sleep soon so off i go
2023-07-14 15:06:44 -0400 < geri> good chat @everyone
2023-07-14 15:07:41 -0400 < jrincayc> Long ago (back when R5RS was the new spec), I used LispMe on a Palm Pilot. I think a cell phone keyboard would be even harder to use for scheme than the stylus on a Palm Pilot.
2023-07-14 15:09:16 -0400 < jrincayc> Bye geri.
2023-07-14 15:32:06 -0400 < mason> I remember LispMe.
2023-07-14 16:17:26 -0400 < lechner> Zipheir / thanks!
2023-07-14 16:18:54 -0400 < lechner> Hi, is guile-gdbm still a good way to get a persistent key-value store in Guile?
2023-07-14 16:19:56 -0400 < wasamasa> dbm in general feels like undervalued technology
2023-07-14 16:20:09 -0400 < wasamasa> the exact flavor doesn't really matter
2023-07-14 16:20:34 -0400 < wasamasa> for something like a cache or some db you don't care about, it's good enough
2023-07-14 16:21:55 -0400 < lechner> thanks! i agree (and have used gdbm with great results before) but did not wish to miss out on the latest and greatest
2023-07-14 16:21:59 -0400 < wasamasa> if you need features like a stable file format, crash resilience, consistency or queries, sqlite is better
2023-07-14 16:22:15 -0400 < wasamasa> if you want to just serialize/deserialize data, read/write is good enough
2023-07-14 16:23:57 -0400 < lechner> thanks!
2023-07-14 16:38:27 -0400 < wasamasa> apparently, there's more implementations of dbm than I thought
2023-07-14 16:38:37 -0400 < wasamasa> https://dbmx.net/tkrzw/ seems like one of the more advanced ones
2023-07-14 16:39:52 -0400 < wasamasa> lmdb is another well-known example
2023-07-14 16:44:34 -0400 < mfiano> neomutt links against any of bdb, gdbm, kyotocabinet, lmdb, qdbm, rocksdb, tdb, tokyocabinet for a cache. talk about too much
2023-07-14 16:44:59 -0400 < wasamasa> lol
2023-07-14 16:50:58 -0400 < Zipheir> Augh, the ifdefs can only be imagined.
2023-07-14 16:56:10 -0400 < sham1> I'm surprised it doesn't link any "real" database like SQLite
2023-07-14 16:56:42 -0400 < Zipheir> They all seem to be "NoSQLs".
2023-07-14 16:57:24 -0400 < mfiano> real-ational. But not as real as datalog
2023-07-14 16:58:02 -0400 < sham1> Well I didn't mean "rational database" when I said real, although admittedly I do tend to have a bias against NoSQL
2023-07-14 16:58:36 -0400 < wasamasa> for the usecase of a cache, there isn't really a point in using SQL
2023-07-14 16:59:14 -0400 < sham1> Sure, but then I'm questioning whether having a "real" database like Redis would work
2023-07-14 16:59:37 -0400 < wasamasa> what makes redis more real here?
2023-07-14 17:01:08 -0400 < sham1> Nothing really I suppose. It's separate from the application while most of these other ones seem separate. And admittedly I've only ever heard of bdb and rocksdb out of these
2023-07-14 17:01:13 -0400 < Zipheir> I imagine that the relational features aren't needed for caches, just as SQLs don't need the full power of relational languages.
2023-07-14 17:01:25 -0400 < sham1> while most of these other ones seem embedded*
2023-07-14 17:07:07 -0400 < Zipheir> Well, I didn't know about all of these dbm libraries until now. More to explore.
2023-07-14 18:28:58 -0400 < dpk> i have closed two issues on the Codeberg, and the most-commented issues i have attempted to supply with a summary of the current status at the top of the page
2023-07-14 18:29:08 -0400 < dpk> there are still some i need to do
2023-07-14 18:29:25 -0400 < dpk> i hope i've been sufficiently neutral in the cases where argument is still ongoing
2023-07-14 18:31:43 -0400 < dpk> (those two are our first closed issues! one because it was a no-hoper, the other because another issue had been opened on a similar topic and subsumed the discussion. but still!)
2023-07-14 21:15:39 -0400 < mdhughes> I've been using LispPad on iOS & Mac, it's R7RS but has a ton of system libraries, and is easy to integrate with Objective-C or Swift applications.
2023-07-14 21:16:06 -0400 < mdhughes> Mediocre editor, but it works fine to edit in something else, and the REPL in it is pretty good.
2023-07-14 21:17:20 -0400 < mdhughes> I do have an external keyboard if I want to use my iPad as a hobo cyberdeck, but largely I thumb-type on it or do the long typing parts on the Mac.
2023-07-14 21:17:37 -0400 < mdhughes> https://www.lisppad.app
2023-07-14 21:32:23 -0400 < Zipheir> There's nothing less cyberpunk than an iPad. :)
2023-07-14 22:08:13 -0400 < mdhughes> The street finding its own uses for industrial tech is the entire point of cyberpunk.
2023-07-14 22:10:41 -0400 < mdhughes> What's hilarious is the dumpster-dived literal garbage nobody else wants Android ecosystem, run by the largest ad company in the world. Yeah, that's rebellious.
2023-07-14 22:13:23 -0400 < mdhughes> When Case goes to run Straylight, he doesn't use a junker deck punched into his back by a gas station attendant, he buys the nicest Ono-Sendai he can get.
2023-07-14 22:20:26 -0400 < mdhughes> So a brief search, finds no working Schemes on Android. There's http://bryanchadwick.com/simplescheme/ and https://github.com/ddasilva/scheme-droid which have dead Google Play links.
2023-07-14 22:20:41 -0400 < mdhughes> There's a CL with 500+ downloads! Wow! https://play.google.com/store/apps/details?id=org.quarkslisp.lisp_ide
2023-07-14 22:21:18 -0400 < mdhughes> (and it looks hideous, but that's lost on Android users)
2023-07-14 22:24:02 -0400 < mdhughes> iOS has LispPad Go, "My Lisp", Replete (online REPL), Gambit (*really* bad editor, but otherwise it's Gambit), "Not Emacs" (Gambit + emacs clone), "My Lisp" which is a weird CL/Scheme hybrid.
2023-07-14 22:25:09 -0400 < mdhughes> I used to have one called iskeme or some such, but it's been dead for most of a decade.
2023-07-14 22:26:40 -0400 < mdhughes> There's a few good Mac-only Schemes, Wraith most amusingly: http://jayreynoldsfreeman.com/My/Wraith_Scheme_%2864-bit_version%29.html
2023-07-14 22:28:51 -0400 < mdhughes> But the nice part to LispPad is being able to write code on desktop or mobile, syncs by iCloud. Get your work done wherever you are.
2023-07-14 22:54:38 -0400 < mdhughes> (I will have to put together a real blog post about this at some point)
2023-07-14 23:17:50 -0400 < Zipheir> If you can run termux on Android, you can get a few Schemes running (CHICKEN and Guile have packages).
2023-07-14 23:19:02 -0400 < Zipheir> Android is certainly adware, but Android devices are very cheap.
2023-07-14 23:26:13 -0400 < Zipheir> As for finding your own uses for fancy tech, Apple really hates _bricolage_.
2023-07-14 23:28:17 -0400 < mdhughes> Have you never looked in the App Store? It's preposterously full of hacky solutions to one problem.
2023-07-14 23:29:03 -0400 < mdhughes> And they ship a scripting engine. I don't like Shortcuts' visual programming, but it does do useful things. I mostly do glue scripts in Pythonista, which has been shipping on iOS for 10+ years.
2023-07-14 23:29:41 -0400 < mdhughes> Something being cheap but also terrible and ad- and spy-ware infested, is not a positive.
2023-07-14 23:30:23 -0400 < Zipheir> Oh, certainly not. But many people can't afford anything else, given the mobile OS duopoly.
2023-07-14 23:30:53 -0400 < mdhughes> There's also ish and a couple other "linux in a box" shells on iOS, which let you run whatever, as long as it stays in that sandbox.
2023-07-14 23:32:01 -0400 < mdhughes> https://github.com/ish-app/ish
2023-07-14 23:41:28 -0400 < daviid> the world needs free h/w free s/w cheap (very cheap) phones - like one child one alptop, one child one free h/w free s/w phone
2023-07-14 23:45:31 -0400 < Zipheir> Yeah, it's too bad OLPC died, whatever its flaws.
2023-07-14 23:46:09 -0400 < daviid> very sad indeed
2023-07-14 23:54:20 -0400 < mdhughes> I doubt there's many Lisp/Scheme programmers who can't afford a little bit of money for decent hardware.
2023-07-14 23:55:17 -0400 < mdhughes> Software either has to be paid, supported by someone, full of ads, or it's a hobby that can go away at any time. Chez noticeably got here by scheme.com charging a lot for it, then Cisco supporting it.
2023-07-14 23:57:53 -0400 < Zipheir> $1000 for e.g. the latest iPhone is quite a lot for many people. (Including me.)
2023-07-14 23:58:57 -0400 < Zipheir> In any case, there's no way to call thousands "a little" in today's world economy.
--- Day changed Sat Jul 15 2023
2023-07-15 00:01:00 -0400 < mdhughes> Yes, I bought an iPhone 14 Pro, which was $1100. But the iPhone SE is $429, cheapo iPad 9G is $329.
2023-07-15 00:01:25 -0400 < mdhughes> And you have a carrier plan, which probably subsidizes that to <$50/mo.
2023-07-15 00:02:40 -0400 < mdhughes> For a programmer, I'd say at least get an iPad Air, $599. That's what I have with extra storage, it's a fine portable Unix workstation.
2023-07-15 00:04:13 -0400 < Zipheir> Sheesh. That's months' worth of groceries.
2023-07-15 00:04:51 -0400 < mdhughes> "When I have a little money, I buy [iPads]. If I have any left over, I buy food." —Erasmus, more or less
2023-07-15 00:04:57 -0400 < Zipheir> I should say that's *years* of groceries in many parts of the world.
2023-07-15 00:05:19 -0400 < mdhughes> OK, or they can do one tech job and buy it.
2023-07-15 01:50:01 -0400 -!- mdhughes_ is now known as mdhughes
2023-07-15 05:09:57 -0400 < dpk> Zipheir: that's months' worth of groceries but it's a phone that will last you like five or six years even without any significant maintenance, and potentially much more if you occasionally invest in replacing the battery
2023-07-15 05:10:08 -0400 < dpk> my work mobile phone is still an iPhone … 5? i think?
2023-07-15 05:11:39 -0400 < dpk> the Vimes' boots principle applies, of course
2023-07-15 05:12:29 -0400 < dpk> i.e. if you can't afford howevermuch for a new iPhone which is fully waterproof, you might drop it in a puddle one day and have to replace it earlier, making it more expensive amortized than the actually more expensive iPhone
2023-07-15 05:13:35 -0400 < dpk> or whatever
2023-07-15 05:14:38 -0400 < dpk> i would not recommend an iPad for any programmer and i think that's a really bizarre recommendation
2023-07-15 05:14:47 -0400 < dpk> if it runs Emacs, it's a computer. otherwise, it's a peripheral
2023-07-15 05:15:11 -0400 < dpk> all of this still applies: https://rixstep.com/2/2/20160319,00.shtml
2023-07-15 05:15:42 -0400 < dpk> or this: https://archive.is/U7OUu
2023-07-15 05:19:19 -0400 < dpk> (i should also note that i think that these things *only* last five or six years without a complicated battery replacement, and even that’s longer than many people keep them (about the boundary of how long the manufacturers expect you to keep them), is a god-damn disgrace)
2023-07-15 05:21:16 -0400 < dpk> thankfully the EU is stepping in and starting to regulate for longer device life spans (even then, the talk was of requiring five years of security updates, when it should be more like ten at the least) and user-replaceable batteries
2023-07-15 05:56:13 -0400 < ecraven> dpk: at least once you have five years, maybe it's easier to extend it to ten years than to introduce it that way right away
2023-07-15 05:56:30 -0400 < ecraven> like pension age, which slowly keeps creeping up :P
2023-07-15 06:05:54 -0400 < mdhughes> iPad can run emacs ("ymacs", or in ish), but that's a horrible thing to do anyway. There's actual good code editors like Koder, Textastic, etc.
2023-07-15 06:07:29 -0400 < sham1> Doesn't look that good
2023-07-15 06:08:37 -0400 < mdhughes> My previous phone was an iPhone 8+ (2017), just under $1000, so its actual cost was ~$150/year. And the only reason I quit using it was it can't run iOS 16, it'd still get 4-6 more years of security updates, unlike any Android.
2023-07-15 06:10:01 -0400 < mdhughes> iPad's the same, 3 of them in 13 years, last one was about 8 years of use. Battery was toast.
2023-07-15 06:11:32 -0400 < mdhughes> Anyway. My whole point was: Here's a cool Scheme for iPad. Not: You are a bad person who should only feel shame and hide in the gutter for using anything else.
2023-07-15 06:15:13 -0400 < aeth> I don't think I'd get $1000 of value out of a phone. Even across many years.
2023-07-15 06:21:47 -0400 < mdhughes> Depends if you ever bought expensive cameras, media players, pagers, maps, portable game systems, all the other stuff a phone's replaced. And it's a little pocket Unix workstation.
2023-07-15 06:22:41 -0400 < dpk> it's funny, my expensive cameras would be my example of how ridiculous a five year lifespan is
2023-07-15 06:23:20 -0400 < dpk> my fiancé’s Hasselblad 500C/M is a model introduced in 1970, but plenty of professionals are still using it, and Hasselblad will still service it
2023-07-15 06:23:34 -0400 < mdhughes> https://laughingsquid.com/r-u-a-cyberpunk-mondo-2000/  Everything except the stun gun is in my phone now.
2023-07-15 06:23:46 -0400 < dpk> even digital cameras have reached this point: my mirrorless camera is a 2018 model, still available new, and i see no reason i should have to replace it in the next ten years
2023-07-15 06:25:05 -0400 < dpk> megapixel counts for ‘small format’ cameras reached the point of being sufficient for most things, dynamic range for sensors is now at 12 or 14 stops (better than negative film in Ansel Adams’s day, which he reckoned at 11 stops), so there's no reason to not just keep using them
2023-07-15 06:25:14 -0400 < mdhughes> Also the photo is ridiculously similar to how I looked then, to the point people I knew accused me of posing for it. I still do sorta.
2023-07-15 06:25:56 -0400 < dpk> haha, that's a terrific page scan
2023-07-15 06:26:31 -0400 < mdhughes> Processing power is valuable in modern cameras, and a 6-year-old camera isn't as good at it. You can record video as well as a (low-end) RED camera with a phone now.
2023-07-15 06:28:25 -0400 < mdhughes> Do I *need* that for dog & backyard bunny pictures? Probably not. But I get more value from that than my old camera's sensor.
2023-07-15 06:31:19 -0400 < aeth> the problem is that phones are a sub par version of all of those that they replaced. Except maps I guess because those systems never got updated after you bought them (often charging for updates, etc.)
2023-07-15 06:31:46 -0400 < aeth> they're necessarily (by physics) bad cameras because of the tiny lens (they just heavily post-process to make up for that, but now you get a "dishonest" image)
2023-07-15 06:31:56 -0400 < aeth> they're bad media players because they removed the headphone jack because style
2023-07-15 06:32:04 -0400 < aeth> they're bad portable game systems because they have no buttons
2023-07-15 06:32:37 -0400 < aeth> they're basically just read-only web browsers, which, yeah, is useful but not $1000 useful when literally everything has a web browser.
2023-07-15 06:32:57 -0400 < dpk> the sensor size is a more limiting factor for ‘real’ photography than the lens size. can't say i've ever noticed significant sharpness or aberration issues with my phone camera lens
2023-07-15 06:33:14 -0400 < dpk> but the tiny sensor means a tiny (real) focal length, which means your depth of field is always going to be massive
2023-07-15 06:33:22 -0400 < mdhughes> Oh you haven't seen the new lenses, either. I had to put a case on mine because it can't lay flat.
2023-07-15 06:33:58 -0400 < dpk> so they have to fake bokeh with the ‘portrait mode’ thingie, which tries to use two cameras to measure how far away everything is and apply an appropriate blur afterwards
2023-07-15 06:34:01 -0400 < mdhughes> The headphone jack thing is so ridiculous. It's a $10 dongle to connect headphones, tho a lot of people seem to tolerate BT stuff (it makes me nauseous).
2023-07-15 06:34:27 -0400 < dpk> if you've ever used it, you know it's not very good at this, and puts random things out of focus when they shouldn't be
2023-07-15 06:34:45 -0400 < aeth> they also don't have a lot of internal space because you're supposed to use The Cloud® for video and even audio... maybe more relevant than the headphone jack
2023-07-15 06:35:19 -0400 < mdhughes> You can tap the screen to focus, and adjust focal settings, and more pro apps like Camera+ have a lot more control of the camera hardware.
2023-07-15 06:35:36 -0400 < aeth> and smartphones replace the entry-level point-and-shoot cameras, not really the big Nikons, Canons, etc., with the really big sensors and gigantic lenses
2023-07-15 06:35:44 -0400 < mdhughes> Apple's own Camera app is very dumb point-and-shoot, it's not the only option tho.
2023-07-15 06:35:58 -0400 < aeth> phones are generally useful because they're always in your pocket for the photo, even if they're not as good as a "real" camera that needs its own case
2023-07-15 06:36:40 -0400 < aeth> you capture good shots because the moment is fleeting, even if a fancy camera (which can cost less than $1000! if that's your only concern!) would take a better shot
2023-07-15 06:36:46 -0400 < dpk> yep
2023-07-15 06:37:15 -0400 < mdhughes> Sure. I'd never have a real camera handy for most of the photos I like.
2023-07-15 06:37:34 -0400 < aeth> phones also do the processing on-phone, which means you get a passable thing you can share directly to social media, instead of having to run it through several (laptop/desktop) apps first
2023-07-15 06:39:56 -0400 < aeth> post processing that can include literally faking the Moon in the case of iirc Samsung
2023-07-15 06:40:10 -0400 < dpk> yeah, that was funny
2023-07-15 06:40:22 -0400 < dpk> i understand why they wanted to do that
2023-07-15 06:40:48 -0400 < mdhughes> I adore Samsung. Exploding phones, fake Moons, folding phones that crack the screen. What nonsense will they do tomorrow?
2023-07-15 06:41:05 -0400 < dpk> you need a 600mm lens or something to take a decent mooon photo (on 135 format), and phones have like 28mm or 35mm equivalent lenses
2023-07-15 06:41:09 -0400 < dpk> hmm, what do we do
2023-07-15 06:41:17 -0400 < aeth> oh, and these fancy cameras last for ages so if you do the whole $/year trick, you can probably budget up to $2000 for those cameras
2023-07-15 06:41:33 -0400 < aeth> probably easy to get a lightly used camera from someone who wanted to get into hobby photography but then gave up on it
2023-07-15 06:41:42 -0400 < dpk> because people love taking moon photos so it'd be a killer feature to be able to take good ones!
2023-07-15 06:41:44 -0400 < aeth> so $2000 might be able to be enough to get the top tier idk
2023-07-15 06:42:10 -0400 < dpk> yeah, DSLRs are currently cheaper on the used market than ever because many people are switching to mirrorless
2023-07-15 06:42:24 -0400 < dpk> you can get a decent full-frame DSLR used for way under $2000!
2023-07-15 06:42:40 -0400 < dpk> $2000 would get you a brand new fairly decent mirrorless camera
2023-07-15 06:43:32 -0400 < sham1> The thing with the headphone jack and needing a dongle to use old headphones is that you can't charge the phone while listening to music with the older headphones
2023-07-15 06:43:58 -0400 < dpk> also Bluetooth is a pain in the arse and sounds like mush
2023-07-15 06:44:38 -0400 < aeth> anyway, smartphones do photos merely passably (despite that being 90% of their marketing... but that's usually good enough due to the pocket-sized form factor) and gaming incredibly poorly
2023-07-15 06:44:49 -0400 < sham1> Personally I like my bluetooth buds well enough since they don't get in the way while I'm cycling
2023-07-15 06:45:14 -0400 < sham1> And for that, the sound quality is fine
2023-07-15 06:45:17 -0400 < dpk> fiancé borrows my Bluetooth headphones (which i mostly use plugged in with the wire, because of the sounds-like-mush thing), it takes him (senior software developer at a major German company) like 15 minutes to get it to stop connecting with my computer and start connecting with his
2023-07-15 06:45:39 -0400 < mdhughes> If the battery lasts all day, you don't need to charge all the time. My new one's at 80% after a day of moderate use now, I got it to 60% when I was out all day and filming some things.
2023-07-15 06:45:43 -0400 < dpk> why Apple thought regular people would be able to deal with this shite, who knows
2023-07-15 06:46:06 -0400 < sham1> Apple didn't think people would be re-pairing devices on the regular
2023-07-15 06:46:19 -0400 < sham1> And... tbf, it's probably a reasonable assumption
2023-07-15 06:46:30 -0400 < aeth> Bad gaming on mobile is probably a combination of (1) no buttons, (2) Apple never understanding gaming ever (and Android smartphone makers only understanding copying Apple), (3) nobody wants to pay for games so the only games you get on mobile are basically successors to the Zynga Facebook Game business model, rather than the more experimental games that people tried and failed to see success with on mobile
2023-07-15 06:46:35 -0400 < mdhughes> Oh, the phone games thing is also incorrect. It's one of the biggest industries in the world now.
2023-07-15 06:46:36 -0400 < aeth> 10 years ago (so they'd definitely *run* today, but nobody would buy them)
2023-07-15 06:46:44 -0400 < aeth> while people will pay $70 for Switch games (and the Switch has weaker hardware than modern phones)
2023-07-15 06:46:51 -0400 < mdhughes> Touch is a great interface. Not so much for older console or arcade games, but new games take advantage of it.
2023-07-15 06:46:57 -0400 < sham1> The phone industry is huge, the quality of those games... not so much
2023-07-15 06:47:12 -0400 < aeth> Gaming on phones is one of the biggest industries in the world, but gaming on phones has more in common with the "gaming" industry (as in gambling) than the "gaming" industry (as in making fun games)
2023-07-15 06:47:13 -0400 < sham1> I mean, you do get the occasional gems, but most mobile games are just not good
2023-07-15 06:47:21 -0400 < mdhughes> I'm a Honkai Star Rail junkie now. It's the best JRPG I've played in many years.
2023-07-15 06:47:38 -0400 < sham1> I like my steam deck especially for older games
2023-07-15 06:47:40 -0400 < aeth> Every single good mobile game is also available on another platform, and discovery is so bad you'll only ever hear about it if you first hear about it on that other platform.
2023-07-15 06:47:47 -0400 < sham1> It's portable enough while having actual controller stuff
2023-07-15 06:48:15 -0400 < aeth> Mobile has Terraria, Minecraft, etc., as well as new hits like Vampire Survivors. You only know about these games from the PC and/or console versions.
2023-07-15 06:48:20 -0400 < mdhughes> And before that was Another Eden, another phone game (by creator of Chrono Cross).
2023-07-15 06:48:39 -0400 < sham1> This stuff is useful if you do emulation, which I do fairly regularly
2023-07-15 06:48:45 -0400 < mdhughes> No? Most gamers now are mobile, have never heard of Steam.
2023-07-15 06:49:07 -0400 < sham1> Emulators on phones... I mean, they work but touch controls for games with D-Pads and such is pain
2023-07-15 06:49:17 -0400 < mdhughes> For emulation, I just got an Anbernic 35xx "gameboy" with 20K ripped old games.
2023-07-15 06:49:40 -0400 < aeth> most "mobile" games are barely games.
2023-07-15 06:49:48 -0400 < mdhughes> Great little device & controller. That's fine for ancient hardware. But the screen's not touch, and there's a lot of game design you can do with touch.
2023-07-15 06:49:52 -0400 < aeth> This is like saying Facebook is a more profitable literature company than any book publisher.
2023-07-15 06:50:14 -0400 < aeth> There are good games on mobile. There are extremely lucrative "games" on mobile. The intersection is close to the null set.
2023-07-15 06:51:01 -0400 < aeth> The profitable mobile games are all free to play pay to win nonsense that are designed to extract as much money as possible from people to play games that would barely pass for something on one of those 50-in-1 bargain bin CDs in 1999
2023-07-15 06:51:28 -0400 < sham1> Unskippable ads is my bane
2023-07-15 06:52:10 -0400 < aeth> It's a limitation in language that we use "game" to describe both traditional games and the set of applications that make a lot of money on mobile. It is somewhat amusing and fitting, though, that "gaming" can also mean gambling, since these games tend to prey on exactly the same psychological circuitry as a gambling addiction.
2023-07-15 06:53:05 -0400 < mdhughes> You really do need to spend more time looking at the top game charts, or what people actually like playing. Because it's not very much PC "AAA" anymore.
2023-07-15 06:53:25 -0400 < sham1> I know what people actually like, and I think they're wrong
2023-07-15 06:54:14 -0400 < mdhughes> The AAA has got so expensive, and so conservative, they're basically repeats constantly of Call of Duty, Heavy Rain Press X to Continue, or Yet Another WoW Ripoff.
2023-07-15 06:54:19 -0400 < aeth> Again, the most lucrative games on mobile are games that would barely pass for something on one of those 50-in-1 bargain bin CDs in 1999, combined with lots of weaponized psychology to extract a lot of money out of some people in exactly the same way as a gambling addiction.
2023-07-15 06:54:31 -0400 < jackdaniel> discussing what people "like" is like discussing what children "like" to eat - duh, sweets
2023-07-15 06:54:41 -0400 < aeth> In an extremely stretched definition of "free to play", these games tend to cost some people many thousands of dollars.
2023-07-15 06:54:47 -0400 < mdhughes> I disagree. They've gone back in many cases to fun, tight gameplay loops. They do over-monetize them, but they don't charge $60 up front like they used to, either.
2023-07-15 06:55:34 -0400 < aeth> if you can name a game with a fun, tight gameplay loop it's probably an indie game, and, yeah, there are lots of those on mobile, but if you can actually *name* it, it probably became a hit somewhere else (like Steam) first, e.g. Vampire Survivors
2023-07-15 06:55:42 -0400 < mdhughes> I've been playing HSR for 2 months now. Spent $25. For what's replaced Elder Scrolls Online to me, which was $100 + 15/mo.
2023-07-15 06:58:25 -0400 < mdhughes> The top games right now, Diablo (PC), Poke Man EX (console/GB), Dragon Ball (console), Cookie Run (mobile), Brawlhalla (mobile), Rise of Kingdoms (mobile), etc. next 5+ are mobile-first.
2023-07-15 06:58:41 -0400 < aeth> If you go to the front of Android Marketplace games you can look at top grossing and top paid and there's basically no overlap. And I know of almost all of those top paid from Steam. Most were ported to mobile. https://play.google.com/store/games
2023-07-15 06:58:56 -0400 < aeth> Afaik, it's a little better on iOS because Apple is aware of this problem. A little.
2023-07-15 06:59:10 -0400 < mdhughes> I had to scroll down 15 to get to another PC game, PubG (fucking CoD shit).
2023-07-15 06:59:26 -0400 < wasamasa> iOS makes it easier to write decently performing code, if only by virtue of not offering java
2023-07-15 06:59:41 -0400 < wasamasa> also, not making you jump through the hoops of JNI
2023-07-15 07:00:05 -0400 < aeth> I can't immediately see how to get to a similar page for Apple, though
2023-07-15 07:00:07 -0400 < mdhughes> Metal's a pain in the ass to use, but it's fast. And you can write C/C++ and just ignore the standard GUI.
2023-07-15 07:00:28 -0400 < mdhughes> I had to go into App Store, page down to This Week.
2023-07-15 07:01:23 -0400 < mdhughes> DUDE! Dumb Ways to Die 4 is out!
2023-07-15 07:01:54 -0400 < aeth> Mobile was way better in 2010 about having actual paid-and-done games. Original experiences and stuff. Iirc e.g. the original Angry Birds
2023-07-15 07:02:45 -0400 < aeth> But by the time of Super Mario Run in 2017, the market expectation was to not pay for games... and Nintendo's experiment failed so their next mobile game (a Mario Kart) was just as predatory as any other mobile game instead of just being a buy-once-to-play-an-actual-game game.
2023-07-15 07:05:15 -0400 < aeth> It's easier to get people to pay for games on any other platform, so you can get some game-first game experiences... but only from smaller developers. AAA games have budgets that are so massive they'll charge a high price and use f2p-mobile-style monetization schemes on top
2023-07-15 07:05:37 -0400 < dpk> i recently read Sam Klein on how humans lost the zeroth war of humans vs AI by allowing AI to monopolize our attention https://blogs.harvard.edu/sj/2017/08/07/mental-battlefield-how-we-are-forfeiting-the-zeroth-ai-war/
2023-07-15 07:06:59 -0400 < aeth> humans lost the war with social media first
2023-07-15 07:07:33 -0400 < aeth> "AI" is just coming up with passable enough (not necessarily true! but nobody really cared on Reddit, either) text (or image meme) generation without needing human contributions
2023-07-15 07:09:09 -0400 < mdhughes> OK, just had a bunch of dumb deaths. And 2 game ads, sigh. This is why I should pay for Apple Arcade, but don't.
2023-07-15 07:09:55 -0400 < mdhughes> LLMs are just automated marketing douchebags. It doesn't mean anything more than the flesher ones do.
2023-07-15 07:10:48 -0400 < aeth> it's an existential threat to early 2010s Reddit because nobody cared if what anyone wrote on r/askreddit was actually true... not really an existential threat to 2023 Reddit because nobody has written a good text comment in years on that site.
2023-07-15 07:11:02 -0400 < aeth> but you can definitely get a lot of confident potential BS
2023-07-15 07:11:07 -0400 < aeth> like early 2010s Reddit
2023-07-15 07:15:21 -0400 < aeth> as for not paying for iOS games, you proved my point :-p
2023-07-15 07:16:22 -0400 < aeth> every other platform is $20-$30 for an indie and $50-$70 for the rest at this point thanks to inflation... which basically removes a lot of gaming experiences from mobile, even if the most lucrative route (from a profit-maximizing point of view) is still possible on mobile
2023-07-15 07:19:38 -0400 < aeth> and the price difference is absolutely going to make mobile the most popular because $0 (* but some people pay thousands) is going to have a wider audience than even $0.01
2023-07-15 07:19:50 -0400 < mdhughes> The "no ads" tier in DWTD4 is $1.99. If I play it more they'll probably get that. And if a million people do, it's $1.4M which this probably cost 2-3 months to develop?
2023-07-15 07:21:10 -0400 < aeth> $1.99 still is'nt a lot... an indie game you've actually heard of on Steam is probably going to be $19.99-$29.99 (the most notable exception is Vampire Survivors, which is (relatively) dirt cheap, maybe $4.99)
2023-07-15 07:21:19 -0400 < mdhughes> And there's gems & shit in there but I dunno if that'll make money. The more serious games do, by making paying them half what another platform charges more fun than the other platform.
2023-07-15 07:22:32 -0400 < mdhughes> The Clash Kings Royal Rumble games make no gameplay sense to me, but apparently they're *so* fun people go broke for it.
2023-07-15 07:22:42 -0400 < aeth> afaik, the most profitable games tend to make a lot of money by (1) releasing maybe a dozen games and quickly cutting the 11 that don't take off and (2) having absolutely no limit to what you can spend in the game and encouraging you to spend, at a minimum, hundreds of dollars to make up for the vast majority that don't spend anything
2023-07-15 07:22:51 -0400 < aeth> Especially anything with "Clash" in the title :-p
2023-07-15 07:23:17 -0400 < wasamasa> I'd play Clash of Parentheses
2023-07-15 07:23:26 -0400 < aeth> and absolutely all of them are in the same budget/team tier as an indie game so they'd just be $29.99 for everyone on PC
2023-07-15 07:23:26 -0400 < mdhughes> I understand how HoyoLabs plans to make money from me. It's a constant temptation to spend a bit more on some pulls, or fuel refreshes.
2023-07-15 07:23:29 -0400 < aeth> PC/Mac
2023-07-15 07:23:42 -0400 < mdhughes> But they spent 5 years and $XXX million developing that.
2023-07-15 07:25:01 -0400 < mdhughes> Scheme Robot Programming is the next big thing in mobile games.
2023-07-15 07:25:24 -0400 < aeth> (And the definition of "indie" has kind of been stretched... they often have publishers and large(ish) teams and it's hard for anyone to make money. 30 people could make a $30 game. 1 person could make a $30 game. They could be equally popular. The one with a 30 person team might have to give a cut to a publisher.)
2023-07-15 07:25:25 -0400 < mdhughes> (Scheme (Robot) Programming) I mean.
2023-07-15 07:30:58 -0400 < dpk> aeth: right, that article is from 2017
2023-07-15 07:31:28 -0400 < dpk> and is bemoaning not the AI text and image generation algorithms, but the AI get-people-to-spend-more-time-watching-videos-on-our-site-so-they-see-more-ads algorithms
2023-07-15 07:33:18 -0400 < dpk> those algorithms undoubtedly won a war against humans for their time and attention
2023-07-15 07:36:17 -0400 < aeth> well, yeah, everything's optimized for "engagement"
2023-07-15 08:39:20 -0400 < lockywolf> https://mastodon.archive.org/@textfiles/110697893762381822
2023-07-15 08:39:21 -0400 < lockywolf> Good news
2023-07-15 08:40:13 -0400 < lockywolf> dpk: it's not the algorithms won against humans, it's people who really care about other people's attention won against those who don't
2023-07-15 09:20:54 -0400 < geri> hi-hi
2023-07-15 09:21:32 -0400 < geri> is there some function like set! that takes a symbol containing a symbol instead of treating variable name literally?
2023-07-15 09:24:46 -0400 < wasamasa> no
2023-07-15 09:27:14 -0400 < geri> abusive primitive-eval it is then...
2023-07-15 09:27:28 -0400 < dpk> that probably won't do what you want either
2023-07-15 09:27:33 -0400 < geri> it does
2023-07-15 09:27:34 -0400 < geri> lol
2023-07-15 09:27:38 -0400 < geri> it's ugly thoug
2023-07-15 09:27:56 -0400 < wasamasa> in a language with lexical scope, eval will most likely misbehave, yes
2023-07-15 09:28:29 -0400 < geri> (primitive-eval (let ((i 'packages)) `(set! ,i '("emacs"))))
2023-07-15 09:28:29 -0400 < geri>
2023-07-15 09:28:50 -0400 < geri> im glad this works at least
2023-07-15 09:29:07 -0400 < dpk> and this is preferable to (set! packages '("emacs")) because …?
2023-07-15 09:29:21 -0400 < geri> because it's not packages but %my-ENVIRONMENT-packages
2023-07-15 09:29:42 -0400 < geri> it's just a testing thing
2023-07-15 09:30:09 -0400 < lockywolf> geri: https://okmij.org/ftp/Scheme/map-set.txt
2023-07-15 09:31:24 -0400 < lockywolf> I think this is what you want.
2023-07-15 09:32:27 -0400 < wasamasa> is it?
2023-07-15 09:32:36 -0400 < wasamasa> it's an impressive hack, but the most important thing seems to be boxes
2023-07-15 09:32:50 -0400 < wasamasa> why not use boxes directly, rather than being meta about identifiers?
2023-07-15 09:33:36 -0400 < dpk> ^
2023-07-15 09:34:04 -0400 < wasamasa> or depending on the code, some less general record type
2023-07-15 09:34:25 -0400 < wasamasa> for example, if I were to do graphics programming, I'd have a record describing a graphics context and pass it around
2023-07-15 09:34:39 -0400 < geri> because i don't know what boxes are?
2023-07-15 09:34:54 -0400 < wasamasa> a box is a mutable type holding a value
2023-07-15 09:35:03 -0400 < wasamasa> there is a basic operation for accessing the value and changing it
2023-07-15 09:35:15 -0400 < wasamasa> you can implement a box using a vector, a record, a closure, ...
2023-07-15 09:35:41 -0400 < wasamasa> there are some SRFIs discussing the idea of boxes
2023-07-15 09:35:53 -0400 < wasamasa> like https://srfi.schemers.org/srfi-111/srfi-111.html for example
2023-07-15 09:36:03 -0400 < wasamasa> > Some Scheme systems use boxes to implement set!
2023-07-15 09:36:09 -0400 < dpk> geri: i think more generally the point is, why aren't you using a data structure mapping %my-ENVIRONMENT-packages to the values you want
2023-07-15 09:36:58 -0400 < dpk> then you could set the key in that data structure dynamically
2023-07-15 09:37:51 -0400 < geri> what data structure are you talking about?
2023-07-15 09:38:17 -0400 < dpk> i dunno, a hash table, an alist, something like that
2023-07-15 09:38:37 -0400 < geri> i do most of the things i do the way i do because im stupid lol
2023-07-15 09:39:06 -0400 < geri> i think i thought having a single variable per environment would make it simpler
2023-07-15 09:39:33 -0400 < geri> cause i need it to be a single variable in the end as well
2023-07-15 09:43:45 -0400 < lockywolf> people are really concerned about environment protection now
2023-07-15 09:44:24 -0400 < geri> i call it environment but it's meant to basically be system vs user package set
2023-07-15 09:44:34 -0400 < geri> env just made sense ig
2023-07-15 10:26:40 -0400 < geri> badkins: are you okay
2023-07-15 10:33:40 -0400 < geri> nested macros work this time, yaaay
2023-07-15 12:15:45 -0400 -!- mode/#scheme [+o Zipheir] by ChanServ
2023-07-15 12:15:59 -0400 -!- mode/#scheme [+b *!*badkins@136.56.92.*] by Zipheir
2023-07-15 12:15:59 -0400 -!- badkins was kicked from #scheme by Zipheir [Excess JOIN/QUIT. Please fix your bouncer.]
2023-07-15 12:16:11 -0400 -!- mode/#scheme [-o Zipheir] by ChanServ
2023-07-15 12:41:59 -0400 < Zipheir> dpk: It may last five years, but there are definitely cheaper phones out there that may last as long.
2023-07-15 12:44:19 -0400 < Zipheir> Dumbphones can be especially durable.
2023-07-15 21:38:54 -0400 < skeemer> people are continuations bad to use, as GOTOs ?
2023-07-15 21:39:19 -0400 < skeemer> i mean i remember people saying that gotos should never be used nowadays so what about continuations?
2023-07-15 21:48:21 -0400 < jcowan> skeemer: Call/cc, like goto, is a building block that you don't need much except when you are devising control structure.  An exception is when you want to break out of a loop or a procedure prematurely, perhaps through several levels.
2023-07-15 22:24:51 -0400 < mdhughes> I use call/cc a lot when prototyping something, then usually figure out how to express it without it. It's not the fastest operation (depends on impl).
2023-07-15 23:03:33 -0400 < lockywolf> Are people here using GNU Artanis for something cool?
2023-07-15 23:03:47 -0400 < lockywolf> I have finally made a build for Slackware
2023-07-15 23:56:01 -0400 < mdhughes> Zipheir: A dumbphone won't run Scheme, or even text editor or ssh. You can't program it. So it's not particularly useful. Maybe it can play Snake!
--- Day changed Sun Jul 16 2023
2023-07-16 00:39:05 -0400 < Zipheir> skeemer: call/cc is very much like GOTO, and has most of the same problems (your programs can become spaghetti). Delimited continuations may be better for sanity. They can also create spaghetti, of course.
2023-07-16 00:45:46 -0400 < Zipheir> skeemer: But, as jcowan says, you often don't need first-class continuations. 90% of the time they're used to simulate 'break' or something similar in otherwise "functional" procedures.
2023-07-16 01:13:20 -0400 < jcowan> you can make java spaghetti by just having enough methods scattered through the class tree so that you can't tell where an applicable method is defined EVEN IF you avoid super().
2023-07-16 01:14:56 -0400 < Zipheir> Yuck. Coffee spaghetti.
2023-07-16 02:13:23 -0400 < mdhughes> I always liked to define a bunch of worker interfaces, then assign specific workers from a Spring config.xml, often different based on what build was used. Guess what the program does, you'll never know!
2023-07-16 02:15:17 -0400 < mdhughes> Which is actually a nice architecture if you do everything on a message bus & database, so it's easy to wire in new request paths. Oh, this admin panel needs login, auth admins only, select all users, present, and then one custom UI worker.
2023-07-16 02:17:27 -0400 < mdhughes> There's not many Scheme/LISP web frameworks, none I'd call good, so it's hard to compare, but doing that requires a lot more code in the ones I have looked at.
2023-07-16 04:26:59 -0400 < wasamasa> lockywolf: I'm deeply suspicious of the broken English in the Artanis documentation
2023-07-16 04:28:04 -0400 < lockywolf> wasamasa: Artanis is developed by guys in the Shenzhen Linux User Group
2023-07-16 04:28:14 -0400 < lockywolf> so I wouldn't expect their English to be good
2023-07-16 04:52:33 -0400 -!- dave69 is now known as dave0
2023-07-16 04:53:30 -0400 -!- Netsplit *.net <-> *.split quits: zwr, robin, xgqt, ft, johnjaye, anthk_, mns, karlosz
2023-07-16 04:53:30 -0400 -!- ft_ is now known as ft
2023-07-16 05:20:03 -0400 < amirouche> In this small snippet:
2023-07-16 05:20:05 -0400 < amirouche> (get "/hello/:who"
2023-07-16 05:20:07 -0400 < amirouche>   (lambda (rc)
2023-07-16 05:20:09 -0400 < amirouche>     (format #f "<p>hello ~a</p> " (params rc "who"))))
2023-07-16 05:20:50 -0400 < amirouche> ref: https://www.gnu.org/software/artanis/manual/manual.html#orge4f9d72
2023-07-16 05:20:54 -0400 < amirouche> There is at least two dubious patterns
2023-07-16 05:21:49 -0400 < amirouche> Tho, I should prolly support artanis because the maintainer is good person
2023-07-16 05:28:15 -0400 < wasamasa> come on, someone needs to preserve PHP-era web applications in 2023
2023-07-16 05:28:47 -0400 < wasamasa> where would be the fun if our web applications were perfectly secure
2023-07-16 05:29:21 -0400 -!- anthk__ is now known as anthk_
2023-07-16 06:03:16 -0400 < mdhughes> Everyone needs to write one 10,000-line blob of code with inline request/response, no templates, database hardcoded. Just to get it out of your system.
2023-07-16 06:04:25 -0400 < mdhughes> "Templating in GNU Artanis, is just writing Scheme code in the HTML document."
2023-07-16 06:13:05 -0400 < mario-goulart> wasamasa: I think the problem with PHP was more related to the fact that it would implicitly bind variables in the PHP code based on patterns specified for URLs.  I don't think that's the case in the code snipped.  There you explicitly use `params' to extract "who" (why I string? -- no clue) from the URL pattern.
2023-07-16 06:13:29 -0400 < wasamasa> it's a pretty obvious example of XSS
2023-07-16 06:13:56 -0400 < mario-goulart> What is?
2023-07-16 06:14:10 -0400 < wasamasa> embedding a query parameter as is into HTML
2023-07-16 06:14:20 -0400 < sham1> Not even a query parameter, but yeah, that's XSS
2023-07-16 06:14:24 -0400 < mario-goulart> Ah, right.
2023-07-16 06:14:24 -0400 < sham1> Sanitise your inputs!
2023-07-16 06:14:45 -0400 < mario-goulart> I have no idea what `params' do, to be honest.
2023-07-16 06:14:51 -0400 < mario-goulart> does*
2023-07-16 06:15:17 -0400 < sham1> It gives you the relevant part of the path in this case
2023-07-16 06:15:20 -0400 < sham1> The :who
2023-07-16 06:15:22 -0400 < mario-goulart> But, yes, if it blindly returns the plain string, that's bad.
2023-07-16 06:15:42 -0400 < mario-goulart> I mean, the example is bad.
2023-07-16 06:16:15 -0400 < wasamasa> it should at the very least explain what's going on
2023-07-16 06:17:49 -0400 < mario-goulart> #t
2023-07-16 06:32:29 -0400 -!- robin_ is now known as robin
2023-07-16 06:34:33 -0400 < wasamasa> I also love the adminer suggestion
2023-07-16 06:34:52 -0400 < wasamasa> at work, people love running into adminer because it has so many security holes
2023-07-16 06:38:19 -0400 < wasamasa> > similar to 'qstr, but try to eliminate evil HTML entities first.
2023-07-16 06:44:24 -0400 < wasamasa> > GNU Artanis doesn't support HTTPS at present. There are plans to support it in the future.
2023-07-16 06:44:31 -0400 < wasamasa> their definition of hmac is pretty funny
2023-07-16 06:47:42 -0400 < wasamasa> overall, this doesn't look good, but then, I doubt people could do better if they had to reinvent a web framework themselves
2023-07-16 07:07:19 -0400 < sham1> Meh, usually you'd end up just reverse proxying your APIs for example through nginx anyway, so not having HTTP isn't the *worst* thing in the world
2023-07-16 07:07:27 -0400 < sham1> Err, HTTPS obv
2023-07-16 07:08:31 -0400 -!- xgqtd is now known as xgqt
2023-07-16 07:11:31 -0400 < wasamasa> I really hope it just means that their application server doesn't support HTTPS and is otherwise oblivious to it
2023-07-16 08:03:06 -0400 < cow_2001> Personal note from Richard Stallman: I wrote GCC without remembering anything about the C precedence order beyond what’s stated here.  I studied the full precedence table to write the parser, and promptly forgot it again.  If you need to look up the full precedence order to understand some C code, add enough parentheses so nobody else needs to do that.
2023-07-16 08:43:58 -0400 < cow_2001> what i'm reading, in not too many words, is to write one's arithmetic in a lisp…
2023-07-16 08:44:14 -0400 < cow_2001> by the way, is this something you can stand behind? https://www.buildyourownlisp.com/
2023-07-16 08:44:38 -0400 < cow_2001> yet another build your own lisp book, this time not in lisp!
2023-07-16 08:50:47 -0400 < wasamasa> it sucks
2023-07-16 08:51:22 -0400 < wasamasa> if you want a book about how to build a lisp in C, try the stuff from Nils M Holm
2023-07-16 08:51:47 -0400 < wasamasa> or read his code: https://t3x.org/s9fes-reimagined/index.html
2023-07-16 08:54:17 -0400 < wasamasa> the reason why I claim that Build Your Own Lisp sucks is the parsing being done with a library provided by the author (mpc) and inventing q-expressions rather than just using macros
2023-07-16 08:54:47 -0400 < cow_2001> hmmmmmm
2023-07-16 08:54:54 -0400 < wasamasa> or quote, lol
2023-07-16 08:54:59 -0400 < wasamasa> (def {true} 1)
2023-07-16 08:55:05 -0400 < wasamasa> what the fuck, seriously
2023-07-16 08:55:21 -0400 < wasamasa> something like (def 'true 1) would have made more sense
2023-07-16 08:55:34 -0400 < cow_2001> quote expressions?
2023-07-16 08:55:38 -0400 < wasamasa> yeah
2023-07-16 08:55:56 -0400 < wasamasa> quote is one of the easiest things to implement in a lisp, but instead there's a whole new notation for it
2023-07-16 08:57:24 -0400 < cow_2001> that's a lot (and lots!) of books https://t3x.org/index.html
2023-07-16 08:57:37 -0400 < wasamasa> yup
2023-07-16 08:57:54 -0400 < cow_2001> like what's his name of the little schemer
2023-07-16 08:58:41 -0400 < cow_2001> all these amazing people. i look at them like an ant at an elephant.
2023-07-16 09:15:19 -0400 < lockywolf> why not just implement a Scheme?
2023-07-16 09:15:26 -0400 < lockywolf> why bothering with lisp?
2023-07-16 09:15:32 -0400 < lockywolf> SICP teaches all of it
2023-07-16 09:15:37 -0400 < lockywolf> except parsing
2023-07-16 09:15:46 -0400 < wasamasa> it doesn't teach you the mundane bits
2023-07-16 09:15:49 -0400 < lockywolf> but scheme parsing isn't exactly hard
2023-07-16 09:15:56 -0400 < wasamasa> parsing, garbage collection, who needs that
2023-07-16 09:16:09 -0400 < lockywolf> SICP has a section on garbage collection
2023-07-16 09:16:22 -0400 < wasamasa> really
2023-07-16 09:16:25 -0400 < lockywolf> yes
2023-07-16 09:16:38 -0400 < wasamasa> perhaps I should bother reading beyond the second chapter thenm
2023-07-16 09:17:21 -0400 < lockywolf> section 5.3.2
2023-07-16 09:17:22 -0400 < rgherdt> totally worth it
2023-07-16 09:18:40 -0400 < lockywolf> whoever wants to write their own lisp, can just take mine and fix the bugs
2023-07-16 10:09:56 -0400 < cow_2001> SICP is not C
2023-07-16 10:14:38 -0400 < wasamasa> one of the last exercises in it tells you to implement scheme in a low-level language
2023-07-16 11:49:12 -0400 < mdhughes> You don't need C if you can parse and then emit machine code.
2023-07-16 12:09:49 -0400 < Zipheir> C is really just another language, though the libraries have gotten pretty entangled with the OS under UNIX.
2023-07-16 12:13:22 -0400 < Zipheir> lockywolf: I don't think that reading SICP's chapter on garbage collection is enough to write anything practical. I think it's there to show that "there's no magic" to Lisp. (At least, that's how the present it in the lectures.)
2023-07-16 12:14:04 -0400 < lockywolf> I never said anything about C
2023-07-16 12:14:11 -0400 < lockywolf> my scheme is not in C
2023-07-16 12:14:27 -0400 < wasamasa> fortran?
2023-07-16 12:14:35 -0400 < lockywolf> positive
2023-07-16 12:15:58 -0400 < Zipheir> I tried that "write a Scheme" exercise in Ada a while back, which was interesting.
2023-07-16 12:39:14 -0400 < sham1> Clearly writing the impl in scheme and emitting machine code is the best way to do the exercise
2023-07-16 12:46:44 -0400 < Zipheir> Since the SICP compiler already emits code for a VM, that's a good way to do it.
2023-07-16 12:49:56 -0400 < sham1> Bootstrapping can be weird
2023-07-16 12:53:13 -0400 < Zipheir> But of course SICP doesn't help you much in implementing Scheme data or control structures in ASM.
2023-07-16 12:53:36 -0400 < Zipheir> *asm
2023-07-16 12:54:39 -0400 < Zipheir> It is, in fact, an open-ended project, not an exercise.
2023-07-16 12:54:39 -0400 < sham1> Well I don't think it would help you very much with that exercise of implementing scheme in a "low-level language" (whatever that means) to begin with.
2023-07-16 12:54:49 -0400 < Zipheir> Exactly.
2023-07-16 12:55:41 -0400 < Zipheir> I never got around to getting the GC working, but I did learn how hard they are to debug. :)
2023-07-16 12:56:36 -0400 < sham1> I reckon that there really are no good ways to test them other than to make a lot of load and see how they act
2023-07-16 12:59:34 -0400 < Zipheir> Just getting one working from scratch can be segfault city.
2023-07-16 13:05:35 -0400 < wasamasa> sham1: a language where one knows the cost of everything and the value of nothing
2023-07-16 13:08:10 -0400 < Zipheir> If you really know the value of nothing, you're using some language designed by Descartes' demon.
2023-07-16 13:09:18 -0400 < wasamasa> to determine the value of anything would require the use of a debugger
2023-07-16 13:09:34 -0400 < wasamasa> so, close enough for me
2023-07-16 14:29:27 -0400 < jcowan> I know the value of Nothing, for what that's worth
2023-07-16 14:45:10 -0400 < sham1> Not much
2023-07-16 14:51:26 -0400 < DKordic> skeemer: LtU GoTo!?  ARM ISA, for example, does not have ""GOTO""!!  ""Branch with Link""?!  https://manybutfinite.com/post/goto-and-the-folly-of-dogma/
2023-07-16 14:51:26 -0400 < DKordic> cow_2001: https://www.cosc.canterbury.ac.nz/research/reports/HonsReps/2016/hons_1604.pdf http://www.t3x.org/clc/index.html
2023-07-16 16:22:10 -0400 < cow_2001> Nothing is a Maybe eh?
2023-07-16 16:34:56 -0400 -!- ced1 is now known as cedb
2023-07-16 16:37:43 -0400 < cow_2001> how much for a lisp machine?
2023-07-16 16:46:21 -0400 < wasamasa> given that a lisp machine keyboard retails for 2000 australian dollars on ebay, lol
2023-07-16 16:49:11 -0400 < dpk> the keyboard might well be the most expensive part
2023-07-16 16:49:50 -0400 < dpk> because [mumble mumble] think they're cool for collecting peripherals which could actually be useful to people who still want to use them with the machines they were made for
2023-07-16 16:56:25 -0400 < wasamasa> supposedly these machines require some electronics skill to use
2023-07-16 16:56:50 -0400 < wasamasa> the keyboard listing for example mentions some missing keycaps that could be replaced via 3d printing, lol
2023-07-16 16:58:10 -0400 < Zipheir> Maybe they're expensive because Stallman is secretly buying them up to have a bonfire of the original proprietary Lisp hardware.
2023-07-16 16:59:39 -0400 < cow_2001> yog.
2023-07-16 17:00:13 -0400 < cow_2001> That's a lot of money I do not have.
2023-07-16 18:23:26 -0400 < skeemer> hej people i was experimenting a bit with the little schemer after having read it once...
2023-07-16 18:23:34 -0400 < skeemer> and i have a question about the function value...
2023-07-16 18:24:20 -0400 < skeemer> the books shows how simple  it is just by changing the order in which we parse things how to be able to parse (2 + (4 + 2)) instead of the prefix order (+ 2 (+ 4 2))
2023-07-16 18:24:35 -0400 < skeemer> anyway i found many cases where this value function breaks... i am going to show you one
2023-07-16 18:27:24 -0400 < skeemer> https://bpa.st/OZ4A
2023-07-16 18:27:53 -0400 < skeemer> ok look at the final test case... so (32 + 2) works fine, but (32 + 2 + 2) does not ... still gives me 34
2023-07-16 18:28:19 -0400 < skeemer> so i was wondering if there was a simple way i could change my functions there to make it work also in this case
2023-07-16 18:32:08 -0400 < Zipheir> skeemer: "value function"?
2023-07-16 18:32:21 -0400 < Zipheir> skeemer: You mean 'eval'?
2023-07-16 18:32:41 -0400 < Zipheir> Oh, I see.
2023-07-16 18:33:30 -0400 < Zipheir> skeemer: Because it's not recursive.
2023-07-16 18:33:49 -0400 < Zipheir> That is, it's not *list* recursive.
2023-07-16 18:34:36 -0400 < Zipheir> skeemer: You need a rule that says that (32 + 2 + 2) is evaluated as 32 + (value (2 + 2))
2023-07-16 18:34:44 -0400 < Zipheir> In effect.
2023-07-16 18:34:59 -0400 < skeemer> Zipheir, it's called "value" in the book
2023-07-16 18:34:59 -0400 < Zipheir> The *language* is not recursive.
2023-07-16 18:35:00 -0400 < skeemer> not eval
2023-07-16 18:35:10 -0400 < Zipheir> Well, eval is the traditional name.
2023-07-16 18:35:16 -0400 < skeemer> okok
2023-07-16 18:35:38 -0400 < skeemer> also as a side note what is this thing about eval/apply always publicized in SICP and other lisp stuff?
2023-07-16 18:35:56 -0400 < skeemer> Zipheir, ok but then how can i make it recursive?
2023-07-16 18:36:55 -0400 < skeemer> i mean to me it already looked recursive
2023-07-16 18:37:08 -0400 < skeemer> but you said "list recursive" what does that mean?
2023-07-16 18:39:10 -0400 < Zipheir> You have to be able to evaluate expressions with more than one operator, if you want that.
2023-07-16 18:40:06 -0400 < Zipheir> Your language doesn't include expressions of the form (A + B + ...)
2023-07-16 18:40:17 -0400 < Zipheir> Write a BNF grammar of what you've got so far.
2023-07-16 18:45:15 -0400 < Zipheir> skeemer: Sorry, I didn't read your evaluator carefully enough before responding. Here's the problem: + takes exactly two arguments.
2023-07-16 18:45:57 -0400 < skeemer> Zipheir, how do i learn writing BNF grammars?
2023-07-16 18:46:08 -0400 < Zipheir> skeemer: So ((A + B) + C) is perfectly fine, but not (A + B + C). If your evaluator were stricter, the latter would be an error; as it is, the extra junk gets thrown out.
2023-07-16 18:47:00 -0400 < Zipheir> Wikipedia has a pretty good summary: https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form
2023-07-16 18:47:10 -0400 < skeemer> Yes i noticed that... but the question is how can i evaluate more than one operator?
2023-07-16 18:49:49 -0400 < skeemer> i mean i understand the limitations but have no idea how to change the code to reflect this generality
2023-07-16 18:50:19 -0400 < Zipheir> There are several ways. One way would be a parsing trick: converting (A + B + C + ...) to (A + (B + (C + (...)))). You can also add the form directly to the language by putting it into 'value'.
2023-07-16 18:52:24 -0400 < Zipheir> This would be something like (+ (value (1st-sub-exp aexp)) (rest-value (cddr aexp))), where 'rest-value' recursively calls 'value'.
2023-07-16 18:53:09 -0400 < Zipheir> skeemer: Note that this is less tricky with prefix notation: you just (map value (cdr aexp)).
2023-07-16 18:53:33 -0400 < skeemer> Zipheir, i can imagine it is less tricky with prefix notation, i see that prefix notation has its advantages
2023-07-16 18:53:58 -0400 < skeemer> ok but how is rest-value written ?
2023-07-16 18:55:46 -0400 < Zipheir> The framework is the same thing you're used to: consider the empty list case and the car/cdr case.
2023-07-16 18:56:43 -0400 < Zipheir> skeemer: You'll probably notice the big headache of adding infix operators when you get to -.
2023-07-16 18:57:16 -0400 < Zipheir> Sorry, infix operators without parens.
2023-07-16 18:58:22 -0400 < Zipheir> It's not going to be obvious how to handle (A + B - C) without adding precedence rules.
2023-07-16 19:02:24 -0400 < Zipheir> skeemer: If this seems like a lot, you may want to check out EoPL next. It will make you very comfortable with evaluators and language grammars.
2023-07-16 19:12:45 -0400 < skeemer> Zipheir, does that also explain BNF ?
2023-07-16 19:14:31 -0400 < Zipheir> Yes.
2023-07-16 19:15:02 -0400 < Zipheir> Every book on programming languages probably starts by explaining BNF.
2023-07-16 19:24:39 -0400 < skeemer> Zipheir, ok so EoPL is like an extension of the last chapter of TLS right?
2023-07-16 19:24:47 -0400 < skeemer> would you suggest it before TSS ?
2023-07-16 19:24:53 -0400 < skeemer> the seasoned schemer ?
2023-07-16 19:25:53 -0400 < Zipheir> I'd probably go on to the Seasoned Schemer. EoPL does expect you to be comfortable with Scheme.
2023-07-16 19:27:35 -0400 < Zipheir> TLS and TSS are the Little books that present the Scheme language. The other ones explore other topics (logic programming, program proofs, dependent types, etc.)
2023-07-16 19:32:35 -0400 < skeemer> Zipheir, can you help me understand some details about chapter  9 the difficult one ?
2023-07-16 19:32:43 -0400 < skeemer> i tried to redo all the steps to get the y combinator
2023-07-16 19:33:08 -0400 < skeemer> but it's not clear to me the step done at page 170
2023-07-16 19:34:40 -0400 < Zipheir> I can't go into depth right now, since it's about to be dinner here.
2023-07-16 19:35:06 -0400 < Zipheir> But ask and someone will probably answer (maybe me, later).
2023-07-16 19:35:16 -0400 < skeemer> ok no worries :)
2023-07-16 19:35:22 -0400 < skeemer> thanks anyway!
2023-07-16 21:17:08 -0400 < lockywolf> Is anybody using Isabelle here?
--- Day changed Mon Jul 17 2023
2023-07-17 05:48:19 -0400 < lockywolf> Is case-lambda the Scheme's way to function definition in ML?
2023-07-17 05:50:24 -0400 < sham1> What do you mean by this
2023-07-17 05:57:48 -0400 < lockywolf> sham1: https://paste.debian.net/1286099/
2023-07-17 05:58:22 -0400 < lockywolf> I am reading a book on ML, and there is an example there, saying that "function definitions in ML support pattern matching, and are therefore more expressive than Lisp's"
2023-07-17 05:58:45 -0400 < lockywolf> I am trying to understand if Scheme now has any response to that.
2023-07-17 05:58:54 -0400 < sham1> Well case-lambda isn't really pattern matching. What it does is multiple arities
2023-07-17 05:59:04 -0400 < flatwhatson> the scheme approach is to make a function which does pattern matching on its arguments
2023-07-17 05:59:30 -0400 < flatwhatson> case-lambda is one way, guile's match-lambda or match-lambda* is another
2023-07-17 06:00:04 -0400 < lockywolf> flatwhatson: can you write an example?
2023-07-17 06:04:09 -0400 < flatwhatson> generic functions and CLOS-alikes (like goops) which do predicate-based dispatch are other options
2023-07-17 06:13:36 -0400 < flatwhatson> lockywolf: here's a match-lambda* example: https://paste.debian.net/1286100/
2023-07-17 06:14:26 -0400 < lockywolf> I see
2023-07-17 06:14:36 -0400 < lockywolf> (chibi generic) has something like that
2023-07-17 06:14:37 -0400 < flatwhatson> SML is a little different because it's statically typed, whereas all the scheme options are runtime type checks
2023-07-17 06:15:39 -0400 < lockywolf> true
2023-07-17 06:15:57 -0400 < flatwhatson> chibi generic is presumably generic functions with predicate dispatch.  guile's match is more powerful, though i'm only showing predicates in the example
2023-07-17 06:16:01 -0400 < mdhughes> The standard is just to use match: https://web.archive.org/web/20180718090106/https://www.cs.indiana.edu/chezscheme/match/
2023-07-17 06:16:20 -0400 < lockywolf> https://synthcode.com/scheme/chibi/lib/chibi/generic.html
2023-07-17 06:18:26 -0400 < mdhughes> And it ships in Thunderchez, so there you can just (import (matchable))
2023-07-17 06:21:26 -0400 < mdhughes> Or https://srfi.schemers.org/srfi-241/srfi-241.html
2023-07-17 06:23:23 -0400 < flatwhatson> srfi-204 is withdrawn but describes guile's match
2023-07-17 06:28:12 -0400 < mdhughes> Now, in a lot of cases I wouldn't suggest using it. If you can just get by with lambda and maybe testing the first argument as a command? Do that. case-lambda's the next step, usually one or two optionals are pretty obvious. Match and keywords and using a dictionary (alist or whatever) of key/values indicate your function's too complex.
2023-07-17 06:37:17 -0400 < flatwhatson> runtime dispatch can be expensive
2023-07-17 10:39:42 -0400 < skeemer> people i have a question about TLS
2023-07-17 10:40:16 -0400 < skeemer> how could i have developed lookup-in-table at pag.192 without using the extra function passed as entry-f ?
2023-07-17 10:41:47 -0400 < jcowan> fwiw, Chibi has SRFI 204 match too.
2023-07-17 10:58:09 -0400 -!- pi2 is now known as johnjaye
2023-07-17 11:16:18 -0400 < skeemer> another question about the little schemer, at pag.182, there are two functions defines called "value" and "meaning"
2023-07-17 11:16:26 -0400 < skeemer> are these what is commonly known as eval/apply ?
2023-07-17 11:18:46 -0400 < Zipheir> skeemer: I'll take a look in a few minutes.
2023-07-17 11:22:06 -0400 < skeemer> Thanks Zipheir
2023-07-17 11:41:46 -0400 < Zipheir> skeemer: Yes, those are a simple eval/apply pair.
2023-07-17 11:42:09 -0400 < Zipheir> "meaning" is a slightly weird and mystical name.
2023-07-17 11:44:39 -0400 < Zipheir> skeemer: You can hardcode the contents of lookup-in-entry into lookup-in-table, of course.
2023-07-17 11:45:49 -0400 < Zipheir> skeemer: TLS doesn't use 'let', but the usual way to do it would be (define (lookup-in-table ...) (let ((entry-f (lambda ...))) <body of lookup-in-table>)), or to use an internal definition.
2023-07-17 11:48:38 -0400 < Zipheir> skeemer: Usually it's parameterizing part of a function that's tricky, not hardcoding a parameter.
2023-07-17 12:07:36 -0400 -!- mode/#scheme [+o Zipheir] by ChanServ
2023-07-17 12:07:44 -0400 -!- mode/#scheme [-b *!*badkins@136.56.92.*] by Zipheir
2023-07-17 12:07:48 -0400 -!- Irssi: No bans in channel #scheme
2023-07-17 12:07:56 -0400 -!- mode/#scheme [-o Zipheir] by ChanServ
2023-07-17 12:27:31 -0400 < Zipheir> skeemer: The mutual eval/apply loop has mystical status because an interpreter for a minimal programming language consists of nothing more.
2023-07-17 13:04:39 -0400 < skeemer> Zipheir, thanks but sorry i don't see the loop
2023-07-17 13:05:07 -0400 < skeemer> i see value (or eval i guess) that calls meaning (apply i guess)
2023-07-17 13:05:15 -0400 < skeemer> but meaning does not call back value right ?
2023-07-17 13:09:16 -0400 < Zipheir> skeemer: True. They actually replace 'meaning' with a true 'apply' on p. 187.
2023-07-17 13:14:35 -0400 < Zipheir> skeemer: The first language they define has only constants and identifiers--no subexpressions.
2023-07-17 13:46:20 -0400 < skeemer> i can follow it easily but stilll don't see the purpose of doing the primitive? non-primitive? thing and so on
2023-07-17 13:50:07 -0400 < Zipheir> skeemer: If you don't have primitives, you'll have to implement numbers and lists within the language.
2023-07-17 16:33:10 -0400 -!- Irssi: No bans in channel #scheme
2023-07-17 17:22:31 -0400 < skeemer> Zipheir, right but then why do we have atom-to-action and  list-to-action?
2023-07-17 17:22:34 -0400 < skeemer> why not a single function?
2023-07-17 17:29:04 -0400 < Zipheir> skeemer: Try writing it as a single function.
2023-07-17 17:29:50 -0400 < Zipheir> Because of the types, it factors nicely as two procedures.
2023-07-17 17:40:28 -0400 < skeemer> Zipheir, you know if i think again about chapter 10, my thought is that i follow the whole reasoning and am able to understand all the pieces of code... but still if i had to come up with the same simple interpreter from scratch i would spend wayyy more time
2023-07-17 17:40:40 -0400 < skeemer> or maybe not be able to redo it from scratch without peeking at the book
2023-07-17 17:57:12 -0400 < Zipheir> skeemer: If you keep studying interpreters, you'll start to recognize the patterns and their variations very quickly. Writing interpreters is a little like chess.
2023-07-17 18:00:19 -0400 < skeemer> yeah i had the same impression, do you recommend any books on the topic?
2023-07-17 18:00:23 -0400 < skeemer> Zipheir,
2023-07-17 18:01:07 -0400 < Zipheir> I've already mentioned EoPL.
2023-07-17 18:02:03 -0400 < Zipheir> Maybe the best way is to just write a lot of interpreters.
2023-07-17 18:06:44 -0400 < skeemer>  Zipheir ok so EoPL is really for writing interpreters
2023-07-17 18:06:52 -0400 < skeemer> what about Beautiful languages?
2023-07-17 18:06:56 -0400 < skeemer> the one in racket ?
2023-07-17 18:22:03 -0400 < Zipheir> That's the first time I've heard of it.
2023-07-17 18:25:57 -0400 < Zipheir> I do appreciate this part of Beautiful Racket's FAQ: "Q: I’m a total pro! Will this help me get an awesome job at a super tech startup? A: I doubt it."
2023-07-17 18:27:35 -0400 < Zipheir> skeemer: The bigger topic, of course, is programming languages. Interpreters are useful, but in one sense they're just an (operational) way to describe a language.
2023-07-17 18:30:18 -0400 < Zipheir> skeemer: So you should also think about compilers.
2023-07-17 18:31:46 -0400 < Zipheir> (Eventually. It's probably best to learn all of Scheme first.)
2023-07-17 18:41:44 -0400 < skeemer> Zipheir, ok so you mean the compiler book ?
2023-07-17 18:41:58 -0400 < skeemer> the dragon book or stuff like that
2023-07-17 18:45:44 -0400 < Zipheir> I like the first edition of the Dragon Book, but I wouldn't recommend it as a starting place.
2023-07-17 18:46:48 -0400 < Zipheir> skeemer: If you can read some simple Haskell, then this is a great approach to compilers: http://www.cs.nott.ac.uk/~pszgmh/ccc.pdf
2023-07-17 19:20:03 -0400 < skeemer> Zipheir, i mean are there conceptually big differences between building interpreters and compilers?
2023-07-17 19:24:55 -0400 < Zipheir> skeemer: Yes.
2023-07-17 19:25:31 -0400 < Zipheir> Riastradh wrote something good:
2023-07-17 19:25:43 -0400 < Zipheir> "/Compilation/ is the analysis of a program's meaning, rendering the same semantics into another language. A /compiler/ is a total function from programs to meanings."
2023-07-17 19:25:57 -0400 < Zipheir> "/Interpretation/ is the execution of a program given the state of the machine, either diverging or yielding a final answer. An /interpreter/ is a partial function from programs and machine states (or simply machine states, if the program is a part of the machine state) to answers."
2023-07-17 19:26:19 -0400 < Zipheir> (Scroll back to 2007 in https://mumble.net/~campbell/blag.txt for the whole thing.)
2023-07-17 19:29:17 -0400 < Zipheir> In practice, many interpreters do some compilation as well.
--- Log closed Mon Jul 17 23:47:37 2023
--- Log opened Mon Jul 17 23:54:26 2023
2023-07-17 23:54:26 -0400 -!- Irssi: #scheme: Total of 210 nicks [0 ops, 0 halfops, 0 voices, 210 normal]
2023-07-17 23:54:26 -0400 -!- Irssi: Join to #scheme was synced in 6 secs
--- Day changed Tue Jul 18 2023
2023-07-18 01:38:53 -0400 < jcowan> https://lists.gnu.org/archive/html/chicken-users/2008-04/msg00013.html is Alex Shinn's post attacking syntax-case
2023-07-18 02:21:28 -0400 < mdhughes> Things that annoy an implementor faced with changing their work, aren't necessarily problems to users.
2023-07-18 03:32:04 -0400 < jackdaniel> isn't this quite retroactive? I thought that scheme is older than cl, but the post says "then scheme came along, and nice unified the cl namespace"
2023-07-18 03:39:47 -0400 < mdhughes> That, too. What did MacLisp do for macros?
2023-07-18 03:40:25 -0400 < sham1> Given that both CL and elisp have defmacro, probably that
2023-07-18 03:40:37 -0400 < sham1> Because MacLisp is the common denominator there
2023-07-18 04:15:47 -0400 < dpk> jackdaniel: Scheme is older than CL in the sense that the first version of something called ‘Scheme’ came out earlier than the first version of something called ‘Common Lisp’, but CL was deliberately more conservative than Scheme and concerned about unifying the features of a number of MacLisp derivatives. it also stopped being standardized after 1994
2023-07-18 04:16:36 -0400 < mdhughes> So, in the factual sense, Scheme is older than CL.
2023-07-18 04:17:29 -0400 < dpk> hygienic macros were still a bleeding-edge area of research even at the time of the ANSI Common Lisp report. also, the ANSI committee didn't wish to start adding big new features to a language which had already been around since 1984
2023-07-18 04:17:43 -0400 < mdhughes> CL was standardized after R4RS/IEEE which is very much a modern, recognizable Scheme.
2023-07-18 04:18:45 -0400 < dpk> the first Scheme report which made syntax-rules mandatory was R5RS (1998), though it was described in an optional appendix to the R4RS (1991)
2023-07-18 04:19:32 -0400 < dpk> even then, the debate over what the best strategy for low-level macros meant that the one R4RS proposed (which was basically syntax-case without the pattern matcher) disappeared in favour of describing the high level interface only
2023-07-18 04:19:40 -0400 < dpk> that particular debate is still raging
2023-07-18 04:28:56 -0400 < aeth> Scheme-the-language is older than CL and influenced e.g. lexical instead of dynamic scope
2023-07-18 04:29:23 -0400 < aeth> but no old Scheme would run in a modern Scheme because at some point, probably after 1984 (the first CL), everything got renamed. Everything.
2023-07-18 04:29:38 -0400 < aeth> Maybe with enough defines it might run, but case sensitivity probably came later, too
2023-07-18 04:31:00 -0400 < aeth> On the other hand, CL is so conservative that a lot of pre-CL Lisp code can run in CL
2023-07-18 04:31:45 -0400 -!- oldf8l is now known as f8l
2023-07-18 04:31:50 -0400 < sham1> It was one of the design goals, no?
2023-07-18 04:32:00 -0400 < sham1> At least I recall that being a thing
2023-07-18 04:32:08 -0400 < aeth> I'm guessing that the main thing that might break things is the lexical scope, but ancient Lisp usually uses things like PROG so not much is going to break even if it doesn't look idiomatic
2023-07-18 04:32:41 -0400 < aeth> And you can DECLARE SPECIAL anything that breaks
2023-07-18 04:33:37 -0400 < mdhughes> R3RS code works pretty much unchanged. We have some nicer abbreviations now. R2RS had #!true, #!false, #!null which is cute, <? >? which is schemier than < >
2023-07-18 04:33:56 -0400 < aeth> I guess R3RS was the renaming then?
2023-07-18 04:36:11 -0400 < mdhughes> Otherwise R2RS code samples look fine. Huh. Numeric tower is in functions, so: (polar (flo 2 (radix 0)) (flo (radix d)))
2023-07-18 04:38:08 -0400 < mdhughes> Couple neat functions in it, substring-move-left! and -right!
2023-07-18 04:40:27 -0400 < mdhughes> object-hash, object-unhash, kinda neat. Same shitty text ports as all non-R6 have.
2023-07-18 04:41:11 -0400 < mdhughes> So that's 1985, and I'd say 80-90% of my code now would run in it with minor library changes.
2023-07-18 04:41:34 -0400 < aeth> oh, if R2RS looks fine then I guess the renaming happened earlier (or with R2RS)
2023-07-18 04:41:45 -0400 < mdhughes> R1RS is uggo.
2023-07-18 04:42:02 -0400 < aeth> the original Scheme PDF uses Lisp-style names on a lot of things where Scheme and historic-Lisp now disagree
2023-07-18 04:42:14 -0400 < mdhughes> Yeah, nothing's named right, predicates don't end in ?, etc.
2023-07-18 04:42:24 -0400 < aeth> original Scheme is ofc pre R1RS (which is already revised)
2023-07-18 04:42:58 -0400 < aeth> but if R2RS is in 1985 and mostly runs, then effectively, "modern Scheme" is (slightly) newer than 1984's CL
2023-07-18 04:43:24 -0400 < aeth> putting Scheme in a weirder both-older-and-newer situation
2023-07-18 04:43:33 -0400 < mdhughes> R0RS really is just a Lisp with better scoping, and very visibly so.
2023-07-18 04:50:00 -0400 < mdhughes> I dunno how much else changed in CL between CLTL1 & 2, but the original didn't have LOOP, and to hear CLers talk about it, that's the only language construct they use.
2023-07-18 04:50:43 -0400  * jackdaniel somtimes uses CONS too
2023-07-18 04:50:51 -0400 < jackdaniel> sometimes*
2023-07-18 04:50:59 -0400 < aeth> you can go surprisingly far with LOOP
2023-07-18 04:51:36 -0400 < ecraven> jackdaniel: you have a working CONS machine? :P :D
2023-07-18 04:51:45 -0400 < aeth> and conversely, it's hard to go far without LOOP if you need "collect" to generate lists
2023-07-18 04:52:02 -0400 < mdhughes> R2RS: "Some implementations of Scheme permit a "named let" syntax in which (let name ((var1 form1) ...) expr1 expr2 ...)"
2023-07-18 04:52:12 -0400 < jackdaniel> I have a translator from atoms LOOP and CONS to 0 1 and that's how I write binary
2023-07-18 04:52:13 -0400 < mdhughes> So that's really the only construct I use in Scheme.
2023-07-18 04:52:25 -0400 < mdhughes> I joke but no seriously.
2023-07-18 04:52:46 -0400 < jackdaniel> #1=(loop (cons #1# #1#))
2023-07-18 04:56:13 -0400 < mdhughes> I like this shortcut in R2RS: (rec var expr) => (letrec ((var expr)) var)
2023-07-18 04:58:48 -0400 < sham1> Did R0RS have proper tail calls or did that come later
2023-07-18 05:01:25 -0400 < mdhughes> Maybe? It does some kind of frame erasure in BLOCK, but then gets into a lot of FRINGE, SAMEFRINGE weird code I don't understand.
2023-07-18 08:23:35 -0400 < mnieper> Thanks to a reference John gave me to read, I now know that garbage collection is mandatory for Scheme. See the discussion here: https://codeberg.org/scheme/r7rs/issues/105
2023-07-18 08:23:48 -0400 < mnieper> Thanks to Daphne for starting this discussion.
2023-07-18 08:32:24 -0400 < dpk> just started reading the Ramsdell paper
2023-07-18 08:33:05 -0400 < dpk> "this means that the procedure cons should return an immutable pair and set-car! and set-cdr! should be eliminated"
2023-07-18 08:33:16 -0400 < dpk> 1995
2023-07-18 08:33:18 -0400 < lockywolf> wow, there is an issue tracker on codeberg
2023-07-18 08:33:21 -0400 < dpk> we'll get there one day
2023-07-18 08:33:28 -0400 < lockywolf> is that why the mailing list is quiet?
2023-07-18 08:33:41 -0400 < dpk> yes, the existence of the issue tracker was announced on the mailing list
2023-07-18 08:35:49 -0400 < dpk> Ramsdell also doesn't very well justify making equality testing on procedures undefined, imo
2023-07-18 08:37:43 -0400 < dpk> since i was one of the people who voted no on R7RS small until they fixed the procedure equality issue, i am obviously biased, but i think i was right then: if procedures are first-class, they should behave like other first class objects
2023-07-18 08:42:05 -0400 < lockywolf> What was that github (?) repo where readscheme papers were saved?
2023-07-18 08:42:31 -0400 < dpk> there might be more justification in the referenced paper on Vlisp
2023-07-18 08:43:17 -0400 < mnieper> dpk: The set-car!/set-cdr! thing is, of course, more important that the procedure equality thing. But the paper I meant above is the Clinger paper on proper tail calls.
2023-07-18 08:49:12 -0400 < mnieper> dpk: Not all first-class objects behave like, say, characters or pairs.  For example, ports in R7RS are allowed to behave as procedures in R6RS when it comes to equality testing.
2023-07-18 08:53:00 -0400 < mnieper> EOF objects in R7RS likewise behave as ports/R6RS procedures.  In fact, this is true for all non-scalar values that do not have locations attached to it.  An irregularity comes in by attaching a dummy location to procedures.
2023-07-18 08:54:05 -0400 < lockywolf> has anyone written an awesome-style list of books dedicated to Scheme?
2023-07-18 09:04:52 -0400 < sham1> dpk: is a procedure eqv? when it's identical (so eq?), when it has the same "code" for some value of such, i.e. the same instructions, or is it equal if a new instance of the closure is created with data with the same values in terms of eqv?
2023-07-18 09:05:35 -0400 < sham1> Before one can decide on that, procedure equality is problematic
2023-07-18 09:09:13 -0400 < mnieper> sham1: Already the meaning of "identical" is problematic.
2023-07-18 09:13:34 -0400 < mnieper> R6RS circumvents this problem by not exposing such a predicate; R7RS circumvents it by attaching a dummy location, which is compared instead of trying to meaningfully compare procedures/closures.
2023-07-18 09:13:58 -0400 < sham1> Exactly, but we could assume something like (let ((a (lambda () ...))) (eq? a a)) would evaluate to #t
2023-07-18 09:14:32 -0400 < mnieper> Without this dummy location, I don't see how to express it in the formal semantics.
2023-07-18 09:17:58 -0400 < mnieper> The first `a` expression (!) evaluates to some object, the second `a` expression as well. Now how to conclude? The evaluator has no memory except for the store, the continuation and the environment.
2023-07-18 09:20:31 -0400 < mnieper> In fact, R6RS allows (let ([a (lambda () ...)]) (eq? a a)) to evaluate to #f because the compiler is allowed to do constant propagation for procedures.
2023-07-18 09:32:28 -0400 < mnieper> Without dummy locations attached to them, procedures are like the empty string in R[67]RS.  We have that (eq(v)? "" "") is unspecified.
2023-07-18 09:34:32 -0400 < sham1> Right and this is why some languages with lambdas don't even try
2023-07-18 09:35:55 -0400 < mnieper> And probably why Clinger/Ramsdell call it a bug in Scheme's specification.
2023-07-18 09:36:02 -0400 < sham1> And some languages don't even give consistent types for lambdas, especially if they have closures
2023-07-18 09:36:52 -0400 < mnieper> Sometimes we want locations associated with procedures, but then I think it is best to make them explicit as in (my) SRFI 229.
2023-07-18 09:37:08 -0400 < mnieper> An alternative approach would be callable records, but the difference is only superficial.
2023-07-18 09:51:19 -0400 < sham1> A slight problem I see with using tagged procedures or (fun)callable records is that in order to have procedures act like any other value, every single procedure would need an identity tag, and/or need to be a callable record
2023-07-18 09:51:46 -0400 < sham1> Well, s/identity/equality/
2023-07-18 09:53:02 -0400 < sham1> And if that isn't done then, well, dpk's original problem remains
2023-07-18 09:57:55 -0400 < mnieper> My claim is that "act like any other value" is based on a misunderstanding.
2023-07-18 09:58:31 -0400 < mnieper> See the empty string, for example. Or ports. Etc.
2023-07-18 09:59:40 -0400 < mnieper> We do want to allow constant propagation in compilers, which is also what the formal semantics allow because it is the simplest computation model.
2023-07-18 10:00:41 -0400 < mnieper> R7RS breaks constant propagation for procedures singularly by attaching a dummy location (which would then have to be propagated as well).
2023-07-18 10:06:47 -0400 < mnieper> Maybe, eventually, we should get rid of `eq?' and `eqv?' altogether and just use type-specific predicates like `string=?' or `=. (We would then need to add something like `record=?`.)
2023-07-18 10:23:56 -0400 < Oxyd> That would be backward-incompatible. Which, as we all know, is a big no-no.
2023-07-18 10:26:36 -0400 < gwatt> That's not apparently stopped rnrs wgs before
2023-07-18 10:37:04 -0400 < mnieper> Deprecating eqv? will surely not happen before R8RS (if at all).
2023-07-18 10:37:45 -0400 < mnieper> But regardless, is there any compelling use case of the generic predicate (apart from saving keystrokes)?
2023-07-18 10:38:29 -0400 < mdhughes> I'd have just eq? (identity, where that makes sense) and = as equal?
2023-07-18 10:38:52 -0400 < Oxyd> Sometimes you want a generic predicate, such as when dealing with something that can return either #f or a useful value.
2023-07-18 10:39:00 -0400 < mdhughes> And then you have a giant problem of registering new types so string=?, foo-record=?, etc. all map to =
2023-07-18 10:39:21 -0400 < mnieper> Oxyd: `not' works on either #f or a useful value.
2023-07-18 10:39:30 -0400 < Oxyd> Such as (case (peek some-stream) ((#f #\x) (foo)) (else (bar))), where peek returns #f on end of stream.
2023-07-18 10:40:50 -0400 < mnieper> Maybe `case' with its built-in comparison procedure has to be revised as well.
2023-07-18 10:41:04 -0400 < mnieper> We already discussed here whether `equal?' would be more helpful.
2023-07-18 10:42:18 -0400 < mnieper> mdhughes: I don't want to register string=? ... so that they all map to =.  When I know that I have two foos, I want to compare them with foo=?.
2023-07-18 10:42:58 -0400 < mdhughes> You still could, but you'd also just be able to ask = to look up the predicate and check.
2023-07-18 10:44:10 -0400 < mnieper> mdhughes: No, if I needed this, it would mean I didn't understand my code.
2023-07-18 10:44:38 -0400 < mnieper> (I would change my opinion here if Scheme had a static type system.)
2023-07-18 10:44:38 -0400 < mdhughes> I often don't know what types are in a bundle of stuff. That's why there's foo? predicates.
2023-07-18 10:45:44 -0400 < mdhughes> The obvious thing is JSON or any network or file traffic, config & database files. They're all "I got something, is it equal to this other thing I was searching for?"
2023-07-18 10:46:15 -0400 < mnieper> What you get are not arbitrary things but values of some large union type.
2023-07-18 10:46:31 -0400 < mnieper> json-object=? could be your tailored predicate here.
2023-07-18 10:46:34 -0400 < mdhughes> Hi, I'm a distinction without a difference.
2023-07-18 10:47:43 -0400 < mnieper> I think a program/procedure has a problem if giving it a nice static type becomes too difficult.
2023-07-18 10:47:52 -0400 < mdhughes> The actual programming experience right now in Scheme is a bunch of (and (number? x) (= x y))  (and (string? x) (string=? x y)) stuff.
2023-07-18 10:48:07 -0400 < mdhughes> "Strong types are for weak minds"
2023-07-18 10:48:35 -0400 < mdhughes> I'm not interested in having that argument again, ever. Just zero.
2023-07-18 10:49:03 -0400 < mdhughes> But comparisons have nothing really to do with it. Being able to say (= x y) and have it work on all x & y, is useful.
2023-07-18 10:49:22 -0400 < mdhughes> Currently (equal? x y) works on some Scheme built-ins, but not all. Does not work on extended types.
2023-07-18 10:49:39 -0400 < mnieper> mdhughes: There is a difference between having to use a fixed static type system and being able to give well-defined and simple types/meanings to your program/procedures.
2023-07-18 10:49:58 -0400 < mnieper> mdhughes: "work on all x & y" is not even remotely well-defined.
2023-07-18 10:50:14 -0400 < mnieper> Otherwise, we wouldn't have any discussion about procedure equality here, for example.
2023-07-18 10:50:27 -0400 < mnieper> Saying that eq? shall mean "identity" is a non-definition, either.
2023-07-18 10:50:46 -0400 < mdhughes> "all x & y" where either of them have had their foo? foo=? predicates registered.
2023-07-18 10:51:17 -0400 < mdhughes> eq? is pretty easy, in most cases; almost everything has an address in the computer.
2023-07-18 10:51:55 -0400 < mnieper> mdhughes: Now give "address" a formal meaning.
2023-07-18 10:52:27 -0400 < mdhughes> Since some types are unique, like interned symbols, their address is identity. I think all functions have an address but special forms probably wouldn't.
2023-07-18 10:52:51 -0400 < mdhughes> Did you know that computers are a giant array of trees, where squirrels store nuts? Each nuthole has a number on it.
2023-07-18 10:53:20 -0400 < mnieper> A registration for foos and bars and so on can work of course (at least assuming that the type predicates do no overlap) but why do you want to do the dispatch at runtime when it is safer and faster at expand-time (by preselecting the right predicate)?
2023-07-18 10:53:21 -0400 < mdhughes> And when you ask that squirrel for the nut with the number, it brings it to you, and you turn that back into a string or something.
2023-07-18 10:54:30 -0400 < mdhughes> I neither demand nor care how the compiler deals with my problem, as long as I'm not required to <Foo<Bar<T>>> anything.
2023-07-18 10:54:45 -0400 < mdhughes> If that means runtime lookup on a hash, OK.
2023-07-18 10:55:09 -0400 < mdhughes> It might be nice to have it be faster, in which case I still have access to the original foo? foo=? preds.
2023-07-18 10:55:14 -0400 < mnieper> Go ahead and write down a formal semantics for Scheme using squirrels and nuts. We can then base the concept of "identity" on this particular model.
2023-07-18 10:55:38 -0400 < mdhughes> By wildest chance, John Von Neumann wrote such a document 70-ish years ago.
2023-07-18 10:55:52 -0400 < Oxyd> No, no, you have to write your own.
2023-07-18 10:55:54 -0400 < mdhughes> His precise terms may not have been "squirrel"
2023-07-18 10:56:07 -0400 < mdhughes> And "nuthole", but I'm sure he was thinking them.
2023-07-18 10:56:32 -0400 < mdhughes> I sure am.
2023-07-18 10:57:03 -0400 < Oxyd> I'm sure that from now on whenever I think about Turing machines, I'll imagine a squirrel running alongside an infinite branch.
2023-07-18 10:57:08 -0400 < mnieper> mdhughes: If you do not want to write <Foo<Bar<T>>>, I wonder whether a statically typed language with templates like C++ or type classes like Haskell oder functors like ML actually better suits you.
2023-07-18 10:57:58 -0400 < mdhughes> No, I'm pretty sure I don't actually like being whipped and chained.
2023-07-18 11:00:10 -0400 < mdhughes> A computer is essentially a trained squirrel: acting on reflex, thoughtlessly running back and forth and storing away nuts until some other stimulus makes it do something else." —Ted Nelson, Literary Machines
2023-07-18 11:00:42 -0400 < Zipheir> mnieper: Welcome back.
2023-07-18 11:02:38 -0400  * mnieper waves.
2023-07-18 11:04:36 -0400 < mnieper> Zipheir: I won't find the time to read through all the logs, so did I miss anything interesting? R9RS with static types, braces and native AI support?
2023-07-18 11:07:30 -0400 < Zipheir> Hah, nothing so interesting.
2023-07-18 11:11:31 -0400 -!- civodul`` is now known as civodul
2023-07-18 11:20:16 -0400 < sham1> I now know my master's thesis topic /s
2023-07-18 11:29:59 -0400 < mnieper> Squirrels?
2023-07-18 11:31:13 -0400 < sham1> AI squirrels maybe
2023-07-18 11:31:19 -0400 < sham1> Climbing up a s-expression tree...
2023-07-18 11:31:22 -0400 < sham1> hm
2023-07-18 12:33:00 -0400 < jcowan> My problem with R6RS eqv-alence is that it's *too* forgiving.  It is perfectly all right for (eqv? car cdr) to return #t.
2023-07-18 12:33:54 -0400 < jcowan> mnieper: ^^
2023-07-18 12:36:06 -0400 < jcowan> This is fundamentally different from "" vs. ""; those two (if they are two) can't possibly *behave* differently.
2023-07-18 12:38:56 -0400 < mdhughes> All my usual suspects report them different, do you have a case where they're eqv?
2023-07-18 12:39:57 -0400 < mdhughes> Tho as noted, I'd only have eq? and = as equal? in a perfect Scheme.
2023-07-18 12:39:59 -0400 < gwatt> jcowan: I don't think that's a correct reading of R6RS' rules for eqv
2023-07-18 12:41:33 -0400 < gwatt> I think when calling eqv? with procedure arguments it's allowed to return #t iff the given procedures are indistinguishable. I'm pretty sure the text mentions returning different values for the same argument(s)
2023-07-18 12:48:15 -0400 < Zipheir> Yeah, I don't see that either. "eqv? returns #f if ... obj1 and obj2 are procedures that would behave differently (return different values or have different side effects) for some arguments." Surely that means (eqv? car cdr) must be false.
2023-07-18 12:49:53 -0400 < Zipheir> If anything, R6RS eqv? implementations have to err on the side of false negatives for procedures that are extensionally equivalent.
2023-07-18 12:50:47 -0400 < Zipheir> Sorry, no need to point out something obvious like that.
2023-07-18 12:52:55 -0400 < Zipheir> Oh, and the language seems to be the same in R7RS.
2023-07-18 13:03:12 -0400 < jcowan> mdhughes: Very few R6RS implementations exploit the theoretical freedom.  It's a matter of what you can count on for portability.
2023-07-18 13:05:31 -0400 < dpk> sham1: in R5RS, a procedure is eq? to another one when it was created by evaluation of the same (lambda ...) expression; in R6RS it's undefined; in R7RS the R5RS semantics are restored
2023-07-18 13:10:10 -0400 < dpk> sham1: in R5RS and R7RS, a procedure can be eqv? to another one if they have ‘equivalent’ code and are closed over the same variables, but this is not guaranteed – all that is guaranteed is that if they are eq?, they are also eqv?, but an implementation *may* provide certain situations in which two procedures that are not eq? are eqv?, if they do not have different return values or side effects for all possible arguments
2023-07-18 13:10:14 -0400 < dpk> in R6RS, again, it's undefined
2023-07-18 13:11:00 -0400 < dpk> i'm not sure any implementation actually exploits the freedom R5RS and R7RS small gives you here, and certainly if i were writing an implementation i wouldn't bother with any semantics for eqv? on procedures distinct from eq?
2023-07-18 13:11:11 -0400 < Zipheir> Maybe eq? should have just been dumped if it's so poorly defined.
2023-07-18 13:11:33 -0400 < sham1> Eh, you need eq? for some things. For example for detecting cycles
2023-07-18 13:11:36 -0400 < mnieper> In R7RS, one can say that not the actual procedures are compared (which is not decidable), but dummy locations.
2023-07-18 13:11:49 -0400 < mnieper> sham1: You can use eqv? for this as well.
2023-07-18 13:13:59 -0400 < dpk> mnieper: it is undecidable in the sense of the halting problem, which is to say that there must either be acknowledged false positives, false negatives, or a ‘maybe, i don’t know’ return value (R7RS explicitly leaves (eqv? (lambda (x) x) (lambda (y) y)) undefined, allowing false negatives)
2023-07-18 13:21:46 -0400 < dpk> procedure equivalence being defined has a great practical benefit whatever the theoretical improvements to formal semantics
2023-07-18 13:23:03 -0400 < dpk> correct eq? is practically automatic in any reasonable implementation of procedures as first-class objects, and the spec allows eqv? iff eq? on procedures, so i'm not convinced by appeals to the ‘compiler writer’s intuition’ either
2023-07-18 13:23:55 -0400 < dpk> jcowan attempted to explain to me why R6RS left eq? undefined a while ago – something involving strategies for inlining of procedure calls i think – but either i didn't understand it or i wasn't convinced, or possibly both
2023-07-18 13:31:05 -0400 < Oxyd> I think one possible source of problems is something like (define (foo a b) (eq? a b)) (define (bar x) (foo x x)) (bar (lambda () #f)). Here, the lambda is bound to x, and then it's effectively (eq? x x) which should be #t. But if you constant-propagate that code, you might end up with (eq? (lambda () #f) (lambda () #f)) which might be #f.
2023-07-18 13:40:54 -0400 < jcowan> dpk: Here's the idea.  Suppose you have a procedure #inline#car that the compiler recognizes and inlines when it is a direct-call position only.  Then you can define the first-class version of car as (define (car x) (#inline#car x)).  Then the compiler can treat (eqv? car car) as (eqv (lambda (x) (#inline#car x)) (lambda (x) (#inline#car x)))
2023-07-18 13:41:37 -0400 < jcowan> In R7RS, this must return #f because the location tags of the two lambdas are different.
2023-07-18 13:41:45 -0400 < dpk> right, but you can still have a singular instance of the actual car procedure when it doesn't appear by name in the operand position
2023-07-18 13:41:55 -0400 < dpk> as the compiler writer, that si
2023-07-18 13:42:38 -0400 < jcowan> Which means car cannot be inlined
2023-07-18 13:42:47 -0400 < dpk> of course it can
2023-07-18 13:43:08 -0400 < dpk> you do (define (car x) (#inline#car x)) once
2023-07-18 13:43:26 -0400 < dpk> or rather call that #noninline#car, or whatever
2023-07-18 13:44:24 -0400 < jcowan> But unless the compiler is Sufficiently Smart (tm), you won't be able to inline calls to it; they will all have to be dispatched through the single point.
2023-07-18 13:44:26 -0400 < dpk> then the equivalent within the compiler of define-syntax for the actual car name, where (_ x ...) becomes (#inline#car x ...) and every other instance, as an identifier, becomes #noninline#car
2023-07-18 14:13:55 -0400 < mnieper> Procedure equivalence as exposed by R7RS is only useful if one can actually use the hidden location, and then we arrive at SRFI 229 (or some equivalent).
2023-07-18 14:15:11 -0400 < mnieper> dpk: As I wrote above, it is about constant inlining. R6RS can treat procedures as constants; R7RS generally cannot.
2023-07-18 14:22:34 -0400 < mnieper> jcowan: Do we agree that (eqv? car cdr) => #f in R6RS?
2023-07-18 14:24:51 -0400 < mnieper> dpk: jcowan: I think dpk is right wrt inlining of car.
2023-07-18 14:25:00 -0400 < mnieper> Primitive procedures are not the best example.
2023-07-18 14:25:25 -0400 < jcowan> gwatt, mnieper:  Yes, that was a mistake on my part.
2023-07-18 14:25:34 -0400 < mnieper> Better examples are local procedures whose closure effectively consists of one cell.
2023-07-18 14:26:43 -0400 < mnieper> In R6RS, the compiler can just propagate the content of the cell and recreate it where needed.
2023-07-18 14:27:58 -0400 < jcowan> Those are operationally distinct, but R6RS allows treating provably operationally equivalent procedures as not equivalent.  Thus procedure still cannot be keys.
2023-07-18 14:29:23 -0400 < jcowan> e.g. procedures without closure
2023-07-18 14:30:23 -0400 < jcowan> Oh, on R7RS formal grammar not being normative: that was an early decision of WG1 that did not get into the R7RS.  In general, what is normative and what is not are debatable points.
2023-07-18 14:30:45 -0400 < jcowan> In R6, examples are normative, which I think is outright bizarre.
2023-07-18 14:31:04 -0400 < jcowan> But it doesn't say so anywhere: Will Clinger said so.
2023-07-18 14:32:25 -0400 < mnieper> R6, on the other hand, says that its formal semantics is non-normative.
--- Log closed Tue Jul 18 14:49:01 2023
--- Log opened Tue Jul 18 14:49:16 2023
2023-07-18 14:49:17 -0400 -!- Irssi: #scheme: Total of 217 nicks [0 ops, 0 halfops, 0 voices, 217 normal]
2023-07-18 14:49:20 -0400 -!- Irssi: Join to #scheme was synced in 10 secs
2023-07-18 17:12:22 -0400 < amirouche> kudos to whoever made https://man.scheme.org
2023-07-18 17:29:36 -0400 < jcowan> Lassi, probably
2023-07-18 17:44:33 -0400 < Oxyd> Nice.
2023-07-18 17:56:05 -0400 < Zipheir> That's very nice.
2023-07-18 18:01:41 -0400 < Zipheir> jcowan: I was looking at your old Powerpoints about XML schemas. Do you know of a good, straightforward prose intro on them? (Or format schemas in general.)
2023-07-18 18:05:29 -0400 < jcowan> https://relaxng.org/compact-tutorial-20030326.html is a good place if you are interested in RELAX NG (which I recommend).
2023-07-18 18:08:21 -0400 < jcowan> I don't know a good XML Schema tutorial
2023-07-18 18:16:37 -0400 < Zipheir> Thanks. That looks useful.
2023-07-18 18:19:21 -0400 < Zipheir> I've heard them described as "type rules for documents", but most of the material is rather opaque.
2023-07-18 18:22:13 -0400 < dpk> RNG Compact is the sweet spot for XML schemas imo (and not only my opinion)
2023-07-18 18:23:30 -0400 < dpk> also, using it means you get schema validation, context-sensitive completion and other niceties in nxml-mode in Emacs
2023-07-18 18:27:10 -0400 < dpk> (shed a tear for SGML)
2023-07-18 18:48:07 -0400 < jcowan> dpk: Did you ever get a copy of Calendrical Calculations?
2023-07-18 18:51:42 -0400 < dpk> i got it off Cambridge Core. i can send it to you, if you like
2023-07-18 18:56:19 -0400 < dpk> or the starry raven or the beresit bibliothecary may have it
2023-07-18 20:11:38 -0400 < seninha> Hi, how are values implemented internally, are they just a list annotated as a different type? In gambit, (display (values 1 2)) displays #<unknown>
2023-07-18 20:28:37 -0400 < Zambyte> Passing a multi-value expression to a continuation that expects one value like that is undefined behavior - it's best to avoid that.
2023-07-18 20:28:54 -0400 < Zambyte> seninha: I'm not sure how they are implemented internally in Gambit though.
2023-07-18 20:30:23 -0400 < Zambyte> You can convert it to a list by doing something like (call-with-values (lambda () (values 1 2 3)) list)
2023-07-18 20:31:59 -0400 < Zambyte> Or: (let-values ((res (values 1 2 3))) res)
--- Day changed Wed Jul 19 2023
2023-07-19 01:01:23 -0400 < mnieper> man.scheme.org and the Scheme manpages project is due to Göran Weinholt.
2023-07-19 01:33:49 -0400 < mnieper> seninha: Some Schemes (Chibi or Gambit, for example) implement multiple values as list/vector-like objects (see also SRFI 195).
2023-07-19 01:36:18 -0400 < mnieper> In general, however, multiple values are not (and cannot be) reified to a single value. They only appear transiently as values being passed on return of a procedure to a continuation. A fast implementation of Scheme would therefore store them in as many machine registers as there are values.
2023-07-19 01:41:57 -0400 < sham1> Or put them into whatever stack if you run out of registers, although that many values should probably be a vector or record instead
2023-07-19 01:44:16 -0400 < mnieper> sham1: Yes; multiple values should be handled like multiple arguments. The details depend on the calling convention.
2023-07-19 01:44:39 -0400 < mnieper> bbl
2023-07-19 04:12:07 -0400 < mnieper> dpk: jcowan: I followed Daphne's example and started to close some issues on Codeberg.  If you disagree on a particular decision, please reopen it.
2023-07-19 04:27:23 -0400 < ecraven> is it just me or does `dynamic-wind' seem rather imperative?
2023-07-19 04:27:47 -0400 < mnieper> Can you explain what you mean?
2023-07-19 04:28:26 -0400 < ecraven> well, by splitting `before', `thunk' and `after' into three parts, I have to introduce a binding *outside*, then *mutate* it in `before' and maybe again in `after'.
2023-07-19 04:28:37 -0400 < ecraven> in order for it to be visible inside `thunk'
2023-07-19 04:29:27 -0400 < ecraven> current problem: make sure a network connection is opened and properly *closed*. I have something like (let ((conn ...)) (dynamic-wind (lambda () (set! conn (open ..))) (lambda () (... use conn ...)) (lambda () (close conn)))
2023-07-19 04:29:37 -0400 < mnieper> I think one can say the whole purpose of dynamic-wind is to turn what is basically impure into something pure.
2023-07-19 04:29:48 -0400 < ecraven> I have no idea how to do this better, but maybe there is a way?
2023-07-19 04:29:55 -0400 < mnieper> Think of a simple implementation of parameters with dynamic-wind.
2023-07-19 04:31:28 -0400 < mnieper> In you example, the network interface is imperative, so you don't introduce extra imperative parts, but try to hide them.
2023-07-19 04:32:07 -0400 < ecraven> so I might just create (with-network-connection ...) to hide it all?
2023-07-19 04:32:25 -0400 < mnieper> What can be problematic is `(set! conn ...)' because the "... use conn ..." body may assume that it can store `conn` in a local variable.
2023-07-19 04:33:17 -0400 < mnieper> Better hide this mutation as well (e.g. by making the exposed `conn' an object with internal state, and where the internal state is explicitely handled only by the before/after thunks).
2023-07-19 04:33:54 -0400 < mnieper> Yes, (call-with-network-connect "... parameters ..." (lambda (conn) ...)) sounds like the way to go.
2023-07-19 04:34:10 -0400 < mnieper> s/-connect/-connection
2023-07-19 04:34:56 -0400 < ecraven> the more networking I do, the more complex it is :P SomeOne™ should write a great and comprehensive SRFI for it with a portable implementation :D
2023-07-19 04:35:40 -0400 < mnieper> With `call-with-network-connection` it also becomes clear that no magic set!ting of `conn` happens outside the user code.
2023-07-19 04:36:35 -0400 < sham1> Networking *is* complex
2023-07-19 04:36:49 -0400 < mnieper> A guideline could be that `dynamic-wind' should only appear in library code, not in application code.
2023-07-19 04:37:45 -0400 < mnieper> sham1: ecraven: I think we are talking about two very different kinds of complexity here. Networking in general on the one hand side and expressing certain constructs nicely in the Scheme language on the other hand side.
2023-07-19 04:38:44 -0400 < ecraven> the happy path in networking is fine, but dealing with random connection aborts and making sure you close all open FDs so the process doesn't run out ... is harder (for me)
2023-07-19 04:41:06 -0400 < mnieper> A modern™ approach to the interface/implementation on the Scheme side may be effect handlers; see here: https://github.com/mnieper/scheme-libraries#effects
2023-07-19 04:41:36 -0400 < mnieper> You would define basic network operations (like send/receive) and leave the handling to the environment.
2023-07-19 04:41:51 -0400 < mnieper> An effect handler doing the actual work can then be installed.
2023-07-19 04:42:39 -0400 < mnieper> This is also great for testing. And in some sense it does make what looks like imperative code (send/receive) into what looks like pure code.
2023-07-19 04:43:39 -0400 < ecraven> mnieper: thanks, I'll look at that!
2023-07-19 04:44:57 -0400 < ecraven> my concrete problem is that at some point the network connection fails (connection reset by peer), and the server won't let me reconnect, because it thinks the connection is still open (and maybe it is..). only if I restart the entire scheme process do things work again.. so I'm leaking *something* somewhere...
2023-07-19 04:45:43 -0400 < mnieper> Which Scheme/low-level lib?
2023-07-19 04:46:21 -0400 < ecraven> chez, my own sockets library
2023-07-19 04:46:36 -0400 < ecraven> which uses either plain networking or libopenssl
2023-07-19 04:47:03 -0400 < ecraven> one of the main pain points is *trying* to use custom ports *and* wanting to have non-blocking io in some way
2023-07-19 04:49:01 -0400 < mnieper> Does the non-custom port part work?
2023-07-19 04:49:53 -0400 < ecraven> oh, it seems to work fine, both modes, however when closing and re-opening connections, something isn't right yet
2023-07-19 04:50:21 -0400 < sham1> Non-blocking with TLS is not fun either
2023-07-19 04:50:49 -0400 < sham1> Sometimes when you're reading the TLS protocol suddenly wants to write, and when writing it suddenly wants to read
2023-07-19 04:50:49 -0400 < ecraven> sham1: yea, never got anywhere, because it doesn't seem like R6RS custom ports even support non-blocking IO in any way
2023-07-19 04:53:50 -0400 < dpk> yeah, the Scheme story for non-blocking IO is … not great
2023-07-19 04:53:51 -0400 < ecraven> hm.. my concrete problem is maybe that I set both REUSEPORT and REUSEADDR
2023-07-19 04:54:02 -0400 < mnieper> ecraven: What would you except? Procedures like `read-char' are defined to only return when there is a character available.
2023-07-19 04:54:04 -0400 < dpk> i think Guile is the only major implementation which has done anything serious about it
2023-07-19 04:54:23 -0400 < ecraven> mnieper: indeed, but why? why not return #f (or provide read-char* which does that)
2023-07-19 04:54:48 -0400 < ecraven> I understand why that doesn't work for *normal* `read' (because #f is a valid return value), but for read-u8, read-bytevector, and so on, this would work very well
2023-07-19 04:54:49 -0400 < dpk> otherwise you have the hilariously inadequate u8-ready? and char-ready? primitives, the latter of which probably doesn't even do what it says on the tin
2023-07-19 04:54:51 -0400 < mnieper> ecraven: This is outside the scope of RnRS is probably the best answer.
2023-07-19 04:55:09 -0400 < ecraven> mnieper: is it though.. the world we live in is a networked world..
2023-07-19 04:55:21 -0400 < mnieper> ecraven: Why don't you use threads instead?
2023-07-19 04:55:36 -0400 < ecraven> dpk: r6rs also doesn't provide any way for custom ports to actually implement those
2023-07-19 04:55:51 -0400 < dpk> yes, also an oversight
2023-07-19 04:55:51 -0400 < mnieper> They are supported by Chez and allow you to turn any networking into a non-blocking version.
2023-07-19 04:56:18 -0400 < ecraven> mnieper: I do, and it's way more complex than just having a reliable way to determine whether I *can* read/write data without blocking
2023-07-19 04:56:32 -0400 < dpk> but probably a deliberate one, given the deficiency of them as primitives for … anything meaningful
2023-07-19 04:56:32 -0400 < mnieper> As u8-ready? and friends seem to be useless, it wouldn't have helped if custom R6RS ports implemented these.
2023-07-19 04:57:23 -0400 < ecraven> mnieper: that is not my experience. in detail: make-custom-binary-input/output-port force you to implement read and write in a way that returns 0 for EOF and > 0 for how many bytes were read/written.. so how do you say "there is nothing to read/write"..?
2023-07-19 04:57:46 -0400 < mnieper> Scheme ports are, by current design, blocking. They are useful when one wants to use the ordinary Scheme port procedures (like write/read/...). But these are also blocking.
2023-07-19 04:57:49 -0400 < mdhughes> In Chez you'd usually either put synch IO in another thread, or wire up select.
2023-07-19 04:57:55 -0400 < ecraven> (I'm sorry if the problem here is me not understanding how things work correctly, I've tried to understand everything, but my understanding may be very much incorrect)
2023-07-19 04:58:22 -0400 < mnieper> So if you want something resembling non-blocking ports, invent your own version of port and don't use the Scheme one.
2023-07-19 04:59:01 -0400 < mnieper> It is not the fault of custom ports because they are there to support the existing (blocking) port interface.
2023-07-19 04:59:05 -0400 < ecraven> that is unfortunately true, but I find it a sad state of affairs.. I can't use a perfectly fine read-u8 or read-bytevector? I have to create even more monomorphic functions?
2023-07-19 04:59:28 -0400 < ecraven> it isn't anyone's fault, it is just a non-ideal state of affairs in our networked world, imho :-/
2023-07-19 04:59:35 -0400 < dpk> if you don't like monomorphism, maybe this is not the right language for you …
2023-07-19 04:59:40 -0400 < mnieper> +1
2023-07-19 05:00:00 -0400 < mnieper> ecraven: Why not introduce new procedures. You want to add timeout parameters, etc.
2023-07-19 05:01:10 -0400 < dpk> is Chez okay with C libraries that do their own OS-level blocking stuff? (i.e. could you reasonably use select(2) in a Chez program?)
2023-07-19 05:01:20 -0400 < dpk> because that might also be a problem
2023-07-19 05:01:37 -0400 < ecraven> dpk: I haven't tried yet, but at some point I'll look into select/poll/epoll
2023-07-19 05:02:02 -0400 < ecraven> I really like MIT's green threads implementation
2023-07-19 05:02:59 -0400 < mnieper> Chez Scheme has native threads, which makes sense on modern processors. But it also has a version of green threads using interrupts.
2023-07-19 05:03:05 -0400 < mdhughes> You can in fact use select, as I noted.
2023-07-19 05:03:23 -0400 < mnieper> See my sample implementation of SRFI 226 where I emulated SRFI 18 threads using Chez's interrupts.
2023-07-19 05:03:32 -0400 < mdhughes> But threads, and mutex wrapped around dumping your collected data/final status back into main thread is much better.
2023-07-19 05:04:53 -0400 < mnieper> ecraven: I don't even understand how you would want to use `get-u8' in a non-blocking fashion? Sure, you could test for `#f' instead of a character of EOF, but eventually you would end up with a busy loop.
2023-07-19 05:05:06 -0400 < ecraven> so say I want to communicate over the network with knxd (a binary protocol over tcp).. should I create one reader thread, one writer thread, and one main thread, that gets data from a mutexed queue and writes data to a mutexed queue?
2023-07-19 05:05:27 -0400 < mnieper> Non-blocking IO (if not done using a different thread as mdhughes suggests as well) needs a different interface (resembling coroutines).
2023-07-19 05:05:51 -0400 < ecraven> mnieper: in my case I want to check three different network connections for available packets, and deal with anything that actually has a packet.
2023-07-19 05:06:06 -0400 < mnieper> And if none has a packet?
2023-07-19 05:06:14 -0400 < ecraven> sleep for a bit, redo ;)
2023-07-19 05:06:21 -0400 < ecraven> as there is nothing *to* do
2023-07-19 05:06:25 -0400 < mdhughes> That's a reasonable use for FFI select.
2023-07-19 05:06:50 -0400 < mdhughes> Because you're not doing work at the same time as waiting for packets.
2023-07-19 05:06:54 -0400 < mnieper> ecraven: It would be much better if the code woke up automatically.
2023-07-19 05:07:06 -0400 < mnieper> Because any sleep is either too long or too short.
2023-07-19 05:07:16 -0400 < ecraven> so, one thread for reading to a network connection, one for writing, a third one to drive both?
2023-07-19 05:07:22 -0400 < mdhughes> Select does a timeout.
2023-07-19 05:07:33 -0400 < mnieper> ecraven: You can do this; but think of a high-level interface first.
2023-07-19 05:07:39 -0400 < mnieper> It could be a Scheme version of select.
2023-07-19 05:08:02 -0400 < mnieper> Like taking three procedures. One of them is called depending on the event.
2023-07-19 05:08:09 -0400 < ecraven> well, at that point it all is just a message bus.. the main thread just waits for messages to appear, and creates new ones
2023-07-19 05:09:30 -0400 < mnieper> I would say that the main code should look like blocking code.
2023-07-19 05:09:31 -0400 < ecraven> thanks a lot for the discussion, much to think about ;D
2023-07-19 05:09:44 -0400 < ecraven> yes, with a message bus it can, it'll just read and write messages blockingly
2023-07-19 05:09:45 -0400 < mnieper> Everything else can be hidden behind call/cc, threads, effects.
2023-07-19 05:10:06 -0400 < dpk> then you also have the problem of Chez's slow call/cc and lack of delimited continuations
2023-07-19 05:10:20 -0400 < ecraven> I don't have to use call/cc here, I think
2023-07-19 05:11:50 -0400 < mnieper> dpk: Why are Chez's continuations slow? It is first on the ctak benchmark, for example.
2023-07-19 05:12:11 -0400 < dpk> it is?
2023-07-19 05:12:15 -0400 < mnieper> The missing delimited continuations are a bigger problem if one wants to code it elegantly.
2023-07-19 05:12:18 -0400 < mnieper> dpk: Yes.
2023-07-19 05:12:30 -0400 < mnieper> According to ecraven's page. :)
2023-07-19 05:13:11 -0400 < mnieper> If something is slow in Chez, it is a bug you should file on its issue tracker. :D
2023-07-19 05:13:30 -0400 < ecraven> I need to run the benchmarks again .. ;)
2023-07-19 05:13:31 -0400 < dpk> mostly, i'd always heard that it was slow
2023-07-19 05:14:14 -0400 < sham1> Clearly the reports of its slowness have been greatly exaggerated
2023-07-19 05:14:35 -0400 < mnieper> Why should it be slow? It uses the segmented stack model, which still seems to be the fasted implementation strategy for general Scheme code.
2023-07-19 05:14:48 -0400 < jackdaniel> not all has been send yet, people wait for the operation to complete before sending the report :)
2023-07-19 05:16:19 -0400 < mnieper> A stack modelled as a linked list on the heap may be even more suitable to call/cc than segmented stacks but it slow even without call/cc (e.g. because of cache locality and because processors are turned to C-like languages and their stack usage).
2023-07-19 05:18:08 -0400 < mnieper> BTW, Chez is also fasted with the "fibc" benchmark, which also uses first-class continuations to stress the implementation.
2023-07-19 05:22:24 -0400 -!- rgherdt_ is now known as rgherdt
2023-07-19 06:25:40 -0400 < ecraven> is there anything like an extensible `with' macro in any srfi? so I can do something like (with ((knx (open-knx-network-connection ...))) <body> ...) and it'll have some sort of protocol on what to invoke in the background?
2023-07-19 06:25:58 -0400 < mnieper> You mean something like Python's `with'?
2023-07-19 06:26:01 -0400 < ecraven> should be without -open (with ((knx (knx-network-connection ...))) <body> ...)
2023-07-19 06:26:34 -0400 < ecraven> I don't know that very well, but I think so, yes.. this should probably wrap dynamic-wind internally, with some way to register new objects
2023-07-19 06:26:46 -0400 < mnieper> You can use Chez's version of `parameterize'.
2023-07-19 06:27:07 -0400  * ManDay tries to figure out how "with" is not just "let"...
2023-07-19 06:27:13 -0400 < mnieper> It is tailored to these use cases.
2023-07-19 06:27:30 -0400 < ecraven> ManDay: it has to have some way to *release* resources (like network connections) on exit
2023-07-19 06:27:39 -0400 < ecraven> mnieper: thanks, I'll look into that
2023-07-19 06:27:41 -0400 < ManDay> Ah heh, okay.
2023-07-19 06:27:47 -0400 < mnieper> Chez Scheme's parameters are better than R7RS-small parameters because the "guard procedure" is called on entry and exit.
2023-07-19 06:28:35 -0400 < mnieper> With Chez's parameters, one can synchronize with a state change external to Scheme (which is what you need, I think).
2023-07-19 06:28:42 -0400 < ManDay> You could try C++. They have destructors and stuff
2023-07-19 06:28:50 -0400 < ManDay> :p
2023-07-19 06:29:14 -0400 < ecraven> ManDay: I can *write* such a `with' macro, but maybe someone has already done that (and knows more about how to do that correctly than me :P)
2023-07-19 06:29:27 -0400 < mnieper> You would then write: (parameterize ([knx (make-knx-network-connection ...)]) ...)
2023-07-19 06:29:39 -0400 < ecraven> mnieper: but how would it be released on exit from that block?
2023-07-19 06:29:48 -0400 < ManDay> yes I have a similar thing for debug output which wraps the body in some intro and outro. if you find an srfi solution let me know :D
2023-07-19 06:29:59 -0400 < mnieper> Of course, knx has to be a predefined parameter here. So better call it current-knx. :)
2023-07-19 06:30:20 -0400 < mnieper> ecraven: Because Chez calls the parameter setting on exist again, using the old value of the knx parameter.
2023-07-19 06:30:41 -0400 < ecraven> ah, so the setter is called on each change?
2023-07-19 06:30:50 -0400 < ecraven> thanks for explaining that
2023-07-19 06:31:19 -0400 < mnieper> This is why it is more expressive than R7RS-small (and why Chez hasn't adopted R7RS parameters).
2023-07-19 06:32:36 -0400 < mnieper> See Dybvig's comment here: https://github.com/cisco/ChezScheme/issues/409
2023-07-19 07:14:16 -0400 < ecraven> hm.. http://ix.io/4AXe that seems a bit too trivial ;)
2023-07-19 07:14:19 -0400 < ecraven> but it works
2023-07-19 07:22:26 -0400 < mnieper> It doesn't. :)
2023-07-19 07:22:58 -0400 < mnieper> Jump out of `fun' and back (using call/cc).
2023-07-19 07:22:58 -0400 < ecraven> hehe, I'll rephrase: the one test I did worked
2023-07-19 07:23:05 -0400 < ecraven> mnieper: yea, I don't :D
2023-07-19 07:23:11 -0400 < mnieper> `fun' will still see the closed port.
2023-07-19 07:23:12 -0400 < ecraven> that won't work for networking anyway
2023-07-19 07:23:24 -0400 < mnieper> Then don't use dynamic-wind.
2023-07-19 07:23:41 -0400 < mnieper> Because it makes your code look like it could work.
2023-07-19 07:23:42 -0400 < ecraven> well, I want to catch exits from `throw'
2023-07-19 07:24:17 -0400 < ecraven> `raise' actually
2023-07-19 07:24:36 -0400 < mnieper> Then code it with unwind-protect (see SRFI 226).
2023-07-19 07:25:12 -0400 < mnieper> But even when you use dynamic-wind: why do you use set! then if not trying to achieve compatiblity with call/cc?
2023-07-19 07:25:39 -0400 < mnieper> You can (and should) leave your before-thunk trivial.
2023-07-19 07:25:50 -0400 < mnieper> (Emulating unwind-protect.)
2023-07-19 07:26:39 -0400 < mnieper> (let ([file (open-...)]) (dynamic-wind (lambda () (values)) (lambda () (fun file)) (lambda () (close-input-port file))))
2023-07-19 07:27:05 -0400 < mnieper> Or, even better:
2023-07-19 07:27:36 -0400 < mnieper> (let ([file (open-...)]) (dynamic-wind (lambda () (unless file (assertion-violation ...)))
2023-07-19 07:27:57 -0400 < mnieper> (lambda () (fun file)) (lambda () (close-input-port file) (set! file #f))))
2023-07-19 07:28:26 -0400 < mnieper> This should guard against call/cc or continuable exceptions.
2023-07-19 07:29:19 -0400 < ecraven> thanks!
2023-07-19 07:29:50 -0400 < mnieper> de rien
2023-07-19 07:34:50 -0400 < mnieper> Your code in http://ix.io/4AXe is a very good example for why Scheme would probably become a better language if `set!' were banned.
2023-07-19 07:35:27 -0400 < mnieper> All uses could be replaced by boxes (SRFI 111) similar to ML's refs and the semantics would be a lot easier.
2023-07-19 07:40:19 -0400 < mnieper> ecraven: Have you taken a look at Chez's guardians? https://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgmt:h2
2023-07-19 07:40:40 -0400 < mnieper> With them you can maintain a pool of connection objects.
2023-07-19 07:41:08 -0400 < mnieper> Whenever you need to create a new connection, you check whether there is one connection object in the guardian because it can be gc'ed.
2023-07-19 07:41:58 -0400 < ecraven> thanks, this is nice, so this would make it possible to release the non-accessible network connections some time after they become inaccessible
2023-07-19 07:42:00 -0400 < mnieper> If you go this route, you don't need any dynamic-wind.
2023-07-19 07:43:04 -0400 < ecraven> well, in my specific case, I do, because the other device I'm talking to will only allow *one* connection from my machine... so if that one breaks, I need to take it down asap to start a new one.
2023-07-19 07:43:07 -0400 < mnieper> And call-with-network-connection can work like Scheme's call-with-input-port.
2023-07-19 07:43:27 -0400 < ecraven> I need to re-read csug, I've read this before, but forgotten about it
2023-07-19 07:44:53 -0400 < mnieper> If only one connection is allowed, one global object (possibly a parameter) seems to be the way to go.
2023-07-19 09:00:00 -0400 < mnieper> sham1: Zipheir: Saw your discussion on testing by chance.
2023-07-19 09:00:24 -0400 < mnieper> If you want a dynamic approach, I would use parameters/effect handlers.
2023-07-19 09:01:21 -0400 < mnieper> E.g. (when using parameters), do not pass db procedures explicitely but call them through parameters that are parameterized only at one point.
2023-07-19 09:01:56 -0400 < sham1> Right, so you'd do ((current-db-accessor-proc) params...)
2023-07-19 09:02:18 -0400 < mnieper> I would hide this behind a procedure, but yes.
2023-07-19 09:03:12 -0400 < mnieper> If you want a static approach use modules like those defined in Chez Scheme or Unsyntax. These allow you to emulate enough of ML functors.
2023-07-19 09:04:02 -0400 < mnieper> If you can't use this kind of modules because you are not (yet?) working with Chez, you should be able to cook up a similar thing with (syntax-case) macros.
2023-07-19 09:05:37 -0400 < mnieper> E.g. you could have a macro like (import-db-procedures <testing?>).
2023-07-19 09:06:51 -0400 < mnieper> The macro expands into a huge list of defines (or, better, aliases; see SRFI 212) where the defined variables are injected unhygienically (as with a usual import).
2023-07-19 09:07:17 -0400 < mnieper> Depending on the <testing?> expand-time parameter, the right hand sides of the defines are choosen differently.
2023-07-19 09:12:06 -0400 < mnieper> Something like this: https://paste.debian.net/plain/1286331
2023-07-19 09:12:34 -0400 < mnieper> This is to be defined in some library, which just exports `import-pares'.
2023-07-19 09:12:48 -0400 < mnieper> You can then do (import-pares list) or (import-pares vector).
2023-07-19 09:31:06 -0400 < sham1> This would be nice to have as a standard
2023-07-19 09:36:15 -0400 < mnieper> What exactly?
2023-07-19 09:36:31 -0400 < mnieper> The modules of Chez?
2023-07-19 09:53:37 -0400 < sham1> Yes
2023-07-19 10:27:36 -0400 < mnieper> I would like to have Chez-style modules in the Foundations.
2023-07-19 10:50:23 -0400 < hexology> never heard of unsyntax before. there are a lot of really interesting r7rs implementations now
2023-07-19 10:50:25 -0400 < hexology> speaking of r7rs, what's the best way to replace a fixed (not regex) substring of a string with some other string? hypothetically: `(string-replace "password=secret" "***")` returning "password=***"
2023-07-19 10:54:17 -0400 < mnieper> You can use string-contains and string-replace from SRFI 152, for example.
2023-07-19 11:01:09 -0400 < hexology> that's easy enough, i forgot about srfi 152. i didn't find a built-in way to do it in a single (optimized?) function in gauche so that works
2023-07-19 11:05:10 -0400 < mnieper> Be careful, though. IIRC, the sample implementation of SRFI 152 uses `string-ref' everywhere.  But `string-ref' is not O(1) in general in R7RS schemes, making many algorithms in the sample implementation accidentally quadratic.
2023-07-19 11:06:08 -0400 < mnieper> Maybe Gauche actually has an O(1) `string-ref'.
2023-07-19 11:12:35 -0400 < mnieper> sham1: https://codeberg.org/scheme/r7rs/issues/120
2023-07-19 11:12:37 -0400 < mnieper> :)
2023-07-19 11:13:02 -0400 < sham1> Neat!
2023-07-19 11:26:56 -0400 < hexology> mnieper: ah, good to know. i *think* gauche has "array" strings with O(1) ref but i should double check.
2023-07-19 11:38:59 -0400 < sham1> mnieper: I wonder if the modules could be integrated nicely into the library system
2023-07-19 11:41:10 -0400 < mnieper> hexology: (string-ref (make-string 1000000) 999999)
2023-07-19 11:41:24 -0400 < mnieper>   (do ((i 0 (+ i 1))) ((= i 10000)) (string-ref s 999999))
2023-07-19 11:41:58 -0400 < mnieper> sham1: Modules are bound to identifiers as procedures or other syntax.
2023-07-19 11:42:05 -0400 < mnieper> So you can export or import them as you wish.
2023-07-19 11:42:19 -0400 < sham1> Oh, so modules can be under libraries
2023-07-19 11:42:28 -0400 < sham1> So they really are just like SML modules
2023-07-19 11:42:30 -0400 < mnieper> Yes. First-class so to speak.
2023-07-19 11:42:36 -0400 < sham1> Neat
2023-07-19 11:42:40 -0400 < mnieper> Expand-time, first-class, that is.
2023-07-19 11:42:50 -0400 < hexology> mnieper: what is that code demonstrating? i assume it'd be a little slow to execute if string ref isn't O(1)
2023-07-19 11:43:00 -0400 < mnieper> hexology: Exactly.
2023-07-19 11:43:03 -0400 < sham1> Maybe modules could then be used like classes
2023-07-19 11:43:13 -0400 < sham1> To emulate a more OO style
2023-07-19 11:43:20 -0400 < mnieper> sham1: They are static.
2023-07-19 11:43:28 -0400 < mnieper> So more like type classes in Haskell.
2023-07-19 11:43:51 -0400 < mnieper> One could think of an alternative to SRFI 225 using modules.
2023-07-19 11:44:09 -0400 < hexology> it's nearly instant in gauche and gambit, just pasting into the repl
2023-07-19 11:44:24 -0400 < mnieper> hexology: Then it looks like O(1). :)
2023-07-19 11:44:33 -0400 < hexology> that was my assumption yeah
2023-07-19 11:44:34 -0400 < mnieper> In Chibi, it takes much, much longer.
2023-07-19 11:44:39 -0400 < sham1> Well modules in SML can be used to do OO so maybe these can also do it, even if they're expand time
2023-07-19 11:44:56 -0400 < sham1> Although a CLOS-like thing might still do "better" for that
2023-07-19 11:45:15 -0400 < mnieper> sham1: I think it really depends on what you want/need.
2023-07-19 11:45:58 -0400 < hexology> i see. chicken and sagittarius are also nearly instant
2023-07-19 11:46:03 -0400 < mnieper> If you want to be able to configure your classes at runtime or need to do runtime dynamic dispatch, you would need more than modules or SML functors, I think.
2023-07-19 11:46:15 -0400 < hexology> i think chibi might be the outlier here. guile is also instant
2023-07-19 11:46:38 -0400 < mnieper> sham1: But, of course, such an OO system could build on modules.
2023-07-19 11:53:43 -0400 < gwatt> I think there's an example in csug of using modules to do that
2023-07-19 12:01:45 -0400 < Zipheir> The supposed seminal paper of OOP, Cardelli & Wagner 1985, is more about modules than objects.
2023-07-19 12:02:08 -0400 < Zipheir> s/Wagner/Wegner/
2023-07-19 12:03:15 -0400 < Zipheir> The ideas are very similar, though I don't know enough OO jargon to say whether a module is more like a class or an object.
2023-07-19 12:12:28 -0400 < mnieper> If Chibi appears to be the only Scheme where string-ref is not O(1), maybe requiring O(1) in R7RS-large is again an option.
2023-07-19 12:34:02 -0400 < gnomon> mnieper, if I recall correctly there were at least two microcontroller-targetted Schemes that had >O(1) string refs.  I think Picobit/Picbit?
2023-07-19 12:48:23 -0400 < mnieper> gnomon: Thanks! But I doubt R7RS-large is relevant for them.
2023-07-19 13:00:00 -0400 < gnomon> Agreed, that's fair
2023-07-19 13:13:18 -0400 < Oxyd> How do other Schemes implement string-ref in O(1) time?
2023-07-19 13:15:29 -0400 < gwatt> Oxyd: use utf-32
2023-07-19 13:15:43 -0400 < Oxyd> That sounds like the wrong choice.
2023-07-19 13:16:14 -0400 < Oxyd> Which Schemes use UTF-32 to represent their strings?
2023-07-19 13:16:21 -0400 < gwatt> chez
2023-07-19 13:17:52 -0400 < gwatt> (and maybe others, but I haven't looked into them)
2023-07-19 13:21:28 -0400 < ecraven> we should use tightly packed 24-bit chars :P should be enough for unicode + some bucky bits
2023-07-19 13:33:23 -0400 < mnieper> If string-set! (to be deprecated) is allowed to operate in O(n), string-ref can be O(1) even when strings are UTF-8 encoded.
2023-07-19 13:35:35 -0400 < gwatt> ecraven: I think that's basically utf-32
2023-07-19 13:44:17 -0400 < dpk> Guile uses UTF-32 for any string which contains characters outside the Latin-1 range
2023-07-19 13:44:37 -0400 < dpk> like Python, except no intermediate 16-bit step for BMP-only strings
2023-07-19 14:39:36 -0400 < ecraven> gwatt: well, we could pack 20-bit chars, but that's even more awkward than handling nibbles :P
2023-07-19 15:27:54 -0400 < mnieper> The important thing is that we have more than one approach to guarantee O(1) for string-ref and that there is no need for string cursors or even more complicated primitives.
2023-07-19 16:03:03 -0400 < Oxyd> Yeah, but they all require extra space.
2023-07-19 16:04:39 -0400 < Oxyd> Besides, I don't think string-ref makes much sense in a Unicode world anyway. Why would you want to access random code-points? Usually you want to go through a string sequentially – and even then you might want to take several code-points at once.
2023-07-19 16:06:13 -0400 < ecraven> I believe there are still many cases for accessing code-points in a string directly, not always having to go through an iterator
2023-07-19 16:07:01 -0400 < Oxyd> Give an example.
2023-07-19 16:07:48 -0400 < ecraven> check for a suffix
2023-07-19 16:07:50 -0400 < ecraven> search inside a longer string
2023-07-19 16:08:22 -0400 < ecraven> my question is rather, what *else* would you use instead of codepoints?
2023-07-19 16:08:33 -0400 < Oxyd> Those both sound like sequential operations.
2023-07-19 16:09:01 -0400 < ecraven> of course, but if you can't access randomly, how do you *get* an iterator to the seventeenth-to-last codepoint and go from there?
2023-07-19 16:09:27 -0400 < Oxyd> Why would you want seventeenth-to-last codepoint in the first place? If you're searching for a suffix, you want to start with the end iterator.
2023-07-19 16:09:58 -0400 < Oxyd> Likewise, if you're searching for a substring, you probably want to start with the start iterator.
2023-07-19 16:10:04 -0400 < ecraven> what would the iterator iterate over, if not codepoints?
2023-07-19 16:11:25 -0400 < Oxyd> I think you're missing the point. If you have an iterator – specifically a string cursor from that SRFI whose number I don't remember – you can just dereference it directly in constant time. You don't need to convert it to n-th codepoint and then string-ref n.
2023-07-19 16:12:07 -0400 < Oxyd> So yes, you will iterate over code-points. But you won't string-ref the n'th code-point.
2023-07-19 16:12:33 -0400 < mnieper> The problem is: as long as string-ref does exist, people use it.
2023-07-19 16:12:44 -0400 < ecraven> I don't see the difference yet.. if all your functions take indices, that's fine.. if all your functions take iterators / cursors, that's fine too.. the mixing is what I don't like, and I don't see an advantage in a cursor that goes over the *same* thing that you'd index anyway yet... now if you have a cursor that iterates by "glyph" or "grapheme" or "cluster", that's way more useful
2023-07-19 16:12:52 -0400 < mnieper> Even if you also offer some fancy iterator objects.
2023-07-19 16:13:03 -0400 < Zipheir> How do you implement whole-string operations without a string-ref procedure (at some level)?
2023-07-19 16:13:07 -0400 < ecraven> mnieper: because all the primitive functions use indices
2023-07-19 16:13:13 -0400 < Zipheir> ^
2023-07-19 16:13:48 -0400 < ecraven> I'm not saying iterators are *worse* than indices, I just haven't found them to be *better* yet :P
2023-07-19 16:13:50 -0400 < Zipheir> Cursors, I guess.
2023-07-19 16:13:57 -0400 < Oxyd> The point is that – on some implementations at least – string-ref with an index is O(n). Which is not gret.
2023-07-19 16:14:19 -0400 < ecraven> Oxyd: well, you can implement iterators badly too, how is that different?
2023-07-19 16:14:33 -0400 < Oxyd> And yes, some better Unicode support that has support for things like glyphs and clusters would be nice too.
2023-07-19 16:14:40 -0400 < mnieper> My point here was that R7RS-large can force O(1) because, as it seems, most implementation guarantee it anyway.
2023-07-19 16:15:08 -0400 < Oxyd> ecraven: Well you can't implement string-ref on indices well. Either it's O(n), or it requires extra storage. String cursors are O(1) with no extra storage.
2023-07-19 16:15:09 -0400 < mnieper> If string-ref is O(n), it should be banned altogether.
2023-07-19 16:15:23 -0400 < Zipheir> Want to ban list-ref, too, then?
2023-07-19 16:15:31 -0400 < Oxyd> I, for one, do.
2023-07-19 16:15:34 -0400 < ecraven> Oxyd: cursors are only O(1) for sequential access though, right?
2023-07-19 16:15:54 -0400 < mnieper> Zipheir: If we had list cursors, it would be an option.
2023-07-19 16:15:59 -0400 < Zipheir> Hmm.
2023-07-19 16:16:04 -0400 < ecraven> the same argument goes for vector-ref and bytevector-ref and all others, doesn't it?
2023-07-19 16:16:26 -0400 < ecraven> (now if the cursor interface were polymorphic over any sequence... that'd be a whole different story :P)
2023-07-19 16:16:35 -0400 < Oxyd> ecraven: Well, dereferencing a cursor is O(1). But this brings us back to the original question – what would you want to do with a string where you want true random access and not sequential?
2023-07-19 16:16:55 -0400 < Zipheir> Searching, perhaps.
2023-07-19 16:16:57 -0400 < ecraven> Oxyd: well, the point is how do I *get* a cursor to dereference?
2023-07-19 16:17:01 -0400 < mnieper> Oxyd: The problem is a different one. People use string-ref to do the stuff where they could use cursors.
2023-07-19 16:17:04 -0400 < ecraven> *that's* not O(1)
2023-07-19 16:17:19 -0400 < Zipheir> cursor-ref from SRFI 130 should be O(1).
2023-07-19 16:17:48 -0400 < mnieper> Offering cursors is one thing. Getting people to use them another.
2023-07-19 16:17:50 -0400 < Zipheir> Er, string-ref/cursor.
2023-07-19 16:18:03 -0400 < Oxyd> ecraven: Of course. Finding a prefix or suffix is going to be O(n), for obvious reasons. But it won't be O(n^2) as it would be if you call O(n) string-ref n times.
2023-07-19 16:18:05 -0400 < ecraven> mnieper: they have to have some advantage, otherwise why bother?
2023-07-19 16:18:22 -0400 < ecraven> Oxyd: well, that's easily solved by just mandating string-ref to be O(1)..
2023-07-19 16:18:30 -0400 < Oxyd> But that requires extra storage.
2023-07-19 16:18:38 -0400 < mnieper> Oxyd: Not much.
2023-07-19 16:18:40 -0400 < ecraven> yes, but *everything* requires tons of storage nowadays...
2023-07-19 16:18:57 -0400 < ecraven> the maximum you need is 4 times the size, 32 bits per character instead of 8, right?
2023-07-19 16:18:57 -0400 < Zipheir> The expense is iterating the cursor forward to a position.
2023-07-19 16:19:37 -0400 < ecraven> so the trivial implementation is just to use utf-32 (or something like it) internally, which is not that much worse for anyone *except* for plain ASCII users
2023-07-19 16:19:48 -0400 < mnieper> ecraven: You can also use UTF-8 and store a vector of every 16th index or so.
2023-07-19 16:20:27 -0400 < ecraven> mnieper: so, why *should* I use cursors instead of indices? ;D
2023-07-19 16:20:32 -0400 < Oxyd> Right, but why would you accept it when it's not really necessary? Again, the only use-case where you truly need that is something like (string-ref s (get-random-number)). Usually you access strings sequentially.
2023-07-19 16:20:47 -0400 < ecraven> the main thing I'll concede (as of my knowledge right now) is out-of-bounds checking
2023-07-19 16:21:01 -0400 < ecraven> Oxyd: but *not* always from the start or end
2023-07-19 16:21:20 -0400 < ecraven> as an example, I'm doing a lot of bytevector extraction for parsing network packets.. that is often *not* a sequential process, but you get an offset and then directly index there
2023-07-19 16:21:27 -0400 < mnieper> Oxyd: I understand it when people say integers are easier than opaque objects.
2023-07-19 16:21:42 -0400 < Oxyd> Network packets and text strings are quite different things.
2023-07-19 16:21:58 -0400 < Oxyd> I wouldn't want to get rid of vector-ref for example.
2023-07-19 16:22:14 -0400 < ecraven> isn't that the same, conceptually? so your gripe is *only* about the space tradeoff?
2023-07-19 16:22:37 -0400 < ecraven> so you prefer a slightly-more-inconvenient interface that doesn't use more space, but others might prefer more convenience over the space savings, right?
2023-07-19 16:22:55 -0400 < Oxyd> My gripe is that strings aren't really random-access so why bother with string-ref?
2023-07-19 16:23:09 -0400 < ecraven> I've seen text formats that have inline offsets, by the way :P (not that anyone should support such abominations)
2023-07-19 16:23:40 -0400 < Zipheir> Every implementation has it. Leave it alone if you don't like it, I say.
2023-07-19 16:24:39 -0400 < Zipheir> I hope it's not the place Scheme reports to decide on philosophical issues like whether strings are "random-access structures" or not.
2023-07-19 16:24:48 -0400 < Zipheir> *place of
2023-07-19 16:25:24 -0400 < Oxyd> It's not philosophical, it's just text and Unicode work.
2023-07-19 16:25:58 -0400 < ecraven> hm.. I read through the rationale of srfi-130, but that also just indirectly says "more space efficient", and gives no *other* explanation on why cursors are better
2023-07-19 16:26:27 -0400 < Oxyd> The code-points depend on each other. If you throw a dart into the middle of a Unicode string, you might end up in the middle of some cluster – and how's that useful?
2023-07-19 16:26:40 -0400 < ecraven> that depends very much on what you want to do
2023-07-19 16:26:41 -0400 < dpk> SRFI 130 is not getting in. WG2 voted it down twice
2023-07-19 16:26:54 -0400 < ecraven> it is trivial to find the start of a codepoint even in utf-8
2023-07-19 16:26:57 -0400 < dpk> to be flippant, basically everyone except Alex Shinn thinks string cursors suck
2023-07-19 16:27:13 -0400 < Zipheir> And Will Clinger, apparently.
2023-07-19 16:27:17 -0400 < Oxyd> And me.
2023-07-19 16:27:33 -0400 < dpk> the problem is that RnRS where n≠6 provides no guarantee of *any* efficient way to do string processing
2023-07-19 16:27:48 -0400 < ecraven> well, I don't think they suck in general, as I said, iterating over glyphs or grapheme clusters or whatever would certainly be nice... though maybe even then indices would be nicer :P
2023-07-19 16:27:53 -0400 < dpk> in practice, the idiom Schemers have settled on is using string-ref
2023-07-19 16:28:32 -0400 < Zipheir> As for landing in the middle of grapheme clusters, string-ref is the least of the problems. I don't think we've come anywhere near dealing with that.
2023-07-19 16:28:34 -0400 < dpk> so the pave-the-cowpaths way to fix that problem is to make string-ref efficient at least for the most common access pattern
2023-07-19 16:29:12 -0400 < dpk> grapheme clusters have the problem that the definition changes with every version of Unicode as new marks and base characters are encoded, whereas an array of codepoints is just an array of codepoints
2023-07-19 16:29:16 -0400 < Zipheir> (Any Unicode normalization libraries for Scheme? I doubt it.)
2023-07-19 16:29:25 -0400 < Zipheir> dpk: That too.
2023-07-19 16:29:28 -0400 < dpk> R6RS include Unicode normalization procedures
2023-07-19 16:29:31 -0400 < ecraven> dpk: I know, just saying there might be a use for iterating over something larger than codepoints
2023-07-19 16:29:31 -0400 < dpk> +s
2023-07-19 16:29:45 -0400 < ecraven> like "the next thing a cursor would point to when going left or right"
2023-07-19 16:29:51 -0400 < dpk> ecraven: certainly there is, but codepoints are the highest level of abstraction it's sensible to offer in the base language
2023-07-19 16:29:52 -0400 < ecraven> (ignoring up/down :P)
2023-07-19 16:29:59 -0400 < Oxyd> Yeah, but an array of codepoints is a very low-level view of things. I'd expect Scheme to be a bit higher level than that.
2023-07-19 16:30:01 -0400 < dpk> grapheme iteration can then freely be a userspace concern
2023-07-19 16:30:02 -0400 < ecraven> dpk: I completely agree
2023-07-19 16:30:10 -0400 < mnieper> There is a semi-efficient way of string processing even outside of R6RS. It is called string->list.
2023-07-19 16:30:28 -0400 < dpk> heh. or string->vector
2023-07-19 16:30:43 -0400 < mnieper> Not in R5RS, is it?
2023-07-19 16:30:48 -0400 < dpk> err, no idea
2023-07-19 16:30:52 -0400 < ecraven> hehe, I remember that the CADR had co-located lists and arrays (due to CDR-coding).. so you could access one set of data as both a list or an array :P
2023-07-19 16:30:53 -0400 < dpk> maybe not
2023-07-19 16:31:02 -0400 < Oxyd> You can't reasonably do grapheme iteration in userspace without somehow including the whole Unicode database there as well. But the implementation already has some version of the database for things like string-upcase.
2023-07-19 16:31:21 -0400 < dpk> Oxyd: the small language only requires ASCII support, remember
2023-07-19 16:31:31 -0400 < Oxyd> So if you really want to throw this problem at users, it should at least expose this database somehow.
2023-07-19 16:31:45 -0400 < ecraven> Oxyd: I was thinking the same thing a few times in the past, it would be nice to have a standard way of accessing the data
2023-07-19 16:31:49 -0400 < dpk> if the implementation supports more, it must do so in a Unicode-consistent way, but only ASCII (minus null) is required
2023-07-19 16:31:54 -0400 < Oxyd> Yes, perhaps that's the best way of solving the string-ref problem. Just give the n-th byte and tell people to not store non-ASCII in it.
2023-07-19 16:32:14 -0400 < jcowan> You can have space efficiency or time efficiency, but not both.
2023-07-19 16:32:18 -0400 < ecraven> we have that in bytevectors already, right? :D
2023-07-19 16:32:24 -0400 < Zipheir> dpk: Thanks, I forgot about string-normalize-*
2023-07-19 16:32:25 -0400 < dpk> we have bytevectors if you wish to be so gauche
2023-07-19 16:32:54 -0400 < Oxyd> Yeah, we have bytevectors and codepointvectors, but no strings.
2023-07-19 16:33:04 -0400 < ecraven> I still think that an overhead of 4 times is acceptable ;D
2023-07-19 16:33:08 -0400 < mnieper> string-ref can be space efficient and time efficient. string-ref+string-set! cannot be all space efficient and time efficient.
2023-07-19 16:33:09 -0400 < ecraven> Oxyd: well, what would a "string" be?
2023-07-19 16:33:24 -0400 < mnieper> ecraven: You don't need an overhead of 4 times.
2023-07-19 16:33:46 -0400 < Oxyd> ecraven: Something with a better understanding of Unicode than just “a bag of codepoints”.
2023-07-19 16:33:49 -0400 < dpk> see https://gitlab.com/dpk/presrfis/-/blob/master/string-notes.md
2023-07-19 16:33:56 -0400 < ecraven> mnieper: yes, but if you accept 4 times, that's easy to do and it won't get worse. you can of course do better
2023-07-19 16:34:16 -0400 < dpk> another problem with extended grapheme clusters is that they're an attempt at a language-neutral
2023-07-19 16:34:21 -0400 < jcowan> ecraven: Yes, if you are willing to pay the 4x space cost, you are basically as efficient as homogeneous vectors.
2023-07-19 16:34:21 -0400 < ecraven> Oxyd: to my understanding, unicode itself *doesn't* provide anything higher-level than codepoints (at least not across versions)
2023-07-19 16:34:22 -0400 < dpk> compromise
2023-07-19 16:34:23 -0400 < mnieper> ecraven: I agree. But if you want to argue in favour of string-ref, you should try to advertise it better. :)
2023-07-19 16:34:24 -0400 < Oxyd> I mean, other languages have string libraries. And they have things like this: https://tomdebruijn.com/posts/rust-string-length-width-calculations/
2023-07-19 16:34:36 -0400 < dpk> like the casefold procedure, they aren't right for all languages, afaik
2023-07-19 16:35:09 -0400 < dpk> (one strangeness in the definition that comes to mind is that iirc the anusvara counts as part of a base grapheme, but the visarga as its own grapheme, in Devanagari)
2023-07-19 16:35:10 -0400 < jcowan> The various kinds of grapheme clusters are part of Unicode
2023-07-19 16:35:22 -0400 < ecraven> dpk: yes, a proper "String" would have to include the language for each of the codepoints :P
2023-07-19 16:35:29 -0400 < Oxyd> I think with case folding and similar, there are language-neutral algorithms and language-dependent ones.
2023-07-19 16:36:14 -0400 < jcowan> Oxyd: Yes, although the difference is minimal
2023-07-19 16:36:24 -0400 < mnieper> The first step to take is to remove string-set! anyway. This makes the least sense of all interfaces discussed so far.
2023-07-19 16:36:40 -0400 < ecraven> I'm trying to come up with a single time when I've used string-set!...
2023-07-19 16:37:14 -0400 < ecraven> I think the only time it came in handy was when creating a "canvas" (like for an LED display), to paint characters at random positions. and I could just as well have used a vector there
2023-07-19 16:37:24 -0400 < ecraven> now multi-dimensional *vectors* would be a great thing to have :P
2023-07-19 16:37:46 -0400 < jcowan> We have two SRFIs for that
2023-07-19 16:38:33 -0400 < mnieper> As we cannot remove it completely (because of RnRS compatibility), we should at least not guide string representations and the non-mutating interfaces by its presence.
2023-07-19 16:38:56 -0400 < ecraven> jcowan: https://xkcd.com/927/ :P
2023-07-19 16:39:45 -0400 < jcowan> I personally prefer 231 to 164, partly because 164's implementation is mostly written in Java
2023-07-19 16:42:24 -0400 < ecraven> thanks, I think I missed 231 (I should read all the newer srfis :-/)
2023-07-19 16:43:16 -0400 < jcowan> it is really awesomesauce
2023-07-19 16:43:35 -0400 < jcowan> it lets you manipulate arrays as bulk containers
2023-07-19 16:43:46 -0400 < jcowan> as in APL
2023-07-19 16:44:42 -0400 < dpk> Oxyd: the language neutral ones are inherently wrong for some languages, most notoriously Turkish where i is not the lower case form of I
2023-07-19 16:45:28 -0400 < ecraven> there's also problems where one "character" expands or contracts to multiple when changing case
2023-07-19 16:45:31 -0400 < Oxyd> Yes, that's the best you can do if you don't specify a language for your string.
2023-07-19 16:46:09 -0400 < ecraven> Oxyd: well, the problem is you need a language for each *codepoint*, not the entire string (otherwise, how do you deal with multi-language strings)
2023-07-19 16:46:22 -0400 < Oxyd> Very true as well.
2023-07-19 16:46:50 -0400 < ecraven> I think the best thing to do here is give up, accept that a "string" doesn't exist, and continue by providing a solid basis of "vector-of-codepoint-with-easy-access-to-unicode-data"
2023-07-19 16:47:14 -0400 < Oxyd> And some things are literally unsolvable – such as those language dropboxes that some websites have these days, where each language is written in that language itself. According to which language's collation rules do you order the dropdown?
2023-07-19 16:47:48 -0400 < dpk> answer: you copy what the Mediawiki Foundation does for its language selectors
2023-07-19 16:47:48 -0400 < ecraven> hehe, well, given that most people can't read most of them anyway, does it matter? :P
2023-07-19 16:48:02 -0400 < Oxyd> Yes, it does matter because you're trying to find your own one in the mix.
2023-07-19 16:48:19 -0400 < ecraven> but if you can't read most of the scripts, where do you look?
2023-07-19 16:48:29 -0400 < ecraven> there's no solution to this, imho ;D
2023-07-19 16:48:44 -0400 < ecraven> well, unless of course you just show the "right" one as the first one always :P
2023-07-19 16:52:57 -0400 < mnieper> Good Night!
2023-07-19 16:53:31 -0400 < sham1> How would you specify languages for use with string casefolding and such
2023-07-19 16:53:40 -0400 < sham1> This just feels like we're back at the locale discussion
2023-07-19 16:55:02 -0400 < Oxyd> Casefolding is locale dependent, yeah. Point is, strings are complicated, and not just a bag of codepoints.
2023-07-19 16:55:23 -0400 < sham1> Well then, define a string, because Unicode certainly doesn't
2023-07-19 16:56:24 -0400 < sham1> Just like how it doesn't define "character"
2023-07-19 16:58:21 -0400 < sham1> Well, it does have a definition for "character" but it's kinda lacking. But it certainly doesn't define "string"
2023-07-19 16:58:27 -0400 < sham1> Nor "text", which is interesting
2023-07-19 16:58:50 -0400 < dpk> Oxyd: as i said above, codepoints are the highest-level abstraction upon which it's possible to build any other application, language-specific or not, correctly
2023-07-19 16:58:52 -0400 < Oxyd> Other languages exist, perhaps we could reappropriate one of those definitions.
2023-07-19 16:59:06 -0400 < sham1> Other languages also do bags of codepoints
2023-07-19 16:59:07 -0400 < dpk> if you start going higher, you compromise correctness for some language or set of languages
2023-07-19 16:59:36 -0400 < sham1> If not just bags of code units. At worst you get something like C where a string is a zero or more non-zero chars followed by a zero char
2023-07-19 16:59:46 -0400 < dpk> strings as arrays of graphemes would be a useful thing for someone to write a library for
2023-07-19 17:00:07 -0400 < dpk> there are other applications where i expect a programmer would have to come up with their own implementation of strings
2023-07-19 17:00:20 -0400 < dpk> anything involving mutation, for example
2023-07-19 17:00:45 -0400 < ecraven> if you write an editor, you probably will use a custom data type for your text anyway...
2023-07-19 17:00:57 -0400 < dpk> by implementing that themselves, programmers can choose their own space/time trade-offs for their particular application
2023-07-19 17:00:58 -0400 < dpk> exactly
2023-07-19 17:01:09 -0400 < jcowan> So we have neutral case folding for all except I, İ in Turkish and Azeri only.  Per contra, there are 1557 case foldings applicable to all languages.  Teeny tiny tail wags great big do
2023-07-19 17:01:09 -0400 < sham1> Ropes
2023-07-19 17:01:11 -0400 < jcowan> dog
2023-07-19 17:01:27 -0400 < ecraven> now one other thing that would be good is string aliases, where you can say "I want to reference this part of that other much larger string"
2023-07-19 17:01:41 -0400 < sham1> You mean... substrings that share the storage
2023-07-19 17:01:47 -0400 < ecraven> I've wanted these often, also for bytevectors... I think CL calls them displaced arrays
2023-07-19 17:01:54 -0400 < sham1> Yeah, it'd be nice if the strings were immutable, but alas
2023-07-19 17:01:54 -0400 < ecraven> sham1: yes.
2023-07-19 17:02:01 -0400 < ecraven> well, I just don't mutate them :P
2023-07-19 17:02:12 -0400 < jcowan> You need to have both share and copy operations
2023-07-19 17:02:15 -0400 < ecraven> also, it'd be great to have not just for strings, but at least for bytevectors too
2023-07-19 17:02:30 -0400 < sham1> I would like for bytevectors to get more love, yes
2023-07-19 17:02:55 -0400 < ecraven> I've been doing a lot of binary parsing recently, but I haven't looked at the existing SRFIs :-/
2023-07-19 17:03:39 -0400 < sham1> For example there's a procedure for turning flexvectors into normal vectors and strings, but not bytevectors which is a weird omission
2023-07-19 17:04:24 -0400 < dpk> jcowan: i dunno, ß case-folding to ss is also wrong for some historic languages which will never be in CLDR but which someone like me might nonetheless want to write case-folding and collation tailorings etc for
2023-07-19 17:04:27 -0400 < sham1> I suppose one can (ab)use bytevector ports for that, but that'd also be a thing for strings
2023-07-19 17:04:57 -0400 < sham1> At least ß can now turn into ẞ
2023-07-19 17:05:58 -0400 < jcowan> But not, thank Ghu, vice versa
2023-07-19 17:06:01 -0400 < ecraven> does ſ case-fold into s?
2023-07-19 17:06:06 -0400 < jcowan> No
2023-07-19 17:06:07 -0400 < sham1> Although if we're looking at that, what would a casefolding look like for example with 'ffi'
2023-07-19 17:06:26 -0400 < ecraven> sham1: those compatibility codepoints are an abomination anyway :P
2023-07-19 17:06:36 -0400 < jcowan> it looks like ffi
2023-07-19 17:06:37 -0400 < sham1> Oh for sure, but they exist and must be handled
2023-07-19 17:06:56 -0400 < sham1> Hm, casefolding was the wrong word I suppose then. Uppercase?
2023-07-19 17:07:03 -0400 < sham1> Ffi? FFI?
2023-07-19 17:07:17 -0400 < jcowan> Those are titlecase and uppercase respectively
2023-07-19 17:07:29 -0400 < sham1> But it does expand
2023-07-19 17:07:34 -0400 < sham1> That's sad
2023-07-19 17:07:38 -0400 < sham1> Expected but sad
2023-07-19 17:07:48 -0400 < jcowan> See https://srfi.schemers.org/srfi-129/srfi-129.html
2023-07-19 17:07:54 -0400 < Oxyd> rudybot: eval (string-upcase "ffi")
2023-07-19 17:07:55 -0400 < rudybot> Oxyd: your sandbox is ready
2023-07-19 17:07:55 -0400 < rudybot> Oxyd: ; Value: "FFI"
2023-07-19 17:08:27 -0400 < dpk> see also https://opoudjis.net/unicode/unicode_adscript.html for some hairyness around title case
2023-07-19 17:08:30 -0400 < Oxyd> rudybot: eval (char-upcase #\ffi)
2023-07-19 17:08:30 -0400 < rudybot> Oxyd: ; Value: #\ffi
2023-07-19 17:08:38 -0400 < jcowan> R6RS is wrong about titlecasing; there's an erratum that fixes it
2023-07-19 17:09:07 -0400 < dpk> (the encoding of Greek was quite a nightmare to start with, from what jcowan has told me, with competing departments of the Greek government arguing for different approaches to acute vs tonos, and a compromise having to be found)
2023-07-19 17:09:18 -0400 < jcowan> yes
2023-07-19 17:09:59 -0400 < ecraven> at least they haven't pre-encoded all variations of classical greek spelling :P
2023-07-19 17:10:10 -0400 < ecraven> sorry, combinations
2023-07-19 17:10:13 -0400 < sham1> On one hand, you wouldn't expect character encoding to be political, but on the other hand, of course it is
2023-07-19 17:10:14 -0400 < jcowan> there are three cases where titlecasing is an issue: ligatures, Croatian pseudo-ligatures, and Greek polytonic
2023-07-19 17:10:34 -0400 < dpk> i maintain that the wrong compromise was chosen and they should have let nobody have their way and just called them ACUTE, GRAVE, CIRCUMFLEX, and DIAERESIS
2023-07-19 17:10:36 -0400 < sham1> Would the Dutch "ij" just become "Ij"
2023-07-19 17:10:44 -0400 < dpk> no, IJ
2023-07-19 17:10:44 -0400 < sham1> I suppose so, but that's a tad ugly IMO
2023-07-19 17:10:49 -0400 < sham1> Oh, that's even worse
2023-07-19 17:10:52 -0400 < sham1> For titlecase?
2023-07-19 17:10:57 -0400 < dpk> them's the rules
2023-07-19 17:11:01 -0400 < ecraven> to my understanding, words are written like that in dutch
2023-07-19 17:11:01 -0400 < Zipheir> Weird.
2023-07-19 17:11:10 -0400 < dpk> well, this is another case where language specific rules exist
2023-07-19 17:11:17 -0400 < dpk> IJ counts as one letter in Dutch
2023-07-19 17:11:22 -0400 < ecraven> so IJsvrij
2023-07-19 17:11:29 -0400 < sham1> Thanks, I hate it
2023-07-19 17:11:33 -0400 < hexology> i believe that is or used to be the case in spanish in some spanish-speaking countries with "ch" and "ll"
2023-07-19 17:11:41 -0400 < dpk> don't complain to me, complain to the Dutch
2023-07-19 17:11:54 -0400 < dpk> when the Dutch write signs vertically, IJ also appears in one row together
2023-07-19 17:12:01 -0400 < Oxyd> In Czech “ch” is also one letter. And it comes after H and before I.
2023-07-19 17:12:05 -0400 < sham1> That's horrifying
2023-07-19 17:12:18 -0400 < ecraven> in the end, it's all way too complex :P
2023-07-19 17:12:23 -0400 < sham1> I mean I did know about the whole "ij" being a ligature, but that's just... ew
2023-07-19 17:12:24 -0400 < Oxyd> Yes, strings are complicated.
2023-07-19 17:12:30 -0400 < sham1> Languages are complicated
2023-07-19 17:12:36 -0400 < Oxyd> Indeed.
2023-07-19 17:12:41 -0400 < ecraven> as dpk repeatedly said, anything more complex than list-of-codepoints is ... not general
2023-07-19 17:12:46 -0400 < sham1> Strings wouldn't be so complicated if people didn't make the stuff represented in strings complicated
2023-07-19 17:13:10 -0400 < dpk> if you go around saying things like that, you'll put people like me out of a job
2023-07-19 17:13:10 -0400 < jcowan> If everybody just used the 27 basic Latin characters, things would be very simple indeed!
2023-07-19 17:13:35 -0400 < Oxyd> English spelling is what happens when you try to restrict people to 26 letters.
2023-07-19 17:13:38 -0400 < ecraven> jcowan: well, dutch does that, and see above :P
2023-07-19 17:13:39 -0400 < sham1> But due to hysterical raisins going all the way back to cuneiforms, this stuff is just complex
2023-07-19 17:13:52 -0400 < ecraven> Oxyd: Shavian looks nice though :D
2023-07-19 17:13:53 -0400 < sham1> No, English spelling is what happens when you make it bloody French
2023-07-19 17:14:15 -0400 < sham1> That's where a lot of the... weird comes from
2023-07-19 17:14:23 -0400 < jcowan> Oxyd: It would be straightforward technically to spell English decently (as well as French, say) without any new letters.
2023-07-19 17:14:47 -0400 < sham1> No one can agree to a spelling reform, and TBF most proposals are terrible in their own ways
2023-07-19 17:15:12 -0400 < ecraven> I don't think that'll ever happen, for the same reason why everybody keeps using Atlassian :P
2023-07-19 17:15:22 -0400 < ecraven> it just costs too much to re-educate everyone
2023-07-19 17:15:46 -0400 < sham1> At least it's not Tibetan... or the Mongol script which goes from top-to-bottom and breaks basically every website ever
2023-07-19 17:16:57 -0400 < sham1> I recall seeing an attempt of having Wikipedia in the Mongol script and it was gloriously broken
2023-07-19 17:17:37 -0400 < sham1> It no longer exists it seems, sadly
2023-07-19 17:17:42 -0400 < ecraven> hehe, I tried learning to read Tibetan once..
2023-07-19 17:17:59 -0400 < ecraven> the mongolian president's website has the vertical script, I think
2023-07-19 17:18:36 -0400 < ecraven> https://president.mn/mng/, then hit the MNG button on the upper right
2023-07-19 17:18:56 -0400 < ecraven> that actually works decently well
2023-07-19 17:19:16 -0400 < sham1> It just gave me the vertical script automatically
2023-07-19 17:19:25 -0400 < ecraven> ah, that link includes mng, right
2023-07-19 17:19:40 -0400 < sham1> And yeah, it works fine since it's designed that way, but it breaks my brain since I use the latin script daily and so that's natural
2023-07-19 17:19:50 -0400 < jcowan> Fourscor and seven years ago our faathers brought forth, on this continent, a new nation, conceeved in liberty and deddicated to the proposition that all men are creäted equal. Now we are engaged in a grait civil war, testing whether that nation, or any nation so conceeved, and so deddicated, can long endure. We are met on a grait battle-feeld in that war. We have cum to deddicate a portion of that feeld, as a final resting place for
2023-07-19 17:19:50 -0400 < jcowan> those who here gave their lives, that that nation might liv. It is altogether fitting and propper that we should do this. But in a larger senss we cannot deddicate, we cannot consecrate, we cannot hallo this ground. The brave men, living and ded, who struggled here, have consecrated it far abuv our poor power to add or detract. The world will little note, nor long remember, what we say here, but it can never forget what they did here.
2023-07-19 17:19:50 -0400 < jcowan> It is for us the living, rather, to be deddicated to the grait task remaining befor us that from these onored ded we take increased devotion to that cause for which they gave the last fuul mesure of devotion - that we here highly resolv that these ded shall not have died in vain, that this nation, under God, shall have a new birth of freedom, and that guvernment of the peeple, by the peeple, for the peeple, shall not perrish from the
2023-07-19 17:19:50 -0400 < jcowan> erth.
2023-07-19 17:20:01 -0400 < sham1> I mean, the script *is* pretty
2023-07-19 17:20:41 -0400 < ecraven> it also fits the language, unlike .. the Tibetan script :P
2023-07-19 17:20:45 -0400 < sham1> yeagh
2023-07-19 17:20:51 -0400 < sham1> Well, I would hope so
2023-07-19 17:21:03 -0400 < sham1> Meanwhile Wikipedia: https://incubator.wikimedia.org/wiki/Wp/mvf/%E1%A0%A5%E1%A0%AA%E1%A0%A6%E1%A0%B7_%E1%A0%AE%E1%A0%A4%E1%A0%A8%E1%A0%AD%E1%A0%AD%E1%A0%A4%E1%A0%AF_%E1%A0%A6%E1%A0%A8_%E1%A0%A5%E1%A0%AA%E1%A0%A1%E1%A0%B7%E1%A0%A1%E1%A0%B2%E1%A0%A1%E1%A0%BA%E1%A0%A1%E1%A0%A8_%E1%A0%B5%E1%A0%A0%E1%A0%B0%E1%A0%A0%E1%A0%AC%E1%A0%A4_%E1%A0%A3%E1%A0%B7%E1%A0%A4%E1%A0%A8
2023-07-19 17:21:04 -0400 < rudybot> https://teensy.info/VpHBs2z2jE
2023-07-19 17:21:14 -0400 < sham1> I'm surprised that link fitted
2023-07-19 17:21:36 -0400 < ecraven> why is it "grait" but not "consecrait".. isn't that the same sound?
2023-07-19 17:22:20 -0400 < sham1> And okay, the Wikipedia layout isn't *too bad* but it was clearly designed for LTR (and RTL can piggy-back on that)
2023-07-19 17:23:01 -0400 < jcowan> ecraven: Minimum change.  "Great" would rhyme with "seat", so must be fixed.
2023-07-19 17:23:02 -0400 < ecraven> jcowan: that is actually not as bad as I was expecting ;)
2023-07-19 17:23:08 -0400 < sham1> "deddicated" wait, English doesn't have phonemic long vowels, does it?
2023-07-19 17:23:19 -0400 < jcowan> Long in the sense of quantity, no.
2023-07-19 17:23:23 -0400 < ecraven> jcowan: also, isn't fuul rather like "fool", due to the long vowel?
2023-07-19 17:23:24 -0400 < sham1> Or long consonants as it may be
2023-07-19 17:23:46 -0400 < ecraven> well, full vs. fool is phonemic vowel length, right?
2023-07-19 17:23:58 -0400 < jcowan> "Long" and "short" are used instead of "tense" and "lax" for hysterical raisins.  No long consonants, so doubling is used to indicate laxness.
2023-07-19 17:24:09 -0400 < Oxyd> Sit — seat. Lid — lead. Fit — feet. Many such cases.
2023-07-19 17:24:15 -0400 < jcowan> ecraven: Not in most accents: it is lax vs tense
2023-07-19 17:24:50 -0400 < ecraven> jcowan: but there are accents where the vowel is the same, only differing in length, aren't there? (for this specific pair of words)
2023-07-19 17:24:53 -0400 < jcowan> Since there is no default way to distinguish between tense and lax "oo", "uu" is artificially used for the matter.
2023-07-19 17:25:29 -0400 < jcowan> There are accents where quantity matters, but they don't match the ancient quantities.  e.g. in AusE "cup" is short, "carp" is long
2023-07-19 17:25:30 -0400 < dpk> alas, no English speaker today will accept the spelling 'cum' for 'come'. (many people in my experience seem to think the two are lexically distinct and regard the latter spelling as incorrect when used in the sense of the former, despite the past tense of the former also being 'came')
2023-07-19 17:26:03 -0400 < jcowan> Yes, I've proposed adding that to the exceptions list
2023-07-19 17:26:12 -0400 < sham1> Yeah no
2023-07-19 17:26:13 -0400 < Oxyd> I once read a book by Stephen King who used the spelling “come” for the fluid. And it was confusing to me.
2023-07-19 17:26:28 -0400 < sham1> They're interchangeable in some sense
2023-07-19 17:26:35 -0400 < wasamasa> rudybot: the real horror was his writing, you see
2023-07-19 17:26:36 -0400 < rudybot> wasamasa: Sharknado was directed for film studio The Asylum by Anthony C. Ferrante, whose previous directing credits include the horror film Boo, and written by Thunder Levin, whose previous writing credits include the film Mutant Vampire Zombies from the 'Hood!.
2023-07-19 17:26:44 -0400 < ecraven> I came across Cumingtonite today, interesting mineral
2023-07-19 17:27:00 -0400 < sham1> Anyway, I don't really understand the difference between tense and lax vowels
2023-07-19 17:27:01 -0400 < wasamasa> can it be found on Pen Island?
2023-07-19 17:27:22 -0400 < sham1> Wikipedia for example used the examples of "beet" vs "bit"
2023-07-19 17:28:05 -0400 < sham1> But to me it just feels more like vowel length. I dunno, maybe it's just the fact that native language has phonemic vowel and consonant length and so it's how I produce those different sounds
2023-07-19 17:28:59 -0400 < Oxyd> Well, it's length plus other aspects.
2023-07-19 17:29:22 -0400 < ecraven> beet is more front than bit, right?
2023-07-19 17:29:49 -0400 < jcowan> sham1: TRAP, DRESS, KIT, LOT, STRUT, FOOT are lax; PALM, FACE, FLEECE, GOAT, THOUGHT, GOOSE are tense
2023-07-19 17:30:10 -0400 < jcowan> ecraven: yes, but for me they have the same length.
2023-07-19 17:30:43 -0400 < jcowan> AmE (and ScE) don't have phonemic vowel length; RP locks length to quality; AusE has phonemic length
2023-07-19 17:31:48 -0400 < jcowan> "bid" is short, "beard" is long, e.g.
2023-07-19 17:32:31 -0400 < sham1> For example the words "tuli" (fire) and "tuuli" (wind) only differ by the /u/ being longer in the second one. And similarly "tulli" (customs) with the /l/
2023-07-19 17:32:44 -0400 < jcowan> Right.
2023-07-19 17:33:02 -0400 < ecraven> that's finnish, right?
2023-07-19 17:33:19 -0400 < sham1> I suppose those could be explained in terms of laxness Vs tense, but usually those are seen as the vowel and consonant lengths
2023-07-19 17:33:23 -0400 < sham1> Yes it is
2023-07-19 17:33:59 -0400 < jcowan> only 8 vowel qualities, vs. 22 in English (dialect-dependent)
2023-07-19 17:34:31 -0400 < jcowan> of course Swedish has about 19 vowel qualities *and* length
2023-07-19 17:34:32 -0400 < Oxyd> Imagine trying to spell a 22-vowel language using just 26 letters.
2023-07-19 17:35:09 -0400 < sham1> Yeah, Swedish is interesting since it has a pitch accent. Well, Swedish in Sweden does. Swedish in Finland doesn't, or at least not as much
2023-07-19 17:35:12 -0400 < ecraven> I guess that in the end it never is *just* vowel length.. to my understanding, even in sanskrit Pāṇini "a" has a different quality than "ā"
2023-07-19 17:35:15 -0400 < jcowan> Just means you need some digraphs and a way of breaking them (historically diaeresis, more recently hyphen) as in "re-enter"
2023-07-19 17:35:59 -0400 < Oxyd> If at least there was a 1-1 correspondence between those digraphs and vowels.
2023-07-19 17:37:42 -0400 < ecraven> it's been a fun evening, thank you all for the discussion and input, much to think about. I'll hit the bed :) good night and sleep well!
2023-07-19 17:45:26 -0400 < sham1> Sleep tight!
2023-07-19 17:46:10 -0400 < sham1> Anyway yeah, strings are complicated because language is complicated because the way people communicate is complicated because the world is complicated because…
2023-07-19 17:47:13 -0400 < sham1> Also doesn't help that indicating the language to use in software is complicated because locales and whatnot
2023-07-19 17:49:54 -0400 < sham1> Not to mention that for example the way locales work in C and POSIX and the like is… not good
2023-07-19 17:51:10 -0400 < sham1> As to how closely Scheme ought to follow the way the surrounding platform handles it, I'm not sure. But at least for FFI kinda stuff it does need to interact with that and so it can be an issue
2023-07-19 17:53:32 -0400 < Oxyd> For FFI you probably want UTF-8. Unless you're Kawa, in which case you want UTF-16.
2023-07-19 17:54:27 -0400 < sham1> Well sure, you'd send over bytevectors with $ENCODING, or more likely have the FFI implementation do that
2023-07-19 18:14:43 -0400 < jcowan> Don't forget IronScheme, which is also UTF-16
2023-07-19 18:25:07 -0400 -!- daviid` is now known as daviid
2023-07-19 22:17:16 -0400 < luk36> Hello, newbie here. I wonder how scheme implementations compile large list literals? I mean, do they somehow store them in binary, or just store some hints to generate them at run-time, or something else? I'm working on a toy compiler and my code size blows up on large lists, so I want to learn some real-world solutions.
2023-07-19 22:24:31 -0400 < gwatt> luk36: How large are the lists you're talking about, and how big is the resulting code size? Does the code size scale linearly to the list size?
2023-07-19 22:32:07 -0400 < luk36> Not so large, just hundreds of leaves. My code size is linear to list size, but it also introduces linearly many variables which put stress on my register allocator
2023-07-19 22:36:00 -0400 < Zipheir> I doubt most compilers do much for large list literals.
2023-07-19 22:36:33 -0400 < Zipheir> List random access is rare, so it doesn't seem like vectorizing them or something would be worth the trouble.
2023-07-19 22:39:02 -0400 < aeth> https://en.wikipedia.org/wiki/CDR_coding
2023-07-19 22:39:15 -0400 < aeth> not particularly popular in modern Lisps/Schemes, though
2023-07-19 22:40:00 -0400 < aeth> because, yes, when people care they mostly just use vectors instead
2023-07-19 22:40:21 -0400 < Zipheir> It wouldn't save space, in any case.
2023-07-19 22:40:44 -0400 < Zipheir> Oh, CDR coding would.
2023-07-19 22:41:28 -0400 < luk36> oh, thanks! Anything better than expanding to cons-es is OK for me
2023-07-19 22:44:36 -0400 < Zipheir> Conses are still quite space-efficient.
2023-07-19 22:45:17 -0400 < Zipheir> Or, rather, most implementations have very tight cons representations.
2023-07-19 22:45:47 -0400 < skeemer> people i was reading this https://matt.might.net/articles/programming-with-continuations--exceptions-backtracking-search-threads-generators-coroutines/
2023-07-19 22:45:48 -0400 < rudybot> https://teensy.info/kv9b0fJg1b
2023-07-19 22:46:01 -0400 < skeemer> but i cannot understand what is the meaning of writing "define (void)"
2023-07-19 22:46:06 -0400 < skeemer> i have never seen this syntax
2023-07-19 22:46:20 -0400 < skeemer> what does the name of the functioni n parenthesis mean?
2023-07-19 22:47:33 -0400 < aeth> You can, if you're writing your own implementation and know it helps you internally, try implementing CDR coding (at least for your own gigantic list literals, if you think they're necessary)
2023-07-19 22:47:37 -0400 < aeth> but you won't really see it in a modern Lisp/Scheme
2023-07-19 22:47:47 -0400 < Zipheir> skeemer: (define (f a b c ...) ...) is syntactic sugar for (define f (lambda (a b c ...) ...))
2023-07-19 22:48:24 -0400 < Zipheir> luk36: Why are there list literals, though?
2023-07-19 22:49:04 -0400 < skeemer> ok but then (define (void) is the same as (define void (lambda () ) " ??
2023-07-19 22:49:13 -0400 < Zipheir> skeemer: TLS doesn't use (define (f ...) ...) syntax, but you should get used to it; everybody else does.
2023-07-19 22:49:20 -0400 < Zipheir> skeemer: Yes.
2023-07-19 22:49:43 -0400 < Zipheir> skeemer: It's called a thunk.
2023-07-19 22:49:53 -0400 < Zipheir> (AKA a procedure with no arguments.)
2023-07-19 22:49:58 -0400 < skeemer> Zipheir, thanks but then what does the function void does there?
2023-07-19 22:50:06 -0400 < luk36> Zipheir oh, maybe I didn't describe the problem clearly. I'm looking for a way to represent list literals in compiled static files
2023-07-19 22:50:16 -0400 < skeemer> i don't understand, no parameters and  then says if #f #t
2023-07-19 22:50:23 -0400 < skeemer> so what's the sense of such a thing
2023-07-19 22:50:34 -0400 < Zipheir> skeemer: It returns a useless value.
2023-07-19 22:50:48 -0400 < skeemer> what does it return actually ?
2023-07-19 22:50:59 -0400 < skeemer> does it return #f ?
2023-07-19 22:51:05 -0400 < Zipheir> skeemer: Try evaluating (if #f #t) and see.
2023-07-19 22:51:34 -0400 < skeemer> complains says i am missing else
2023-07-19 22:51:39 -0400 < Zipheir> luk36: OK. Are you trying to efficiently compile list literals, or does your compiler emit them?
2023-07-19 22:51:43 -0400 < skeemer> ok i am going to sleep but i will tryagain tomorrow
2023-07-19 22:51:47 -0400 < skeemer> thanks in the meanwhile
2023-07-19 22:51:49 -0400 < Zipheir> skeemer: What impl.?
2023-07-19 22:51:59 -0400 < skeemer> racket
2023-07-19 22:52:17 -0400 < Zipheir> Yeah, try it with #!r6rs.
2023-07-19 22:52:24 -0400 < skeemer> ok i tried in chez
2023-07-19 22:52:32 -0400 < skeemer> and it does not return anything
2023-07-19 22:52:33 -0400 < Zipheir> You won't be able to run Scheme code in Racket without changes.
2023-07-19 22:52:46 -0400 < luk36> Zipheir now it just expand them to conses
2023-07-19 22:52:56 -0400 < skeemer> Zipheir, i have noticed
2023-07-19 22:53:59 -0400 < skeemer> Zipheir, what scheme do you use these days ? is there one who has a nice data frame/ data analysis module ?
2023-07-19 22:54:06 -0400 < skeemer> something like pandas in python or R
2023-07-19 22:54:21 -0400 < Zipheir> skeemer: It would be Racket, if there is such a thing.
2023-07-19 22:54:31 -0400 < Zipheir> I use Chez or CHICKEN, for the most part.
2023-07-19 22:55:37 -0400 < Zipheir> luk36: I meant that large list literals are probably rare enough that you don't have to worry about CDR coding.
2023-07-19 22:55:50 -0400 < skeemer> Zipheir, is there any nice pakcage manager for chez ?
2023-07-19 22:55:53 -0400 < skeemer> do you use akku?
2023-07-19 22:56:21 -0400 < Zipheir> No, I haven't tried it. I just installed chez-srfi, which is all I need at the moment.
2023-07-19 22:57:30 -0400 < Zipheir> luk36: Of course, if you're targeting some very low-memory environment, it might be worth it. You might look at chibi-scheme, which puports to be super low in space usage.
2023-07-19 22:58:54 -0400 < luk36> OK, I see.
2023-07-19 22:59:03 -0400 < Zipheir> skeemer: (if #f #t) is required to return a value, though what it is is unspecified.
2023-07-19 22:59:03 -0400 < luk36> I'll take a look
--- Day changed Thu Jul 20 2023
2023-07-20 01:51:59 -0400 < mnieper> skeemer: Most Schemes define a value "VOID", which they return when the report leaves the returned value unspecified.
2023-07-20 01:52:44 -0400 < mnieper> In particular, (if #f #f) works for most Schemes to produce this value, which, however, is not part of any standard.
2023-07-20 01:53:03 -0400 < mnieper> The REPL printer usually surpresses printing this value.
2023-07-20 01:53:49 -0400 < mnieper> In Chez, which defines a procedure `(void)' returning this value, we can see the following at the REPL:
2023-07-20 01:53:58 -0400 < mnieper> > (values 1 (void) 3)
2023-07-20 01:54:00 -0400 < mnieper> 1
2023-07-20 01:54:01 -0400 < mnieper> 3
2023-07-20 01:54:26 -0400 < sham1> Well the void really isn't a value as such
2023-07-20 01:55:18 -0400 < mnieper> I would say, the "VOID" value is mostly a historical artifact.  Since R5RS, we have multiple values, including zero values.  When there is nothing sensible to return, I usually write `(values)'.
2023-07-20 01:55:29 -0400 < mnieper> sham1: Guten Morgen!
2023-07-20 01:55:34 -0400 < sham1> Good morning!
2023-07-20 01:55:43 -0400 < mnieper> What do you mean by "VOID" isn't a value as such?
2023-07-20 01:57:53 -0400 < sham1> Well I mean exactly that. At most I'd say that it's a placeholder
2023-07-20 02:01:17 -0400 < mnieper> In those Schemes that define it, it behaves as any other value.  It's no more special than the, say, EOF value (or a EOF value).
2023-07-20 02:14:45 -0400 < aeth> I don't like this. This is my least favorite part of Scheme.
2023-07-20 02:15:16 -0400 < aeth> Returning some #<nonsense> (and it has a different name in every implementation) while technically correct makes a lot of return values useless, which doesn't make sense in an expression language
2023-07-20 02:16:01 -0400 < aeth> even (values) would be better
2023-07-20 02:16:54 -0400 < aeth> because then at least it's not a new thing that's implementation-specific
2023-07-20 02:17:58 -0400 < sham1> R7RS specified itself into a corner wrt. that, sadly
2023-07-20 02:18:15 -0400 < aeth> R5RSes do this, too...
2023-07-20 02:18:28 -0400 < aeth> although most probably converted to 7 by now
2023-07-20 02:18:46 -0400 < sham1> So you will need to have #<nonsense> sadly. And one could even have it so that it's something you get from (values) somehow
2023-07-20 02:19:00 -0400 < mnieper> (values) is a lot better because the implementation can then warn you when you try to process something meaningless.
2023-07-20 02:19:50 -0400 < mnieper> R6RS got it 3/4 right. It allows "(values)" (good), but doesn't enforce it (not so good).
2023-07-20 02:20:17 -0400 < aeth> (values) would also sort of parallel (+) => 0
2023-07-20 02:20:21 -0400 < aeth> in that it's needlessly elegant
2023-07-20 02:20:55 -0400 < aeth> more of a "hey, that's neat" than a necessary thing
2023-07-20 02:22:34 -0400 < mnieper> I am more concerned with code like this: https://paste.debian.net/plain/1286402
2023-07-20 02:23:50 -0400 < mnieper> When I use it in Schemes (like R7RS) that must return a value, I will get an error like "#<void> is not a hashtable" possible very late.
2023-07-20 02:23:59 -0400 < mnieper> Making it hard to debug.
2023-07-20 02:24:13 -0400 < aeth> heh, CL would probably make it something like 2
2023-07-20 02:24:46 -0400 < sham1> CL:NIL
2023-07-20 02:24:47 -0400 < mnieper> That's even worse! If, on the other hand, `(hashtable-set! ...)' returned no values, already trying to bind the result of `filled-hashtable' would raise an exception.
2023-07-20 02:25:07 -0400 < aeth> sham1: CL often defaults to returning NIL, but often also returns one of the input
2023-07-20 02:25:18 -0400 < mnieper> The "2", I meant with "worse".
2023-07-20 02:25:24 -0400 < aeth> in this case, there isn't a direct equivalent, but it probably would be 2 if you were to define a direct equivalent from SETF
2023-07-20 02:25:45 -0400 < aeth> but, yeah, random NILs in CL are annoying, too
2023-07-20 02:26:14 -0400 < aeth> don't break as much because NIL-is-false so it's basically returning #f instead of #<void>
2023-07-20 02:26:22 -0400 < aeth> but in this case that just means you'll find out even later!
2023-07-20 02:26:39 -0400 < mnieper> Which is even worse in a dynamically-typed language.
2023-07-20 02:28:04 -0400 < mnieper> I also want to remove one-armed "if" from the language.  More often than not, you forgot the extra arm and wonder about some late "VOID" value.  And if you really need a one-armed "if", we have `when' and `unless'.
2023-07-20 02:28:22 -0400 < aeth> yes, it's bad style to use that instead of when
2023-07-20 02:29:58 -0400 < aeth> the solution in CL (or at least mine, which obviously is going to be controversial in a dynamically typed language) is generally to add some types to things where action-at-a-distance is an issue (i.e. a random wrong value showing up on the other side of thousands of lines of code)
2023-07-20 02:30:45 -0400 < aeth> Scheme doesn't even really have portable types, though, just things that solve predicates, some of which basically require being runtime (so they basically would be CL's SATISFIES types)
2023-07-20 02:33:09 -0400 < aeth> I personally treat r7rs as having an implicit type system of types that share the name of the predicate
2023-07-20 02:33:31 -0400 < sham1> That is probably the best way to consider it
2023-07-20 02:33:42 -0400 < aeth> for instance, a cons pair is a pair?
2023-07-20 02:33:46 -0400 < mnieper> Scheme has record types.  Instead of, say, using overly generic pairs to model a particular type of abstract pair, it is much better to define a specific record.
2023-07-20 02:33:46 -0400 < aeth> as in, I write it as "pair?"
2023-07-20 02:34:02 -0400 < mnieper> Like (define-record-type result (fields player points)).
2023-07-20 02:34:25 -0400 < sham1> Isn't that an incomplete record?
2023-07-20 02:34:39 -0400 < mnieper> sham1: In what sense?
2023-07-20 02:34:44 -0400 < ecraven> that's r6rs record-type syntax, isn't it?
2023-07-20 02:34:54 -0400 < mnieper> Yes, of course.
2023-07-20 02:35:01 -0400 < sham1> Ah, fair enough
2023-07-20 02:37:39 -0400 < mnieper> Because we have records, I am convinced that no one needs mutable pairs anymore and that Scheme would become a better language without.  When you need a mutable pair-like type, define a domain-specific record, which also helps documenting and debugging your code.
2023-07-20 02:38:33 -0400 < wasamasa> (define-record cons ar dr)
2023-07-20 02:38:44 -0400 < aeth> mnieper: In that case, I treat the record name and the predicate as the same by convention. Not like the record name shows up anywhere important.
2023-07-20 02:39:15 -0400 < aeth> Or at least to avoid name collisions portably because Scheme is very Lisp-1 and doesn't like multiple names... something like e.g. (define-record-type <foo?> (foo) foo?)
2023-07-20 02:39:26 -0400 < aeth> to copy the <...> from the spec
2023-07-20 02:40:04 -0400 < aeth> Since in Scheme world, the type is only meaningfully expressed by its predicate, so you might as well name it by the only observable property, its predicate
2023-07-20 02:40:24 -0400 < aeth> so the cons would be a <pair?> I suppose
2023-07-20 02:40:27 -0400 < mnieper> The way as it stands now, all list-processing code has to deal with the possiblity of a list being modified in-between and of a list actually being circular. Because 0.1% of the code might want to use mutable pairs.
2023-07-20 02:41:18 -0400 < aeth> to be fair, that's probably closer to 1% because the standard is so minimalist and the most straightforward way to do a lot of list creation things is mutation (even if you never mutate it again)
2023-07-20 02:41:19 -0400 < mnieper> aeth: The <...>-"convention" clashes with the identifier generation of R6RS's `define-record-type'.
2023-07-20 02:41:58 -0400 < Zipheir> aeth: Sometimes I'd like an interpreter/compiler option to incorporate code which raises an exception if #<unspecified> or #<void> or whatever is actually used. But "usage" may be hard to determine.
2023-07-20 02:42:46 -0400 < mnieper> aeth: Do you have a good example for a list creation that uses `set-cXr!' for convenience?
2023-07-20 02:46:32 -0400 < aeth> mnieper: just in general, lists are annoyingly built backwards
2023-07-20 02:46:38 -0400 < aeth> so you set-cdr! or you reverse at the end
2023-07-20 02:46:55 -0400 < aeth> consider e.g. implementing your own `map`
2023-07-20 02:48:12 -0400 < mnieper> Zipheir: In most of the cases, this would not be needed if procedures returned no value instead of a result having no meaning.  But I see that it has its niche, like for `(make-vector 1000)'.
2023-07-20 02:48:39 -0400 < mnieper> In that case, we may want an exception to be raised when trying to retrieve an uninitialized vector element.
2023-07-20 02:48:48 -0400 < Zipheir> Right.
2023-07-20 02:49:51 -0400 < mnieper> aeth: My own `map' wouldn't use list mutation.  Mutating can interfere with the garbage collector, so a mutating version is probably slower.
2023-07-20 02:49:58 -0400 < mnieper> And it is harder to understand and to debug.
2023-07-20 02:50:53 -0400 < Zipheir> And as Olin Shivers says, "don't stand on your head to iterate. Recurse, when natural."
2023-07-20 02:51:11 -0400 < Zipheir> Agh, bed time. Good night/morning, all.
2023-07-20 02:52:16 -0400 < mnieper> aeth: It mutating `map' is even wrong in the presence of call/cc, which can detect the mutation.
2023-07-20 02:52:22 -0400 < mnieper> Zipheir: Good night!
2023-07-20 02:57:45 -0400 < mnieper> aeth: Having thought about building lists iteratively from left to right a bit more, I still don't think that `set-cdr!' is the right abstraction (it's a hammer that can also launch nuclear weapons).  Use SRFI 158's `list-accumulator' instead.
2023-07-20 02:58:11 -0400 < mnieper> Internally, the Scheme system may use whatever mutation it likes to implement `list-accumulator'.
2023-07-20 02:58:27 -0400 < aeth> do you implement that SRFI with set-cdr! though
2023-07-20 02:58:48 -0400 < mnieper> The portable implementation can use `reverse', for example.
2023-07-20 03:00:00 -0400 < mnieper> Or (possible better for large lists) a flexvector followed by vector->list (which can generate a list with optimal cache locality).
2023-07-20 03:01:07 -0400 < mnieper> s/possible/possibly
2023-07-20 03:02:02 -0400 < mnieper> That said, I have my issues with accumulators but, thankfully, a fully functional interface is also possible.
2023-07-20 03:03:46 -0400 < mnieper> A hypothetical procedure "list-collector" would return two values DONE and NEXT.
2023-07-20 03:04:31 -0400 < aeth> yeah, but at some level a functional interface may or may not use set-cdr! to implement it, even if it is observably functional
2023-07-20 03:04:32 -0400 < mnieper> DONE called with no arguments would return the collected list. NEXT called with an element would return a new pair DONE and NEXT.
2023-07-20 03:05:07 -0400 < rgherdt> did a scan of some implementations here: all of them have LOTS of set-car!'s and set-cdr!'s
2023-07-20 03:05:49 -0400 < mnieper> rgherdt: In R<6RS, you had no records.
2023-07-20 03:05:58 -0400 < rgherdt> disallowing it would probably push r7rs large towards the reality of a standard without implementations
2023-07-20 03:06:39 -0400 < mnieper> rgherdt: We can't disallow them in R7RS; Scheme would just be a much better language without.
2023-07-20 03:06:57 -0400 < mnieper> But we can deprecate them.
2023-07-20 03:07:19 -0400 < rgherdt> ok, I see your point
2023-07-20 03:07:28 -0400 < mnieper> But even if they were disallowed, that wouldn't reduce the number of implementations.
2023-07-20 03:07:37 -0400 < mnieper> Only the number of valid programs.
2023-07-20 03:08:38 -0400 < aeth> technically speaking, the implementation could set-cdr! even if the user can't
2023-07-20 03:08:40 -0400 < mnieper> aeth: My point is that any interface, functional or not, doesn't need `set-cdr!' to build a list.
2023-07-20 03:09:02 -0400 < mnieper> And "for efficiency" is no argument here because that really depends on the underlying implementation.
2023-07-20 03:09:07 -0400 < sham1> You need something like a set-cdr! for example with (read) because of datum labels
2023-07-20 03:09:21 -0400 < sham1> Even if only as an implementation internal thing
2023-07-20 03:09:28 -0400 < aeth> sham1: yes, but (read) is provided, not implemented by the user
2023-07-20 03:09:43 -0400 < aeth> so what you get is basically, a ton more complexity
2023-07-20 03:10:12 -0400 < mnieper> sham1: removing set-cdr! but letting the reader create circular lists doesn't solve much.
2023-07-20 03:10:42 -0400 < mnieper> So #1=(#1#) has to go away at the same time.
2023-07-20 03:11:12 -0400 < aeth> Does that really exist in the wild outside of #commonlisp's IRC topic? (And that's Common Lisp, not Scheme!)
2023-07-20 03:11:26 -0400 < aeth> Only time I've seen something like that is to express shared state, but not circularly
2023-07-20 03:12:35 -0400 < sham1> I like the relative elegance of #1=(a b c d . #1#) for a circular buffer
2023-07-20 03:12:57 -0400 < sham1> Easier to "iterate" than with a vector+index
2023-07-20 03:13:39 -0400 < mnieper> Every single list processing procedure has to pay for this "relative elegance". I am not even mentioning the handling for rest arguments.
2023-07-20 03:13:53 -0400 < mnieper> This is just bad language design.
2023-07-20 03:14:15 -0400 < ecraven> mnieper: so how *would* you build circular lists then?
2023-07-20 03:14:21 -0400 < sham1> Probably wouldn't
2023-07-20 03:14:49 -0400 < mnieper> Yes, circular lists would be removed.
2023-07-20 03:14:55 -0400 < mnieper> They are not even lists. :)
2023-07-20 03:15:11 -0400 < mnieper> sham1: circular-generator from SRFI 158
2023-07-20 03:15:26 -0400 < ecraven> hehe, well my definition of list is "a pair whose cdr is either a pair or '()", and that includes circular lists :D
2023-07-20 03:15:28 -0400 < sham1> Circular streams?
2023-07-20 03:15:50 -0400 < ecraven> reasonable enough, we can't have circular bytevectors either.. (or can we? :P)
2023-07-20 03:16:18 -0400 < mnieper> I mean, circular data structures won't go away. We still have records with mutable fields.
2023-07-20 03:17:05 -0400 < mnieper> The problem is that Scheme currently has no type for a (proper) immutable list.
2023-07-20 03:17:18 -0400 < mnieper> It wants to have such a type.
2023-07-20 03:17:35 -0400 < mnieper> E.g. for the use as rest arguments or for procedures like `map'.
2023-07-20 03:19:07 -0400 < mnieper> The situation can be remedied by (A) making pairs immutable or by (B) defining a completely new immutable list-type.
2023-07-20 03:20:01 -0400 < mnieper> The problem with (B) is that this would require heavy changes to the semantics of Scheme because rest arguments are hard-wired and they would want to use this new type.
2023-07-20 03:20:23 -0400 < mnieper> On the other hand, Racket has shown that (A) is a very viable option.
2023-07-20 03:20:55 -0400 < mnieper> With immutable pairs, one can even implement `list?' in O(1).
2023-07-20 03:21:27 -0400 < rgherdt> but in Racket srfi's are defined in terms of immutable lists, rendering it useless for writing practical r7rs+srfi's programs
2023-07-20 03:23:20 -0400 < mnieper> Why?
2023-07-20 03:23:41 -0400 < rgherdt> if I declare #lang r7rs, I can't use srfi/1, for example
2023-07-20 03:23:51 -0400 < rgherdt> because r7rs lists are mutable
2023-07-20 03:23:58 -0400 < rgherdt> this was discussed here: https://github.com/lexi-lambda/racket-r7rs/issues/3
2023-07-20 03:24:58 -0400 < mnieper> Don't use #lang r7rs.
2023-07-20 03:25:40 -0400 < rgherdt> I know, even better, I don't use racket
2023-07-20 03:26:01 -0400 < mnieper> #lang r7rs doesn't mean anything about the success/failure of Racket's approach because with #lang r7rs you get back mutable pairs.
2023-07-20 03:26:31 -0400 < mnieper> The problem you point at arises because srfi/1 is written for Racket, not for its R7RS emulation.
2023-07-20 03:26:51 -0400 < mdhughes> I really dislike this "let's make everything more complex to fit some purity standard" thing. Let people have their string-set!, mutable pairs, etc. It's no skin off your back.
2023-07-20 03:27:23 -0400 < ecraven> mnieper: how do you implement list? in O(1) with immutable pairs?
2023-07-20 03:27:24 -0400 < mnieper> mdhughes: It is about making things less complex.
2023-07-20 03:28:01 -0400 < mnieper> ecraven: The internal pair representation could include a bit whether its cdr is a well-formed list.
2023-07-20 03:28:15 -0400 < ecraven> (random remark, emacs links `map' fine, but `list?' doesn't seem to match the regex it uses...)
2023-07-20 03:29:04 -0400 < ecraven> mnieper: :D that sounds like a start towards cdr-coding
2023-07-20 03:29:10 -0400 < mdhughes> Mutation is a useful, simple tool. Having to make a new record with its overhead for a thing that holds 2 references just like a pair is excessive.
2023-07-20 03:29:45 -0400 < ecraven> mdhughes: do records have more overhead than pairs? I'd guess many implementations have about the same?
2023-07-20 03:30:16 -0400 < sham1> You'd need a separate GC pool if you wanted to make it so that pairs don't have overhead
2023-07-20 03:30:16 -0400 < mnieper> mdhughes: The overhead is minimal, your code becomes much more self-explanatory, and Scheme still remains an impure language.
2023-07-20 03:30:58 -0400 < mdhughes> At the very least, a record is a vector, with length, class rtd, and then the values. Pairs may be tagged pointers or at least just a tag & 2 pointers.
2023-07-20 03:31:07 -0400 < mnieper> One can relatively easily encode pairs in 2 words on the heap, while a record with two fields usually takes up 3 words.
2023-07-20 03:31:14 -0400 < ecraven> sham1: might even be worth it though, if you use pairs a lot :D I think there was a paper somewhere about whether cdr-coding was worth it or not, and the conclusion was even back then (when lists were more prevalent) it wasn't actually worth the complexity
2023-07-20 03:31:26 -0400 < mdhughes> So it may double or more the memory footprint. Which on a big tree quickly gets out of cache size.
2023-07-20 03:31:47 -0400 < mnieper> mdhughes: This analysis is wrong.
2023-07-20 03:31:55 -0400 < ecraven> mdhughes: but the pairs are spread out all over memory anyway, and not inside a single cache line, right?
2023-07-20 03:31:56 -0400 < mnieper> There will be only one RTD.
2023-07-20 03:32:20 -0400 < mdhughes> If you're allocating a tree mostly at once, they'll be lumped together. There'll be some fragging as you add/delete/move.
2023-07-20 03:32:26 -0400 < sham1> Well you also need to somehow make the pair into a forwarding pointer if you're using a Cheney collector
2023-07-20 03:32:32 -0400 < mdhughes> The pointer to the RTD also takes up space.
2023-07-20 03:32:58 -0400 < mnieper> And, indeed, if you care about cache locality, work with two vectors, the vector of CARs and the vector of CDRs.
2023-07-20 03:33:11 -0400 < mnieper> mdhughes: As I said, 3 words instead of 2.
2023-07-20 03:33:28 -0400 < mnieper> And that before compiler optimization, which can lead to record type deletion.
2023-07-20 03:38:03 -0400 < mdhughes> Is that compiler optimization in the spec? Does anyone actually do it?
2023-07-20 03:39:25 -0400 < mdhughes> My poking around memory has mostly shown records as tag, length, rtd, fields. Chicken has them inside a struct which was harder to follow.
2023-07-20 03:40:09 -0400 < mdhughes> But if it's not in the spec, it's good to have one guaranteed least-wasteful way to build structures.
2023-07-20 03:40:35 -0400 < sham1> Bytevectors
2023-07-20 03:40:45 -0400 < mdhughes> It's even nicer if it's very traditional and we can use old set-cdr! code.
2023-07-20 03:40:45 -0400 < ecraven> bytevectors can't point anywhere
2023-07-20 03:40:54 -0400 < mdhughes> Also a giant pain in the ass to expand them.
2023-07-20 03:41:19 -0400 < mnieper> mdhughes: If you care about efficiency/speed, that you really want immutable pairs.
2023-07-20 03:41:29 -0400 < mdhughes> You could store length in bytes 1-4, then pointers in x*4 and cast them out in FFI. No fun.
2023-07-20 03:41:50 -0400 < mdhughes> How does immutability help me build a structure?
2023-07-20 03:41:52 -0400 < sham1> ecraven: not with that attitude
2023-07-20 03:41:58 -0400 < mdhughes> It can be infinitely fast if it does nothing!
2023-07-20 03:41:59 -0400 < ecraven> mdhughes: that won't work with the GC, who doesn't know about the pointers
2023-07-20 03:42:16 -0400 < mdhughes> ecraven: Correct, you have to manage everything. That's why nobody does that.
2023-07-20 03:42:18 -0400 < mnieper> mdhughes: Because the presence of mutability makes all of Scheme slower than in has to be.
2023-07-20 03:42:49 -0400 < mdhughes> I'm pretty sure computers have been running with mutable state for 70+ years, and it's been optimized a bit.
2023-07-20 03:43:02 -0400 < ecraven> mnieper: I don't know much about this, but when creating binary data structures (like messages for network packets), how would I do that without bytevector-u8-set! and friends? create a list of bytes and then at the end convert it to a bytevector?
2023-07-20 03:43:09 -0400 < mdhughes> Haskell's a *great* language for Haskell users.
2023-07-20 03:43:39 -0400 < mnieper> mdhughes: If, in your particular implementations, records of two fields take up more than three words on the heap, you can also use a vector of two fields. This doesn't help documenting your code (you don't seem to be interested in this aspect, anyway), but it doesn't need mutable pairs either.
2023-07-20 03:44:06 -0400 < mnieper> ecraven: There is a big misunderstanding going on.
2023-07-20 03:44:07 -0400 < mdhughes> The premise of LISP and Scheme was that it's this very practical language (family). You can be functional, or dig into RAM and do whatever.
2023-07-20 03:44:20 -0400 < mnieper> I never meant to remove mutability.
2023-07-20 03:44:40 -0400 < ecraven> mnieper: so mutating *bytevectors* is fine, the point of contention is mutating *pairs*?
2023-07-20 03:44:41 -0400 < mdhughes> ^ says, removing all the mutability tools
2023-07-20 03:44:51 -0400 < mnieper> ecraven: Yes.
2023-07-20 03:45:01 -0400 < mnieper> Because pairs currently serve double duty.
2023-07-20 03:45:32 -0400 < mnieper> To represent what are conceptually immutable proper lists (or should be) and to represent general two-element records/vectors.
2023-07-20 03:45:43 -0400 < ecraven> personally, I've never used set-cxr! when it couldn't just as easily have been replaced with something else, so I'd be fine with immutable pairs as the default.
2023-07-20 03:46:00 -0400 < mdhughes> I don't hate the Racket solution of pair/mpair, but it breaks existing code.
2023-07-20 03:46:05 -0400 < ecraven> well, we don't have specific one- or three-element records/vectors either..
2023-07-20 03:46:33 -0400 < mnieper> One-element vectors are boxes.
2023-07-20 03:47:00 -0400 < mdhughes> And makes it very hard to do some jiggery-pokery like a delete! or insert! or inline sort (those are usually better in vectors tho)
2023-07-20 03:49:43 -0400 < dpk> i thought the solution for R7RS Large was going to be that literal pairs (and maybe rest argument pairs, depending on small language compatibility) are enforced immutable, and we have icons from SRFI 116 to create immutable pairs programmatically, but those immutable pairs can be deconstructed with regular car and cdr
2023-07-20 03:49:58 -0400 < dpk> *ipair, sorry, not icons
2023-07-20 03:50:58 -0400 < aeth> I like the Common Lisp solution, where literal pairs are immutable, but not enforced, so you introduce weird bugs if you try to mutate '(1 2 3 4) with nothing to stop you :-)
2023-07-20 03:51:01 -0400 < mnieper> dpk: Making rest argument pairs immutable would break compatibility to both R6RS and R7RS-small.
2023-07-20 03:51:53 -0400 < mnieper> And it doesn't solve the problem that there many more lists that really would like to be immutable.
2023-07-20 03:52:07 -0400 < mnieper> At least not circular.
2023-07-20 03:53:22 -0400 < mnieper> SRFI 116 is a non-solution unless one invents imap, ifold, ilambda, icase-lambda, string->ilist, iapply, ...
2023-07-20 03:53:52 -0400 < dpk> but if literals are immutable, we have immutable circular lists
2023-07-20 03:53:53 -0400 < mnieper> It has somewhat the same problem SRFI 135 has.
2023-07-20 03:54:40 -0400 < dpk> yes and no, SRFI 116 was originally intended to do something which its PFNs later changed, creating a real mess
2023-07-20 03:54:41 -0400 < mnieper> dpk: See above. Deprecating set-cXr! would entail deprecating circular list literals.
2023-07-20 03:55:49 -0400 < mnieper> (The latter is not a problem in R6RS because it does not define datum labels.)
2023-07-20 03:56:09 -0400 < ecraven> see, polymorphism is nice :P :D
2023-07-20 03:56:15 -0400 < dpk> there's no reason to deprecate set-car! and set-cdr!
2023-07-20 03:56:26 -0400 < mnieper> dpk: See above.
2023-07-20 03:56:44 -0400 < mnieper> Lots of reasons IMO.
2023-07-20 03:57:12 -0400 < ecraven> we need CoW pairs :D
2023-07-20 03:58:37 -0400 < mnieper> Deprecating mutable pairs is more important than deprecating string-set! because pairs are so ubiquituous.
2023-07-20 03:59:35 -0400 < dpk> except mutable pairs don't intrinsically cause asymptotic performance headaches
2023-07-20 04:01:32 -0400 < mnieper> They do.
2023-07-20 04:01:39 -0400 < mnieper> Chain apply :)
2023-07-20 04:02:02 -0400 < mnieper> Much more common that string headaches.
2023-07-20 04:05:42 -0400 < mnieper> I also invite everyone to take a look at Chez's implementation of the standard libraries.  Perceived, 80% of the code dealing with lists is concerned with checking that proper lists are processed and not with the actual processing.
2023-07-20 04:06:22 -0400 < mnieper> So if people like mdhughes are concered about efficiency, they should be doubly concerned about the presence of mutable pairs.
2023-07-20 04:06:44 -0400 < mdhughes> I'm sure those are mostly short-circuits. "Is this a pair I see before me? Do stuff."
2023-07-20 04:07:27 -0400 < mnieper> mdhughes: `map' mustn't loop if presented with a circular list, for example.
2023-07-20 04:07:48 -0400 < mdhughes> The longer-term replacement type if you really don't want any more set-c.r! fiddling, is a real mutable list type, probably built over a record with a length & vector.
2023-07-20 04:08:07 -0400 < sham1> Replace lists with flexvecfors
2023-07-20 04:08:13 -0400 < mnieper> For example.
2023-07-20 04:08:35 -0400 < mnieper> This gives you cache locality for free.
2023-07-20 04:08:42 -0400 < mnieper> And fast random access.
2023-07-20 04:08:43 -0400 < mdhughes> Sure. And then you can have all the safety, and memory efficiency, and caching.
2023-07-20 04:08:48 -0400 < dpk> apropos of nothing, i have a half-working patch to make list? run in O(1) on immutable lists in Chibi. main reason i haven't merged it is because of https://github.com/ashinn/chibi-scheme/issues/877
2023-07-20 04:09:15 -0400 < mnieper> Ah, one of the zillion readers in Chibi.
2023-07-20 04:09:15 -0400 < mdhughes> And you'll also need a cursor type that can walk over them, to replace car/cdr looping.
2023-07-20 04:09:38 -0400 < mnieper> Or use an integer index.
2023-07-20 04:09:59 -0400 < mnieper> Or improve flexvectors by allowing views into flexvectors.
2023-07-20 04:10:40 -0400 < mdhughes> I'm always sus of views, either people make a new one on every step and churn memory, or accidentally return the view instead of the OG list.
2023-07-20 04:11:04 -0400 < mdhughes> I've had a lot of that from Java and not-so-senior devs, and it's infuriating.
2023-07-20 04:13:16 -0400 < mnieper> What if flexvector-views and flexvectors are the same type?
2023-07-20 04:13:22 -0400 < mnieper> Like Guile handles bytevectors?
2023-07-20 04:13:30 -0400 < mdhughes> Anyway, put that together with a complete set of SRFI-1 equivalents (and mostly those exist in flexvector, but not all), and shift libraries to use them. And by R8 or R9RS, pairs can be that weirdo thing for oldies.
2023-07-20 04:14:07 -0400 < mnieper> 90% of SRFI 1 deals with conceptually immutable lists.
2023-07-20 04:14:15 -0400 < mnieper> This doesn't have to be replaced.
2023-07-20 04:14:19 -0400 < mdhughes> As soon as you can return a sublist that is actually a fragment of a superlist, idiots not paying attention will fill up memory with two bytes from a 2GB list.
2023-07-20 04:14:44 -0400 < sham1> That's their problem, frankly
2023-07-20 04:15:04 -0400 < sham1> While we have things like automatic memory management, we can't make things idiot-proof franjly4
2023-07-20 04:15:09 -0400 < mdhughes> That's the best part about pairs, cdr is efficient.
2023-07-20 04:16:02 -0400 < mdhughes> A tool shouldn't *explicitly* be set up to cut your hand off if you're not watching every step of the way.
2023-07-20 04:16:08 -0400 < mdhughes> See also: C
2023-07-20 04:18:53 -0400 < ecraven> well, if lists are immutable, then list views *could* just automatically "expand" if a 2 byte view into a 2gb list exists, and the 2gb list is unreachable.. the GC (or something else) could just throw away the 2gb thing and keep those 2 bytes
2023-07-20 04:20:19 -0400 < mdhughes> How? The 2-byte view is midway into a vector (or a zipper of vectors)
2023-07-20 04:21:49 -0400 < ecraven> copy the data, throw away the old thing. if everything is immutable, no-one will notice a difference
2023-07-20 08:09:39 -0400 -!- rgherdt_ is now known as rgherdt
2023-07-20 14:13:21 -0400 < jcowan> That's how SRFI 135 works: texts are shared, but only up to a point.  "Implementations that share storage between texts must satisfy the following requirement: There is some reasonably small fixed bound on the ratio of storage used by the shared representation divided by the storage that would be used by an unshared representation."
2023-07-20 14:14:18 -0400 < jcowan> "For the sample implementations with their default configurations, the worst case arises with UTF-8, when a 1-character ASCII text retains up to 127 characters of a text that is no longer reachable, and all 127 of those retained characters lie outside Unicode's Basic Multilingual Plane (BMP). Making reasonable assumptions about the representations of records, vectors, bytevectors, and strings on a 64-bit machine, that shared text
2023-07-20 14:14:19 -0400 < jcowan> would occupy no more than about 16 times the space occupied by an unshared representation. If the retained characters were in the BMP, the shared text would occupy no more than about 8 times the space occupied by an unshared representation. If the retained characters were ASCII, the shared text would occupy no more than about 4 times the space occupied by an unshared representation. The sample implementations can be configured to
2023-07-20 14:14:19 -0400 < jcowan> reduce those worst-case bounds, most obviously by reducing the maximum number of characters that can be shared with a very short text."
2023-07-20 14:40:50 -0400 < f-a> I feel I have asked already, but then forgot. mit-scheme, I would like to bind — say — C-q to `(debug)`. Any way to do that?
2023-07-20 14:54:10 -0400 < wasamasa> mit-scheme, like many CLI programs, is blissfully unaware what control keys you type, so this would need to be solved with another abstraction on top, such as rlwrap or emacs
2023-07-20 14:55:02 -0400 < wasamasa> both should allow that
2023-07-20 14:55:12 -0400 < f-a> mhhh rlwrap, good suggestion
2023-07-20 14:57:21 -0400 < wasamasa> if you use rlwrap, you can try and see whether you can add an .inputrc entry applying to mit-scheme only
2023-07-20 14:57:35 -0400 < wasamasa> and do the equivalent of a key macro inserting "(debug)\n"
2023-07-20 17:07:20 -0400 < mfiano> I keep meaning to try this (the above discussion reminding me to put it higher in my priority queue): https://github.com/rvaiya/keyd
2023-07-20 20:00:08 -0400 -!- Netsplit *.net <-> *.split quits: mfiano, croc, micro, ello, cky, yewscion, Everything, fadein
2023-07-20 20:00:25 -0400 -!- Netsplit over, joins: micro, fadein, cky
2023-07-20 21:09:58 -0400 < mdhughes> But if you're in edwin, you can just edit edwin's bindings.
--- Day changed Fri Jul 21 2023
2023-07-21 04:22:34 -0400 < f-a> wasamasa: I followed your suggestion and added  "\C-g":     "(debug)\n"  in my .inputrc.  Works fine!
2023-07-21 09:29:22 -0400 -!- rgherdt_ is now known as rgherdt
2023-07-21 12:11:41 -0400 < mnieper> Completely off-topic: I would like to remove a watermark from a PDF. I can open the uncompressed PDF in Emacs, but as I don't know the PDF language: how am I going to find the watermark data? (no piracy, in case you wonder)
2023-07-21 12:16:01 -0400 < mdhughes> While it can be in plain text, that's really foolish watermarking. So it'll be just a repeated blob of drawing commands near the bottom of each page.
2023-07-21 12:16:31 -0400 < mdhughes> Or sometimes on a background element. Without a good PDF editor, you're not really going to succeed.
2023-07-21 12:16:32 -0400 < mnieper> It's not in plain text.
2023-07-21 12:16:44 -0400 < mnieper> It's some textual blob :)
2023-07-21 12:17:25 -0400 < mdhughes> If you have PDFPen or something like it, you can often just pick the element and delete it.
2023-07-21 12:20:20 -0400 < Zipheir> I've wondered about this, too.
2023-07-21 12:20:59 -0400 < Zipheir> In my case, I absolutely intended to share the file without permission. :)
2023-07-21 12:22:14 -0400 < mnieper> In my case, it is a proof file from Springer. It is an imposition to correct it with their watermark across every page.
2023-07-21 12:22:30 -0400 < mnieper> I would need a PDF editor on Linux.
2023-07-21 12:22:43 -0400 < Zipheir> Yeah, I've been trying to find one.
2023-07-21 12:24:19 -0400 < Zipheir> I found https://itsfoss.com/pdf-editors-linux/
2023-07-21 12:24:36 -0400 < Zipheir> Most of the real PDF editors seem to be proprietary, unfortunately.
2023-07-21 12:25:55 -0400 < Zipheir> (Actually, I mostly want to get rid of watermarks because I think they're an exceptionally stupid form of DRM.)
2023-07-21 12:28:33 -0400 < sham1> IIRC libreoffice's Draw can edit PDFs
2023-07-21 12:30:17 -0400 < mnieper> sham1: Thanks for the tip but Draw messes around with the PDF, replacing fonts, destroying formulas, etc.
2023-07-21 12:30:23 -0400 < sham1> Ah
2023-07-21 12:30:29 -0400 < sham1> Well that's not good
2023-07-21 12:31:22 -0400 < Zipheir> I didn't know that. Draw is what most sources recommend, it seems. :(
2023-07-21 12:33:04 -0400 < Zipheir> I'm sure there's a way to do it with mutool, but it involves taking the PDF apart and reassembling it.
2023-07-21 12:35:04 -0400 < sham1> I don't get why it would touch the fonts and whatnot, but I'm also not an expert in editing PDFs like this
2023-07-21 12:35:24 -0400 < mnieper> I think it converts the PDF into its internal format first.
2023-07-21 12:37:38 -0400 < Zipheir> PDF isn't exactly a format designed for editing.
2023-07-21 12:38:13 -0400 < Zipheir> I guess you're supposed to print your proofs and edit them the old fashioned way.
2023-07-21 12:38:43 -0400 < mnieper> Then I have this big fat watermark printed over it.
2023-07-21 12:41:25 -0400 < mnieper> Okay... I did some experiments with Emacs and removed the watermarks at least in Emacs' doc-view.
2023-07-21 12:41:38 -0400 < mnieper> Now evince tells me the PDF is corrupted, so I have to solve this...
2023-07-21 12:51:54 -0400 < mnieper> Okay... probably an Emacs encoding problem. Editing with vim worked!
2023-07-21 12:58:52 -0400 < mnieper> Final solution:
2023-07-21 12:58:56 -0400 < mnieper> perl -0777 -pe 's/XObject.*?>>//sg' < uncompressed.pdf > fixed.pdf
2023-07-21 13:01:49 -0400 < Zipheir> Wow. What's the -0777 for?
2023-07-21 13:05:25 -0400 < Zipheir> Ah, found it. What a weird option.
2023-07-21 13:11:37 -0400 < LeoNerd> More modern perls added `-g` for that
2023-07-21 13:12:37 -0400 < sham1> So what does -0777 do
2023-07-21 13:14:52 -0400 < LeoNerd> -0{some number} sets the line-break character, the value that it will consider is the linebreak for processing one per line. The octal number 777 isn't a valid byte, so effectively no byte is the linebreak. The entire file, every byte of it, is considered one "line" for the purposes of s/// operating on "a line"
2023-07-21 13:15:10 -0400 < LeoNerd> Since that's a rather nonobvious hack, `-g` was added as a much cleaner notation for it
2023-07-21 13:15:59 -0400 < Zipheir> Why would you need it, though? To avoid wasting cycles on line-splitting?
2023-07-21 13:16:59 -0400 < LeoNerd> If s/// operates per line, then  s/XObject.*?>>/something/  means that the >> has to appear on the same line as the XObject
2023-07-21 13:17:15 -0400 < LeoNerd> If you treat the entire input as "one line", then it'll find it even if split across multiple lines
2023-07-21 13:17:41 -0400 < Zipheir> Ah, OK.
2023-07-21 13:17:53 -0400 < Zipheir> Non-line-oriented regexes would be a nicer fix.
2023-07-21 13:18:02 -0400 < LeoNerd> Wellsure but that's not what -p does
2023-07-21 13:18:22 -0400 < LeoNerd> -p is a big shortcut for writing most of an entire program in the -e
2023-07-21 13:18:52 -0400 < LeoNerd> -pe "some code"  really means   -e 'while( $_ = readline STDIN ) { some code; print $_ }'   i.e. it'll keep reading/editing/printing lines of input into the output
2023-07-21 13:18:55 -0400 < Zipheir> That makes sense.
2023-07-21 13:19:05 -0400 < LeoNerd> So it's the -p part that really makes it operate "per line"
2023-07-21 13:19:14 -0400 < Zipheir> "sed mode"
2023-07-21 13:19:34 -0400 < LeoNerd> Yeah kinda, except not limited to s///; you could put anything there
2023-07-21 13:20:18 -0400 < Zipheir> Well, sed's not limited to s///, either. But of course Perl has much more power.
2023-07-21 13:20:49 -0400 < LeoNerd> -pe '$_ = http_fetch($_)->dom_tree->head->title'   for some random made-up functions you'd probably find in a module somewhere
2023-07-21 13:21:03 -0400 < LeoNerd> Convert a file of one URL per line, into page titles per line
2023-07-21 13:22:09 -0400 < sham1> Probably would have to use WWW::HTTP for that
2023-07-21 13:22:15 -0400 < sham1> Or whatever it's actually called
2023-07-21 13:50:11 -0400 < mnieper> In my case, removing the XObjects worked because only they were only used for the watermark.
2023-07-21 13:56:54 -0400 < jackdaniel> YObjects probably contained questions
2023-07-21 15:20:49 -0400 -!- cow_2001 is now known as SureAViking
2023-07-21 15:21:10 -0400 -!- SureAViking is now known as cow_2001
2023-07-21 15:44:50 -0400 -!- aeth_ is now known as aeth
2023-07-21 15:53:02 -0400 < mnieper> jcowan: Who said that lists were obsolescent?
2023-07-21 15:54:20 -0400 -!- Netsplit *.net <-> *.split quits: groovy, jcowan, yosafbridge, buhman, rudybot, energizer
2023-07-21 16:02:03 -0400 -!- Netsplit over, joins: groovy
2023-07-21 16:02:15 -0400 -!- Netsplit over, joins: buhman
2023-07-21 16:02:25 -0400 -!- Netsplit over, joins: rudybot
2023-07-21 16:02:35 -0400 -!- Netsplit over, joins: jcowan
2023-07-21 17:47:42 -0400 < jcowan> dpk: ping about R6RS
2023-07-21 20:17:50 -0400 -!- grettke_ is now known as grettke
2023-07-21 20:26:51 -0400 -!- grettke is now known as grettke_
--- Day changed Sat Jul 22 2023
2023-07-22 01:21:24 -0400 -!- mdhughes_ is now known as mdhughes
2023-07-22 03:05:40 -0400 -!- energizer_ is now known as energizer
2023-07-22 05:24:29 -0400 < Dooshki> Hey there!  After falling in love with LISP after experiencing it at work (Cadence SKILL), I'd love to incorporate a LISP interpreter in one of my projects that I'm working on, and the Scheme language seems like a pretty nice dialect!
2023-07-22 05:25:26 -0400 < Dooshki> Does anyone have any recommendations?  I value simplicity and ease of portability.  Currently, I'm thinking of s7 as the best choice, does anyone have any experience with it or a better recommendation?
2023-07-22 05:34:55 -0400  * Dooshki was also thinking about guile, since that implementation has a lot of visibility, but doesn't like the way its C API implements garbage collection - it seems very error-prone to me - and it might be a bit overkill for what I'm doing
2023-07-22 05:41:29 -0400 < Dooshki> Even an end-user's perspective could be useful - which implementations do you like the most?  Which quirks annoy you?  etc.
2023-07-22 05:43:59 -0400 < Dooshki> Since even though I'm excited about it and its potential, my experience is rather limited
2023-07-22 05:58:41 -0400 < mnieper> Chibi Scheme, which supports R7RS-small plus many extensions, is mainly intended to be used as a library.
2023-07-22 05:59:00 -0400 < mnieper> It conforms to the standard very well.
2023-07-22 06:00:15 -0400 < mnieper> Its disadvantages are that it is quite slow and that it even becomes slower when working under memory constraints (due to its GC performance).
2023-07-22 06:01:50 -0400 < Dooshki> I might take a look at it, thanks!  For my application, I don't need the Scheme code itself to be too performant, most of the heavy lifting should be done by the application itself, and the lisp code is mainly there to prepare and process (relatively small) data sets
2023-07-22 06:03:11 -0400 < mnieper> If you are looking for an industrial-strength Scheme to embed and/or want the more expressive R6RS standard, you can also embed Chez Scheme easily: https://www.reddit.com/r/scheme/comments/a3oogf/questions_on_embedding_chez_scheme_into_a_c_app/
2023-07-22 06:03:54 -0400 < mnieper> Then there is Guile, the GNU project's Scheme. Made to be embedded.
2023-07-22 06:04:54 -0400 < mnieper> If you don't care about strict compatibility to any Scheme standard but are just looking for a Scheme language, it is a good choice.
2023-07-22 06:05:48 -0400 < mnieper> Both Guile and Chez have great online documentation.
2023-07-22 06:06:14 -0400 < mnieper> There are many more Schemes, of course.
2023-07-22 06:07:20 -0400 < mnieper> At least Chez is so performant (unless you do very specific stuff like number crunching) that you should actually be able to code your whole project in Scheme.
2023-07-22 06:07:50 -0400 < Dooshki> Thanks a lot!  I'll spend a bit more time researching and comparing the pros and cons!  In the end, it shouldn't be too difficult to swap out the interpreter if I feel like I made the wrong choice, as long as I keep my code clean and the interfaces well-defined
2023-07-22 06:14:15 -0400 < mnieper> Yes, indeed.  It depends, of course, on how many bridges you need between Scheme and your native code.
2023-07-22 06:19:18 -0400 < jcowan> Dooshki: If you are thinking of s7, Chibi's advantages over s7 are conformance and speed.  Chibi is not as small, though.
2023-07-22 06:20:09 -0400 < Dooshki> Thanks for the info!
2023-07-22 06:49:17 -0400 < dpk> jcowan: pong
2023-07-22 06:57:09 -0400 < jcowan> dpk: see pm
2023-07-22 07:06:57 -0400 < Dooshki> Alright, thanks a lot, jcowan and mnieper, after spending some time with the documentation, I think Chibi Scheme is perfect for my needs!
2023-07-22 07:07:09 -0400  * jcowan nods
2023-07-22 07:07:11 -0400 < jcowan> Good!
2023-07-22 07:07:39 -0400 < mnieper> Dooshki: Happy coding!
2023-07-22 07:07:44 -0400 < Dooshki> Thanks! <3
2023-07-22 10:48:08 -0400  * sham1 reads codeberg issue about unicode gamut
2023-07-22 10:49:20 -0400 < sham1> Mapping \x80 - \xFF to range U+110080 - U+1100FF is something Emacs does. Well, it does something similar. I don't recall the exact details, but Emacs does for example map bytes like that
2023-07-22 10:50:18 -0400 < sham1> Err, Emacs apparently goes from U+110000 to U+3FFFFF
2023-07-22 10:50:44 -0400 < sham1> So for prior art: https://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html
2023-07-22 10:53:52 -0400 < sham1> The advantage of this would be that things such as filenames with weird non-character bytes in them could be represented uniformly
2023-07-22 11:51:18 -0400 < cow_2001> Copying stuff from SICP.
2023-07-22 11:57:15 -0400 -!- f-a_ is now known as f-a
2023-07-22 12:41:06 -0400 < skeemer> hello everyone, i finisehd reading the The little schemer few days ago, and was wondering why racket or some other schemes do not have the function "atom?" ?
2023-07-22 12:41:24 -0400 < skeemer> i mean it is basically used in most recursive functions...
2023-07-22 12:41:39 -0400 < skeemer> what is the racket equivalent or let's say the other schemes equivalent to that?
2023-07-22 12:47:29 -0400 < Zipheir> skeemer: "atom" isn't an idea used much outside of TLS.
2023-07-22 12:47:59 -0400 < sham1> And it's not really all that useful
2023-07-22 12:48:39 -0400 < Zipheir> I think it is, it's just that there are other ways of expressing it.
2023-07-22 12:48:48 -0400 < Zipheir> It's basically the "not a list" predicate.
2023-07-22 12:48:58 -0400 < mfiano> 'atom` is oddly named, because it is a predicate. Thank Common Lisp for that.
2023-07-22 12:49:28 -0400 < mfiano> CL code will see atom used a bit, though even there you would probably see 'not cons' more.
2023-07-22 12:49:42 -0400 < Zipheir> skeemer: The conventional way would be to ask if something *is* a list, not if it's an "atom".
2023-07-22 12:49:57 -0400 < Zipheir> skeemer: You'll most often see 'pair?' used for this.
2023-07-22 12:50:22 -0400 < Zipheir> (This does not tell you for sure that something's a list, but it's faster than 'list?'.)
2023-07-22 12:51:09 -0400 < Zipheir> mfiano: Yeah, that's what I would guess.
2023-07-22 12:51:50 -0400 < mfiano> Is `pair` synonymous with the historical lisps' use of 'cons' as a data structure?
2023-07-22 12:52:01 -0400 < mfiano> Sorry for scheme ignorance
2023-07-22 12:52:14 -0400 < sham1> Pairs are indeed what other lisps call cons cells
2023-07-22 12:52:20 -0400 < mfiano> Thanks
2023-07-22 12:52:50 -0400 < sham1> Of course, Scheme uses cons to construct them and car & cdr to access the two parts of the cell
2023-07-22 12:53:12 -0400 < sham1> Although for car and cdr, there aren't really better names
2023-07-22 12:54:26 -0400 < Zipheir> 'head' & 'tail' have been used in the ML world for decades.
2023-07-22 12:54:38 -0400 < sham1> But that implies a list
2023-07-22 12:54:49 -0400 < Zipheir> I suppose so.
2023-07-22 12:58:17 -0400 < skeemer> thank you guys!
2023-07-22 12:59:18 -0400 < f-a> left and right
2023-07-22 13:00:36 -0400 < Zipheir> sham1: I guess the weird nuts-and-bolts 1950s names remind you that Scheme pairs aren't necessarily lists.
2023-07-22 13:01:26 -0400 < Zipheir> f-a: That's not bad.
2023-07-22 13:02:55 -0400 < sham1> Zipheir: also, head & tail don't compose
2023-07-22 13:03:04 -0400 < sham1> Although left and right might
2023-07-22 13:03:21 -0400 < sham1> Because now we have cadr, caar and so on
2023-07-22 13:03:58 -0400 < Zipheir> Well, car and cdr *barely* compose. No one wants to deal with programs full of caddadrs
2023-07-22 13:13:32 -0400 < Zipheir> There is a certain wisdom to 'atom?': You can consistently answer the question "is X not a proper/improper list?" in O(1) time, but "is X a list?" is O(n).
2023-07-22 13:17:16 -0400 < sham1> Well that'd just make atom? into (not (pair? obj)) and I frankly don't know if that's all that useful
2023-07-22 13:17:49 -0400 < sham1> Also on that note, would '() be atom? or not
2023-07-22 13:22:53 -0400 < Zipheir> () isn't an atom, which is the only reason it's not (∘ not pair?).
2023-07-22 13:23:20 -0400 < Zipheir> It's not earth-shakingly brilliant, but I understand why someone would want atom?.
2023-07-22 13:25:29 -0400 < mnieper> Without set-car!/set-cdr!, `list?' could work in O(1).
2023-07-22 13:25:44 -0400 < mnieper> SRFI 101 (https://srfi.schemers.org/srfi-101/srfi-101.html) is also great.
2023-07-22 13:27:04 -0400 < Zipheir> It's unappreciated.
2023-07-22 13:27:07 -0400 < Zipheir> *under
2023-07-22 13:27:16 -0400 < Zipheir> At least one person appreciates it. :)
2023-07-22 13:27:21 -0400 < mnieper> Scheme would be an even better language if it had a proper list type (and that type would be used wherever it makes sense).
2023-07-22 13:27:34 -0400 < Zipheir> mnieper: What's to stop you building a long (immutable) improper list with 'cons'?
2023-07-22 13:28:27 -0400 < mnieper> The problem with SRFI 101 is its incompatibility with set-cdr!.
2023-07-22 13:29:00 -0400 < mnieper> Of course, the latter is the problem. :)
2023-07-22 13:29:27 -0400 < mnieper> Zipheir: You can store as a flag in the cons cell whether the tail is a proper list.
2023-07-22 13:29:43 -0400 < Zipheir> Hmm, that's true.
2023-07-22 13:30:00 -0400 < mnieper> cons cells are a relic from the 60s.
2023-07-22 13:30:07 -0400 < mnieper> Where there were no records.
2023-07-22 13:30:17 -0400 < mnieper> And maybe no vectors either.
2023-07-22 13:36:08 -0400 < mnieper> The only real use case for them in modern Scheme is the syntax for rest arguments in lambdas.
2023-07-22 13:36:53 -0400 < mnieper> Already in 1990, a better solution was found (https://legacy.cs.indiana.edu/~dyb/pubs/LaSC-3-3-pp229-244.pdf), but didn't make it into the standard.
2023-07-22 14:08:58 -0400 < taylan> skeemer: (define (atom? x) (not (pair? x))) should serve you well enough
2023-07-22 14:10:18 -0400 < Zipheir> It's got to be false of '(), though, at least to work in The Little Schemer.
2023-07-22 14:10:51 -0400 < taylan> yes, () isn't a pair
2023-07-22 14:10:56 -0400 < taylan> so that works fine
2023-07-22 14:12:07 -0400 < Zipheir> So (not (pair? '())) => (not #f) => #t, which isn't what it's supposed to return.
2023-07-22 14:12:38 -0400 < Zipheir> The Little Schemer gives (lambda (x) (and (not (pair? x)) (not (null? x))))
2023-07-22 14:13:16 -0400 < taylan> Zipheir: oh, (atom? '()) is supposed to be false?
2023-07-22 14:13:38 -0400 < taylan> if so, that's weird
2023-07-22 14:15:06 -0400 < jcowan> sham1: The Emacs approach pretty much requires that the internal format be utf-32 (or more accurately ucs-4); the "third approach" in #33 (last few comments) does not care, because everything is encoded as a simple sequence of Unicode characters.
2023-07-22 14:15:26 -0400 < mnieper> A vector shouldn't be an atom.
2023-07-22 14:15:30 -0400 < jcowan> s/encoded/decoded
2023-07-22 14:15:52 -0400 < jcowan> My tree library provides the atom function
2023-07-22 14:15:59 -0400 < Zipheir> taylan: It would be even weirder in CL where, I suppose, nil is not an atom.
2023-07-22 14:16:22 -0400 < mnieper> This is my definition of an atom: https://github.com/scheme-libraries/scheme-libraries/blob/main/lib/scheme-libraries/atoms.sls
2023-07-22 14:16:23 -0400 < jcowan> No, () is an atom in CL
2023-07-22 14:17:03 -0400 < Zipheir> OK, then it's just Dan Friedman and Matthias Felleisen being contrary.
2023-07-22 14:17:19 -0400 < Zipheir> They use atomp x = (not (listp x)) in CL.
2023-07-22 14:18:05 -0400 < mnieper> sham1: With the Emacs approach, we would have strings and almost-strings.
2023-07-22 14:18:32 -0400 < mnieper> Strings being homogeneous vectors of Unicode scalar vectors, almost-strings being homogeneous vectors of 32-bit numbers.
2023-07-22 14:19:28 -0400 < mnieper> TYPO: ... Unicode scalar values ...
2023-07-22 14:19:45 -0400 < Zipheir> "vectors of scalar vectors" 8-|
2023-07-22 14:21:17 -0400 < jcowan> Which causes very ugly polymorphism.  There has to be a wart somewhere, and the "third approach" puts the wart down in the details of particular Unicode characters.
2023-07-22 15:01:07 -0400 < sham1> Well paths for example would need to be these almost-strings. POSIX for example allows basically anything except \x00 and the forward slash, and even the latter is just because it's the directory separator
2023-07-22 15:01:27 -0400 < sham1> So really we'd have to make bytestrings actually a thing
2023-07-22 15:05:31 -0400 < mnieper> sham1: A path is, from the OS level, a bytevector. On a modern Unix, it is almost the UTF-8 encoding of a Unicode string.
2023-07-22 15:06:52 -0400 < mnieper> All that is needed is a "codec" that can decode an almost-UTF-8-encoded string into a proper Unicode string so that the properly encoded parts of the UTF-8 bytevector are mapped according to the UTF-8 codec.
2023-07-22 15:07:06 -0400 < sham1> But what would this "amost UTF-8" look like
2023-07-22 15:07:12 -0400 < sham1> That's the entire question here
2023-07-22 15:07:46 -0400 < sham1> How do you map the invalid bytes into Unicode codepoints. The Emacs approach is nice in that it doesn't even try to do that and just basically passes them along
2023-07-22 15:08:12 -0400 < mnieper> Have you read jcowan's proposal in issue #33?
2023-07-22 15:09:14 -0400 < mnieper> Valid UTF-8 sequences representing characters are decoded as specified by UTF-8. Invalid bytes are decoded into noncharacters.
2023-07-22 15:09:27 -0400 < mnieper> Valid UTF-8 sequences representing noncharacters as well.
2023-07-22 15:09:42 -0400 < sham1> I have read it
2023-07-22 15:09:43 -0400 < mnieper> This gives a bijection between bytevectors and UTF-8 strings.
2023-07-22 15:09:52 -0400 < sham1> How would this work in UTF-16
2023-07-22 15:10:01 -0400 < sham1> Windows, for example
2023-07-22 15:10:11 -0400 < mnieper> Likewise. Replace UTF-8 by UTF-16 in my explanation.
2023-07-22 15:10:22 -0400 < sham1> Or for example with Kawa running on the JVM, strings are UCS-2*
2023-07-22 15:10:45 -0400 < mnieper> A Java string is not a Unicode string and not a Scheme string.
2023-07-22 15:11:44 -0400 < sham1> Yeah, because Scheme strings are mutable, so you'd instead use a StringBuilder or some other container of char.
2023-07-22 15:12:09 -0400 < mnieper> But Kawa could use the same scheme to bijectively map between Java strings and Scheme strings.
2023-07-22 15:12:32 -0400 < mnieper> The bijection is so that well-formed strings of Unicode characters are mapped by the identity.
2023-07-22 15:12:33 -0400 < sham1> Of course, Unicode doesn't define the term "string", so what are we working with here?
2023-07-22 15:12:53 -0400 < mnieper> In Scheme, a string is a homogeneous vector of characters.
2023-07-22 15:13:01 -0400 < mnieper> So it boils down to what a character is.
2023-07-22 15:13:08 -0400 < mnieper> It would be a Unicode scalar value.
2023-07-22 15:14:40 -0400 < sham1> Another question is how would a user of a string distinguish between having those scalar values encode bytes and the string just having those non-characters
2023-07-22 15:15:53 -0400 < mnieper> From the point of view from Scheme, non-characters are just non-characters.
2023-07-22 15:16:48 -0400 < mnieper> Only the interface between Scheme/system would be concerned with it.  Textual ports are not concerned with it.
2023-07-22 15:18:59 -0400 < mnieper> So, for example, command line parameters are just bytevectors on the Unix side. But they have to be mapped to Scheme strings because of the `(command-line)` API.
2023-07-22 15:19:42 -0400 < mnieper> As long as the mapping is bijective and is exactly what the user expects for strings containing no non-characters, there is no problem.
2023-07-22 15:21:15 -0400 < mnieper> So when I call `scheme-program FOOBAZ.TXT`, I will see the string "FOOBAZ.TXT" in the Scheme program.
2023-07-22 15:21:49 -0400 < sham1> Right, but that's of course assuming that there aren't any non-characters there
2023-07-22 15:21:59 -0400 < sham1> Which is allowed with POSIX file names
2023-07-22 15:22:12 -0400 < mnieper> Yes, they will be mapped to some other.
2023-07-22 15:22:27 -0400 < sham1> And these non-characters are also required to be supported since they're valid Unicode codepoint scalars
2023-07-22 15:22:46 -0400 < mnieper> Yes.
2023-07-22 15:22:57 -0400 < mnieper> But there's no problem here.
2023-07-22 15:24:20 -0400 < sham1> How so? You can't map them to other non-characters within the Unicode codepoint range
2023-07-22 15:24:29 -0400 < sham1> Because now those would also have to be mapped
2023-07-22 15:24:38 -0400 < mnieper> A POSIX file name is a bytevector, which is meant to be interpreted as an UTF-8 encoded string of Unicode characters.  We follow this interpretation and handle the corner cases when it cannot be interpreted as such.
2023-07-22 15:24:54 -0400 < mnieper> sham1: Yes, but this is what I wrote (and what's in #33).
2023-07-22 15:25:23 -0400 < mnieper> Ah, now I understand your problem.
2023-07-22 15:25:36 -0400 < mnieper> You can map one non-character to two non-characters.
2023-07-22 15:25:43 -0400 < mnieper> See jcowan's encoding Scheme.
2023-07-22 15:26:06 -0400 < sham1> Right, and jcowan objected to this very argument, saying that it's a dirty encoding just like an unpaired surrogate, but I do disagree
2023-07-22 15:26:06 -0400 < mnieper> A lot of things have cardinality aleph-0. :)
2023-07-22 15:26:48 -0400 < mnieper> I wouldn't call it dirty encoding.
2023-07-22 15:27:27 -0400 < mnieper> But a byte sequence in a POSIX path UTF-8-encoding a noncharacter need not be mapped to exactly this noncharacter.
2023-07-22 15:28:05 -0400 < mnieper> It is okay to limit the identity part of the bijection to non-noncharacters.
2023-07-22 15:31:28 -0400 < sham1> The reason I personally like mapping above U+10FFFF for this is because if the value of this "pseudo-codepoint" is U+110000 or higher, there's absolutely no mistaking it for a valid Unicode codepoint
2023-07-22 15:34:51 -0400 < mnieper> I think you read to much into the meaning of the byte sequences making up a POSIX/Windows pathname.
2023-07-22 15:36:00 -0400 < sham1> Oh I know. I'm quite passionate about this stuff
2023-07-22 15:36:17 -0400 < sham1> And the fact that these weird things are allowed in filenames is such a pain
2023-07-22 15:36:20 -0400 < mnieper> As soon as you allow pseudo-characters into Scheme strings, you have problems with interchanging these strings (which are encoding-unaware) with Unicode-aware software.
2023-07-22 15:36:31 -0400 < sham1> That is also true
2023-07-22 15:36:40 -0400 < mnieper> sham1: Why it is a pain?
2023-07-22 15:37:11 -0400 < mnieper> For 99.99999% of the filenames on my system I get exactly what I expect even without looking at jcowan's encoding Scheme.
2023-07-22 15:37:48 -0400 < mnieper> For the rest, I know I will get something but what I get I don't care because these pathnames aren't made up of a pronouncable/writable string anyway.
2023-07-22 15:37:50 -0400 < sham1> Well I personally think that aside from just allowing basically arbitrary non-zero bytes, the fact that for example control codes such as newlines are allowed in these names makes things irritating. For example output of tools such as ls are highly sensitive to this stuff
2023-07-22 15:38:20 -0400 < sham1> And it's not just file paths, you also get things like mixed binary and textual data which needs dealing with
2023-07-22 15:38:24 -0400 < mnieper> sham1: This is true, but this is orthogonal to what is solved in #33.
2023-07-22 15:38:34 -0400 < sham1> For example with certain protocols
2023-07-22 15:38:46 -0400 < sham1> Although I suppose for those you usually would use bytestrings
2023-07-22 15:40:52 -0400 < mnieper> The proposal in #33 is for the case when a bijective mapping between bytevectors and strings is needed, a subset of the bytevectors is distinguished as the "well-formed" set and the bijection restricted to the "well-formed" set is predescribed.
2023-07-22 15:41:13 -0400 < sham1> I suppose
2023-07-22 15:41:25 -0400 < mnieper> For pathnames, "well-formed" means properly UTF-8/16-encoded characters.
2023-07-22 15:41:46 -0400 < sham1> Well, non-zero UTF-8/16 encoded characters. You're not allowed U+0000 <control> anywhere
2023-07-22 15:42:10 -0400 < mnieper> (Of course, having one bijection, on can map any bytevector to a string, but usually this is not meaningful.)
2023-07-22 15:42:31 -0400 < mnieper> The bijection would respect U+0000.
2023-07-22 15:43:08 -0400 < mnieper> That some strings don't correspond to valid pathnames (vs all bytevectors) is outside of what #33 deals with.
2023-07-22 15:43:25 -0400 < mnieper> But some library should export `(pathname? string).
2023-07-22 15:45:41 -0400 < sham1> I do like this proposal in a way, but I'm still having these objections because it does feel weird
2023-07-22 15:45:55 -0400 < sham1> Another problem I thought of is non-Unicode locales
2023-07-22 15:46:12 -0400 < sham1> For example, I distinctly remember you describing having a somewhat active Latin-1 system in use
2023-07-22 15:46:57 -0400 < sham1> So... How'd that work, since the assumption of the path being unicode codepoints no longer holds
2023-07-22 15:50:01 -0400 < mnieper> The scheme has to be devised for each native system.  What we described is how it works for UTF-8 and UTF-16.
2023-07-22 15:50:26 -0400 < mnieper> For Latin-1 we can just map to the corresponding Unicode characters directly.
2023-07-22 15:51:17 -0400 < mnieper> I suggested in #33 to leave the exact mapping implementation-dependent; John suggested that it should be documented.
2023-07-22 15:51:52 -0400 < sham1> I'd say that it should be implementation-specific, so I could do my own thing, for example
2023-07-22 15:52:06 -0400 < sham1> Although I also think that we should have a specific OS string/path type
2023-07-22 15:52:30 -0400 < sham1> Where you can use strings for the file port opening stuff, but you could also use these OS strings which are just whatever
2023-07-22 15:53:01 -0400 < mnieper> The constraint for anything implementation-specific is, though, that the result is a proper Scheme string and not just some int32-vector.
2023-07-22 15:53:36 -0400 < mnieper> And that the glyphs printed by the OS correspond to the glyphs printed by Scheme.
2023-07-22 15:54:00 -0400 < mnieper> (This subsumed the user-visible part of "valid Unicode character".)
2023-07-22 15:54:35 -0400 < sham1> I'll look up some prior art, maybe that could also help
2023-07-22 15:54:42 -0400 < mnieper> +1
2023-07-22 15:55:13 -0400 < mnieper> Having a type of OS string is less of a problem when the program wants to supply a string to the OS.
2023-07-22 15:55:22 -0400 < mnieper> The other way round, it is a problem.
2023-07-22 15:55:41 -0400 < mnieper> Because procedures like (command-line) have to return a Scheme string.
2023-07-22 15:55:55 -0400 < sham1> Ah, because we can't just change it anymore. Yeah...
2023-07-22 15:56:17 -0400 < mnieper> We could double these procedures.
2023-07-22 15:56:31 -0400 < mnieper> But then we would also need OS-string-append, OS-string-regexp, ...
2023-07-22 15:56:45 -0400 < sham1> Right. R6RS also didn't seem to handle this in a nice way
2023-07-22 15:56:50 -0400 < sham1> It also has strings for command-lines
2023-07-22 15:57:05 -0400 < mnieper> Yes. It gives freedom the other way.
2023-07-22 15:57:14 -0400 < mnieper> Filenames can be strings or something implementation-specific.
2023-07-22 15:58:09 -0400 < mnieper> We can leave this in because there may be something like an "unnamed file".
2023-07-22 15:58:37 -0400 < sham1> FWIW, Python for example has it so that paths can be strings, bytes (what we'd have as bytevectors/bytestrings) and any objects that implement a certain protocol. Of course in Python's case that protocol relies on things having methods on them, but that could also somehow be made work if we had generic procedures
2023-07-22 15:58:50 -0400 < sham1> So something like CLOS or whatever else
2023-07-22 15:59:51 -0400 < mnieper> Generic or not, you would still have to specify all procedures for strings and bytevectors.
2023-07-22 16:01:01 -0400 < mnieper> And you would not only have to make sure that everything stringy make semantically sense for bytevectors as well.
2023-07-22 16:01:06 -0400 < sham1> Sure but that'd also mean that those could then also be extended for user stuff
2023-07-22 16:01:17 -0400 < mnieper> And that you freely switch from strings to bytevectors and vice versa
2023-07-22 16:01:32 -0400 < mnieper> Because the user may give "*.scm" and the system may return a bytevector.
2023-07-22 16:01:45 -0400 < mnieper> And then you have to do some encoding back and forth anyway.
2023-07-22 16:02:09 -0400 < sham1> Well at least in POSIX systems *.scm would be processed by the shell
2023-07-22 16:02:15 -0400 < mnieper> TYPO: And that you CAN freely ...
2023-07-22 16:02:26 -0400 < mnieper> sham1: Only on the command line.
2023-07-22 16:02:46 -0400 < sham1> Where else would you use that asterisk like that, you reckon
2023-07-22 16:03:12 -0400 < mnieper> In a file dialogue, for example?
2023-07-22 16:03:20 -0400 < sham1> Ah
2023-07-22 16:03:25 -0400 < mnieper> (Or whatever search interface)
2023-07-22 16:17:07 -0400 < mnieper> FWIW, Rust, representing a modern programming language with few historical baggage, defines a character also as a Unicode scalar value: https://doc.rust-lang.org/std/primitive.char.html
2023-07-22 16:17:20 -0400 < sham1> And it also has OS strings
2023-07-22 16:19:07 -0400 < mnieper> How are they caled?
2023-07-22 16:19:09 -0400 < mnieper> l
2023-07-22 16:19:55 -0400 < sham1> OsString, &OsStr, etc
2023-07-22 16:21:37 -0400 < mnieper> That would be our bytevector on the system side.
2023-07-22 16:21:52 -0400 < mnieper> How does Rust define the encoding/decoding from OsString to String and back?
2023-07-22 16:23:13 -0400 < sham1> Conversion to OsString works always, but from it is only if the OsString is a valid Unicode
2023-07-22 16:23:35 -0400 < mnieper> Then our Scheme is better.
2023-07-22 16:24:05 -0400 < mnieper> s/Scheme/scheme
2023-07-22 16:36:53 -0400 < mnieper> Found some prior art. MirBSD: https://lists.suckless.org/dev/1312/18786.html
2023-07-22 16:37:51 -0400 < mnieper> It uses the PUA, but not noncharacters.
2023-07-22 16:38:15 -0400 < mnieper> As I read the Unicode FAQ, using noncharacters as in #33 is more correct.
2023-07-22 16:41:46 -0400 < sham1> Link? Because that sounds like an interesting thing
2023-07-22 16:44:24 -0400 < mnieper> The FAQ I linked in Codeberg issue #33.
2023-07-22 16:45:20 -0400 < mnieper> A PUA character (!) can be assigned a glyph (a private one) and is meant to be exchanged between cooperating parties.
2023-07-22 16:45:34 -0400 < mnieper> For our use case, the noncharacter definition applies.
2023-07-22 16:48:53 -0400 < mnieper> A completely different approach would be to have Scheme strings possibly be backed-up by native strings ("OS strings"). On decoding an OS string, the replacement character is used in case of errors, but the actual bytes preserved in the shadow.
2023-07-22 16:49:11 -0400 < mnieper> Decoding back would just return the shadow "OS string".
2023-07-22 16:49:36 -0400 < mnieper> s/Decoding back/Encoding back
2023-07-22 16:49:58 -0400 < mnieper> Problem with this approach: what looks like a valid string could produce an invalid encoded version.
2023-07-22 16:50:34 -0400 < mnieper> Also: It is not well-defined how string operations (e.g. splitting at whitespace) operate on the shadow.
2023-07-22 16:51:16 -0400 < mnieper> I am thus not convinced of this idea.
2023-07-22 17:44:03 -0400 < jcowan> I agree that the shadow idea is problematic (the same with shadow condition objects, btw)
--- Day changed Sun Jul 23 2023
2023-07-23 05:31:45 -0400 < Dooshki> ... okay.  There is one thing that I'm not thrilled about Chibi Scheme.  It appears, if I understand it correctly, that its API relies on you being able to provide a `FILE *` to implement a port.  There is a mechanism for custom ports, but it appears to depend on fopencookie()/funopen() to create a `FILE *` stream, which aren't available on all systems, like Windows
2023-07-23 05:38:28 -0400 < Dooshki> Perhaps I'm interpreting it wrong though, since I see that the sexp_buffered_read_char() and sexp_buffered_flush() functions don't use the file descriptor created by fopencookie()/funopen() but instead use the provided callbacks...  Hmmm...
2023-07-23 05:41:36 -0400 < Dooshki> I'm an idiot :P
2023-07-23 05:42:09 -0400 < Dooshki> Sorry for wasting your time, I didn't look at the other side of an ifdef, there are custom ports that don't rely on `FILE *`
2023-07-23 05:42:41 -0400 < sham1> It's okay
2023-07-23 05:46:42 -0400 < Dooshki> It seems that it just uses fopencookie()/funopen() by default, if available, and only uses the "explicit" custom ports as a last resort, on Windows
2023-07-23 05:49:45 -0400 < Dooshki> I guess it could make sense from a performance point of view, if the OS does more efficient/thoughtful caching than the code that uses the callbacks explicitly
2023-07-23 06:10:04 -0400 < mnieper`> jcowan: I replied to you about "use before definition". But, maybe, I didn't get what you actually meant.
2023-07-23 06:12:10 -0400 < jcowan> I agree that it won't work with letrec* semantics.  But when it comes to arbitrary restrictions, there is no obvious reason why (begin (define x 2) (+ x 1)) shouldn't mean the same thing as (begin (+ x 1) (define x 2)).
2023-07-23 06:12:33 -0400 < jcowan> This is true e.g. in Algol 68 and PL/I.
2023-07-23 06:12:51 -0400 < sham1> That's the hoisting behaviour you see in something like JavaScript and it's... eh
2023-07-23 06:13:16 -0400 < jcowan> no, no hoisting here in the sense that something is hoisted from one scope to another.  They are both in the same scope.
2023-07-23 06:13:44 -0400 < sham1> JS doesn't do that, it puts it at the top of the current scope
2023-07-23 06:13:50 -0400 < sham1> Just like this
2023-07-23 06:14:18 -0400 < sham1> Also, what would (begin (+ x 1) (define x 2)) evaluate to? define doesn't have a specified result
2023-07-23 06:15:26 -0400 < jcowan> It's *because* it doesn't have a defined result that it's unambiguously 3.
2023-07-23 06:15:51 -0400 < jcowan> er, the first  "it" means the definition, the second "it" means the block.
2023-07-23 06:16:31 -0400 < sham1> Anyway, I disagree with the assessment that (begin (+ x 1) (define x 2)) be allowed. That should be a compilation error
2023-07-23 06:16:55 -0400 < sham1> (begin (define x 2) (do-thing) (define y 3) (+ x y)) on the other hand should just work
2023-07-23 06:17:07 -0400 < jcowan> You're right about JS, but I think of it is "hoisted to the top of the current function",  since (unlike C/C++) you are not allowed to declare arbitrary blocks.
2023-07-23 06:17:28 -0400 < sham1> Yes you are, although it only affects let and const
2023-07-23 06:17:32 -0400 < sham1> var is function scoped
2023-07-23 06:18:08 -0400 < jcowan> Again, what's wrong with use before definition other than that we are not used to it?  We allow it at the top level.
2023-07-23 06:18:17 -0400 < sham1> Because that's not top-level
2023-07-23 06:18:22 -0400 < jcowan> Isn't that an arbitrary top/non-top distinction?
2023-07-23 06:18:26 -0400 < sham1> Yeas
2023-07-23 06:19:36 -0400 < jcowan> (I see now that JS has three different hoisting rules, which is icky)
2023-07-23 06:20:06 -0400 < sham1> That's JS being JS. Anyway, having definitions after use is not something most people expect within scopes
2023-07-23 06:21:11 -0400 < mnieper`> jcowan: We can't allow it at the top-level.
2023-07-23 06:21:27 -0400 < mnieper`> It would only work with "script" semantics.
2023-07-23 06:21:39 -0400 < jcowan> What is "it"?
2023-07-23 06:22:23 -0400 < sham1> (define x (+ y 1)) (define y 2)
2023-07-23 06:22:41 -0400 < sham1> That on top level
2023-07-23 06:22:58 -0400 < mnieper`> The top level also has letrec* semantics.
2023-07-23 06:24:13 -0400 < sham1> I actually tried the line I typed in chibi. Doesn't work
2023-07-23 06:24:27 -0400 < mnieper`> One cannot just move something like `(define y 2)` upwards.
2023-07-23 06:24:39 -0400 < sham1> I'll also try Gauche
2023-07-23 06:24:42 -0400 < mnieper`> Because the right hand side `2` is an arbitrary expression (and can have side-effects).
2023-07-23 06:25:09 -0400 < sham1> Also doesn't work on Gauche with the R7RS mode on
2023-07-23 06:25:52 -0400 < sham1> No dice on Guile either
2023-07-23 06:27:21 -0400 < sham1> And it works neither in REPL nor when it's actually in a file
2023-07-23 06:27:39 -0400 < mnieper`> By the way, sham1 and jcowan, the scope of the defines is always the whole body.
2023-07-23 06:27:56 -0400 < mnieper`> It is about use before initialization, not about lexical scope.
2023-07-23 06:28:13 -0400 < jcowan> Ah.
2023-07-23 06:28:21 -0400 < sham1> But this use before definition is usually also tied to having lexical scope
2023-07-23 06:28:25 -0400 < sham1> But fair enough
2023-07-23 06:29:32 -0400 < mnieper`> sham1: I don't understand you latest comment.
2023-07-23 06:29:54 -0400 < sham1> Languages with lexical scope also tend to disallow use-before-definition
2023-07-23 06:33:38 -0400 < mnieper`> Use-before-definition does not make sense in any semantics.
2023-07-23 06:33:54 -0400 < mnieper`> At best, you get undefined behavior.
2023-07-23 06:35:14 -0400 < sham1> Well some languages allow it. In lua for example: `print(x); local x = 5; print(x)` will print nil and 5
2023-07-23 06:36:04 -0400 < sham1> Because the first x is looked up from the global environment, and the global environment table will give you nil if there is nothing there as all tables do
2023-07-23 06:37:20 -0400 < sham1> But yeah, I agree. Use-before-definition makes no sense IMO
2023-07-23 06:39:46 -0400 < mnieper`> sham1: Lua's semantics are incompatible with (identifier) macros and recursive definitions.
2023-07-23 06:40:07 -0400 < sham1> Right. It was more to illustrate the point than actually to have this be a thin g
2023-07-23 07:24:58 -0400 < mnieper`> sham1: Thanks to your Lua example, I now understand what you meant by being tied to lexical scope.
2023-07-23 07:32:14 -0400 < mnieper`> It seems that one may say that Lua is dynamically scoped.
2023-07-23 07:33:27 -0400 < sham1> Well, in Lua all variables are in the global scope by default, and after a local statement, it will look it in the current scope, which in this case would be the "chunk" which in the REPL is the current line
2023-07-23 07:37:11 -0400 < mnieper`> What would be the result of the following code in Lua (using Scheme syntax because I don't know Lua): (define (f) x) (define x 3) (f)?
2023-07-23 07:38:42 -0400 < wasamasa> don't worry, you won't lose your scheme cred for learning lua syntax
2023-07-23 07:39:14 -0400 < wasamasa> https://learnxinyminutes.com/docs/lua/
2023-07-23 07:39:53 -0400 < sham1> Depends. If we'd do something like `local function f() return x; end; x = 3; print(f())`, this will print 3. But if we make x local, then it doesn't work out so well
2023-07-23 07:40:14 -0400 < sham1> Because yeah, it looks it up in the local environment, so it'll print nil
2023-07-23 07:43:04 -0400 < mnieper`> sham1: So Lua does basically dynamic lookup. When it encounters x, it seems to dynamically check whether it is registered with local and in which "alist" its value is stored.
2023-07-23 07:43:11 -0400 < sham1> Yeah
2023-07-23 07:43:48 -0400 < mnieper`> Why would I want to learn Lua?
2023-07-23 07:44:33 -0400 < wasamasa> to keep your brain healthy
2023-07-23 07:49:27 -0400 < mnieper`> I already do C programming from time to time! :)
2023-07-23 07:54:06 -0400 < wasamasa> I'm not sure C helps with that
2023-07-23 07:57:18 -0400 < mnieper`> I see use cases of C where Scheme can't be used (in the foreseeable future). But where would I want to use Lua when there's Scheme?
2023-07-23 07:58:08 -0400 < sham1> Easier embedding job into other applications. Like yeah, Chibi and Guile will work for that nicely, but Lua is so small and easy to add to existing stuff
2023-07-23 07:58:14 -0400 < sham1> Mostly because that's what it was designed to do
2023-07-23 07:59:28 -0400 < mnieper> Embedding Chibi, Guile or Chez is not hard. And if I embedded Lua, I would force the users of my application to use it when they could have something better.
2023-07-23 08:00:01 -0400 < wasamasa> better is relative
2023-07-23 08:00:06 -0400 < wasamasa> does lua have better or worse backtraces than guile?
2023-07-23 08:00:20 -0400 < wasamasa> I'd like to think it's hard to be worse than guile, but who knows
2023-07-23 08:00:24 -0400 < sham1> Fairly good backtracing
2023-07-23 08:00:36 -0400 < mnieper> I meant mainly the language, not a particular implementation.
2023-07-23 10:36:44 -0400 < Dooshki> Yeah, I was also thinking of Lua for the application I'm doing, but I feel that a Lisp dialect would have better productivity, since lists of items will be the main thing it'll be used for manipulating, and I feel that a language built around them will make the experience of writing extension code more pleasant, instead of doing things in a C-like way
2023-07-23 10:38:20 -0400 < Dooshki> ... the application is already written in C, so if the user wants to, they will still be able to do it :P  But they also have an alternative which is right there, they can use it immediately
2023-07-23 10:40:22 -0400 < Dooshki> Though I can imagine that for a non-list-centric application, where the data you're manipulating are individual items or objects, Lua might end up being more convenient for the end-user
2023-07-23 10:43:49 -0400 < Dooshki> What I've learned in the final years of school (university) and in my first year of work is that comparing the technical parameters of a language is not enough, you also need to evaluate productivity for the kinds of tasks you'll be doing, otherwise you might be slaving away writing loads of frustrating and finnicky code when it could've been really simple and elegant with a more appropriate
2023-07-23 10:43:51 -0400 < Dooshki> language
2023-07-23 10:43:54 -0400 < mnieper> I am not sure whether Lisp/Scheme = list-oriented is more than just a pseudo-wisdom.
2023-07-23 10:44:41 -0400 < mnieper> I can't speak for Lua, but as long as the language has an equivalent of car/cdr or head/tail, it is no less "list-oriented".
2023-07-23 10:45:06 -0400 < mnieper> ML or Haskell, for example.
2023-07-23 10:46:32 -0400 < mnieper> Python lists are no worse either.
2023-07-23 10:47:53 -0400 < mnieper> The primary reason of choosing Scheme is IMO if you (a) want clear language semantics, (b) an easily extendible syntax, (c) to be able to choose among many implementations, (d) to program mostly in a functional style, (e) dynamic typing, (f) automatic garbage collection.
2023-07-23 10:49:19 -0400 < Dooshki> I guess I should disclose that I'm someone who mainly does things in C and Rust, with pretty minimal experience with dynamic or functional languages :P  So that's why my perspective is kinda skewed
2023-07-23 10:49:54 -0400  * Dooshki 's experience with Python is debugging a horribly bitrotten codebase at a previous job which broke if you juts looked at it funny
2023-07-23 10:54:47 -0400 < Dooshki> I wonder if Scheme, with its module system, has similar problems with bitrot as Python...  Since e.g. you can find packages in common distros like Debian which are broken in subtle ways because the APIs of libraries they use have changed in subtle ways, so if you go down a particular code path, bam, crash!
2023-07-23 10:57:05 -0400 < Dooshki> (in a statically typed language, you'd discover these sorts of issue in the compiler or linter phase)
2023-07-23 10:57:55 -0400 < wasamasa> that's quite the assumption to make for a language that has quite the dysfunctional relationship with package management
2023-07-23 10:58:39 -0400 < Dooshki> I'm not making assumptions, I'm curious and hoping that it's not the case :P
2023-07-23 10:58:54 -0400 < wasamasa> for starters, there would need to be working package management
2023-07-23 10:59:23 -0400 < wasamasa> that alone limits you to a handful of implementations
2023-07-23 10:59:34 -0400 < Dooshki> I think I saw something about "snowballs" as a proposed package management system?
2023-07-23 10:59:40 -0400 < wasamasa> chibi uses that, yes
2023-07-23 11:00:11 -0400 < wasamasa> I tried to use it from CHICKEN and had to open a R7RS compatibility bug that prevents me from using any of the interesting packages
2023-07-23 11:00:38 -0400 < mnieper> The package manager won't help much against bitrot, I fear.
2023-07-23 11:01:56 -0400 < sham1> Stability helps with that
2023-07-23 11:02:26 -0400 < wasamasa> you mean, lack of overall activity?
2023-07-23 11:03:14 -0400 < mnieper> R7RS allows (a) for implementation-specific extensions to standard procedures and allows (b) undefined behavior whenever the domain of (standard) procedures is violated.  Thus, you won't necessarily detect if the semantics of some procedure you use in such a way silently change.
2023-07-23 11:03:17 -0400 < wasamasa> you don't need to worry about API breakage if the API never changes because it's someone's weekend project
2023-07-23 11:04:02 -0400 < mnieper> That R7RS has cond-expand inviting #ifdef-like programming (instead of actual feature testing) makes the problem worse.
2023-07-23 11:04:37 -0400 < wasamasa> how would you do actual feature testing?
2023-07-23 11:04:55 -0400 < wasamasa> by porting autoconf to scheme?
2023-07-23 11:05:51 -0400 < mnieper> Dooshki: If this is a problem for you, R6RS may be the better dialect.  Implementations must raise exceptions when standard features are used in a non-standard way.  It also supports library versioning which, when used correctly, makes clear which API version a library implements.
2023-07-23 11:06:41 -0400 < mnieper> wasamasa: You don't have to port autoconf to Scheme.  You can do the feature testing in Scheme.
2023-07-23 11:06:54 -0400 < wasamasa> go on, how would that look like?
2023-07-23 11:07:23 -0400 < mnieper> Depending on the feature, of course.  See Chez Scheme's meta-cond, for example.
2023-07-23 11:07:58 -0400 < mnieper> It works better with R6RS because there you are guaranteed to get an exception if you try to do something out of the domain of your implementation.
2023-07-23 11:08:11 -0400 < wasamasa> in the case of autoconf, the basic concept is simple, generate a file proving the existence of a feature
2023-07-23 11:08:19 -0400 < wasamasa> then compile and see what it emits
2023-07-23 11:08:23 -0400 < Dooshki> mnieper: It's not actually a problem in this project, since I expect the code to be small, and you shouldn't need to use any 3rd party libraries, but I'll definitely keep that in mind if I'd want to implement something larger in Scheme itself
2023-07-23 11:08:31 -0400 < wasamasa> but in the case of scheme, invoking a process in a portable way is an unsolved problem
2023-07-23 11:08:47 -0400 < Dooshki> Thanks a lot for the insight!
2023-07-23 11:08:51 -0400 < mnieper> wasamasa: You can run arbitrary code at expand-time.
2023-07-23 11:09:02 -0400 < mnieper> If you have syntax-case, ER macros, ...
2023-07-23 11:09:35 -0400 < mnieper> Then your macro can expand into the result of your test.
2023-07-23 11:09:53 -0400 < wasamasa> that doesn't solve the lack of agreed upon API to do the feature testing with
2023-07-23 11:10:21 -0400 < mnieper> Of course, if you have to test for something outside of what Scheme has access to, you need some Autoconf-like approach generating something like config.sls instead of config.h.
2023-07-23 11:10:32 -0400 < wasamasa> no, I suspect that to implement bigger projects, you need to embrace the balkanization and use non-portable features
2023-07-23 11:11:09 -0400 < mnieper> wasamasa: One can hide the non-portable features behind libraries.
2023-07-23 11:11:26 -0400 < wasamasa> otherwise you're not getting anywhere if you'd first have to implement a few dozen libraries
2023-07-23 11:12:16 -0400 < mnieper> What does this have to do with configuration directly?
2023-07-23 11:12:49 -0400 < wasamasa> I find it odd to paint cond-expand as the culprit, rather than as something going against your tastes
2023-07-23 11:14:05 -0400 < mnieper> My problem with cond-expand is not code like (cond-expand ((fixnums-are-exactly-63-bit-wide) ...) ((library (foo bar)) ...))
2023-07-23 11:14:42 -0400 < mnieper> My problem is something like (cond-expand (chibi ...) (gauche ...) (some-obscure-feature-identifier-that-happens-to-bet-set ...) ...)
2023-07-23 11:15:03 -0400 < mnieper> This code guaranteedly breaks with the next version of either chibi, gauche, ...
2023-07-23 11:15:54 -0400 < wasamasa> like all cases of monkey-patching, that depends how it's written
2023-07-23 11:15:55 -0400 < mnieper> But even the feature (library (foo bar)) is dangerous without library versioning support.
2023-07-23 11:16:34 -0400 < mnieper> wasamasa: Sure.  And that's why I wrote that "R7RS has ... inviting ..."
2023-07-23 11:16:49 -0400 < mnieper> And if you look at code published, you see that people felt invited! :)
2023-07-23 11:17:05 -0400 < wasamasa> how dare they use features that work for them
2023-07-23 11:17:21 -0400 < mnieper> The original question was about bitrot.
2023-07-23 11:17:28 -0400 < wasamasa> how dare they don't first come up with a new SRFI library solving the problem in a generic way
2023-07-23 11:17:42 -0400 < mnieper> And what works for them today is the recipe for bitrot in the future.
2023-07-23 11:17:50 -0400 < mnieper> This may be no problem for them.
2023-07-23 11:18:11 -0400 < wasamasa> probably not, no
2023-07-23 11:18:31 -0400 < wasamasa> scheme's lack of popularity compared to something like elisp makes it rather unlikely it's a problem for other people
2023-07-23 11:18:45 -0400 < mnieper> If libraries aren't shared, no.
2023-07-23 11:18:56 -0400 < wasamasa> with elisp libraries, people finally ran into the issue of colliding package prefixes
2023-07-23 11:20:19 -0400 < wasamasa> not surprising after like 7k packages
2023-07-23 13:26:21 -0400 < seninha> hi, how does tail recursion work with multiple values? As far as I understand, tail recursion can only work when returning a single value.
2023-07-23 13:28:50 -0400 < mnieper> seninha: It does not depend on the number of values.
2023-07-23 13:29:21 -0400 < mnieper> An implementation has to choose an ABI that allows PTCs where multiple values are returned.
2023-07-23 13:29:55 -0400 < mnieper> seninha: What made you think otherwise?
2023-07-23 13:33:22 -0400 < seninha> i am trying to think how a function consuming and producing multiple values could be recursive;
2023-07-23 13:34:10 -0400 < seninha> idk how it could work
2023-07-23 13:38:41 -0400 < mnieper> https://paste.debian.net/plain/1286737
2023-07-23 13:39:08 -0400 < mnieper> Sorry, forget it. This was not iterative.
2023-07-23 13:39:19 -0400 < Zipheir> seninha: Recursive, or specifically tail-recursive?
2023-07-23 13:40:41 -0400 < mnieper> I meant this: https://paste.debian.net/plain/1286738
2023-07-23 13:41:48 -0400 < Zipheir> With tail-recursion you don't even need let-values, receive, etc.
2023-07-23 13:47:17 -0400 < seninha> i think i got it, the callstack to f is replaced with f itself until it evaluates to two values
2023-07-23 13:48:53 -0400 < mnieper> Think of a tail call as a goto.
2023-07-23 13:49:23 -0400 < Zipheir> It is slightly odd because of the varying number of values returned by f.
2023-07-23 13:49:47 -0400 < mnieper> In a traditional stack model, this means that the return address is left on the stack and the rest of the stack reused for the current call.
2023-07-23 13:50:14 -0400 < Zipheir> No, sorry, I'm wasn't thinking clearly.
2023-07-23 13:50:40 -0400 < mnieper> In my example, f always returns two values. But I forget one f in the named-let, which is no named-let in my code. :)
2023-07-23 13:51:02 -0400 < Zipheir> Ah, true.
2023-07-23 13:51:07 -0400 < mnieper> Corrected, hopefully: https://paste.debian.net/plain/1286740
2023-07-23 13:52:30 -0400 < Zipheir> seninha: There's nothing weird about normal recursion on multiple values, either. You'd just have to bind the values of the recursive call with 'let-values' or 'receive'.
2023-07-23 13:54:33 -0400 < sham1> Or call-with-values if you wish to use the primitive procedure for that
2023-07-23 13:54:51 -0400 < sham1> Well, as primitive as is defined by the standard
2023-07-23 13:56:05 -0400 < Zipheir> In principle, I think let-values and receive are more optimizable.
2023-07-23 13:57:28 -0400 < Zipheir> IIRC there were some complaints about call-with-values on those grounds.
2023-07-23 13:57:33 -0400 < sham1> Well depends on the calling convention. If the convention for returning values is the same as for calling a procedure, it should be some minimal shuffling at most
2023-07-23 13:58:26 -0400 < sham1> And of course on most modern architectures you have enough registers to just contain your values in 99.9% of the time, even when you have two or more returns, because with one return it's trigial
2023-07-23 13:59:22 -0400 < mnieper> sham1: The problem with call-with-values is that the first argument must also be a procedure because c-w-v is a procedure, not syntax.
2023-07-23 14:00:06 -0400 < seninha> thanks, i didn't know about receive and let-values.
2023-07-23 14:00:08 -0400 < sham1> Well there's not much else it could be. I suppose you could have a bare call to values, but that's about it
2023-07-23 14:00:50 -0400 < seninha> I'm reading their SRFI and could not see the difference between them, seems that let-values is a chain of receives
2023-07-23 14:00:52 -0400 < mnieper> See Dybvig's 1997 paper on mvs.  It shows what can be rewritten and how.
2023-07-23 14:00:55 -0400 < sham1> Well, values or a call to call/cc that does the equivalent thing
2023-07-23 14:01:20 -0400 < Zipheir> mnieper: Thanks. I was trying to find the discussion of call-with-values' issues.
2023-07-23 14:01:22 -0400 < sham1> Oh that, okay yeah, but that can already be done even if you have procedures
2023-07-23 14:01:38 -0400 < mnieper> sham1: There are other procedures apart from values that can yield multiple values.
2023-07-23 14:02:03 -0400 < mnieper> In the c-w-v interface, the procedure has to be packaged into a thunk first.
2023-07-23 14:02:26 -0400 < Zipheir> Which may be opaque, and thus harder to statically analyze.
2023-07-23 14:02:34 -0400 < sham1> The only other one I can think about is call/cc, but that's also how values is canonically implemented
2023-07-23 14:02:49 -0400 < mnieper> seninha: Here are hopefully helpful procedures: https://srfi.schemers.org/srfi-210/srfi-210.html
2023-07-23 14:02:58 -0400 < sham1> Anything else would just be some combination of those
2023-07-23 14:03:35 -0400 < mnieper> sham1: div-and-mode
2023-07-23 14:03:39 -0400 < mnieper> div-and-mod
2023-07-23 14:03:47 -0400 < mnieper> Or any procedure you write.
2023-07-23 14:04:07 -0400 < sham1> div-and-mod is implemented as-if it's return values are returned by use of values
2023-07-23 14:04:13 -0400 < sham1> It's*
2023-07-23 14:04:16 -0400 < sham1> Its**
2023-07-23 14:04:20 -0400 < sham1> Good grief
2023-07-23 14:04:21 -0400 < Zipheir> floor/, etc. in Scheme
2023-07-23 14:04:36 -0400 < mnieper> sham1: Maybe we are talking past each other.
2023-07-23 14:04:53 -0400 < sham1> Maybe we are
2023-07-23 14:06:33 -0400 < mnieper> (receive F E B) => (call-with-values (lambda () E) (lambda F B))
2023-07-23 14:06:44 -0400 < mnieper> The problem is the first lambda.
2023-07-23 14:06:53 -0400 < sham1> A compiler should be able to optimise thst
2023-07-23 14:06:54 -0400 < seninha> btw, i just finished section 5.4 of SICP, i've been delaying reading it for quite a long time. I just need to read the compiling section to finish it.
2023-07-23 14:06:55 -0400 < seninha> Reading about the register machine implementation of the evaluator inspired me to add tail call optimization to my never-completed/always-changing lisp implementation
2023-07-23 14:07:27 -0400 < mnieper> sham1: Yes it should be able to do it.
2023-07-23 14:07:45 -0400 < mnieper> But that it has to do it means that c-w-v is not the best primitive.
2023-07-23 14:08:22 -0400 < sham1> Well sure, but that would also apply to other things, no?
2023-07-23 14:08:35 -0400 < mnieper> Yes, to some.
2023-07-23 14:09:10 -0400 < mnieper> But, luckily, Scheme has `if' and not just `if-procedure' from SRFI 235.
2023-07-23 14:09:14 -0400 < sham1> The fact that we define formally define let as an immediately invoked lambda means that it's perhaps not the best way to do this, because we assume that the compiler is smart enough to turn that into efficient code
2023-07-23 14:10:12 -0400 < mnieper> sham1: I would categorize it as a similar problem if `let' were not offered by the standard.
2023-07-23 14:10:51 -0400 < mnieper> What's core or not is pedagogical, somehow.
2023-07-23 14:11:45 -0400 < sham1> I don't think that logic works here though, since c-w-v is also in the standard and clearly it has this efficiency problem. Of course we can argue if it is a good primitive for multiple values, but we also get the problem where we first have to know just what an alternative would be
2023-07-23 14:12:06 -0400 < sham1> receive?
2023-07-23 14:12:32 -0400 < sham1> Because the dygvib paper does still use what is essentially c-w-v
2023-07-23 14:13:07 -0400 < mnieper> `with-values' from SRFI 210 (and Dybvig's paper).
2023-07-23 14:14:11 -0400 < sham1> Since the paper, assuming I'm even looking at the correct one, has mv-call which can be used to implement c-w-v trivially
2023-07-23 14:14:53 -0400 < mnieper> To give another example, Marc Feeley argued that `call/cc` should take additional arguments that are passed down to its argument along with the current continuation.
2023-07-23 14:15:05 -0400 < mnieper> This can help avoiding the creation of closures.
2023-07-23 14:15:29 -0400 < mnieper> All closed-over variables would become arguments.
2023-07-23 14:15:45 -0400 < mnieper> Gambit has this optimization IIRC.
2023-07-23 14:17:15 -0400 < Zipheir> 'with-values' seems to be a good way to fix the problem.
2023-07-23 14:29:47 -0400 < sham1> mnieper: so something like (call/cc func args ...) where func would be something like (lambda (k . args)) ?
2023-07-23 14:30:59 -0400 < Zipheir> No need for the dotted tail, I think.
2023-07-23 14:31:20 -0400 < mnieper> Zipheir: yes
2023-07-23 14:31:24 -0400 < sham1> That's for the full generality since you don't know just how many args you'll get
2023-07-23 14:31:42 -0400 < mnieper> I meant: sham1: yes :)
2023-07-23 14:31:55 -0400 < sham1> Although in practice you would since most of the time the procedure passed to call/cc is a lambda defined then and there
2023-07-23 14:32:35 -0400 < Zipheir> Right, right.
2023-07-23 14:33:08 -0400 < mnieper> An optimizing compiler would translate (call/cc (lambda (c) ...)) into (call/cc (lambda (c x ...) ...) x ...)
2023-07-23 14:33:19 -0400 < mnieper> where x ... are all variables free in the lambda body.
2023-07-23 14:33:29 -0400 < Zipheir> Clever.
2023-07-23 14:34:13 -0400 < sham1> That is clever
2023-07-23 14:50:06 -0400 < jcowan> mnieper`: Why would you want to learn Hungarian, when all Hungarians over age five already speak German and/or English?  Hungarian poetry aside, the answer is: To talk to Hungarians.
2023-07-23 14:50:54 -0400 < mnieper`> +1
2023-07-23 14:51:23 -0400 < jcowan> There are a lot of people who know Lua, and if you embed Lua they will be able to write extensions to your program without having to learn a completely new language.  I mean, to Scheme-speakers, Lua is just a dialect of Scheme, but not so to Lua-speakers.
2023-07-23 14:51:39 -0400 < wasamasa> you can even use fennel
2023-07-23 14:55:25 -0400 < gwatt> mnieper`: How much does that multi-arity call/cc optimization improve memory usage? Does it not require allocating the rest args instead of a closure?
2023-07-23 14:56:55 -0400 < mnieper`> My question about why I should learn Lua (at least if I had the time) had this bit of serious background.
2023-07-23 14:57:09 -0400 < mnieper`> gwatt: The args can go into registers
2023-07-23 14:57:11 -0400 < dpk> also, LuaJIT is mad science. (imagine an implementation as fast as Chez with a footprint the size of Chibi)
2023-07-23 14:59:21 -0400 < gwatt> mnieper`: up to a point, sure, but that is heavily dependent on the calling convention.
2023-07-23 14:59:55 -0400 < mnieper`> dpk: Does LuaJIT contain the full compiler and development environment?
2023-07-23 15:00:50 -0400 < mnieper`> gwatt: As long as procedure arguments are not allocated on the heap (where closures go), it does matter a lot.
2023-07-23 15:02:17 -0400 < mnieper`> Is Scheme translatable to Lua more or less directly without loss or is Scheme more expressive?
2023-07-23 15:02:43 -0400 < dpk> Scheme is more expressive, but probably also more optimizable than Lua
2023-07-23 15:03:21 -0400 < dpk> i don't know what you mean by full compiler and development environment
2023-07-23 15:03:28 -0400 < dpk> it's a JITting interpreter
2023-07-23 15:03:39 -0400 < dpk> you give it your code, it runs the code, and the code is fast
2023-07-23 15:05:17 -0400 < mnieper`> You give it source code?
2023-07-23 15:05:49 -0400 < wasamasa> it's the JIT
2023-07-23 15:07:04 -0400 < dpk> yeah, there's no compile step
2023-07-23 15:07:04 -0400 < mnieper`> It would be interesting to see and experiment with such an interpreter for Scheme. Chez is an AOT compiler, so it has to statically analyze the code.
2023-07-23 15:07:10 -0400 < dpk> and there is a REPL
2023-07-23 15:07:22 -0400 < dpk> if that's what you meant by development environment
2023-07-23 15:07:35 -0400 < mnieper`> Yes, and maybe a simple debugger or inspector.
2023-07-23 15:08:06 -0400 < mnieper`> The stdlib is also part of the footprint?
2023-07-23 15:08:18 -0400 < dpk> there isn't much of one in Lua, but yes
2023-07-23 15:08:58 -0400 < sham1> Lua is very small in terms of the standard library, because of its role as being primarily embedded
2023-07-23 15:09:15 -0400 < sham1> The expectation is that the embedding program will provide most functionality as needed by the specific application
2023-07-23 15:09:24 -0400 < sham1> It originated as a way to specify configurations
2023-07-23 15:09:39 -0400 < dpk> but its core has ‘features’ like tables being the main data structure, meaning e.g. Scheme's record library isn't needed per se, so one can't really meaningfully compare
2023-07-23 15:09:50 -0400 < dpk> but that sort of thing is what i meant by Scheme probably being more optimizable
2023-07-23 15:10:02 -0400 < dpk> the table is a very dynamic data structure compared to Scheme's very static record types
2023-07-23 15:10:21 -0400 < mnieper`> Just checking the size of Chibi on my notebook
2023-07-23 15:10:35 -0400 < sham1> Well the tables have to do both the duty of arrays/vectors and also of hashmaps/mappings
2023-07-23 15:10:56 -0400 < sham1> And also be able to do prototypical OO because of metatables. It's a whole mess
2023-07-23 15:11:14 -0400 < mnieper`> Including Chibi's libraries, it is more than 4 MB
2023-07-23 15:11:53 -0400 < dpk> dpk@Copernicus ~> du -cksh /nix/store/mm53mbac7andqqy8xilb3v0vrssk9pyb-luajit-2.1.0-2022-10-04
2023-07-23 15:11:53 -0400 < dpk> 2.5M	/nix/store/mm53mbac7andqqy8xilb3v0vrssk9pyb-luajit-2.1.0-2022-10-04
2023-07-23 15:12:43 -0400 < sham1> Yeah, and within that size we have one of, if not the fastest JIT engines
2023-07-23 15:14:30 -0400 < mnieper`> Chez Scheme's binary is 384K on my system and its boot file is 936K (becomes inflated in memory).
2023-07-23 15:14:55 -0400 < mnieper`> 1,3 MB disk space.
2023-07-23 15:15:12 -0400 < sham1> Of course, rather famously, Mike Pall who does LuaJIT is a robot from the future, as is said in this website about benchmarking a language called Wren: <https://wren.io/performance.html>
2023-07-23 15:15:34 -0400 < sham1> > uaJIT is run with the JIT disabled (i.e. in bytecode interpreter mode) since I want to support platforms where JIT-compilation is disallowed. LuaJIT with the JIT enabled is much faster than all of the other languages benchmarked, including Wren, because Mike Pall is a robot from the future.
2023-07-23 15:15:34 -0400 < mnieper`> If I used image files for Chibi, it would probably be better than > 4MB
2023-07-23 15:16:05 -0400 < dpk> i can't easily measure for a fair comparison with Chez because i have to install Racket's Chez to get it to run on my Aarch64 Mac, and i don't do that through Nix
2023-07-23 15:16:38 -0400 < mnieper`> Don't sell your soul to Apple. :-p ;-)
2023-07-23 15:16:50 -0400 < sham1> I think that has already happened in this case
2023-07-23 15:18:06 -0400 < mnieper`> There's /dev/null (if that works for hardware, don't know).
2023-07-23 15:19:24 -0400 < mnieper`> How does LuaJIT compare to modern JS engines? JS is also not easily optimizable.
2023-07-23 15:19:31 -0400 < mnieper`> At least less than Scheme, I think.
2023-07-23 15:19:41 -0400 < sham1> Usually faster
2023-07-23 15:20:09 -0400 < dpk> meh. it has a Unix terminal (Unix somehow being the best of the utterly miserable selection of operating systems we have today, if you want to get real work done) and it runs Lightroom. admittedly, since there is now WSL on Windows, that's now also the case over there
2023-07-23 15:20:20 -0400 < mnieper`> That is very impressive, given how much money goes into JS.
2023-07-23 15:20:41 -0400 < mnieper`> My Linux system also has a Unix terminal.
2023-07-23 15:23:14 -0400 < dpk> JS is a much bigger and more complex language than Lua, especially considering some very poorly-designed features from the very early days
2023-07-23 15:25:25 -0400 < mnieper`> Optimizing Lua table access may be similar to optimizing JS object access.
2023-07-23 15:28:32 -0400 < aeth> Lua and JS are very, very similar languages conceptually. Of course, Lua is minimalist and has slightly different syntax (slightly by a Lisper's standards, anyway)
2023-07-23 15:28:59 -0400 < aeth> But I'd consider them as basically in the same conceptual family. And if you get OOP working in Lua with tables it's kind of JS-like
2023-07-23 18:14:35 -0400 < jcowan> Actually, Smalltalk gets along fine with just lambda and if-procedure and no if, because the Smalltalk compiler optimizes explicit lambdas.  (The same for other control structures.)
2023-07-23 18:15:46 -0400 < jcowan> Scheme compilers can do the same thing with c-w-v.
2023-07-23 21:19:56 -0400 < seninha> my toy lisp finally is tail call optimized! https://ttm.sh/Bfy.png
2023-07-23 23:05:09 -0400 -!- mode/#scheme [+o Zipheir] by ChanServ
--- Day changed Mon Jul 24 2023
2023-07-24 01:29:09 -0400 < siraben> seninha: nice!
2023-07-24 01:29:22 -0400 < siraben> what strategy did you use to TCO it?
2023-07-24 01:57:29 -0400 < mnieper> jcowan: The point was not that the lambda in c-w-v cannot be optimized away (easily), but the fact that it should could imply (by some measure) that c-w-v is not the best choice of a primitive form.
2023-07-24 01:58:02 -0400 < jcowan> And what would the best choice be?
2023-07-24 01:59:08 -0400 < mnieper> If the only syntax of Smalltalk is a lambda, the Smalltalk makes a lot of sense, on the other hand.  Likewise, in Schemes before R5RS, c-w-v made a lot of sense because it allowed the implementation of multiple values more or less in user space without having to introduce new syntactic forms.
2023-07-24 01:59:33 -0400 < mnieper> jcowan: One can argue that `with-values' is a better primitive.
2023-07-24 02:00:00 -0400 < mnieper> (with-values E C) => (call-with-values (lambda () E) C)
2023-07-24 02:00:25 -0400 < mnieper> Halfway between c-w-v and  receive.
2023-07-24 02:03:07 -0400 < mnieper> Re LuaJIT: With these impressive results for a jitting interpreter, maybe a fully dynamic Lisp (including fexprs) can be made efficient.  The argument (by Pitman) that finally removed fexprs was that with fexprs a program is not statically analyzable, making AOT compilation somewhere between very hard and impossible.
2023-07-24 02:03:40 -0400 < mnieper> Maybe runtime analysis can help; haven't thought about it, though.
2023-07-24 02:12:56 -0400 < jcowan> That's only part of the argument against fexprs, the other part being that they are difficult for the *programmer* to analyze, especially in hindsight.
2023-07-24 02:15:03 -0400 < jcowan> The inability to optimize a program may be tolerable; the inability to understand it is pretty much fatal.
2023-07-24 02:18:57 -0400 < mnieper> Okay.
2023-07-24 02:19:13 -0400 < mnieper> So, maybe more of a theoretical question.
2023-07-24 02:21:08 -0400  * jcowan nods
2023-07-24 02:21:24 -0400 < jcowan> btw, I spotted an error in SRFI 210 (which can be fixed by erratum)
2023-07-24 02:21:41 -0400 < jcowan> for "the function multiple-value-call" read "the special operator multiple-value-call"
2023-07-24 02:21:57 -0400 < jcowan> it is obviously not a function (procedure)
2023-07-24 02:24:12 -0400 < jcowan> http://lambda-the-ultimate.org/node/3640 is a good fexprs vs macros discussion
2023-07-24 02:28:35 -0400 < mnieper> jcowan: Thanks for spotting the error.
2023-07-24 02:28:48 -0400 < jcowan> (Probably my own error, in fact)
2023-07-24 02:30:43 -0400 < mnieper> I just sent a message to the SRFI 210 ML so that Arthur is informed.
2023-07-24 02:33:25 -0400 < mnieper> jcowan: And thanks for copying relavant bits of our discussion here to Codeberg issue #104.
2023-07-24 02:33:42 -0400 < jcowan> Thanks on both counts
2023-07-24 02:34:11 -0400 < mnieper> Are your questions/comments fully answered?
2023-07-24 03:41:18 -0400 < mnieper> jcowan: Thanks for the lambda-the-ultimate reference.
2023-07-24 03:41:46 -0400 < mnieper> John Shutt seems to argue that fexprs are okay when combined with lexical scoping.
2023-07-24 04:30:21 -0400 -!- wasa is now known as wasamasa
2023-07-24 04:45:33 -0400 < cow_2001> How do you mark bits of code "unimplemented"?
2023-07-24 04:45:54 -0400 < cow_2001> Instead of just putting '() in some places and then forget about those and be utterly perplexed
2023-07-24 04:46:06 -0400 < cow_2001> maybe just (error "unimplemented")?
2023-07-24 04:48:36 -0400 < wasamasa> pretty much
2023-07-24 04:49:26 -0400 < cow_2001> oh my gourd
2023-07-24 04:50:03 -0400 < cow_2001> Okay, you know what?  I need a shower.  This constant sauna I've been living in is not good for my odour.
2023-07-24 04:50:25 -0400 < cow_2001> wasamasa: Thank you!
2023-07-24 04:50:58 -0400 < wasamasa> alternatively, if you want things to error out at compilation time, () does the trick
2023-07-24 04:51:04 -0400 < wasamasa> no quote
2023-07-24 04:57:25 -0400 < mdhughes> Protip: Always put the function name in your errors, so you know where it crashed.
2023-07-24 05:10:08 -0400 < mnieper> This is why R6RS's `error' (and `assertion-violation') has the `who' argument.
2023-07-24 05:11:23 -0400 < mnieper> cow_2001: Depending on the Scheme you use, an `(assert #f)' or `(assert (and #f 'frobnicate-not-implemented))' may be more helpful.
2023-07-24 05:11:41 -0400 < mnieper> `assert' is syntax and you should get precide source location information.
2023-07-24 05:14:22 -0400 < mnieper> Maybe it is a good idea to invent a "marker macro": https://paste.debian.net/plain/1286775
2023-07-24 05:14:54 -0400 < mnieper> You can then just write (fixme "handle negative numbers")
2023-07-24 05:17:48 -0400 < mnieper> dpk: Could you answer my follow-up question on R6RS compatibility in Codeberg issue #121?  At least when this question is solved in one way, many other questions will have an answer as well.  On the other hand, as long as there is no decision on R6RS compatibility, we cannot really move forward without going in circles.
2023-07-24 05:36:41 -0400 < cow_2001> I can just write the unquoted symbol "unimplemented"
2023-07-24 05:37:02 -0400 < cow_2001> would have been nice if I had some sort of a form that would fail at compile time
2023-07-24 05:38:04 -0400 < cow_2001> A fancy scheme implementation would tell me where it bumped into an unbound variable.
2023-07-24 05:38:11 -0400 < cow_2001> mnieper:
2023-07-24 05:38:19 -0400 < cow_2001> err mdhughes ^
2023-07-24 05:38:31 -0400 < cow_2001> oh! () is the trick.
2023-07-24 05:38:46 -0400 < cow_2001> (reading the log in parts is bad.)
2023-07-24 05:40:05 -0400 < cow_2001> Hmm... but () doesn't fail because I used it, but then again, this is scheme. I don't know what I'll use.
2023-07-24 05:49:22 -0400 < mdhughes> You don't always want to dig thru a debug log, and if you give it to users/testers they won't.
2023-07-24 05:52:42 -0400 < cow_2001> mdhughes: Ah, of course.  Users!  Sorry.
2023-07-24 05:53:56 -0400 < cow_2001> Not blaming users.  I am one.  We're all mortals after all and cannot debug every crashing program.
2023-07-24 05:54:44 -0400 < mdhughes> Of course I grew up in a time when error codes were just numbers, assigned sequentially as created. Then later IBM's error code system. https://archive.org/details/hug-atari-error-codes
2023-07-24 05:54:57 -0400 < dpk> () as code may be a compile error rather than a runtime error (it is in Chibi, for example)
2023-07-24 05:55:34 -0400 < dpk> (error "not implemented yet") is probably the best solution
2023-07-24 05:56:11 -0400 < cow_2001> If you're lazy you can you (define (poop) poop-not-implemented-yet)
2023-07-24 05:56:45 -0400 < cow_2001> Wait, no.  That'll only fail at runtime.
2023-07-24 05:56:56 -0400 < dpk> an unbound identifier is even more likely to fail at compile time
2023-07-24 05:57:19 -0400 < cow_2001> Not here in Guileland... <_<
2023-07-24 05:57:50 -0400 < dpk> really?
2023-07-24 05:58:05 -0400 < dpk> at the REPL, or when compiling a library/program?
2023-07-24 05:58:06 -0400 < cow_2001> You can always get the current environment and inject stuff into it or delete stuff from it
2023-07-24 05:58:41 -0400 < cow_2001> When running, it'll run until it tries to get the value of that unbound variable.
2023-07-24 06:01:33 -0400 < wasamasa> honestly, I prefer runtime errors, that way I can incrementally develop until fixing them
2023-07-24 06:01:35 -0400 < cow_2001> Things like string->symbol make it impossible to know beforehand.
2023-07-24 06:01:45 -0400 < wasamasa> rather than the compiler stopping early because I inserted a () accidentally
2023-07-24 06:01:52 -0400 < dpk> mnieper: am out and about atm but will try to remember later
2023-07-24 06:02:12 -0400 < cow_2001> wasamasa: It's not just early, It's the earliest.
2023-07-24 06:02:39 -0400 < cow_2001> should have used a prick there, not a comma.
2023-07-24 06:02:47 -0400 < dpk> cow_2001: string->symbol is irrelevant, only eval could potentially create/access bindings at runtime
2023-07-24 06:03:37 -0400 < cow_2001> dpk: You could take user input, convert to a symbol, delete it or assign a value to it, and then eval.
2023-07-24 06:04:01 -0400 < cow_2001> err
2023-07-24 06:04:04 -0400 < cow_2001> ya
2023-07-24 06:04:22 -0400 < cow_2001> Read eval puts everything up in the air, no?
2023-07-24 06:04:54 -0400 < cow_2001> I'm still in chapter 3.  I should go back to copying stuff from the pages until I can start writing exercise solutions.
2023-07-24 06:05:19 -0400 < cow_2001> Sorry if I am talking nonsense.
2023-07-24 06:14:16 -0400 < mnieper> cow_2001: Use R6RS to get an undefined variable violation. Or use a macro that throws an error at compile-time.
2023-07-24 06:14:20 -0400 < mnieper> See my fixme macro.
2023-07-24 09:14:06 -0400 < cow_2001> What was that form used to find which version / implementation is currently used, kind of like the C #ifdef
2023-07-24 09:15:29 -0400 < mnieper>  You mean `cond-expand', I guess.
2023-07-24 09:15:43 -0400 < cow_2001> Yes!
2023-07-24 09:16:18 -0400 < mnieper> If you want to use it, don't ask me whether you should use it. ;)
2023-07-24 09:16:19 -0400 < cow_2001> Says it's in SRFI-0.
2023-07-24 09:28:20 -0400 < cow_2001> <_<
2023-07-24 09:50:00 -0400 < mdhughes> but now you need SRFI-00 to test for the presence of SRFI-0.
2023-07-24 09:50:25 -0400 < cow_2001> :|
2023-07-24 09:50:34 -0400 < cow_2001> Oh no.
2023-07-24 09:51:06 -0400 < sham1> That is truly a conundrum
2023-07-24 11:00:57 -0400 < jcowan> mnieper: I don't see any question about R6RS compatibility in #121.
2023-07-24 11:23:05 -0400 < mnieper> jcowan: In #121, dpk objects to "The Foundations are an implementation of R6RS." (one of the many items on my list of things we have settled/have to settle for the foundations).
2023-07-24 11:23:19 -0400 < mnieper> My reply in #121: "What is your argument against it?"
2023-07-24 11:23:34 -0400 < mnieper> For reference: https://codeberg.org/scheme/r7rs/wiki/Foundations-Issues
2023-07-24 11:24:53 -0400 < mnieper> (The tick-offs may still be subject to debate because of the WIP status.)
2023-07-24 11:27:54 -0400 < mnieper> The question of R6RS-compatibility touches so many other issues (or would resolve them) that the question is a foundational one for the Foundations; this is why I hope we find some answer soon.
2023-07-24 11:28:12 -0400 < mnieper> (R7RS-small compatibility is not touched by this, of course.)
2023-07-24 11:59:50 -0400 < sham1> What behaviour shall be used when R7-small and R6 contradict each other
2023-07-24 12:00:50 -0400 < sham1> For example with let, the fact that R6RS disallows you from re-entering the continuation of the let binding initializers makes it incompatible with R7-small, since its behaviour is inherited from R5
2023-07-24 12:01:04 -0400 < sham1> Or do we just say "both"
2023-07-24 12:01:51 -0400 < gwatt> Does R6RS actually prohibit that, or just say "it is an error"?
2023-07-24 12:02:37 -0400 < sham1> I personally like the R6 behaviour better. It's easier to optimise, but that ship has sailed over a decade ago, when R7-small was ratified
2023-07-24 12:03:30 -0400 < jcowan> OtoH, does R5 actually *prohibit* implementations from disallowing such behavior in initializers?
2023-07-24 12:04:57 -0400 < jcowan> mnieper: I remember you saying that there is a procedure in R6RS that accepts multiple lists and chokes if they are different lengths, but R7RS truncates to the shortest length.  What procedure was that?
2023-07-24 12:07:01 -0400 < sham1> I mean, at least with a cursory reading the R7-small let doesn't prohibit using the R6 behaviour, but I don't know if it's the kind of thing we cannot make stricter on account of someone somewhere maybe depending on call/cc-ing into <init_1> of <variable_1> of let
2023-07-24 12:07:02 -0400 < mnieper> sham1: You mean letrec, not let.
2023-07-24 12:07:03 -0400 < jcowan> In addition, I spotted something weird about the &undefined condition type: its description says "This type describes unbound identifiers in the program", but there is no actual MUSTard (that I can find) saying that it must or should be signaled in any circumstance.
2023-07-24 12:07:08 -0400 < sham1> Err, letrec
2023-07-24 12:07:10 -0400 < sham1> Yeah
2023-07-24 12:07:56 -0400 < mnieper> sham1: The R6RS solution is arguably correct (and that's what most Schemes, even R7RS Schemes implement), but, in principle, (scheme base) can export a different version than (rnrs base).
2023-07-24 12:08:17 -0400 < sham1> Right, but that'd be extra effort for implementors, and my question is whether that's a good thing
2023-07-24 12:08:35 -0400 < mnieper> sham1: Implementers follow the R6RS semantics anyway.
2023-07-24 12:08:44 -0400 < mnieper> Even R5RS schemes followed the R6RS semantics.
2023-07-24 12:08:49 -0400 < sham1> Although if R7RS could get away with using the (saner) R6RS letrec then that'd be marvellous
2023-07-24 12:08:59 -0400 < mnieper> File an erratum :)
2023-07-24 12:09:36 -0400 < mnieper> R7RS uses the sane semantics for letrec*.  So it is not very consistent; maybe not fixing letrec was an oversight.
2023-07-24 12:09:38 -0400 < jcowan> Now if a variable is unbound as opposed to undefined, it is said to be a syntax error, which means (IIUC) that it can be reported before execution begins.
2023-07-24 12:09:52 -0400 < jcowan> I think you are right about fixing letrec.
2023-07-24 12:10:05 -0400 < sham1> mnieper: yeah. Also means that an implementation can't just implement letrec in terms of letrec*
2023-07-24 12:10:35 -0400 < mnieper> jcowan: `map' is an example of where R6RS raises an exception on lists of different lengths, but R7RS doesn't.
2023-07-24 12:10:55 -0400 < mnieper> The versions in (rnrs base) and (scheme base) have to be different.
2023-07-24 12:11:11 -0400 < mnieper> For the vast majority of uses cases, you want the (rnrs base) version.
2023-07-24 12:12:06 -0400 < mnieper> jcowan: An unbound variable is a syntax violation in R6RS, so much is clear.
2023-07-24 12:12:39 -0400 < jcowan> Yes, but as we now know, unbound != undefined.
2023-07-24 12:13:27 -0400 < mnieper> The naming of the condition type is not the best one.
2023-07-24 12:14:12 -0400 < jcowan> Fair enough.
2023-07-24 12:15:10 -0400 < jcowan> One of the things that always worries me when standards prescribe that an exception is thrown is that a compiler that can detect that the exception will always happen can reduce the code to just call `raise`, but can't reject the program outright.
2023-07-24 12:15:35 -0400 < jcowan> "Is an error"/UB semantics don't have that problem.
2023-07-24 12:16:33 -0400 < andydude> I recently read WAIIG, which implemented "return" in a way that kind of reminds me of exceptions.
2023-07-24 12:17:40 -0400 < mnieper> One more thing about letrec(*): If a variable bound by letrec(*) is used before it is initialized, an implementation MUST report this by raising an &assertion violation.  It MAY detect a violation of the call/cc condition sham1 talked about.
2023-07-24 12:17:49 -0400 < mnieper> See page 36 of the R6RS.
2023-07-24 12:18:46 -0400 < sham1> Well, an exception is just a continuation, just like an escape continuation you'd use for return
2023-07-24 12:18:52 -0400 < sham1> Well, "just"
2023-07-24 12:18:54 -0400 < mnieper> jcowan: What you say about UB is what C compilers use aggressively and why C is so complicated.
2023-07-24 12:19:12 -0400 < mnieper> ... to use right.
2023-07-24 12:19:34 -0400 < jcowan> Right, but that is because C programmers value only 3 things: (a) performance, (b) perfomance, (c) I lied, there is no third thing.
2023-07-24 12:20:23 -0400 < jcowan> *Most* Scheme programmers don't think like that.
2023-07-24 12:20:39 -0400 < mnieper> Ah, I think I misunderstood you.
2023-07-24 12:21:23 -0400 < mnieper> You meant that Scheme should not do whatever on UB but already throw an error at compile-time.
2023-07-24 12:21:33 -0400 < jcowan> Yes.
2023-07-24 12:21:56 -0400 < jcowan> Or at least have the option to do so.  Some UB is not detectable until runtime.
2023-07-24 12:22:16 -0400 < mnieper> An implementation is always free to emit a warning.
2023-07-24 12:22:22 -0400 < mnieper> (Or a &warning. :))
2023-07-24 12:22:32 -0400 < sham1> Is it free to emit an error
2023-07-24 12:23:01 -0400 < mnieper> Given the program (+ 1 'a) it can have two meanings:
2023-07-24 12:23:53 -0400 < mnieper> (a) It is typo/programmer error. (b) The programmer intended this to be a cheap way to implement that the compiled program raises an exception.
2023-07-24 12:24:04 -0400 < mnieper> How can the implementation know, sham1?
2023-07-24 12:24:42 -0400 < sham1> Well in this case it's easy because the static analysis can see that "this will always error, so I'll just throw during compilation"
2023-07-24 12:25:01 -0400 < sham1> Even if it is a typographical error, you want to catch it at compile-time
2023-07-24 12:25:08 -0400 < sham1> And by compile-time I also mean REPL time
2023-07-24 12:26:02 -0400 < mnieper> This is probably conforming to the standard; R6RS (or any other R7RS) does not say anything about WHEN is compile or execution time.  So your compiler can just execute such programs directly. :)
2023-07-24 12:26:22 -0400 < mnieper> But what about (begin (delete-disk) (+ 1 'a)) ?
2023-07-24 12:26:35 -0400 < mnieper> You may want to delete the disk of your client and not your disk.
2023-07-24 12:27:09 -0400 < mnieper> I think it is best if the compiler emits a warning.
2023-07-24 12:27:18 -0400 < mnieper> (This is also what C compilers do.)
2023-07-24 12:28:04 -0400 < mnieper> For example, Chez warns if I have a procedure with the wrong arity in the code.
2023-07-24 12:28:13 -0400 < sham1> Static analysis or partial evaluation wouldn't (and IMO shouldn't) do the side-effect of deleting the disk. And yeah, C compilers do emit the warnings, but some of the standard diagnostics are defined to be errors instead, which in this case would be the case and analysable even if the compiler doesn't evaluate the delete-disk then and there
2023-07-24 12:28:27 -0400 < sham1> Or any side-effects as such
2023-07-24 12:28:48 -0400 < mnieper> sham1: I didn't mean that static analysis should or would delete this disk.
2023-07-24 12:28:54 -0400 < mnieper> It was about the time when the program is run.
2023-07-24 12:29:47 -0400 < mnieper> In all but the simplest programs, the halting problem prevents a global solution.
2023-07-24 12:30:17 -0400 < mnieper> If a program contains something like (define (f x) (if x (car 0) '())), the compiler can only emit a warning.
2023-07-24 12:30:37 -0400 < mnieper> Refusing the program would be wrong because we don't know in general the values f is called with.
2023-07-24 12:30:51 -0400 < sham1> That's true
2023-07-24 13:02:33 -0400 < mnieper> So the best answer to John's observation is, I think, encourage implementations to emit plenty of warnings when code looks dubious to their static analyzers.
2023-07-24 13:08:26 -0400 <@Zipheir> "Warning: Your code looks dubious." :)
2023-07-24 13:10:41 -0400 < sham1> STYLE WARNING: This code looks silly. Please fix it: (car 'a)
2023-07-24 13:10:41 -0400 <@Zipheir> "Warning: Here I am, static analyzer the size of a planet, trudging through another day of your one-armed ifs."
2023-07-24 13:16:16 -0400 <@Zipheir> I'm reminded of Asimov's story "All the Troubles in the World" in which the world computer becomes suicidal after years of analyzing the humanity's horrors.
2023-07-24 13:16:28 -0400 <@Zipheir> s/the/all of/
2023-07-24 13:17:29 -0400 <@Zipheir> A Sufficiently Smart Compiler might be very depressed.
2023-07-24 14:12:15 -0400 < seninha> after one year staled i am continuing my toy lisp project, here's its spec (some parts blatantly stolen from r5rs and sicp): https://github.com/phillbush/simp/blob/master/simp.7.pdf
2023-07-24 14:12:56 -0400 < seninha> basically vector-based (rather than cons-cell-based) scheme with kernel-like macros
2023-07-24 14:13:32 -0400 < seninha> it currently does not support sequences, sono (lambda (x) thing0 thing1)
2023-07-24 14:13:38 -0400 < seninha> s,sono,so no,
2023-07-24 14:28:52 -0400 < jcowan> mnieper: R6 does not specify raising an exception for `map`; indeed, the MUSTard is SHOULD.
2023-07-24 14:29:17 -0400 < jcowan> So the claim that R6 systems will always puke on (map '(1 2) '(1 2 3)) is not necessarily true.
2023-07-24 14:29:45 -0400 < sham1> Well it should puke on that because there's no procedure there
2023-07-24 14:29:47 -0400  * sham1 runs
2023-07-24 14:33:37 -0400 < mnieper> jcowan: You are right.  Yet, an implementation needs a good reason not to check by definition of SHOULD in R6RS.
2023-07-24 14:34:09 -0400 < jcowan> Compatibility with r7rs `map` might be a good reason.
2023-07-24 14:34:31 -0400 < jcowan> sham1: the procedure is named ||
2023-07-24 14:34:33 -0400 < sham1> And I'm assuming that R7RS is not allowed to barf on that
2023-07-24 14:34:48 -0400 < jcowan> R7 truncates to the shortest length
2023-07-24 14:35:02 -0400 < sham1> Right, so yeah
2023-07-24 14:35:10 -0400 < mnieper> jcowan: It might; but in the case of `map' it really should raise an exception.
2023-07-24 14:35:12 -0400 < sham1> Anyway, why is map under "control features" instead of "pairs and lists"
2023-07-24 14:35:23 -0400 < mnieper> sham1: Because it is higher-order.
2023-07-24 14:35:30 -0400 < sham1> okay
2023-07-24 14:35:31 -0400 < jcowan> Because it has an argument that's a procedure.
2023-07-24 14:36:11 -0400 <@Zipheir> So the RnRS thinking is of 'map' as a loop?
2023-07-24 14:36:33 -0400 < jcowan> Yes
2023-07-24 14:36:48 -0400 <@Zipheir> That agrees poorly with its unspecified order of evaluation.
2023-07-24 14:36:51 -0400 < jcowan> ditto for-each
2023-07-24 14:37:36 -0400 < mnieper> Simple definition: when something can interfere with call/cc, it is a control feature :)
2023-07-24 14:37:46 -0400 < jcowan> It's a loop that executes its passes in an unspecified order.
2023-07-24 14:37:49 -0400 <@Zipheir> Maybe 'map' is just a poorly-controllable control feature. :)
2023-07-24 14:38:05 -0400 <@Zipheir> mnieper: That's a good one. :)
2023-07-24 14:38:47 -0400 < mnieper> jcowan: I would leave the R6RS SHOULDs as is.  Then an implementation does not need to provide both versions and can just take the R7RS one.
2023-07-24 14:39:43 -0400 < jcowan> Just so
2023-07-24 14:40:51 -0400 < jcowan> I think my answer on R6RS is that a conforming implementation of R7-large must provide the (rnrs * (6)) libraries, but that we should not, unless absolutely necessary, write any (rnrs * (7)) libraries.
2023-07-24 14:41:05 -0400 < jcowan> iow, R6RS is encapsulated
2023-07-24 14:41:38 -0400 < sham1> Yeah. (rnrs * (7)) would feel quite weird with how we already have the (scheme *) and (srfi *) namespaces already
2023-07-24 14:41:57 -0400 < mnieper> I would use it.
2023-07-24 14:42:27 -0400 < sham1> So would (scheme base) map to (rnrs base (7))? Or whatever the equivalent R6 package would be but with the version incremented?
2023-07-24 14:42:49 -0400 < jcowan> no
2023-07-24 14:42:57 -0400 < jcowan> they are unrelated packages
2023-07-24 14:43:01 -0400 < sham1> So what would be in it
2023-07-24 14:43:12 -0400 < sham1> What would (rnrs * (7)) have
2023-07-24 14:43:13 -0400 < jcowan> in what exactly?
2023-07-24 14:43:23 -0400 < jcowan> Nothing, according to my proposal
2023-07-24 14:43:47 -0400 < mnieper> I am going to give my answer later.  Busy atm.
2023-07-24 14:44:03 -0400 < sham1> right
2023-07-24 14:44:56 -0400 < jcowan> okay, II'll put my position in the issue
2023-07-24 14:45:05 -0400 < jcowan> with bells, whistles and gongs
2023-07-24 14:45:18 -0400 < jcowan> with a prolonged and ironic accent on the word "gongs"
2023-07-24 15:05:31 -0400 < Dooshki> Heh, and I think I found my first bug in Chibi Scheme :D  The custom port callbacks have an inconsistent definition, the documentation suggests that they accept a string buffer and a start and end index into this buffer, but I find that that's only the case on Windows for writer callbacks; on FreeBSD and Linux, and on reader callbacks on all platforms, the first numeric argument seems to be the
2023-07-24 15:05:33 -0400 < Dooshki> offset into the buffer, but the second one is the size of the entire buffer
2023-07-24 15:07:51 -0400 < Dooshki> https://github.com/ashinn/chibi-scheme/blob/master/sexp.c <- lines 1665, 1749 - see how the arguments prepared for the read callback and write callback differ?  (These are used on Windows; on Linux/FreeBSD, the cookie functions in https://github.com/ashinn/chibi-scheme/blob/master/lib/chibi/io/port.c are used)
2023-07-24 15:09:19 -0400 < Dooshki> At least if I'm understanding it correctly, my brain is still trying to wrap itself around all of these macros to work with scheme concepts in C
2023-07-24 15:47:40 -0400 -!- mode/#scheme [-o Zipheir] by ChanServ
2023-07-24 16:07:34 -0400 < cow_2001> how do I find endless loops?
2023-07-24 16:07:52 -0400 < cow_2001> do i put displays everywhere?
2023-07-24 16:08:58 -0400 < Zipheir> That's one way.
2023-07-24 16:09:23 -0400 < jackdaniel> wait for the end of time and see which loops are still running (or just finished)
2023-07-24 16:10:40 -0400 < wasamasa> cow_2001: you tryna solve the halting problem?
2023-07-24 16:11:28 -0400 < Zipheir> Well, the only practical way to find truly endless loops is to prove non-termination.
2023-07-24 16:16:10 -0400 < cow_2001> ~_~
2023-07-24 16:16:54 -0400 < cow_2001> I am quoting stuff and see if it crashes due to memory getting full.
2023-07-24 16:17:12 -0400 < cow_2001> Turns out it is the half-adder procedure
2023-07-24 16:17:14 -0400 < cow_2001> .
2023-07-24 16:22:18 -0400 < wasamasa> what are you writing?
2023-07-24 16:42:53 -0400 < mnieper> jcowan: sham1: So this is what I think about (rnrs (7)): (a) If https://github.com/cisco/ChezScheme/issues/574 bears any fruit, we should use this.  (b) We don't want to copy the mistakes of R6RS (it has some problems with port positions, for example), but we can't fix them in (rnrs (6)) if the resulting API is not 100% compatible.  (c) We need to make some adjustments to R6RS to improve interoperability like self-quoting vector
2023-07-24 16:42:53 -0400 < mnieper> literals.  We cannot do these changes in (rnrs eval (6)), we have to change the version number.  (d) Extensions due to the Foundations (like a continuation prompt tag argument for call/cc) that work for R6RS code as well as for the other code, should also make it into (rnrs (7)).  We cannot apply these improvements to (rnrs (6)).  (e) People coming from R6RS (or favouring it over R7RS-small) should be enabled to continue using their
2023-07-24 16:42:53 -0400 < mnieper> known libraries but also with the new features R7RS-large brings to the table.  (f) Some procedures in R6RS are arguably more useful than their cousins in R7RS-small, e.g. the error procedure taking a `who' argument in R6RS.  We can't change (scheme base), so people believing that the R6RS version of this and other procedures is better would want to import (rnrs).
2023-07-24 16:43:14 -0400 < cow_2001> the circuit language code
2023-07-24 16:43:23 -0400 < cow_2001> In SICP
2023-07-24 16:44:52 -0400 < cow_2001> It is a bit involved. Procedures in procedures calling procedures in the future.
2023-07-24 16:49:18 -0400 < mnieper> So my idea is that initially (rnrs (6)) and (rnrs (7)) are just the same libraries (so the version doesn't matter) and they begin to differ as soon as we see the need to extend procedures.
2023-07-24 16:50:00 -0400 < seninha> Hi, what are the actual benefits of kernel compared to scheme regaarding implementing the language (other than having to write a simpler eval process)? I opted to implement a kernel-like language and 90% of what i'm doing involves applying arguments, and i rarely use vau at all
2023-07-24 16:50:50 -0400 < mnieper> E.g. should R7RS-large incorporate SRFI 240, which is based on SRFI 237, which improves the R6RS record system, it would make no sense if (scheme base) exported the SRFI 240 define-record-type but (rnrs) would ignore the improvements of SRFI 237.
2023-07-24 16:51:31 -0400 < mnieper> seninha: The benefit is that writing fexprs is usually easier than writing macros.
2023-07-24 16:52:36 -0400 < mnieper> Macros have to produce code while fexprs just need to produce a result like any other procedure.
2023-07-24 16:52:50 -0400 < mnieper> Writing macros is like writing bits of a compiler.
2023-07-24 16:53:15 -0400 < mnieper> Of course, a lot of macros are still quite simple to write.
2023-07-24 16:54:33 -0400 < seninha> i see
2023-07-24 16:54:55 -0400 < mnieper> You also don't need to understand hygiene, etc.
2023-07-24 16:55:31 -0400 < seninha> i have no idea how to implement (hygienic) macros tho, all my experience on implementing scheme comes from SICP, and they do not try to implement macro definitions on their evaluators
2023-07-24 16:55:45 -0400 < mnieper> Wrt cow_2001's endless loop: Has anyone tried to specify a transfinite Scheme?
2023-07-24 16:56:35 -0400 < mnieper> So when the number of computational steps is numbered by the elements of an ordinal larger than ω?
2023-07-24 16:57:21 -0400 < mnieper> seninha: It is not trivial, but not undoable, either. But one has to understand them first.
2023-07-24 16:57:34 -0400 < mnieper> I think it really depends on what kind of language you are interested.
2023-07-24 16:59:00 -0400 < mnieper> Scheme is quite static (but that does not mean that dynamic features are not expressible in Scheme) and compilers can distinguish between compilation/expand time and run time.
2023-07-24 17:00:08 -0400 < mnieper> Kernel, on the other hand, is much more dynamic; there is no phasing between compilation and executing.
2023-07-24 17:00:41 -0400 < mnieper> A nice experiment is also 3-Lisp, which is a fully reflecting Lisp.
2023-07-24 17:01:41 -0400 < mnieper> It also tries to be more regular than regular Lisp/Scheme when it comes to designating values.
2023-07-24 17:02:17 -0400 < mnieper> In Lisp/Scheme, newcomers are often confused about when to quote and when not and why some quotes seem to become stripped and others aren't.
2023-07-24 17:02:24 -0400 < mnieper> With 3-Lisp, it is completely regular.
2023-07-24 17:04:00 -0400 < mnieper> Anyway, good night, everyone!
2023-07-24 17:11:51 -0400  * seninha googles about 3-Lisp
2023-07-24 17:17:04 -0400 < jcowan> seninha: https://www.ics.uci.edu/~jajones/INF102-S18/readings/17_Smith84.pdf
2023-07-24 17:17:17 -0400 < jcowan> there's a lot there
2023-07-24 17:17:25 -0400 < jcowan> 1-Lisp is basically Scheme
2023-07-24 17:24:20 -0400 < andydude> namespaces are for barbarians
2023-07-24 17:25:06 -0400  * jcowan hunts through the forests of the North the sanguinary boar and horrid bear
2023-07-24 17:25:33 -0400 < jcowan> Anyway, that is Lisp-[12], which has nothing to do with [123]-Lisp, all of which are Lisp-1s.
2023-07-24 17:25:42 -0400 < andydude> hi jcowan
2023-07-24 17:26:01 -0400 < andydude> I used to be called adu on freenode
2023-07-24 17:27:52 -0400 < andydude> After reading WIIGO, I think I'm going to rewrite Droscheme from scratch
2023-07-24 17:28:45 -0400 < andydude> WAIIG*
2023-07-24 17:31:55 -0400 < Zipheir> WHATWAIIG?
2023-07-24 17:40:47 -0400 < andydude> https://interpreterbook.com/ = Writing an interpreter in go = WAIIG
2023-07-24 17:41:33 -0400 < andydude> https://github.com/andydude/droscheme = Droscheme
2023-07-24 17:42:08 -0400 < andydude> I think I gave up on call/cc because it was so frustrating, and gave up on the whole project
2023-07-24 17:42:28 -0400 < wasamasa> to be fair, I'd just omit call/cc from a scheme implementation
2023-07-24 17:42:41 -0400 < Zipheir> Go's an interesting choice.
2023-07-24 17:43:02 -0400 < andydude> I got call/ec working, I don't remember how
2023-07-24 17:43:27 -0400 < Zipheir> call/cc's easy in a CPS interpreter. I don't remember it being too hard in a tree-walker either...
2023-07-24 17:44:04 -0400 < Zipheir> wasamasa: Sacrilege!
2023-07-24 17:44:21 -0400 < wasamasa> it's such a weird hill to die on
2023-07-24 17:44:42 -0400 < wasamasa> particularly the undelimited/delimited debate
2023-07-24 17:45:04 -0400 < andydude> I think I was also inspired by vonuvoli
2023-07-24 17:45:23 -0400 < Zipheir> Fortunately, few people die due to interpreters.
2023-07-24 17:45:31 -0400 < andydude> vonuvoli made some interesting choices, for example they don't implement macros
2023-07-24 17:46:03 -0400 < Zipheir> More sacrilege.
2023-07-24 17:47:03 -0400 < Zipheir> I kid. It's reasonable to have a language without macros, as it is to have one without first-class continuations. But they're part of the Scheme tradition.
2023-07-24 17:47:13 -0400 < seninha> how can i test the tail call optimization on my implementation? I tried something like (define count (lambda (n) (if (= n 0) 0 (count (- n 1))))) and it can run (count 100000000) with no problem (in a dozen seconds)
2023-07-24 17:47:46 -0400 < wasamasa> I wonder, how do lua-style coroutines compare?
2023-07-24 17:48:03 -0400 < seninha> and what's the difference of "proper tail recursive" to "tail recursive"?
2023-07-24 17:48:18 -0400 < wasamasa> one unexpected discovery from reading the rabbit paper was that early scheme used to have concurrency constructs
2023-07-24 17:48:52 -0400 < andydude> seninha: "pop; call" vs "call; pop", or something
2023-07-24 17:49:00 -0400 < sham1> mp
2023-07-24 17:49:02 -0400 < sham1> jmp
2023-07-24 17:49:21 -0400 < andydude> **or something**
2023-07-24 17:49:58 -0400 < Zipheir> seninha: You really want continuation marks (originally https://srfi.schemers.org/srfi-157/) to test this, but only Racket has them AFAIK.
2023-07-24 17:50:00 -0400 < sham1> Doing call there is not "something"
2023-07-24 17:50:16 -0400 < Zipheir> What is "proper" tail-recursion?
2023-07-24 17:50:50 -0400 < seninha> Zipheir, idk, that's what r5rs refers to
2023-07-24 17:53:11 -0400 < Zipheir> I suppose the meaning in the reports is just "optimized to iterative".
2023-07-24 17:54:12 -0400 < Zipheir> "Proper" could also mean that all instances of tail-recursion are optimized, not just self-calls, say.
2023-07-24 17:55:11 -0400 < Zipheir> "A Scheme implementation is properly tail-recursive if it supports an unbounded number of active tail calls."
2023-07-24 17:56:14 -0400 < Zipheir> So it's an implementation that's proper, not an expression.
2023-07-24 17:59:40 -0400 < seninha> Zipheir: i see, thanks :)
2023-07-24 19:31:02 -0400 < flatwhatson> wasamasa: any more on those concurrency constructs?
2023-07-24 19:32:36 -0400 < flatwhatson> the weirdest thing i've seen in this space is xappings from Connection Machine Lisp
2023-07-24 19:34:26 -0400 < flatwhatson> https://dl.acm.org/doi/10.1145/319838.319870
2023-07-24 20:44:14 -0400 < jcowan> andydude: Yeah, the mistake is to think that you can write a conventional interpreter and patch it up to do call/cc and multiple values.  They have to be built in from the beginning.
2023-07-24 20:47:17 -0400 < jcowan> https://dspace.mit.edu/bitstream/handle/1721.1/5794/AIM-349.pdf is the original Lambda paper and spells out how to write a Scheme interpreter from a conventional Lisp environment, assuming you know nothing (as nobody did in 1975) about all this stuff.
2023-07-24 20:48:44 -0400 < seninha> do scheme implementations have a limit on how much values can be returned/passed around?
2023-07-24 21:05:43 -0400 < jcowan> Sometimes, but typically it's large.
2023-07-24 21:06:12 -0400 < flatwhatson> (apply (lambda _ (length _)) (make-list 10240000))
2023-07-24 21:06:26 -0400 < jcowan> It's like how many arguments you are allowed to have, since return values are the dual of arguments.  Returning 2 values is equivalent to calling your continuation with 2 arguments.
2023-07-24 21:06:58 -0400 < jcowan> seninha: ^^
2023-07-24 21:07:19 -0400 < DeeEff_> Generally speaking it will probably be specific to whatever the backend Scheme is implemented in. e.g. if implemented in C it may be dependent on platform restrictions or total stack size
2023-07-24 21:08:24 -0400 < seninha> thanks :)
2023-07-24 21:13:49 -0400 < flatwhatson> heh, rabbit paper uses the term UNCOL (UNiversal Computer-Oriented Language)
2023-07-24 21:13:53 -0400 < Zipheir> It always "depends on the backend", although that's a bottomless recursion in principle.
2023-07-24 21:15:04 -0400 < DeeEff_> Zipheir: In this case I guess I meant that one could in theory either utilize existing C-calling convention limits, wrap their own implementation on the heap for passing across continuations, or even be limited by the number of total registers on the host system
2023-07-24 21:15:08 -0400 < DeeEff_> or some hybrid therein
2023-07-24 21:16:04 -0400 < DeeEff_> e.g. optimized to use registers up to some upper limit of 128 and using a slower, heap based return if you're returning more than that
2023-07-24 21:16:19 -0400 < Zipheir> Yes.
--- Day changed Tue Jul 25 2023
2023-07-25 01:35:54 -0400 < mnieper> wasamasa: So you would rather add delimited continuations instead of call/cc?
2023-07-25 01:36:55 -0400 < sham1> I reckon most people would. Although if you have delimited continuations, you can of course simulate call/cc
2023-07-25 02:05:29 -0400 -!- hbonly1 is now known as bonly
2023-07-25 03:27:47 -0400 -!- mdhughes_ is now known as mdhughes
2023-07-25 04:26:20 -0400 -!- ormaaj1 is now known as ormaaaj
2023-07-25 06:54:16 -0400 < seninha> hi, r5rs does not require write/display to detect cycles in the printed structures, right?
2023-07-25 06:54:46 -0400 < dpk> no, it also lacks any standard way to display cycles since there are no datum labels in R5RS
2023-07-25 06:55:39 -0400 < seninha> i'm using gambit's scheme-r5rs binary, which does detects cycles and prints datum labels
2023-07-25 06:59:33 -0400 < seninha> i tried to print a recursive structure on other r5rs implementations, they either crash or give up on a deep level of recursion
2023-07-25 07:07:33 -0400 < seninha> tinyscheme and scheme48 abort with heap overflow. Only gambit handle such case.
2023-07-25 12:01:27 -0400 < mnieper> jcowan: Do you agree about that the body "(+ x 1) (define x 2)" is not a syntactic violation (of the syntax for top-level program bodies)? (See https://codeberg.org/scheme/r7rs/issues/104#issuecomment-1004263)
2023-07-25 12:04:20 -0400 -!- Irssi: No bans in channel #scheme
2023-07-25 13:23:24 -0400 < wasamasa> mnieper: I wouldn't implement continuations at all
2023-07-25 13:23:58 -0400 < wasamasa> mnieper: the benefit compared to the cost simply isn't worth it, unlike with something like TCO
2023-07-25 13:30:59 -0400 < wasamasa> flatwhatson: the paper I'm thinking of is [Guy L. Steele, Gerald J. Sussman] Scheme - An Interpreter for Extended Lambda Calculus (1975)
2023-07-25 13:31:43 -0400 < wasamasa> flatwhatson: the concurrency primitives are create!process, start!process, stop!process and evaluate!uninterruptibly
2023-07-25 13:45:03 -0400 < mnieper`> wasamasa: Then I don't understand your comment "particularly the undelimited/delimited debate" unless it was just meant as some noise to make (delimited) continuations look like a bad feature.
2023-07-25 13:45:35 -0400 < wasamasa> you have a questionable feature and you have people who cannot agree which variation of it is better
2023-07-25 13:46:00 -0400 < wasamasa> for a language that used to be designed by consensus, this is a bad look
2023-07-25 13:47:02 -0400 < sham1> Well this'll just add more flames to the fire of delims vs call/cc, but I'd say delims are just simply better because you can implement call/cc in terms of delims. Now, you can go the other way as well, but not as neatly
2023-07-25 13:49:19 -0400 < mnieper`> wasamasa: I don't think you will find anyone who knows this stuff and prefers undelimited continuations.
2023-07-25 13:50:16 -0400 < wasamasa> so you haven't been to #chicken, I see
2023-07-25 13:51:02 -0400 < mnieper`> No, I moved past R5RS. ;-)
2023-07-25 13:51:05 -0400 < wasamasa> textbook cognitive dissonance anyone?
2023-07-25 13:51:35 -0400 < mnieper`> wasamasa: Give me one argument in favour of traditional call/cc (from #chicken if you want).
2023-07-25 13:52:14 -0400 < wasamasa> lol, I don't even use the feature, how could I argue for those who do use it
2023-07-25 13:52:27 -0400 < wasamasa> these people do exist, that's all I'm saying
2023-07-25 13:52:48 -0400 < mnieper`> Then give me a reference.
2023-07-25 13:52:55 -0400 < sham1> All I can synthesise in my head is that because Chicken does CPS transformation that it might have something to do with that and an idea that thus call/cc is "easier"
2023-07-25 13:52:56 -0400 < wasamasa> you want some IRC logs?
2023-07-25 13:53:04 -0400 < mnieper`> wasamasa: for example.
2023-07-25 13:53:33 -0400 < mnieper`> sham1: That is no argument that call/cc is better. Implementing an assembler is also easier than implementing Scheme. :)
2023-07-25 13:54:17 -0400 < mnieper`> By the way, delimited continuations are so *questionable* that other languages are adding them right now (like OCaml).  Algebraic effects are hot stuff (and are a feature with a good theory behind).
2023-07-25 13:59:24 -0400 < wasamasa> search results: http://ix.io/4Bu2
2023-07-25 13:59:36 -0400 < mnieper`> Merci !
2023-07-25 13:59:45 -0400 < wasamasa> so, 3 conversations on libera
2023-07-25 13:59:59 -0400 < wasamasa> there may have been more on freenode
2023-07-25 14:01:18 -0400 < wasamasa> one thing I've come across is this API: http://wiki.call-cc.org/eggref/5/continuations
2023-07-25 14:01:24 -0400 < wasamasa> it probably originates from some paper
2023-07-25 14:02:40 -0400 < wasamasa> https://www.researchgate.net/publication/2405339_A_Better_API_for_First-Class_Continuations
2023-07-25 14:03:41 -0400 < mnieper`> In the IRC snippets you shared, "bunny351" just proves that he doesn't know this stuff.
2023-07-25 14:04:58 -0400 < wasamasa> I mean, obviously, the creator of CHICKEN couldn't possibly know how continuations work
2023-07-25 14:06:08 -0400 < mnieper`> He certainly knows CPS and how call/cc works, but he obviously doesn't understand why call/cc cannot emulate delimited continuations fully.
2023-07-25 14:07:54 -0400 < mnieper`> I implemented this stuff at least twice and thought a lot about it while writing SRFI 226, so I think I know what I am talking about.
2023-07-25 14:10:01 -0400 < mnieper`> To illustrate, saying that one only needs call/cc and delimited continuations (or some equivalent) can be built on top is like saying one only needs R4RS call/cc and that dynamic-wind can be built on top.
2023-07-25 14:11:03 -0400 < mnieper`> The latter is certainly true, but for dynamic-wind to work you must then expose a new call/cc to the user and not the primitive one.
2023-07-25 14:11:55 -0400 < mnieper`> The same is true for delimited continuations (to some extent, see below).  You can implement them in terms of call/cc, but then you have to expose a different call/cc to the user.
2023-07-25 14:11:56 -0400 < dpk> (Felix also turned his nose up when i made this analogy)
2023-07-25 14:13:22 -0400 < mnieper`> In fact, you need slightly more than just call/cc for delimited continuations.
2023-07-25 14:13:40 -0400 < mnieper`> See my sample implementation for SRFI 226 and the implementation notes of SRFI 226.
2023-07-25 14:14:01 -0400 < wasamasa> I feel like there'd be more point to the conversation if there was some PoC to play around with to demonstrate why it is good/bad
2023-07-25 14:14:16 -0400 < mnieper`> PoC?
2023-07-25 14:14:23 -0400 < wasamasa> proof of concept
2023-07-25 14:14:47 -0400 < wasamasa> actual code targetting an actual implementation
2023-07-25 14:14:59 -0400 < mnieper`> There are lots of recent papers on algebraic effects.
2023-07-25 14:15:08 -0400 < mnieper`> Coming with implementations and code.
2023-07-25 14:15:41 -0400 < wasamasa> like, say there was a PoC for delimited continuations on top of call/cc for CHICKEN, then the claims that it's fine/not fine could be checked
2023-07-25 14:16:09 -0400 < wasamasa> if there were another such PoC for another scheme, the claims could be checked for that and the results compared
2023-07-25 14:16:23 -0400 < wasamasa> then you'd have a much more fruitful discussion than this
2023-07-25 14:16:33 -0400 < mnieper`> This happened 20 years ago.
2023-07-25 14:16:49 -0400 < wasamasa> show me
2023-07-25 14:17:05 -0400 < mnieper`> https://www.deinprogramm.de/sperber/papers/shift-reset-direct.pdf
2023-07-25 14:17:58 -0400 < sham1> Guile also does have delimited conts, so one can just look at that
2023-07-25 14:18:12 -0400 < mnieper`> Racket also.
2023-07-25 14:18:13 -0400 < sham1> I imagine Chez also has them, and Racket certainly does
2023-07-25 14:18:29 -0400 < mnieper`> Chez has them under the hood, but not exposed to the user.
2023-07-25 14:19:05 -0400 < sham1> That's a shame
2023-07-25 14:19:17 -0400 < wasamasa> so that PDF is about the results of scheme48 for both direct/indirect implementation
2023-07-25 14:20:53 -0400 < wasamasa> now all that's missing is a CHICKEN equivalent comparing call/cc and an indirect implementation
2023-07-25 14:22:33 -0400 < mnieper`> The paper shows in particular that Felix's claim of that a userspace call/cc-implementation can be as space efficient is wrong, in general.
2023-07-25 14:23:04 -0400 < wasamasa> how can you say that in general when looking at benchmark data from a small number of implementations?
2023-07-25 14:23:19 -0400 < mnieper`> Because of the halting problem.
2023-07-25 14:23:36 -0400 < mnieper`> Even a sufficiently smart compiler cannot eliminate all space leaks.
2023-07-25 14:25:05 -0400 < mnieper`> If you store in a (regular) continuation in some location, the compiler cannot prove in general which continuation frames will be invoked in the future and which can be garbage collected.
2023-07-25 14:25:49 -0400 < mnieper`> With delimited continuations, the programmer can say which part of the list of continuation frames should be stored.
2023-07-25 14:27:31 -0400 < mnieper`> s/should/need to
2023-07-25 14:28:07 -0400 < wasamasa> does the same thing hold true for delimited continuations on top of call/cc?
2023-07-25 14:28:55 -0400 < mnieper`> You mean when the user space call/cc is not the native call/cc because that is used to implement delimited continuations?
2023-07-25 14:28:57 -0400 < wasamasa> with a naive implementation, I guess
2023-07-25 14:29:54 -0400 < wasamasa> no, when the user space shift/reset is used compared to a direct shift/reset
2023-07-25 14:30:55 -0400 < mnieper`> Then you have a space leak.
2023-07-25 14:31:23 -0400 < mnieper`> To get rid of it, you have to capture a continuation very early in the process of running your program (stack is small).
2023-07-25 14:31:45 -0400 < mnieper`> If you have one, you can always abort to it, keeping your stack small.
2023-07-25 14:33:12 -0400 < wasamasa> ok, so a constant-time overhead
2023-07-25 14:33:19 -0400 < mnieper`> See Dybvig/Peyton Jones/Sabry: https://www.microsoft.com/en-us/research/wp-content/uploads/2005/01/jfp-revised.pdf
2023-07-25 14:33:40 -0400 < mnieper`> for the semantic model (which also shows you how to implement the stuff).
2023-07-25 14:33:51 -0400 < wasamasa> well, constant factor (in terms of O)
2023-07-25 14:34:06 -0400 < mnieper`> wasamasa: If you capture a continuation early, yes.
2023-07-25 14:34:15 -0400 < mnieper`> Otherwise, the overhead can be as large as you want.
2023-07-25 14:34:34 -0400 < mnieper`> A (portable) user-space implementation of shift/reset cannot capture such a continuation.
2023-07-25 14:35:15 -0400 < mnieper`> Moreover, it is incompatible with the existing call/cc (which also includes guard and maybe some other forms).
2023-07-25 14:35:36 -0400 < mnieper`> CHICKEN has some shift/reset egg, but it is broken because of that.
2023-07-25 14:36:06 -0400 < wasamasa> F-operator?
2023-07-25 14:37:46 -0400 < sham1> BTW, since we're on the topic of delimited continuations, I wonder whether threads delimit their own continuations. I.e. whether you can or can't jump from one thread to another with a captured continuation. My intuition is that you can't, but I'm not so sure. I've looked into SRFIs 18 and 226 and can't figure it out
2023-07-25 14:47:40 -0400 < mnieper`> wasamasa: Read the paper.  Ask if something is unclear.
2023-07-25 14:48:31 -0400 < mnieper`> sham1: You can call in thread B a continuation captured in thread A.
2023-07-25 14:48:44 -0400 < mnieper`> But this means that the continuation then runs in thread B.
2023-07-25 14:48:55 -0400 < mnieper`> It is an orthogonal concept.
2023-07-25 14:49:02 -0400 < sham1> oh
2023-07-25 14:49:07 -0400 < mnieper`> You cannot jump from thread B to thread A.
2023-07-25 14:49:17 -0400 < sham1> Okay good
2023-07-25 14:49:27 -0400 < mnieper`> I mean this cannot make sense because thread A may be running.
2023-07-25 14:50:07 -0400 < mnieper`> Calling a continuation just means to replace the program that is currently run by a thread.
2023-07-25 14:50:12 -0400 < sham1> Yeah. That's what I'm mainly thinking of, because if you run the continuation from thread A in thread B, you'd of course for example have an implementation that does this with stack capture
2023-07-25 14:50:23 -0400 < sham1> And suddenly you're in a world of hurt and data racers
2023-07-25 14:50:26 -0400 < sham1> races*
2023-07-25 14:51:50 -0400 < mnieper`> I have a hard time to parse what you wrote.
2023-07-25 14:52:07 -0400 < sham1> Well, let me expand what I mean
2023-07-25 14:53:39 -0400 < sham1> We have thread A, with a stack of call frames/continuation frames. These frames of course contain things such as the values of the local variables of the continuations, which would probably translate to a procedure's local variables when thought of as call frames in something like C
2023-07-25 14:53:57 -0400 < sham1> We capture these frames up to some delimiter
2023-07-25 14:54:14 -0400 < sham1> And now we call the captured continuation in another thread B
2023-07-25 14:55:52 -0400 < sham1> Now, because of the way this continuation capture scheme works, you'd replace your current stack of continuations in thread B with the ones in the captured continuation, so now you're using the frames from thread A, which can lead to data races since you can have both A and B access the same frames and data in parallel
2023-07-25 14:56:20 -0400 < sham1> And you've also lost your original frames from thread B
2023-07-25 14:56:48 -0400 < sham1> Well, I suppose unless you have a composable continuation
2023-07-25 15:09:02 -0400 < mnieper`> sham1: This is only a problem if the processor does not allow two threads to read from the same memory location at the same time.
2023-07-25 15:09:20 -0400 < mnieper`> There is no read/write race.
2023-07-25 15:09:30 -0400 < mnieper`> Continuation frames are never modified.
2023-07-25 15:09:50 -0400 < mnieper`> If they were, already capturing a continuation in a single-threaded implementation would be a problem.
2023-07-25 15:12:24 -0400 < sham1> So you couldn't set! things in a frame (regardless of set! being or not being a good idea). Hm
2023-07-25 15:20:08 -0400 < Oxyd> Implementations already box local variables that are set! – i.e. they add a level of indirection to those variables.
2023-07-25 15:20:35 -0400 < mnieper`> Yes, set! is (in typical implementations) somewhat of a red herring.
2023-07-25 15:20:57 -0400 < mnieper`> We are just talking about SRFI 111 boxes hidden behind syntax.
2023-07-25 15:21:39 -0400 < mnieper`> Nevertheless, whether mutable variables are boxed or not does not affect sham1's question.
2023-07-25 15:22:13 -0400 < sham1> Fair enough. Although now that I'm thinking about it, since the stack frames are copied, even if the "boxes" are just in the stack frames, that shouldn't matter because you're in a different thread, unless we assume that they should affect each other
2023-07-25 15:22:21 -0400 < mnieper`> Whenever in a multithreaded program locations are modified, a data race can show up.
2023-07-25 15:23:02 -0400 < mnieper`> sham1: An implementation need not copy any stack frames.
2023-07-25 15:23:09 -0400 < mnieper`> Think of the stack as an ordinary Scheme list.
2023-07-25 15:23:14 -0400 < mnieper`> A shared one.
2023-07-25 15:23:25 -0400 < mnieper`> A continuation is just a handle into the list.
2023-07-25 15:24:20 -0400 < sham1> Yeah, even hardware stacks can be thought of as linked lists
2023-07-25 15:24:21 -0400 < mnieper`> What I meant with continuation not being modified is that the cdrs in this list are never mutated.
2023-07-25 15:24:34 -0400 < mnieper`> insert THE
2023-07-25 15:29:24 -0400 < mnieper`> sham1: At least with SRFI 226, modifying a single location (e.g. set!ing a variable) won't crash your program.
2023-07-25 15:29:34 -0400 < mnieper`> From the SRFI: "All modifications to single locations in the store must appear atomic to each thread."
2023-07-25 15:31:10 -0400 < sham1> Now I wonder if a modification is observable from every thread
2023-07-25 15:31:23 -0400 < sham1> And apparently yes
2023-07-25 15:32:11 -0400 < Oxyd> Does that mean that all potentially set! variables must be protected by a mutex?
2023-07-25 15:32:32 -0400 < sham1> Well that or whatever ISA-level atomic write
2023-07-25 15:32:42 -0400 < mnieper`> Oxyd: No, because a location usually has the size of a word and processors usually work atomically on word sizes.
2023-07-25 15:32:51 -0400 < mnieper`> IIRC, Rust makes the same assumption.
2023-07-25 15:33:21 -0400 < mnieper`> In portable C, you would have to mark the variables of your implementation atomic.
2023-07-25 15:34:44 -0400 < mnieper`> Check ATOMIC_xxx_LOCK_FREE in your C compiler's <stdatomic.h>.
2023-07-25 15:35:33 -0400 < mnieper`> What SRFI 226 doesn't guarantee is that (set! x (+ x 1)) increases the value of x by one.
2023-07-25 15:37:14 -0400 < sham1> Okay, so for that you need user-level locks
2023-07-25 15:37:27 -0400 < sham1> Or some other synchronisation primitive
2023-07-25 15:37:34 -0400 < mnieper`> Yes, this is neither guaranteed by processors nor by declaring a variable atomic in C.
2023-07-25 15:37:50 -0400 < mnieper`> (Unless you use x++ in C, which we don't have in Scheme.)
2023-07-25 15:38:02 -0400 < mnieper`> instead of x = x + 1, I mean.
2023-07-25 15:38:25 -0400 < sham1> Yeah, x++ would be a fetch-and-add
2023-07-25 15:38:43 -0400 < sham1> Well, basically, depends on things
2023-07-25 15:39:47 -0400 < mnieper`> If you declare x as atomic, a C compiler has to implement it as a fetch-and-add, which involves (usually) at least a processor lock.
2023-07-25 15:40:24 -0400 < sham1> Well it might also need to do a mutex to ensure atomicity because if it's an unsigned integer, it might have to do the wrapping
2023-07-25 15:40:25 -0400 < mnieper`> In the worst case, the C compiler has to use a mutex.
2023-07-25 15:40:37 -0400 < mnieper`> LOL, yes.
2023-07-25 15:40:49 -0400 < sham1> Unless it's at the same size as the native word. For signed it can just do f-a-a just fine
2023-07-25 15:42:59 -0400 < sham1> Anyway, another question then comes with just where the conceptual "delimiter" for call/cc should be. Because in principle it's "at the end of the program", but for example if there's a C runtime thing for a scheme implementation, does it like come within the main function and if so, do threads also do stuff with that, because they also might need setup code
2023-07-25 15:43:59 -0400 < sham1> I suppose that this is an implementation-specific thing, but for things like stack copying, this can be significant
2023-07-25 15:45:12 -0400 < sham1> Because then, if you're activating your frames in another thread, it needs to patch the return addresses properly so that the stack frames point to the proper places and instead of just suddenly exiting the program once your now-active continuation stack runs out, it just exits the thread instead
2023-07-25 15:58:30 -0400 < mnieper> The SRFI 226 continuations are well-definedly delimited.
2023-07-25 15:59:28 -0400 < mnieper> See 5.12, the Initial Continuation
2023-07-25 15:59:39 -0400 < mnieper> sham1: ^^
2023-07-25 16:10:03 -0400 < sham1> Ah, I didn't remember this thing, but it makes sense
2023-07-25 16:10:44 -0400 < sham1> But wait, if I activate the continuation from thread A in thread B, wouldn't the initial continuation from thread B get replaced?
2023-07-25 16:11:19 -0400 < mnieper> No because the initial continuation is tagged with a prompt.
2023-07-25 16:11:27 -0400 < mnieper> Delimiting what you can capture.
2023-07-25 16:11:45 -0400 < mnieper> And delimiting what can be replaced.
2023-07-25 16:12:04 -0400 < sham1> Oh okay. See, I have tried to read this SRFI a couple of times, but I don't always understand what is going on. I didn't quite understand what some of this stuff means, but in this case that's brilliant
2023-07-25 16:14:22 -0400 < mnieper> Thanks about the last thing. :) And feel free to pick at what's hard to understand.
2023-07-25 16:26:19 -0400 < sham1> So, one thing confuses me about call-in-initial-continuation. What's the difference between using that and calling the thunk itself? Well, aside from the fact that the thunk is called in the initial continuation, but then the parameters and exception handlers from the call to call/iic are used
2023-07-25 16:27:17 -0400 < sham1> What's the idea/usecase here?
2023-07-25 16:29:38 -0400 < mnieper> You cut off all continuation prompts, for example.
2023-07-25 16:30:00 -0400 < mnieper> The whole continuation looks truncated from the point of view of the thunk.
2023-07-25 16:30:40 -0400 < mnieper> This is used for promises, for example.  You don't want the code the calculates the promise's value to escape its prison, so to speak.
2023-07-25 16:31:12 -0400 < sham1> Right, and if you for example capture the continuation, you'd just end up right above the initial continuation. Alright
2023-07-25 16:33:32 -0400 < mnieper> This was the idea.
2023-07-25 16:34:16 -0400 < sham1> And so force for example would use call/iic or equivalent when evaluating the promise value. Hm
2023-07-25 16:35:23 -0400 < mnieper> Yes.
2023-07-25 16:35:59 -0400 < mnieper> This also makes promises parallel to threads.
2023-07-25 16:36:21 -0400 < mnieper> The difference in their semantics is that promises are synchronous, threads are asynchronous.
2023-07-25 16:37:14 -0400 < mnieper> It makes it easy to implement promise-like object with analogous semantics that, when created, already begin to force their result but in another thread.
2023-07-25 16:38:38 -0400 < sham1> Ah, so you could implement promises as worker thread pools
2023-07-25 16:40:01 -0400 < mnieper> Not the original promises because they mustn't evaluate their expression before they are forced, but promise-like objects.
2023-07-25 16:44:26 -0400 < sham1> Oh, so can't even do that with 226 promises?
2023-07-25 16:44:31 -0400 < sham1> Oh well
2023-07-25 16:48:36 -0400 < mnieper> SRFI 226 cannot just maybe-force promises.
2023-07-25 16:48:48 -0400 < mnieper> Forcing them may produce some side-effect.
2023-07-25 16:49:30 -0400 < sham1> Oh fair enough
2023-07-25 16:52:15 -0400 < mnieper> But you can use promises to code "threaded promises".
2023-07-25 16:53:38 -0400 < mnieper> (maybe-delay <expr>) would create a thread which evaluates <expr>.  The delay expression then returns a SRFI 226 that, when forced, waits for the thread to deliver.
2023-07-25 16:57:20 -0400 < mnieper> sham1: Something like this: https://paste.debian.net/plain/1286950
2023-07-25 16:57:32 -0400 < mnieper> (not tested)
2023-07-25 16:58:00 -0400 < sham1> Interesting
2023-07-25 16:58:36 -0400 < mnieper> (define p (maybe-delay (factorize <large number>))) would store a regular promise in p
2023-07-25 16:58:50 -0400 < mnieper> and start with the calculation in some other thread.
2023-07-25 16:59:13 -0400 < mnieper> When you do (force p), the current threads waits for the calculation to finish.
2023-07-25 16:59:24 -0400 < mnieper> maybe-delay is probably a very bad name.
2023-07-25 16:59:52 -0400 < sham1> delay/thread
2023-07-25 17:00:05 -0400 < mnieper> Definitely better.
2023-07-25 17:00:59 -0400 < mnieper> In any case, promises seem flexible enough.
2023-07-25 17:01:20 -0400 < mnieper> Anyway, it is already too late here.  See you tomorrow.
2023-07-25 19:25:51 -0400 -!- ced1 is now known as cedb
2023-07-25 20:00:11 -0400 -!- Netsplit *.net <-> *.split quits: notzmv, justache, enzuru, Kooda2, torresjrjr, weinholt`, m1dnight, xelxebar, sham1, deltab,  (+4 more, use /NETSPLIT to show all of them)
2023-07-25 20:00:20 -0400 -!- Netsplit over, joins: deltab, torresjrjr
2023-07-25 20:01:02 -0400 -!- Netsplit over, joins: Kooda2
2023-07-25 20:01:09 -0400 -!- Netsplit over, joins: m1dnight
2023-07-25 20:01:48 -0400 -!- Netsplit over, joins: justache
2023-07-25 20:02:25 -0400 -!- Netsplit over, joins: xelxebar, lockywolf
2023-07-25 20:02:34 -0400 -!- Netsplit over, joins: fizzie
2023-07-25 20:02:52 -0400 -!- Netsplit over, joins: krjt
2023-07-25 20:02:58 -0400 -!- Netsplit over, joins: enzuru
2023-07-25 20:03:43 -0400 -!- Netsplit over, joins: sham1
2023-07-25 23:49:35 -0400 < mdhughes> <giant scrollback> Wow, something interesting must've come up… Nope, just cc/delcc nonsense again.
--- Day changed Wed Jul 26 2023
2023-07-26 00:15:02 -0400 < sham1> The nonsense affects the software engineering strategy here
2023-07-26 01:36:05 -0400 < mnieper``> Si tacuisses...
2023-07-26 02:19:05 -0400 < lockywolf> mdhughes: which topic would you like to discuss?
2023-07-26 02:34:20 -0400 < cedb> sometimes i look at say, medical or economic, models of "things" (sidelining) couldnt possibly have the generative power to be meaningful given how complex the "thing" described is. is there some field/literature about investigating those questions. (intuitively im mostly thinking of information theory for machine learning where you do have some measure of "capacity" and although we have no precise
2023-07-26 02:34:22 -0400 < cedb> analytic way to quantify that accross different architecture/tasks theres still some form of intuition as to how to navigate those metrics.)
2023-07-26 02:35:16 -0400 < cedb> sorry i blame this channel for making be leading me to think about random stuff again
2023-07-26 02:36:51 -0400 < flatwhatson> because something is complex doesn't mean it's unpredictable
2023-07-26 02:37:08 -0400 < cedb> ok so i was looking at neuro science
2023-07-26 02:37:22 -0400 < cedb> and receptor sensitvity theory
2023-07-26 02:37:50 -0400 < cedb> so its not just about having predictive power, thats fine i guess
2023-07-26 02:38:18 -0400 < cedb> but the idea that  a model with a causal structure has a limited generativepower
2023-07-26 02:39:16 -0400 < cedb> flatwhatson: for econ its more like using naive equilibrium models that have no dynamics, or
2023-07-26 02:39:31 -0400 < cedb> the course that turned me on these kinds of thoughts was algorithmic game theory
2023-07-26 02:40:23 -0400 < flatwhatson> i'm not sure what you mean by "generative power"?  i'm thinking like cellular automata, the whole idea of emergent complexity
2023-07-26 02:44:05 -0400 < cedb> the state space in which the features predicted move
2023-07-26 02:44:36 -0400 < cedb> i guess in machine learning terms itd be framed as doubting the manifold hypothesis for some kind of dataset
2023-07-26 04:38:33 -0400 < mnieper``> https://codeberg.org/scheme/r7rs/issues/127 --- OPEN FOR EVERYONE
2023-07-26 04:45:45 -0400 < wasamasa> why does this look like the UwU meme
2023-07-26 04:47:47 -0400 < sham1> Because omega kinda looks like that
2023-07-26 04:48:27 -0400 < mnieper> Blame Cantor for it.
2023-07-26 09:54:57 -0400 < seninha> my toy lisp now has garbage collection, i just need to figure out when to call it for optimization (i'm calling it after every evaluation)
2023-07-26 09:55:32 -0400 < seninha> any idea what to make with it? i do not want to make this project die after practically done
2023-07-26 10:17:25 -0400 < drakonis> been a while since i checked the latest in r7rs-large goodness
2023-07-26 10:17:34 -0400 < drakonis> seems like its going places
2023-07-26 10:17:40 -0400 < drakonis> https://kraken-lang.org/
2023-07-26 10:18:35 -0400 < gwatt> seninha: Two common options for GC timing would be 1) Run GC when you're going to exceed your allocated pool size. 2) Run it periodically after you've allocated a certain amount, regardless of pool size
2023-07-26 10:20:09 -0400 < seninha> gwatt: i'm not using any memory pool, but a linked list of allocated space. Like, if I allocate a vector of 4 objects, then that vector is added on a linked list. Same for strings.
2023-07-26 10:20:51 -0400 < seninha> I'm doing a DFS to mark reachable objects and move them to an alternate list. The objects that remain on the initial list are freed.
2023-07-26 10:21:04 -0400 < seninha> And then the alternate list and the original list are swapped.
2023-07-26 10:21:18 -0400 < seninha> (kind of the same algorithm on SICP section 5.4)
2023-07-26 10:21:20 -0400 < drakonis> is this a hypothetical omega scheme report?
2023-07-26 10:21:30 -0400 < drakonis> linked earlier
2023-07-26 10:21:48 -0400 < sham1> Yeah, it's basically "if you're not constrained by anything, what would you do"
2023-07-26 10:24:26 -0400 < drakonis> that'd be nice, tbh
2023-07-26 10:29:35 -0400 < flatwhatson> R5.5RS
2023-07-26 12:14:40 -0400 < mnieper> dpk: Do you have a link to `egal?' for me?
2023-07-26 12:47:14 -0400 < dpk> mnieper disappeared two minutes after asking that :<
2023-07-26 12:49:01 -0400 < dpk> mnieper: https://dl.acm.org/doi/pdf/10.1145/165593.165596
2023-07-26 12:49:03 -0400 < mnieper> dpk: *I* didn't disappear.  I shut down my Emacs.
2023-07-26 12:49:06 -0400 < mnieper> ;)
2023-07-26 12:49:10 -0400 < dpk> hehe
2023-07-26 12:49:13 -0400 < mnieper> Merci !
2023-07-26 12:49:29 -0400 < mnieper> egal? sounds funny when you know German
2023-07-26 12:50:12 -0400 < dpk> the brief summary is: two mutable objects of any kind are `egal?' iff they occupy the same location in memory; two immutable collections are `egal?` if all their members are `egal?' to one another
2023-07-26 12:51:09 -0400 < mnieper> Interesting.
2023-07-26 12:52:01 -0400 < mnieper> This is as if eqv? were used and immutable objects are automatically interned.
2023-07-26 12:52:36 -0400 < dpk> yes, basically eq? semantics for mutable things and equal? semantics for immutable things
2023-07-26 12:53:26 -0400 < mnieper> Should we enforce immutability in R7RS-large, we could define this predicate.
2023-07-26 12:55:50 -0400 < dpk> indeed
2023-07-26 12:56:03 -0400 < dpk> FWIW Racket now has this since a recent version too
2023-07-26 12:56:36 -0400 < dpk> called equal-always? https://docs.racket-lang.org/reference/Equality.html#%28def._%28%28quote._~23~25kernel%29._equal-always~3f%29%29
2023-07-26 12:56:37 -0400 < rudybot> https://teensy.info/hHwMVLoqZi
2023-07-26 12:57:00 -0400 < sham1> Immutability, now coming in R^{\omega}RS
2023-07-26 12:57:01 -0400 < mnieper> Mutable objects are very close to closures (which can carry state), so if closures are also compared with eq?, this makes sense.
2023-07-26 12:57:11 -0400 < mnieper> sham1: :)
2023-07-26 12:58:30 -0400 < mnieper> Just in case people are worried, RωRS won't be the last Scheme.
2023-07-26 12:58:52 -0400 < mnieper> The following one will be Rω+1RS.
2023-07-26 13:00:15 -0400 < mnieper> ping-test
2023-07-26 13:00:19 -0400 < sham1> pong
2023-07-26 13:00:21 -0400 < dpk> pong-test?
2023-07-26 13:00:38 -0400 < mnieper> Thought I had a connection problem. :)
2023-07-26 13:00:41 -0400 < Oxyd> But, ω+1 is just ω.
2023-07-26 13:01:03 -0400 < sham1> ω+1 is explicitly not ω. It's the position after ω
2023-07-26 13:01:13 -0400 < Oxyd> 2^ω would be better.
2023-07-26 13:01:32 -0400 < mnieper> ω+1 is correct.
2023-07-26 13:01:49 -0400 < mnieper> ω is viewed as an ordinal number (what else).
2023-07-26 13:02:22 -0400 < mnieper> If you viewed it as a cardinal number, you would write it as an aleph.
2023-07-26 13:02:33 -0400 < mnieper> In that case you are right.
2023-07-26 13:03:23 -0400 < dpk> (i didn't do A-level Further Maths, what is ω? as an historical linguist i assumed it was simply chosen as the last letter of the Greek alphabet, signifying the ultimate version)
2023-07-26 13:04:01 -0400 < mnieper> Cantor chose this letter for this reason (and also because he was religious).
2023-07-26 13:04:20 -0400 < mnieper> It is the first infinite ordinal number.  What comes after 0, 1, 2, ...
2023-07-26 13:04:59 -0400 < mnieper> You can continue counting from ω.  ω+1, ω+2, ω+3, ...
2023-07-26 13:05:28 -0400 < mnieper> You end with ω2. Then ω2+1, ω2+2, ..., ω3
2023-07-26 13:05:40 -0400 < mnieper> Eventually ω4, ω5, ...
2023-07-26 13:06:03 -0400 < mnieper> At the end of this sequence ω \cdot ω
2023-07-26 13:06:16 -0400 < mnieper> That is ω^2.
2023-07-26 13:06:20 -0400 < dpk> oh. so you can also move aleph null guests into Hilbert's hotel by moving all guests from room n to ω+n?
2023-07-26 13:06:33 -0400 < mnieper> Yes
2023-07-26 13:07:32 -0400 < mnieper> Because ω2 still has the same cardinality as ω
2023-07-26 13:08:01 -0400 < mnieper> It has only aleph0 many predecessors.
2023-07-26 13:08:29 -0400 < mnieper> But there is a smallest ordinal number that has more then aleph0 predecessors.  This is \omega_1.
2023-07-26 13:08:31 -0400 < Oxyd> Also ω+1 and 1+ω are different. Which is where my confusion came from.
2023-07-26 13:08:44 -0400 < sham1> Yeah, it's not commutative
2023-07-26 13:08:47 -0400 < mnieper> Yes, 1+\omega is just \omega.
2023-07-26 13:09:19 -0400 < mnieper> 0, 1, 2, 3, ... is order-isomorphic to -1, 0, 1, 2, 3, ...
2023-07-26 13:09:46 -0400 < mnieper> 0, 1, 2, 3, ... is not order-isomorphic to 0, 1, 2, 3, ..., ω
2023-07-26 13:11:25 -0400 < mnieper> Here you find some of the countable ordinals, all ready to name a future Scheme standard: https://neugierde.github.io/cantors-attic/Lower_attic
2023-07-26 13:12:20 -0400 < dpk> "theory of infinite time Turing machines" – ah, this maybe answers something i idly wondered a few months ago
2023-07-26 13:12:56 -0400 < dpk> (what the cardinality of the infinity is, if any, in which time it may be possible to prove haltingness)
2023-07-26 13:14:04 -0400 < dpk> (i expressed it somewhat more coherently at the time)
2023-07-26 13:20:54 -0400 < dpk> 18:07:52 <dpk> pointless thought of the moment:
2023-07-26 13:20:54 -0400 < dpk> 18:08:43 <dpk> the Halting Problem is unsolvable in finite time. can it then be resolved in an infinite time less than the infinite time it would take to run the program itself?
2023-07-26 13:20:54 -0400 < dpk> 18:09:30 <dpk> i guess all infinities in program execution time are countable though, since it's a discrete unit (instructions, or beta-reductions, or whatever)
2023-07-26 13:29:35 -0400 < mnieper> There are successor ordinal numbers (+1 of another one) and limit ordinal numbers (being the supremum of all smaller ones).
2023-07-26 13:29:46 -0400 < mnieper> Time becomes an ordinal number.
2023-07-26 13:30:16 -0400 < mnieper> The state at a successor "time" is what happens after performing one computation step as always.
2023-07-26 13:30:32 -0400 < mnieper> So this way you get from step 0 to 1 to 2 to ...
2023-07-26 13:30:51 -0400 < mnieper> ... and also from omega to omega+1 to omega+2 to ...
2023-07-26 13:31:16 -0400 < mnieper> So one has to answer what happens at limit times.  The first such time is omega itself.
2023-07-26 13:33:06 -0400 < mnieper> What you do is taking the supremum of the results on the strip of the Turing machine of all earlier times.
2023-07-26 13:34:34 -0400 < mnieper> So you can achieve at omega time countably many 1s on the strip.
2023-07-26 13:37:29 -0400 < mnieper> limsup instead of sup to be precise.
2023-07-26 13:38:58 -0400 < mnieper> These are infinite Turing machines with countable strip length.  But one can also consider ones where the strip is modelled by an ordinal itself.
2023-07-26 13:50:04 -0400 < mnieper> dpk: See the model here, for example: https://arxiv.org/pdf/math/0502264.pdf
2023-07-26 13:51:08 -0400 < mnieper> In this model, the running time can be any ordinal.
2023-07-26 13:57:04 -0400 < mnieper> So your question about whether more than infinity plays a role is a good one.
2023-07-26 14:26:08 -0400 < pinoaffe> dpk: you may be interested in computability theory, which deals with precisely these sorts of questions
2023-07-26 14:33:28 -0400 < pinoaffe> I can recommend the following introduction to computability theory: https://www.math.ru.nl/~terwijn/teaching/syllabus.pdf
2023-07-26 17:42:04 -0400 < seninha> hi, in schemes, a garbage-collected port -- say, the programmer runs (open-input-file /etc/passwd) on repl without assigning it to something in the environment -- is also closed or just the port object is freed?
2023-07-26 17:43:48 -0400 < seninha> The REPL of gambit correctly prints that it is a port object: #<input-port #2 "/etc/passwd"> does the spec requires it to be also closed?
2023-07-26 17:45:08 -0400 < sham1> I'd be surprised if it didn't get closed, but the spec has no such requirement
2023-07-26 18:02:39 -0400 < seninha> sham1: thanks; i think the implementation is free to handle that case or not then.
2023-07-26 18:24:16 -0400 < flatwhatson> it's common for gc'd languages to "leak" open file descriptors, with no guarantees about if/when they'll be closed.  it's why we have call-with-input-file or python's "with" keyword
2023-07-26 18:25:12 -0400 < flatwhatson> so eg. naively opening a bunch of files in a loop can easily hit limits on number of open files
2023-07-26 18:25:44 -0400 < flatwhatson> so not explicitly closing ports or using a scope guard is a programming error
2023-07-26 18:29:20 -0400 < jcowan> A particularly interesting case is that if two procedures have the same code and all their local variables are immutable, they are egal?, but if some variables are mutable they are not egal? unless they are eq?.
2023-07-26 18:29:55 -0400 < jcowan> s/are immutable/& and their values are egal?/
2023-07-26 18:39:39 -0400 < wasamasa> clearly, the correct behavior should be informing the programmer of any leaked resources and reprimand them
2023-07-26 18:48:32 -0400 < seninha> flatwhatson: thanks. I was thinking about that case now after implementing gc on my scheme: whether should i close the ports or not
2023-07-26 18:51:19 -0400 < seninha> i will not close them. just to simplify implementation (and the programmer (myself) should close them anyway)
2023-07-26 21:02:20 -0400 < flatwhatson> what's the mnemonic for "egal?"?  google tells me it's german for "doesn't matter"
2023-07-26 21:02:57 -0400 < flatwhatson> or an eagle meme
--- Day changed Thu Jul 27 2023
2023-07-27 00:27:19 -0400 < jcowan> flatwhatson: egal as in égalité
2023-07-27 00:29:08 -0400 < jcowan> Baker's paper says it is Old French
2023-07-27 00:32:17 -0400 < flatwhatson> (equal? equal? egal?)
2023-07-27 00:33:13 -0400 < sham1> #f
2023-07-27 00:33:17 -0400 < sham1> Different semantics
2023-07-27 00:35:35 -0400 < flatwhatson> ah, like eq? that respects referential transparency?
2023-07-27 00:37:12 -0400 < flatwhatson> EGAL: Compare mutable objects with reference equality, and immutable objects with value equality.
2023-07-27 00:39:47 -0400 < flatwhatson> cool, deduplicating closures is a nice use-case
2023-07-27 01:20:41 -0400 < mnieper> The German "egal" =
2023-07-27 01:21:12 -0400 < mnieper> = "doesn't matter" is, of course, rooted in the concept of equality.
2023-07-27 01:28:43 -0400 < mnieper> As for `egal?', it should be an error to apply on procedures; "having the same code" should not be an observable property because that is an implementation detail (depending on the implementation, two definitions of the same procedure may be joined or not, for example).
2023-07-27 01:29:54 -0400 < mnieper> Moreover, looking into closures (by examining the local variables) breaks abstraction barriers because things that were assumed to be private no longer are.
2023-07-27 01:33:02 -0400 < flatwhatson> i was thinking from an implementation level, the vm or garbage collector running egal? on its internal representation of a closure
2023-07-27 01:34:25 -0400 < mnieper> Yes, but that should not be exposed to the user IMO.
2023-07-27 01:35:54 -0400 < mnieper> Use a tagged procedure with a mutable cell, instead.  In this case, there are no doubts about equality.  Every (lambda/tag () ...) creates a new one.
2023-07-27 01:36:15 -0400 < mnieper> If we distinguished between (IEEE) floats and inexact real numbers, equality comparison of floats should work but equality comparison between inexact numbers should be an error.
2023-07-27 01:38:11 -0400 < mnieper> For some areas, predicates do not seem to be sufficient.  They have to return #t or #f, so the problem at hand needs to be decidable.
2023-07-27 01:39:41 -0400 < mnieper> What's needed (but I don't know how to make this part of a language in a formal, satisfying way) is also a concept of a statement that can be made (which means #t) but where one cannot force a result.
2023-07-27 01:40:08 -0400 < mnieper> For example, asking whether a general program halts would be predicate that would not be computable.
2023-07-27 01:40:20 -0400 < mnieper> But the statement that a particular program halts makes sense.
2023-07-27 01:42:02 -0400 < flatwhatson> #maybe
2023-07-27 01:48:55 -0400 < sham1> Eh, I don't think we need to have that in the language. Like for type predicates, you want them to halt
2023-07-27 01:49:32 -0400 < mnieper> With #maybe an implementation can do: (= 1.0 1.0) => #maybe
2023-07-27 01:50:29 -0400 < mnieper> The problem I see is that it may give too much freedom to implementations, allowing them to always return #maybe.
2023-07-27 01:51:06 -0400 < aeth> maybe
2023-07-27 01:51:18 -0400 < sham1> Perhaps
2023-07-27 01:51:41 -0400 < mnieper> Vielleicht
2023-07-27 01:51:45 -0400 < flatwhatson> every #maybe causes execution to diverge along both #t and #f paths simultaneously
2023-07-27 01:52:15 -0400 < sham1> Oh, so it'd be a built-in amb
2023-07-27 01:52:24 -0400 < flatwhatson> RΨRS
2023-07-27 01:53:00 -0400 < mnieper> (if (nuclear-attack-detected?) <strike-back> <peace>)
2023-07-27 01:54:45 -0400 < mnieper> Maybe the concept of "proof" helps here.  In logic/mathematics, theorems are judgments.  One cannot hope for a decision procedures whether a formula is a theorem or not.  But given a proof candidate, one can effectively decide whether this candidate is a proof of the formula and the formula thus a theorem.
2023-07-27 01:55:14 -0400 < mnieper> So we would have predicates with an extra argument, a potential witness.
2023-07-27 01:55:59 -0400 < mnieper> The predicate checks whether the witness proves the truth.
2023-07-27 01:59:14 -0400 < mnieper> For example, whether two (exact) real numbers are not equal to each other is generally undecidable.
2023-07-27 01:59:46 -0400 < mnieper> So (!= x y) is not a good predicate for exact real numbers.
2023-07-27 02:00:01 -0400 < mnieper> But (!= x y d) would be.
2023-07-27 02:00:38 -0400 < mnieper> Here, "d" is the decimal place (as an integer) where "x" and "y" are supposed to differ.
2023-07-27 02:01:09 -0400 < mnieper> The implementation can check this and accordingly return a result.
2023-07-27 02:11:29 -0400 < flatwhatson> srfi-64 has test-approximate for this
2023-07-27 02:14:43 -0400 < mnieper> This is not exactly the same (but better than a simple equality test).
2023-07-27 02:15:09 -0400 < mnieper> In `test-approximate', the programmer has to understand which epsilon they may choose.
2023-07-27 02:15:53 -0400 < mnieper> All test-approximate does is answering the question: Assume the two real values are exact, then they are within epsilon.
2023-07-27 02:16:00 -0400 < mnieper> The problem is the assumption.
2023-07-27 02:16:01 -0400 < jackdaniel> "exact" real number either can be represented as a ratio, and then you may say with certainity that x and y are the same, or you'll end up with no memory to compare them
2023-07-27 02:16:23 -0400 < jackdaniel> s/compare them/represent them/
2023-07-27 02:16:47 -0400 < mnieper> I can represent pi, which is not a rational, in finite memory.
2023-07-27 02:16:59 -0400 < jackdaniel> you represent it as float which has finite precision
2023-07-27 02:17:02 -0400 < jackdaniel> it is not "exact"
2023-07-27 02:17:02 -0400 < mnieper> I can prove in finite time that pi and e differ in the first place.
2023-07-27 02:17:22 -0400 < mnieper> jackdaniel: In Scheme, float is not the same as a real is not the same as an inexact.
2023-07-27 02:18:16 -0400 < jackdaniel> how do you represent pi in scheme?
2023-07-27 02:18:19 -0400 < mnieper> I could represent pi as an unevaluated `(* 4 (arctan 1))'
2023-07-27 02:18:29 -0400 < mnieper> (The implementation could, that is.)
2023-07-27 02:18:30 -0400 < jackdaniel> that's an unevaluated form, isn't it?
2023-07-27 02:18:52 -0400 < jackdaniel> I mean - I'm sure that scheme makes a difference between lists and numbers
2023-07-27 02:19:45 -0400 < mnieper> The exact internal representation won't be exactly the same representation as chosen for lists.
2023-07-27 02:20:49 -0400 < jackdaniel> let me ask differently - do you know of a scheme implementation that represents pi as an "exact real" (for whatever it means)?
2023-07-27 02:20:51 -0400 < mnieper> The root of the misunderstanding is, I guess, that the RnRS define a fancy numeric tower and the attributes inexact and exact, but the existing implementations are a mere, shallow shadow of this tower.
2023-07-27 02:21:15 -0400 < mnieper> jackdaniel: I don't know.
2023-07-27 02:21:41 -0400 < jackdaniel> I see
2023-07-27 02:22:39 -0400 < mnieper> An actually working method to represent exact real number is to represent them as what I want to call an "oracle".
2023-07-27 02:23:18 -0400 < mnieper> You give the oracle a rational epsilon and it answers with a rational number that is guaranteed within epsilon of the real number the oracle represents.
2023-07-27 02:23:45 -0400 < mnieper> Up to some type code, oracles are thus Scheme procedures mapping rational numbers to rational numbers.
2023-07-27 02:24:09 -0400 < mnieper> (define (rational->real q) (lambda (eps) q)) defines the embedding of Q into R.
2023-07-27 02:24:17 -0400 < mnieper> Addition is given by:
2023-07-27 02:24:53 -0400 < mnieper> (define (real+ x y) (lambda (eps) (+ (x (/ eps 2)) (y (/ eps 2)))))
2023-07-27 02:27:15 -0400 < mnieper> Multiplication is a bit more complicated (because one cannot just use (/ eps 2) flatly).
2023-07-27 02:47:33 -0400 < mnieper> An efficient implementation would cache some results, of course.
2023-07-27 02:54:59 -0400 < flatwhatson> it reminds me of "expression templates", but i guess that's true of any delayed evaluation
2023-07-27 02:57:05 -0400 < flatwhatson> also this seems to be approaching symbolic computation
2023-07-27 03:12:34 -0400 -!- Netsplit *.net <-> *.split quits: lonjil, dave0, sp1ff, teiresias, madage, yosafbridge, koluacik_, thatcher, GreaseMonkey, enzuru,  (+175 more, use /NETSPLIT to show all of them)
2023-07-27 03:17:29 -0400 -!- Netsplit over, joins: jeosol, ecraven, bandali, hirigaray, ggoes, libfud, conjunctive, ornx, zups, LeoNerd (+17 more)
2023-07-27 03:17:45 -0400 -!- Netsplit over, joins: mrvdb, pinoaffe, motersen, mirai, madage, ec, deltab, thatcher, elflng_, polyrob (+21 more)
2023-07-27 03:18:14 -0400 -!- Netsplit over, joins: atka, dave0, mala, ft, rx80, fizzie, turlando, ronald
2023-07-27 03:19:01 -0400 -!- Netsplit over, joins: cpli, csepp, dan_berg_pub
2023-07-27 03:19:01 -0400 -!- Netsplit over, joins: kws, fluffyballoon, wklew
2023-07-27 03:19:01 -0400 -!- Netsplit over, joins: listentolist
2023-07-27 03:19:01 -0400 -!- Netsplit over, joins: zyd, whereiseveryone
2023-07-27 03:19:01 -0400 -!- Netsplit over, joins: evhan
2023-07-27 03:19:07 -0400 -!- Netsplit over, joins: hugo, klovett, mwnaylor, lechner, enzuru, xelxebar, leah2, mns, _________, Spawns_Carpeting (+52 more)
2023-07-27 03:19:41 -0400 < rudybot> la la la
2023-07-27 03:46:45 -0400 < mdhughes> Normally I just use a float/double representation of pi, but I have done more demanding simulations where pi was pre-evaluated to a bignum of whatever digits we needed. You only need a certain number of digits to satisfy any physics problem.
2023-07-27 03:47:29 -0400 < mdhughes> Also: https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimals-of-pi-do-we-really-need/
2023-07-27 03:50:42 -0400 < jackdaniel> 3 is a reasonable approximation of pi (and it is a fixnum™)
2023-07-27 03:54:00 -0400 < sham1> e = 3 = π
2023-07-27 03:54:11 -0400 < sham1> Or have I spent too much time around engineers
2023-07-27 04:00:02 -0400 < mnieper> Yes, for any practical problem one only needs a certain number of decimal places.  That's exactly what the oracle idea represents.
2023-07-27 04:00:05 -0400 < mdhughes> For some tasks, yes.
2023-07-27 04:00:26 -0400 < mnieper> sham1 and jackdaniel will always set the allowance to 1/2. :)
2023-07-27 04:00:40 -0400 < mnieper> (pi-oracle 1/2) -> 3
2023-07-27 04:00:51 -0400  * jackdaniel will work with pi being a long float;)
2023-07-27 04:00:56 -0400 < mnieper> But even (pi-oracle 1/2) -> 7/2 is possible
2023-07-27 04:01:13 -0400 < jackdaniel> that said that's still inexact, but with explicit precision
2023-07-27 04:01:31 -0400 < mnieper> Your long float? Or what?
2023-07-27 04:01:37 -0400 < jackdaniel> even if we make a leap of faith that this can be performant and practical to use
2023-07-27 04:01:59 -0400 < jackdaniel> no, the idea of oracles
2023-07-27 04:02:49 -0400 < mdhughes> You don't want to be recalculating it during work, though.
2023-07-27 04:05:37 -0400 < sham1> You use the spigot algorithm and get as many digits as you think you'll need
2023-07-27 04:05:42 -0400 < sham1> Or something like that
2023-07-27 04:05:56 -0400 < mnieper> jackdaniel: It is exact insofar as when you give an allowance of eps and receive an x, you know for SURE that the true result is within eps around x.
2023-07-27 04:07:40 -0400 < mnieper> You certainly don't want exact reals (e.g. oracles) when training a neural network or something like this.  Hardware floats will be a magnitude faster.
2023-07-27 04:07:49 -0400 < jackdaniel> sure, but that's the same as with having some precision with floats (or bigfloats if we want to have it arbitrary)- each numerical operations makes us stray further from the "exact" result
2023-07-27 04:07:56 -0400 < mnieper> But there are areas where you have to be sure about the validity of your result.
2023-07-27 04:08:14 -0400 < mnieper> jackdaniel: No, here lies a big difference.
2023-07-27 04:08:21 -0400 < mnieper> See my example definition of the addition.
2023-07-27 04:08:53 -0400 < mnieper> The result cannot diverge because of numerical reasons.
2023-07-27 04:10:08 -0400 < jackdaniel> addition won't diverge, but you yourself noted that it will be more tricky with multiplication
2023-07-27 04:12:12 -0400 < jackdaniel> and non-trivial programs won't be limited only to one operation, (real-* (real-+ x y) z) and whatnot
2023-07-27 04:18:52 -0400 < mnieper> jackdaniel: It would be more tricky with multiplication but far from being impossible.
2023-07-27 04:22:07 -0400 < jackdaniel> I don't agree nor disagree, I've clearly did not spend any significant amount of time thinking about the topic; that said not losing precision with limited precision numerics after a long (possibly recursive) chain of arithmetic operations sounds (at a glance) implausible
2023-07-27 04:22:55 -0400 < mnieper> It works because (real-* (real-+ x y) z) is still a procedure.
2023-07-27 04:23:10 -0400 < mnieper> An algorithm to calculate your final result.
2023-07-27 04:23:28 -0400 < mnieper> Only when you need it, you give your needed precision.
2023-07-27 04:24:01 -0400 < mnieper> It then bubbles up, possibly needing temporary results in higher precision.
2023-07-27 04:24:08 -0400 < jackdaniel> I get the part that you may create a computation where eta is a parameter, but multiple operations may blow sub-eta differences to bigger disparities
2023-07-27 04:24:34 -0400 < mnieper> Take my addition definition from above, for example.
2023-07-27 04:24:54 -0400 < jackdaniel> I'd like to take an exponent if that's an option
2023-07-27 04:25:16 -0400 < mnieper> ((real-+ x y) 1) becomes (+ (x 1/2) (y 1/2))
2023-07-27 04:25:17 -0400 < jackdaniel> if your eta must be exponentially smaller than the desired precision of the final result, then ...
2023-07-27 04:25:38 -0400 < mnieper> What do you mean by "expoentially smaller"?
2023-07-27 04:26:07 -0400 < mnieper> You would like to see an implementation of real-exp?
2023-07-27 04:27:09 -0400 < jackdaniel> I mean a situation where each operation requires 2^n higher precision than the input eta parameter
2023-07-27 04:27:33 -0400 < mnieper> What is n and what is eta?
2023-07-27 04:28:15 -0400 < mnieper> As long as the precision needed for the inputs is computable (not the BB function) there is no problem, in principle.
2023-07-27 04:28:21 -0400 < jackdaniel> in your example above eta would be "1", and n would be also 1 because there is only one operation
2023-07-27 04:29:09 -0400 < jackdaniel> the 'in principle' is a worrying part :) that said I have work to do (and keep in mind that I'm only expressing my doubts, not denying the idea), good luck :)
2023-07-27 04:29:28 -0400 < jackdaniel> (I'll read the logs later of course)
2023-07-27 04:30:57 -0400 < mnieper> One last remark: If your problem is numerically so unstable that this blow-up of needed precision happens, it is inherent to the problem.
2023-07-27 04:31:28 -0400 < mnieper> Using inexact floats would not work at all.
2023-07-27 04:32:20 -0400 < jackdaniel> sure, I'm only questioning whether the oracle is really exact in practice (for numbers which precise non-symbolic representation would require infinite memory)
2023-07-27 04:32:58 -0400 < mnieper> It works for "definable" real numbers.
2023-07-27 04:33:29 -0400 < mnieper> Definable means real numbers you can describe (with an algorithm) in finite length.
2023-07-27 04:33:30 -0400 < jackdaniel> and numerically stable problems(?)
2023-07-27 04:33:52 -0400 < mnieper> There are uncountably many real numbers, but only countably definable ones.
2023-07-27 04:34:17 -0400 < mnieper> But no one can write down a non-definable one, so there is no problem. :)
2023-07-27 04:35:03 -0400 < mnieper> " and numerically stable problems(?)" ... ?
2023-07-27 04:35:03 -0400 < mnieper>
2023-07-27 04:35:45 -0400 < mnieper> If a problem is unstable, the oracle approach would at least tell you that the inputs are needed in a 100000-digit precision for your result to be exact up to 3 digits.
2023-07-27 04:35:46 -0400 < jackdaniel> I really need to get things done today! I'm referring to "If your problem is numerically so unstable that this blow-up of needed precision ..."
2023-07-27 04:36:10 -0400 < mnieper> Then let's continue to talk about it later.
2023-07-27 04:36:13 -0400 < mnieper> Happy working!
2023-07-27 04:36:17 -0400 < jackdaniel> thanks! :)
2023-07-27 05:20:17 -0400 < mnieper> Here is an untested implementation of some exact real number operations: https://paste.debian.net/plain/1287078
2023-07-27 05:20:21 -0400 < mnieper> jackdaniel: ^^^
2023-07-27 05:22:58 -0400 < jcowan> mnieper: egal? was designed in an era when transparency was considered a central value of Lisp
2023-07-27 05:36:10 -0400 < mnieper> I understand.  If you equate a Scheme/Lisp procedure (actually a closure) with a representation of the form "code + a vector of closed over variables" then the old-era specification of "egal?" is perfect.
2023-07-27 05:37:07 -0400 < mnieper> Early Lisp was definitely closer to the metal, where metal may not mean the actual hardware (as it does in C) but some form of idealized hardware.
2023-07-27 05:39:53 -0400 < mnieper> Re: mdhughes: https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimals-of-pi-do-we-really-need/:
2023-07-27 05:40:06 -0400 < mnieper> The article ^^ makes some assumptions that may or may not be true.
2023-07-27 05:40:33 -0400 < mnieper> As long as we only look at the formulas for the circumference or area of a circle, the estimates work.
2023-07-27 05:41:22 -0400 < mnieper> But, in principle, there could be a law of nature being described by a formula where Pi has to be taken by its 10,000,000 power.
2023-07-27 05:41:31 -0400 < mdhughes> I'm gonna go with the JPL scientists' estimates, not yours. And the ones I've dealt with for work have been similar.
2023-07-27 05:42:16 -0400 < mdhughes> If you have an actual example of such a formula, evidence talks.
2023-07-27 05:42:32 -0400 < mnieper> I am referring to the last sentence: "But there are no questions – prosaic or esoteric – in humankind’s noble efforts to explore or comprehend the marvels of the cosmos, from the unimaginably smallest scales to the inconceivably largest, that could require very many of those digits."
2023-07-27 05:43:29 -0400 < mnieper> That remains an unproven claim in the text.
2023-07-27 05:48:40 -0400 < mdhughes> OK, feel free to disprove it, and let them know.
2023-07-27 05:55:00 -0400 < sham1> I'm gonna nitpick a bit and say that C also deals with what we'd call "idealised metal" because while CPU designers do "target" C in a way, no hardware in existence works like the standard abstract machine, not even original PDP-11s as such
2023-07-27 05:55:23 -0400 < mnieper> sham1: I was waiting for such a nitpick! :)
2023-07-27 05:55:47 -0400 < sham1> That's why there's the as-if rule, and Scheme of course can also be said to have that
2023-07-27 05:56:34 -0400 < mnieper> The problem is that I used the term "closer to" without giving a precise definition what this means.
2023-07-27 05:56:45 -0400 < mnieper> Or is supposed to mean.
2023-07-27 07:01:19 -0400 < lockywolf> https://github.com/Calysto/calysto_scheme
2023-07-27 07:21:42 -0400 < mnieper> lockywolf: What is the context?
2023-07-27 07:52:30 -0400 < lockywolf> mnieper: just found this scheme-related thing, and thought that someone might be interested
2023-07-27 07:54:56 -0400 < mnieper> Ah, gotcha!
2023-07-27 08:20:57 -0400 < lockywolf> mnieper: did you get the postcard?
2023-07-27 08:29:06 -0400 < mnieper> lockywolf: You mean an old-style paper postcard?
2023-07-27 08:29:17 -0400 < lockywolf> yeah
2023-07-27 08:30:40 -0400 < mnieper> No, unfortunately not.
2023-07-27 08:30:55 -0400 < mnieper> :-/
2023-07-27 08:32:42 -0400 < lockywolf> :(
2023-07-27 08:33:07 -0400 < lockywolf> maybe the address on your website is outdated?
2023-07-27 08:33:13 -0400 < mnieper> That would have been a nice surprise.  When should it have arrived?
2023-07-27 08:33:25 -0400 < mnieper> s/nice/very nice
2023-07-27 08:34:19 -0400 < lockywolf> Who knows? postcards are delivered with "best effort"
2023-07-27 08:34:30 -0400 < lockywolf> I sent one about February
2023-07-27 08:34:57 -0400 < mnieper> From where exactly?
2023-07-27 08:35:17 -0400 < lockywolf> China
2023-07-27 08:35:43 -0400 < lockywolf> it's UDP, so some mail-o-grams might be lost
2023-07-27 08:37:31 -0400 < mnieper> So far, every postcard I knew of had arrived. But I think the maximal running times were like two or three months.
2023-07-27 08:38:51 -0400 < mnieper> Anyway, I feel truly flattered for the honour to receive an old-fashioned postcard!
2023-07-27 08:40:00 -0400 < mnieper> Even if the actual receipt hasn't yet happened.
2023-07-27 11:35:35 -0400 < mnieper> Do we have a well-known algorithm that takes a Scheme datum value and produces a reproducible hash from it?
2023-07-27 11:36:21 -0400 < mnieper> Scheme systems have `equal-hash', but this is implementation-specific and has no collision guarantees.
2023-07-27 11:37:58 -0400 < mnieper> Writing the datum into an (UTF-8 encoded) bytevector and taking the SHA-1 of it is another option, but the result will depend on the Scheme writer (because the written representation is not unique/canonical).
2023-07-27 11:38:49 -0400 < mnieper> Having a well-specified (datum->uuid DATUM) sounds like a good idea.
2023-07-27 11:46:37 -0400 < sham1> I feel that it should be implementation-specific but consistent
2023-07-27 11:56:48 -0400 < mnieper> Why implementation-specific?
2023-07-27 11:57:22 -0400 < mnieper> Say, someone gives me a datum and the hash. I may want to check whether the hash corresponds to the datum.
2023-07-27 11:57:31 -0400 < mnieper> I may have a different implementation.
2023-07-27 12:01:43 -0400 < sham1> Well you'd have to choose how to hash it
2023-07-27 12:02:52 -0400 < mnieper> Yes, indeed.
2023-07-27 12:03:26 -0400 < mnieper> I wonder whether one of you have already thought about it and could propose a good algorithm.
2023-07-27 12:03:36 -0400 < mnieper> s/have/has
2023-07-27 12:17:29 -0400 < amirouche> hello schemers :)
2023-07-27 12:19:58 -0400 < sham1> All I can really think of is SipHash, but then we'd also have to think just how every standard type is hashed and how to combine values, although the latter is probably part of the SipHash to begin with
2023-07-27 12:20:41 -0400 -!- mirai_ is now known as mirai
2023-07-27 12:22:40 -0400 < mnieper> sham1: To have something well-defined, I would restrict the domain to (non-circular) datum values.
2023-07-27 12:25:08 -0400 < mnieper> vectors, pairs, empty list, numbers, strings, characters, booleans, bytevectors, symbols.
2023-07-27 12:25:36 -0400  * mnieper waves to amirouche saying hello
2023-07-27 12:35:42 -0400 < seninha> How can a scheme-with-fexprs (like kernel) do tail call optimization if the evaluator does not know how the combiner (like, everything is a combiner) will evaluate? For example, on Scheme, the evaluator knows that it can tail-call optimize the last expression of a (begin ...) sequence; but in kernel, the car of a pair is a combiner and there is no notion of syntatic forms like begin or if that could have a tail context. How is tail call optimization
2023-07-27 12:35:43 -0400 < seninha> possible there?
2023-07-27 12:37:34 -0400 < seninha> (i think i was not right on "everything is a combiner"... maybe "every combination is either an applicative or operative, there's no syntactic forms")
2023-07-27 12:40:08 -0400 < sham1> Optimisations are one reason fexprs aren't really that good
2023-07-27 12:42:40 -0400 < seninha> the kernel spec requires an implementation to be tail call optimized, but as far as could understand it cherry picks which operators have a tail call context.
2023-07-27 12:43:33 -0400 < seninha> (i may be talking nonsense, but that's how i understood kernel)
2023-07-27 12:43:41 -0400 < sham1> You can't optimise fexprs
2023-07-27 12:44:07 -0400 < mnieper> That does not necessarily have something to do with tail calls.
2023-07-27 12:48:45 -0400 < dpk> seninha: there is still the notion of a tail context. the implementation of a given special form will typically tail-call eval
2023-07-27 12:53:27 -0400 < seninha> so the evaluator is not as simple as "if symbol, lookup environment; if non-pair, self evaluate; if (car pair) is combiner, apply; else error"
2023-07-27 12:55:00 -0400 < seninha> special forms should then handled case-by-case by the eval procedure in order to a recursion yield an iterative process
2023-07-27 12:57:27 -0400 < dpk> why do you think eval isn't as simple as that?
2023-07-27 12:59:20 -0400 < dpk> eval will tail-call apply in the example you give (in the standard SICP model of evaluations, anyway); apply will tail-call the procedure it is given as an argument; that procedure, if it is a special form, will probably ultimately tail-call back to eval
2023-07-27 13:02:41 -0400  * mnieper nods to what dpk says
2023-07-27 13:03:10 -0400 < sham1> RE hashing: for prior art from CLHS: <http://www.lispworks.com/documentation/lw71/CLHS/Body/f_sxhash.htm>
2023-07-27 13:03:39 -0400 < sham1> This one also does work for cyclic values fwiw
2023-07-27 13:03:43 -0400 < mnieper> seninha: Think of every procedure/combiner taking its continuation as a hidden argument (CPS-style).  It's free to do anything with it what it wants.
2023-07-27 13:03:54 -0400 < sham1> Speaking of that, I noticed that (equal?) in Chibi is non-compliant
2023-07-27 13:04:16 -0400 < seninha> dpk, the way I see how eval is implemented imperatively (and how I learnt from sicp) is as a routine with a loop: if eval is performed on a non-tail call context, call the eval recursivelly, otherwise just set the proper registers/variables and goto the beginning of the routine
2023-07-27 13:04:19 -0400 < mnieper> sham1: It stops after 10000 cylcles?
2023-07-27 13:04:27 -0400 < sham1> In fact the opposite. It doesn't stop
2023-07-27 13:04:52 -0400 < dpk> i think Chibi has multiple equal? implementations
2023-07-27 13:05:06 -0400 < mnieper> dpk: It would a surprise if not :)
2023-07-27 13:05:07 -0400 < sham1> I was just using the one that is in the default REPL
2023-07-27 13:05:11 -0400 < dpk> one of them checks for cycles as required by R7RS and another doesn't
2023-07-27 13:05:30 -0400 < sham1> (equal? '#1=(#1# . #1#) '#2=(#2# . #2#)) ; Loops even though it shouldn't. Maybe the one in the REPL by default is just borked
2023-07-27 13:05:45 -0400 < mnieper> Maybe it is the other one that stops after 10,000 comparisons.
2023-07-27 13:06:02 -0400 < mnieper> sham1: Have you done (import (scheme base))?
2023-07-27 13:06:08 -0400 < sham1> I could try that, yes
2023-07-27 13:06:19 -0400 < sham1> It's weird that it's not using that version by default though
2023-07-27 13:06:32 -0400 < dpk> hmm, the (scheme base) version loops for me as well
2023-07-27 13:06:44 -0400 < dpk> (and the loop can only be exited by SIGQUIT, how fun)
2023-07-27 13:07:14 -0400 < dpk> this appears to be a genuine bug
2023-07-27 13:07:20 -0400 < dpk> (equal? '#1=(a . #1#) '#2=(a . #2#)) does terminate
2023-07-27 13:07:28 -0400 < sham1> Yeah
2023-07-27 13:07:42 -0400 < sham1> Of all the implementations I tested, Gauche was the only one that halted, and gave #t
2023-07-27 13:08:02 -0400 < sham1> Which seems reasonable. Both pairs are infinite trees of themselves
2023-07-27 13:08:03 -0400 < mnieper> sham1: Chez didn't halt???
2023-07-27 13:08:08 -0400 < sham1> I didn't check chez
2023-07-27 13:08:28 -0400 < dpk> go, claim your eternal glory https://github.com/ashinn/chibi-scheme/issues/new
2023-07-27 13:08:42 -0400 < dpk> Chez halts correctly
2023-07-27 13:08:52 -0400 < sham1> I didn't have Chez on anything. I just tested Chibi, Guile, Gauche and CHICKEN. And I had to tweak the example in CHICKEN because it didn't like the datum labels
2023-07-27 13:09:04 -0400 < sham1> And of course the R7RS egg even warns about equal? not being proper for r7rs
2023-07-27 13:09:39 -0400 < sham1> I would imagine Chez halting. Does it give #t or #f
2023-07-27 13:09:52 -0400 < dpk> Chicken has a half-arsed implementation of something? i'm shocked, shocked i say
2023-07-27 13:09:58 -0400 < dpk> #t
2023-07-27 13:10:04 -0400 < sham1> You said it, not me
2023-07-27 13:10:29 -0400 < mnieper> In Chibi, you find something like: https://github.com/ashinn/chibi-scheme/blob/67fdb283b667c8f340a5dc7259eaf44825bc90bc/include/chibi/features.h#L884
2023-07-27 13:10:30 -0400 < rudybot> https://teensy.info/b5rL4AjZKA
2023-07-27 13:10:56 -0400 < mnieper> That smells like its implementation of equal? will never be bug-free.
2023-07-27 13:11:27 -0400 < mnieper> sham1: You have no Chez?
2023-07-27 13:11:54 -0400 < sham1> Yeah no. I should probably try to install it on my machines, but didn't just happen to have it handy
2023-07-27 13:12:01 -0400 < dpk> mnieper: i think that's the C implementation
2023-07-27 13:12:15 -0400 < dpk> the Scheme implementation, which appears to be the one you get when you start the REPL, is equiv? here https://github.com/ashinn/chibi-scheme/blob/67fdb283b667c8f340a5dc7259eaf44825bc90bc/lib/chibi/equiv.scm
2023-07-27 13:13:33 -0400 < dpk> but that also has some weird stuff going on with an apparent ‘bound’ of 100000
2023-07-27 13:13:54 -0400 < mnieper> Chibi is a great & grand hack.
2023-07-27 13:14:56 -0400 < mnieper> sham1: For serious work or when I don't feel like being in bug-hunting mood, I just use Chez. :)
2023-07-27 13:15:31 -0400 < sham1> I wasn't even hunting for bugs. I was discussing differences between CL and Scheme, and in particular how CL:EQUALP doesn't deal with cyclic data
2023-07-27 13:16:22 -0400 < mnieper> dpk: Maybe the equiv? stuff is not weird.
2023-07-27 13:16:39 -0400 < mnieper> It seems that it tries the approximation.
2023-07-27 13:17:03 -0400 < mnieper> And if this still has found no divergence after 100000 steps, a hashtable impl is used.
2023-07-27 13:17:45 -0400 < dpk> ah
2023-07-27 13:17:59 -0400 < mnieper> So this is probably correct but super-slow for circular data.
2023-07-27 13:18:24 -0400 < dpk> oh, right, there's a procedure called equiv? *inside* the procedure called equiv?
2023-07-27 13:18:44 -0400 < mnieper> Yeah... names are precious
2023-07-27 13:19:08 -0400 < mnieper> But thanks for pointing out Chibi's equiv? impl!
2023-07-27 13:22:31 -0400 < mnieper> seninha: In your eval-loop implementation.  Doesn't you get proper tail calls with your code because you call your eval in tail context?
2023-07-27 13:23:30 -0400 < mnieper> A super-small meta-circular interpreter is in TSPL: https://www.scheme.com/tspl4/examples.html#./examples:h7.  Here, `exec' is called in tail context.
2023-07-27 13:32:07 -0400 < mnieper> seninha: You may want to read about 3-LISP.
2023-07-27 13:32:17 -0400 < mnieper> Here is a modern approach: http://www.p-cos.net/documents/s32008.pdf
2023-07-27 13:33:14 -0400 < mnieper> Eval is called normalize (for some good reasons)
2023-07-27 13:33:20 -0400 < mnieper> Take a look at Fig. 4.
2023-07-27 13:34:07 -0400 < mnieper> Tail calls everywhere between normalize and reduce (this is the host language).
2023-07-27 13:36:04 -0400 < mnieper> It does not only have fexprs but from inside the program/repl it looks as if the interpreter is not running in the host language but in the language itself.
2023-07-27 13:36:20 -0400 < sham1> Issue sent
2023-07-27 13:36:25 -0400 < mnieper> So another interpreter is needed, but this one is also running in the language as well.
2023-07-27 13:51:20 -0400 < seninha> mnieper, this sounds like typing stuff with the coq programming language (the infinite chain of types of types of ...)
2023-07-27 13:59:16 -0400 < mnieper> seninha: In some sense, yes. There is also a reflection principle between universes.
2023-07-27 14:00:05 -0400 < seninha> mnieper, thanks im gonna read that
2023-07-27 14:01:35 -0400 < mnieper> sham1: dpk: Does the Chibi bug example already loop at (equal?/bounded a b 100000 100000)?
2023-07-27 14:03:40 -0400 < mnieper> Generally, cycles in datums should be banned.  It is an obscure, seldom used feature that produces a lot of edge cases, makes a lot of troubles, degrades performance and is always good for bugs.
2023-07-27 14:03:58 -0400 < mnieper> If one needs cycles, one can produce them procedurally.
2023-07-27 14:04:20 -0400 < mnieper> Datums should be inductive types.
2023-07-27 14:07:13 -0400 < sham1> Well you'd still need datum labels for when you (write) a cyclic datum, unless you just make them unwritable
2023-07-27 14:07:26 -0400 < sham1> And if you can write them, you might as well read them
2023-07-27 14:12:02 -0400 < mnieper> sham1: Make them unwritable (as in R<7RS) and, if possible, make them uncreatable.
2023-07-27 14:13:49 -0400 < mnieper> A possible way to achieve this is to forbid storing mutable vectors/lists in vector/pair locations.
2023-07-27 14:30:45 -0400 < sham1> Eh, I don't like that idea
2023-07-27 14:43:10 -0400 < mnieper> Why?
2023-07-27 14:45:16 -0400 < sham1> Feels like an arbitrary restriction
2023-07-27 14:45:58 -0400 < sham1> Unless one was to also ban mutable records from vectors/pairs, I suppose
2023-07-27 14:46:18 -0400 < sham1> And with a mutable record you can still do the self-reference, albeit with an indirection
2023-07-27 14:52:12 -0400 < mnieper> Records cannot be part of datum values, so this is less of a problem (also less of a problem for equal?).
2023-07-27 14:52:40 -0400 < mnieper> But I agree that one should be as radical and remove this kind of indirection as well, making records also an inductive type.
2023-07-27 14:53:08 -0400 < mnieper> People usually think of them as an inductive type anyway.
2023-07-27 14:53:42 -0400 < sham1> I personally like to think of them mostly as newtypes
2023-07-27 14:53:44 -0400 < mnieper> Infinite trees, etc. should be represented through procedures.
2023-07-27 14:54:01 -0400 < mnieper> sham1: Sure, but they also have fields.
2023-07-27 14:54:34 -0400 < mnieper> So, what you do is you define a data type.
2023-07-27 14:55:18 -0400 < mnieper> You have an introduction rule (the constructor) and elimination rules (the accessors).
2023-07-27 14:55:48 -0400 < mnieper> The picture breaks down and becomes messy as soon as you have circles.
2023-07-27 14:58:33 -0400 < mnieper> On the other hand, the benefit of allowing circles is minimal.
2023-07-27 16:02:44 -0400 < mnieper> dpk: In your R^{\omega}RS proposal you say that the symbol type may go.  What would the reader return for an input like "(foo bar)"?
2023-07-27 16:05:25 -0400 < mnieper> Unrelated: The idea of getting rid of (byte)vector literals in source code sounds intriguing.  (I argued that we didn't need #u64 ... and friends; but this was indeed only part of the story.)
2023-07-27 16:06:08 -0400 < mnieper> In principle, one could also get rid of string literals (just being vectors or characters), but that would make the code unreadable.
2023-07-27 16:10:18 -0400 < jcowan> Lexical syntax is mostly about convenience in code. In data files it is a necessity.
2023-07-27 16:12:14 -0400 < jcowan> That's why I designed Twinjo
2023-07-27 16:13:47 -0400 < jcowan> That's why I am willing to be guided by history in choosing what gets lexical syntax and what does not.
2023-07-27 16:14:21 -0400 < jcowan> (er, "that" has different referents in those two sentences)
2023-07-27 16:18:07 -0400 < mnieper> jcowan: Whether #(1 2 3) or (vector 1 2 3) is written in data files does not make such a big difference, does it? Even with a dumb reader that reads a list first (that has to be converted to a vector), the overhead is probably neglectable.
2023-07-27 16:19:00 -0400 < mnieper> I would rather think more about a FASL/binary format if large data needs to be written very fast and very efficiently.
2023-07-27 16:19:57 -0400 < mnieper> But I have to check out your Twinjo first. Do you have a link for me?
2023-07-27 16:23:03 -0400 < jcowan> It has both text and binary.
2023-07-27 16:23:41 -0400 < jcowan> Related question: Given a string that might be hex and might be base64, what would be a good convention for telling them apart?
2023-07-27 16:24:03 -0400 < dpk> you can't, reliably, so you shouldn't
2023-07-27 16:24:10 -0400 < jcowan> I'm thinking a base64 string should have a leading character that is not a hexdigit and is otherwise ignored
2023-07-27 16:24:17 -0400 < dpk> but base64 will of course contain letters other than a-fA-F
2023-07-27 16:24:18 -0400 < jcowan> but what is the best character for that?
2023-07-27 16:24:30 -0400 < dpk> and may end with some number of =
2023-07-27 16:24:42 -0400 < dpk> hmm, doesn't MIME use something for this
2023-07-27 16:24:57 -0400 < jcowan> I don't think so, they put it in the header name
2023-07-27 16:25:00 -0400 < sham1> You'd have to tag it
2023-07-27 16:25:09 -0400 < jcowan> Right, but with what tag?
2023-07-27 16:25:12 -0400 < jcowan> Shorter is better.
2023-07-27 16:25:33 -0400 < sham1> str
2023-07-27 16:25:52 -0400 < jcowan> so e.g. / can't appear in either notation, so we could use it to signal hex (or signal base64)
2023-07-27 16:26:01 -0400 < jcowan> what is the best signal/
2023-07-27 16:26:02 -0400 < jcowan> ?
2023-07-27 16:26:03 -0400 < dpk> oh, i'm thinking of https://en.wikipedia.org/wiki/MIME#Encoded-Word
2023-07-27 16:26:07 -0400 < dpk> which isn't particularly relevant
2023-07-27 16:26:33 -0400 < dpk> (write email software once, carry this shit around in your brain for the rest of your life)
2023-07-27 16:27:13 -0400 < dpk> mnieper: good question
2023-07-27 16:27:17 -0400  * jcowan nods and chuckles
2023-07-27 16:27:36 -0400 < dpk> i'm not sure. there are a number of things marked ‘maybe’ in my ideas list like that which would need further consideration and experimentation
2023-07-27 16:29:00 -0400 < jcowan> How about this:  hexdigit data is prefixed with #, since we are used to seeing that before hex numbers (no need for X)
2023-07-27 16:29:06 -0400 < sham1> Should probably write a list for R^{\omega}RS
2023-07-27 16:29:08 -0400 < dpk> e.g. i wrote maybe require SRFI 101 semantics for lists, but i'd want to do experiments first to see how that affects overall performance, given that a lot of lists are quite short so the extra constant overhead of Okasaki's random-access lists may outweigh the asymptotic performance gain compared to regular paris
2023-07-27 16:29:09 -0400 < jcowan> base64 data has no prefix
2023-07-27 16:29:24 -0400 < dpk> *regular pairs
2023-07-27 16:29:25 -0400 < sham1> You can add one: string:AAAA
2023-07-27 16:29:39 -0400 < jcowan> Too long
2023-07-27 16:29:48 -0400 < jcowan> the whole point here is compactness
2023-07-27 16:29:48 -0400 < mnieper> dpk: I understand your reservation against symbols+identifiers.  It makes things complicated to understand.  And then there is this strange quote which turns an identifier to a symbol.
2023-07-27 16:30:14 -0400 < jcowan> Symbols turn out to be an important runtime data structure, even if they had zip to do with identifiers.
2023-07-27 16:30:43 -0400 < sham1> That's about as compact you'll get in text without ambiguity
2023-07-27 16:30:55 -0400 < jcowan> Yes, it's about "Is it readable?"
2023-07-27 16:31:08 -0400 < jcowan> {xbabecafe}
2023-07-27 16:31:26 -0400 < sham1> For the binary version I'd probably just look at CBOR
2023-07-27 16:31:27 -0400 < jcowan> vs. {babecafe=} which is base64
2023-07-27 16:31:29 -0400 < sham1> For inspiration
2023-07-27 16:31:43 -0400 < jcowan> I'm using ASN.1 without schemas because of its extensibility
2023-07-27 16:31:44 -0400 < dpk> jcowan: x is a valid base64 digit, no?
2023-07-27 16:32:03 -0400 < jcowan> sorry, miswrote:  {#babecafe}
2023-07-27 16:32:06 -0400 < sham1> CBOR is also extendable. In fact, it's extendable in much the same way as ASN.1
2023-07-27 16:34:33 -0400 < mnieper> In Scheme/Lisp data files we obviously need something like symbols (if we don't want them to have a completely different form); in the running program, in the long term, they can be replaced by more type-safe enumeration values.
2023-07-27 16:37:15 -0400 < jcowan> Okay, here are the links you asked for: <https://github.com/s-expressions/twinjo/blob/master/spec/Twinjo.md> <https://github.com/s-expressions/twinjo/blob/master/spec/TwinjoLib.md> <https://docs.google.com/spreadsheets/u/1/d/1V-7E5d3fLON5DrVeHkVvp9h5SRgcteOgnPl8KvWTA3M/>
2023-07-27 16:39:52 -0400 < mnieper> Thank you!
2023-07-27 16:41:35 -0400 < mnieper> jcowan:
2023-07-27 16:41:46 -0400 < mnieper> No vectors then?
2023-07-27 16:42:03 -0400 < jcowan> No, a vector is a tagged list with an empty tag.
2023-07-27 16:42:10 -0400 < sham1> Vectors for a data format?
2023-07-27 16:42:13 -0400 < mnieper> Ah, found it.
2023-07-27 16:42:26 -0400 < jcowan> I'll clarify that
2023-07-27 16:42:59 -0400 < jcowan> sham1: Yes.
2023-07-27 16:43:40 -0400 < jcowan> For interoperability, what other languages interpret as a vector, Twinjo interprets as a proper list, so there are separate tags for vectors and for improper lists.
2023-07-27 16:44:05 -0400 < mnieper> jcowan: The overhead wouldn't be much if Twinjo Text would be a "true" S-expression, would it?
2023-07-27 16:44:19 -0400 < jcowan> What does "true" mean?
2023-07-27 16:45:37 -0400 < jcowan> The arguement for symbols as opposed to enums is that you cannot always statically know all the elements.  The world is too open-ended for that.
2023-07-27 16:45:39 -0400 < mnieper> Just lists, symbols and atoms for which a different representation would be truly inconvenient (strings, numbers)
2023-07-27 16:46:16 -0400 < jcowan> There's a different proposal for that, which is a subset of Twinjo
2023-07-27 16:46:37 -0400 < jcowan> Twinjo is meant to be able to serialize Scheme data
2023-07-27 16:46:54 -0400 < jcowan> I can't remember the name of the subset proposal, it's Lassi's
2023-07-27 16:47:39 -0400 < mnieper> The minimal S-expression format would as well:   true would be #t, (quote true) would be the symbol true, (vector 1 2 3) would a vector, etc.
2023-07-27 16:48:26 -0400 < jcowan> How do you tell the difference between a 3-element vector and a 4-element list?
2023-07-27 16:48:45 -0400 < sham1> Lists have the tag (list 1 2 3)
2023-07-27 16:49:06 -0400 < mnieper> jcowan: Re open-ended world. An argument why this argument may be a fallacy is here: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/.  She talks about static/dynamic typing, but the idea also applies to symbols/enum values
2023-07-27 16:49:16 -0400 < mnieper> jcowan: Indeed, what sham1 says
2023-07-27 16:49:23 -0400 < jcowan> Ugh, there goes readability.  Using #, which cannot be in an unescaped symbol, escapes :-) the problem.
2023-07-27 16:49:48 -0400 < mnieper> I really like the simplicity of https://en.wikipedia.org/wiki/Canonical_S-expressions
2023-07-27 16:50:09 -0400  * jcowan reads
2023-07-27 16:51:46 -0400 < jcowan> If you wanted (#vector 1 2 3) I wouldn't complain too much
2023-07-27 16:52:19 -0400 < mnieper> Why not (#list 1 2 3) for symmetry?
2023-07-27 16:56:28 -0400 < jcowan> Why not (1 2 3) for readability?  If you don't care about readability, you should be using binary anyway.
2023-07-27 16:58:07 -0400 < mnieper> For symmetry and uniformity, I would say. It would also remove the need of having an extra keyword lexical type "#...".
2023-07-27 16:58:08 -0400 < jcowan> Back to symbols vs. enums. If you are getting data that includes ISO 3166 country codes (us, gb, de etc.) and you get a novel country code, it is *not* the case that you can do nothing with it.  You can record it and set its official name to "(Unknown country)"
2023-07-27 16:58:28 -0400 < mnieper> Right.
2023-07-27 16:58:37 -0400 < jcowan> This is about content, not structure, so lexilambda's argument is irrelevant.
2023-07-27 16:58:43 -0400 < mnieper> So in your enumeration, you have one value for "unknown".
2023-07-27 16:59:01 -0400 < jcowan> No, because unknown "fq" is not the same as unknown "qf"
2023-07-27 16:59:45 -0400 < mnieper> Then you won't use a simple enumeration but a record type.
2023-07-27 17:00:09 -0400 < jcowan> This is like giving "number of people in car" a type of "0 <= n <= 5)" and then along comes the Volkswagen with 22 people in it.
2023-07-27 17:00:30 -0400 < jcowan> I am assuming that enum objects can have properties.  You still want uniqueness.
2023-07-27 17:00:51 -0400 < mnieper> jcowan: Either you can anticipate that the Volkswagen will come; in this case you prepare your program to handle it.
2023-07-27 17:01:18 -0400 < mnieper> Or you can't. But then hoping your program happens to do the right thing is dangerous.
2023-07-27 17:02:25 -0400 < mnieper> Isn't Alexis' json example basically the same?
2023-07-27 17:02:36 -0400 < jcowan> Depends what the right thing is.  If all you are doing is counting the number of people in cars in a parking lot, you don't want to restrict type of "occupants" that way.
2023-07-27 17:02:46 -0400 < mnieper> Then don't. :)
2023-07-27 17:03:27 -0400 < jcowan> No. Her argument that dynamic typing can't handle unknown *structure* is sound.  But it is not sound to say it can't handle unknown *content*.
2023-07-27 17:03:50 -0400 < mnieper> I claim that content is structure.
2023-07-27 17:04:02 -0400 < mnieper> Might be a union of finite domains.
2023-07-27 17:04:23 -0400 < jcowan> Of course they are finite.  Everything is finite.  Computers can only handle a finite number of things.
2023-07-27 17:04:42 -0400 < mnieper> I didn't mean it this way.
2023-07-27 17:05:05 -0400 < mnieper> So, my point of view on it is that it is not about expressibility but about convenience.
2023-07-27 17:05:10 -0400 < jcowan> My point is forward compatibility, aka future-rpoofing.
2023-07-27 17:05:17 -0400 < jcowan> proofing, even
2023-07-27 17:05:32 -0400 < mnieper> Symbols are more convenient because I don't have to declare anything first.
2023-07-27 17:05:50 -0400 < mnieper> Similar things can be said for dynamic typing vs static typing.
2023-07-27 17:06:00 -0400 < jcowan> I get that.  But there are domains, ,like countries, where I *can't* declare them all in advance.
2023-07-27 17:06:10 -0400 < sham1> Countries should be strings
2023-07-27 17:06:23 -0400 < jcowan> Then you lose uniqueness.
2023-07-27 17:06:31 -0400 < mnieper> In what sense?
2023-07-27 17:06:31 -0400 < sham1> Yes
2023-07-27 17:06:45 -0400 < jcowan> "In what sense," what?
2023-07-27 17:06:58 -0400 < mnieper> That you lose uniqueness
2023-07-27 17:08:28 -0400 < mnieper> What do you mean by this?
2023-07-27 17:08:45 -0400 < sham1> The string's not interned, although I'd argue that there's a difference between the data as represented in the data interchange format versus as an actual domain object you use within the application
2023-07-27 17:08:54 -0400 < jcowan> Yes.
2023-07-27 17:09:01 -0400 < jcowan> That.
2023-07-27 17:09:33 -0400 < jcowan> You could intern all strings, as Lua does, but there are issues.  Also, strings don't have properties and enums should.
2023-07-27 17:11:18 -0400 < sham1> Right, but again, you'd intern it afterwards because you as the application know what you need to do with the data
2023-07-27 17:12:27 -0400 < sham1> While the data is "in flight" either through space (sending to another computer) and/or time (storage), it can be in a simpler format
2023-07-27 17:13:31 -0400 < mnieper> Whether strings are interned or not is an implementation-detail, isn't it?
2023-07-27 17:13:40 -0400 < sham1> That too
2023-07-27 17:13:44 -0400 < mnieper> symbols, one can compare with eq?; strings with string=?.
2023-07-27 17:13:50 -0400 < sham1> Well, if we'd have immutable strings
2023-07-27 17:14:11 -0400 < mnieper> Let's assume this.
2023-07-27 17:14:27 -0400 < sham1> Then yeah, an implementation can intern them
2023-07-27 17:14:57 -0400 < mnieper> let's continue this discussion tomorrow. Have to say good night!
2023-07-27 17:15:15 -0400 < sham1> Gn
2023-07-27 17:42:37 -0400 < jcowan> Gambit claims to be the 3rd oldest Scheme still running.  MIT must be the oldest.  What comes next, anyone know?
2023-07-27 17:45:02 -0400 < wasamasa> why not ask the gambit people about that claim?
2023-07-27 17:47:42 -0400 < taylan> jcowan: Scheme48 is 1987 according to Wikipedia, Gambit 1988
2023-07-27 17:47:53 -0400 < jcowan> Thanks
2023-07-27 17:47:58 -0400 < jcowan> wasamasa: I did, but this is faster
2023-07-27 17:48:05 -0400 < jcowan> and it's a trivial ask anyway
2023-07-27 17:48:52 -0400  * jcowan thinks 9 years is a long time
2023-07-27 17:48:59 -0400 < jcowan> (last update of s48)
2023-07-27 17:49:13 -0400 < dpk> Chez would be second oldest
2023-07-27 17:49:19 -0400 < gwatt> Dybvig claims chez was released in 85
2023-07-27 17:49:20 -0400 < dpk> (1985)
2023-07-27 17:49:35 -0400 < dpk> then MIT the oldest
2023-07-27 17:50:35 -0400 < jcowan> Okay, so it was worth asking on the gambit list, since there is more than one possible answer
2023-07-27 17:51:05 -0400 < dpk> Scheme 48 is barely still running
2023-07-27 17:51:13 -0400 < jcowan> well, no there isn't, it's Chez, but I wonder if that's what Marc meant.
2023-07-27 18:27:09 -0400 < taylan> Wikipedia also says Chez is 1985, didn't know it was that old
2023-07-27 18:28:43 -0400 < taylan> maybe Gambit meant to say the third oldest free software Scheme, or they didn't count S48 for being arguably abandoned
2023-07-27 18:36:44 -0400 < aeth> or they start counting at 0
2023-07-27 20:27:27 -0400 < Riastradh> Zipheir: I don't think I invented #; but I don't remember where I got it from two decades ago either.
2023-07-27 20:29:23 -0400 < jcowan> taylan: The latter, he considers s48 abandoned
2023-07-27 20:29:33 -0400 < jcowan> which is sad imo
2023-07-27 20:30:23 -0400 < jcowan> Riastradh: It's a fairly obvious choice to use #;, but it's the idea that's interesting
2023-07-27 20:31:16 -0400 < aeth> the idea might come from #+(or) in Common Lisp, which is the less elegant CL way to do it. Sometimes incorrectly done as #+nil
2023-07-27 20:31:36 -0400 < flatwhatson> it's just resting
2023-07-27 20:37:12 -0400 < flatwhatson> i don't understand "barely still running", scheme48 works fine
2023-07-27 20:40:13 -0400 < flatwhatson> it's lacking modern convenience like geiser, and it's not being actively developed, but it's still an excellent grokkable scheme implementation
2023-07-27 20:48:18 -0400 < jcowan> no build issues?
2023-07-27 20:48:42 -0400 < jcowan> usually in my experience when things rot it shows up when trying to build them.
2023-07-27 20:50:06 -0400 < flatwhatson> guix has a working scheme48 package, the only problem is lack of reproducibility due to some mysterious differences in heap image dumps
2023-07-27 20:50:34 -0400 < jcowan> unsurprising, reallly
2023-07-27 20:51:35 -0400 < flatwhatson> i looked into it a few months back, it's not address layout randomization or timestamps, there's something non-deterministic happening
2023-07-27 20:52:45 -0400 < flatwhatson> actually just this week i've been implementing a parser for the image format to get a better idea of exactly what is different (it can be only a handful of bytes in some cases)
2023-07-27 20:56:29 -0400 < jcowan> okay, I've built it on Cygwin (which often fails because Linuxism) and it was clean.
2023-07-27 20:56:32 -0400 < Riastradh> Curious to hear what you find out!  ...It's not a random seed, is it?
2023-07-27 20:56:40 -0400 < jcowan> beware, you may become the world expert on s48
2023-07-27 20:56:43 -0400 < Riastradh> or a pid
2023-07-27 20:56:59 -0400 < Riastradh> (or both, which would be disappointing but not surprising)
2023-07-27 21:02:43 -0400 < flatwhatson> this was my last email to the list on this topic: https://paste.debian.net/1287168/
2023-07-27 21:04:04 -0400 < flatwhatson> the number of differences can vary by at least an order of magnitude, but are still few enough to analyze manually
2023-07-27 21:07:13 -0400 < flatwhatson> at that time i hadn't looked into the data format to identify what the records actually were.  now i've been digging more, it uses a pretty straightforward lo-byte tagging mechanism, so i should be able to identify exactly *what* they are quite soon
2023-07-27 21:43:25 -0400 < flatwhatson> looking at a few differences manually, they all seem to be fixnums between 1000000 and 3000000, eg. https://paste.debian.net/1287169/
2023-07-27 21:47:51 -0400 < flatwhatson> a bit more work on the parser and i should be able to rebuild the containing structures to get some more context.  but it's been a great excuse to read a bunch of prescheme code!  the allocators (twospace and bibop) and image dumping code is all prescheme.
2023-07-27 21:51:12 -0400 < flatwhatson> with joys like buffered writes: https://notabug.org/flatwhatson/scheme48/src/main/scheme/vm/heap/write-image-util.scm#L49
2023-07-27 22:44:11 -0400 < mfiano> exciting stuff
2023-07-27 22:44:15 -0400 < mfiano> Good luck :)
--- Day changed Fri Jul 28 2023
2023-07-28 03:30:47 -0400 < mdhughes> The MacPorts build of scheme48 reports no errors, "Welcome to Scheme 48 1.9.2 (made by root on 2021-01-01)"
2023-07-28 03:31:10 -0400 < mnieper> What is actually meant by "still running"?
2023-07-28 03:32:50 -0400 < mdhughes> Can build & run on modern OS, not an emulator?
2023-07-28 03:41:37 -0400 < mdhughes> There's a really annoying trait of modern software esp that if you don't screw with it every few days/months, it's "DEAD". You can't have software just be done, it works, use it for years or decades in peace.
2023-07-28 03:42:15 -0400 < mdhughes> It's nice to have new features, sometimes, but some programs just do what they were supposed to, and never need anything else.
2023-07-28 03:42:21 -0400 < mdhughes> That's why ed is the standard text editor.
2023-07-28 03:43:25 -0400 < dave0> it does what it says it does
2023-07-28 03:43:37 -0400 < dave0> cant fault it for that!
2023-07-28 06:36:26 -0400 < Riastradh> flatwhatson: Another approach you could take is to simplify the image.  Start by seeing if dumping a statically linked image yields differences.  Make the statically linked image dump itself, and see if that produces differences each time you run it.
2023-07-28 06:42:33 -0400 < Riastradh> And then add more and more to the image each time.
2023-07-28 07:13:58 -0400 < mnieper> I don't know much about reproducible builds, but can't one just run the building process in a well-controlled and well-defined container?
2023-07-28 07:18:29 -0400 < weinholt> mnieper, reproducibility tests usually do the opposite, they mix up the environment as much as is feasible (different locales, directories, user names, timezones, etc, etc)
2023-07-28 07:20:04 -0400 < sham1> Reproducibility tests ≠ reproducible builds
2023-07-28 07:22:56 -0400 < weinholt> sure. i'm speaking from experience with how Debian tests that package builds are reproducible.
2023-07-28 07:27:20 -0400 < weinholt> it's kind of a thing with reproducible builds that other people should also be able to get a bit-for-bit identical build, not just you. i mean, ideally. why else are you doing it? but i didn't read up on the context of the discussion, so sorry if this isn't relevant
2023-07-28 07:41:21 -0400 < Riastradh> mnieper: The goal here is to figure out what undocumented input is affecting the output.
2023-07-28 07:45:44 -0400 < mnieper> weinholt: The container could be part of the build system.
2023-07-28 07:49:28 -0400 < mnieper> Riastradh: I haven't followed the details (so my response is probably nonsense) but why should hash tables and similar data structures be deterministic?  The order may depend on some object address in memory.  That's why I thought about running the build in a container so that addresses/time stamps/... can be controlled.
2023-07-28 10:26:21 -0400 < mnieper> For those taking part in the RnRS standardization process: https://codeberg.org/scheme/r7rs/issues/129
2023-07-28 11:47:07 -0400 < f-a> https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-31.html#%_sec_5.1.1 ← why are the lines under `test-b` indented by two lines? (instead of one, like in the rest of the code?)
2023-07-28 11:47:08 -0400 < rudybot> https://teensy.info/hnEDSS6siA
2023-07-28 11:57:16 -0400 < mnieper> Why not?
2023-07-28 11:57:37 -0400 < mnieper> There are also two spaces indentation when you have special form.
2023-07-28 11:58:07 -0400 < mnieper> Labels are not part of the Scheme language, so the authors were free to choose between 1 or 2 spaces.
2023-07-28 11:59:53 -0400 < f-a> thanks
2023-07-28 16:34:13 -0400 -!- grettke_ is now known as grettke
2023-07-28 16:44:13 -0400 -!- grettke is now known as grettke_
2023-07-28 19:30:21 -0400 -!- grettke_ is now known as grettke
2023-07-28 21:15:41 -0400 -!- grettke is now known as grettke_
2023-07-28 21:16:12 -0400 -!- grettke_ is now known as grettke
--- Day changed Sat Jul 29 2023
2023-07-29 12:36:22 -0400 -!- ced1 is now known as cedb
2023-07-29 14:26:55 -0400 < seninha> That was a bad idea. apply-ing every procedure turned out to be annoying... ¬¬
2023-07-29 14:27:41 -0400 < seninha> (and really forgettable)
2023-07-29 14:33:11 -0400 < Zipheir> seninha: All you remember about it was that it was annoying?
2023-07-29 14:33:21 -0400 < seninha> 75% of the example program in the README is procedure application, so that's the most common syntactical form (which explains why it is handled specially): https://github.com/phillbush/simp/blob/master/README.md
--- Day changed Sun Jul 30 2023
2023-07-30 06:12:36 -0400 < lisbeths> I am considering implementing r5rs in pure lambda calculus with define
2023-07-30 06:15:01 -0400 < lisbeths> what is the best guide for implementing r5rs
2023-07-30 07:56:17 -0400 < cow_2001> People really love Crafting Interpreters.
2023-07-30 07:57:05 -0400 < wasamasa> there wouldn't be much of a point to scheme if implementing it were as easy as following some guide from beginning to end
2023-07-30 07:57:23 -0400 < wasamasa> just the idea of implementing it in pure lambda calculus means you cannot just follow some guide, lol
2023-07-30 08:01:29 -0400 < Dooshki> Join us next time for Part 146 if our Implementing Scheme video tutorial!
2023-07-30 08:21:39 -0400 < DKordic> lisbeths: AFAIC see you are missing both halves of the problem.  Do you have some examples?
2023-07-30 08:23:27 -0400 < cow_2001> wasamasa: But you could write something very simple, in comparison, to get a glimpse and skills.
2023-07-30 08:23:48 -0400 < wasamasa> sure
2023-07-30 08:24:38 -0400 < cow_2001> I think that is what most of these books do.  I don't want to write my own language.  I want to maybe be able help with existing ones.
2023-07-30 08:24:49 -0400 < cow_2001> able to help
2023-07-30 08:26:28 -0400 < cow_2001> I have finally made Emacs load nov-mode, greader-mode, and nano-tts-mode when opening a *.epub file ~_~
2023-07-30 08:27:32 -0400 < wasamasa> I recognize one of these modes
2023-07-30 08:43:33 -0400 < cow_2001> wasamasa: Wrote one myself!
2023-07-30 08:43:42 -0400 < wasamasa> me too
2023-07-30 08:43:57 -0400 < wasamasa> so, what's the odd one out?
2023-07-30 08:44:17 -0400 < cow_2001> https://sr.ht/~kakafarm/emacs-nano-tts-minor-mode/
2023-07-30 08:44:33 -0400 < cow_2001> wasamasa: Which one did you write?
2023-07-30 08:44:38 -0400 < wasamasa> nov-mode
2023-07-30 08:44:42 -0400 < cow_2001> Wala!
2023-07-30 08:44:57 -0400 < cow_2001> Thank you!
2023-07-30 08:45:20 -0400 < cow_2001> This is how I read epubs now on my phone.
2023-07-30 08:45:26 -0400 < wasamasa> I thank the fit of procrastination that prompted me to write esxml-query
2023-07-30 08:45:34 -0400 < cow_2001> Together with GReader
2023-07-30 08:45:36 -0400 < wasamasa> everything else was trivial
2023-07-30 08:46:43 -0400 < wasamasa> so, greader-mode, where does that live?
2023-07-30 08:46:53 -0400 < cow_2001> melpa………
2023-07-30 08:47:18 -0400 < wasamasa> https://elpa.gnu.org/packages/greader.html
2023-07-30 08:47:24 -0400 < cow_2001> Spooky who knows what's there repository
2023-07-30 08:47:26 -0400 < cow_2001> oh
2023-07-30 08:47:34 -0400 < cow_2001> also on elpa?
2023-07-30 08:47:49 -0400 < wasamasa> I wasn't able to find it on melpa, hence the question
2023-07-30 08:47:50 -0400 < cow_2001> So what was on melpa that made me add it?
2023-07-30 08:48:00 -0400 < wasamasa> ¯\_(ツ)_/¯
2023-07-30 08:49:30 -0400 < cow_2001> Your nickname keeps reminding me of that very strange and ancient Japanese photo journal named MasaMania.
2023-07-30 08:50:37 -0400 < cow_2001> Beware.  It was made by a cheeky monkey.
2023-07-30 08:51:03 -0400 < wasamasa> yes, I've looked at it on archive.org
2023-07-30 09:44:29 -0400 < cow_2001> Okay.  My language shall be named Kakalang.
2023-07-30 09:44:58 -0400 < cow_2001> No clue what will be its syntax or how it will be implemented.
2023-07-30 09:45:37 -0400 < wasamasa> the name suggests decisions are made by throwing things at the wall and observing what sticks
2023-07-30 09:47:29 -0400 < cow_2001> Sounds like C++, no?
2023-07-30 09:47:35 -0400 < wasamasa> https://en.wiktionary.org/wiki/Kacke
2023-07-30 09:48:47 -0400 < cow_2001> Yeah, that's why I call my site https://kaka.farm/, because everything I do is a kind of kaka………
2023-07-30 09:49:34 -0400 < cow_2001> We use that word in Hebrew as well.
2023-07-30 09:49:39 -0400 < wasamasa> I wonder whether it's just me not taking Kotlin seriously because of the name
2023-07-30 09:50:05 -0400 < cow_2001> I never looked at it for more than a minute.
2023-07-30 09:50:28 -0400 < cow_2001> I have no opinion on it.
2023-07-30 09:50:32 -0400 < wasamasa> it comes up occasionally in android apps, otherwise I'd have forgotten about it entirely
2023-07-30 09:50:46 -0400 < wasamasa> in terms of design it looks like a big usability improvement over java
2023-07-30 11:28:12 -0400 < jcowan> after all, Java is an island, so is Kotlin
2023-07-30 11:33:55 -0400 < wasamasa> no
2023-07-30 11:34:10 -0400 < wasamasa> there's a city in Poland by that name
2023-07-30 12:01:28 -0400 < jackdaniel> indeed, Kotlin is a city in Poland
2023-07-30 12:01:53 -0400 < jackdaniel> there is even an exquisite ketchup made in kotlin ;)
2023-07-30 12:02:38 -0400 < jcowan> Right, but the creators explicitly said that Kotlin the language is named after Kotlin, the Russian island in the Baltic in which the fortress city of Kronstadt stands
2023-07-30 12:03:36 -0400 < wasamasa> if Google Maps doesn't know of such an island, does it even exist?
2023-07-30 12:05:01 -0400 < wasamasa> hum, so it does find it if you enter "Kotlin Island", otherwise not
2023-07-30 12:05:37 -0400 < jackdaniel> there is such an island
2023-07-30 12:05:55 -0400  * jackdaniel was confirming the city part
2023-07-30 12:51:54 -0400 < sham1> It's probably just considered as a part of St. Petersburg nowadays even though it's technically separate
2023-07-30 12:52:24 -0400 < sham1> And apparently it is
2023-07-30 14:32:26 -0400 < jcowan> yes
2023-07-30 14:59:36 -0400 -!- dstein64- is now known as dstein64
2023-07-30 19:43:58 -0400 < andydude> I thought Java was a coffee
2023-07-30 19:56:02 -0400 < mdhughes> Coffee is grown in Java.
2023-07-30 19:58:08 -0400 < mdhughes> Kotlin's weird, it's a corporate IDE language that's escaped to be more widely used. And there's Kotlin Native, which is sugar for Objective-C or Swift.
2023-07-30 20:59:39 -0400 < lisbeths> is there a metacular compiler written in scheme that I can use to learn our 5RS?
2023-07-30 20:59:51 -0400 < lisbeths> s/our/r
2023-07-30 21:00:08 -0400 < lisbeths> s/cular/circular
--- Day changed Mon Jul 31 2023
2023-07-31 01:39:12 -0400 < jackdaniel> metatriangular!
2023-07-31 01:46:49 -0400 < flatwhatson> scheme48 is metatriangular.  prescheme -> C -> scheme -> prescheme ...
2023-07-31 12:09:19 -0400 < mwnaylor> Is there an online repository for guile code that can easily be installed? I'm thinking of something like chicken with 'chicken-install' and racket with 'raco install'.
2023-07-31 12:10:19 -0400 < mwnaylor> I'm trying to pick a lisp that works well from emacs. I had ssl errors trying to install code w/ raco. Which chicken, I get errors when attempting 'geiser-eval-buffer'. I may fall back on guile, since it seems that geiser works best with that dialect.
2023-07-31 12:10:50 -0400 < Dooshki> depending on how compatible guile is with r7rs, there's snowfort
2023-07-31 12:18:40 -0400 < Zipheir> Wasn't there something called 'guild'?
2023-07-31 12:20:13 -0400 < Zipheir> Hmm, it seems that's just a build tool now.
2023-07-31 12:22:29 -0400 < mwnaylor> FWIW, I am running GNU Guile 3.0.9.16.
2023-07-31 12:23:20 -0400 < Zipheir> It seems they use Guix these days.
2023-07-31 12:24:01 -0400 < mwnaylor> (info "guile") seems to be lacking some the nodes that should be there according to the TOC.
2023-07-31 12:24:19 -0400 < Zipheir> It's mildly funny that the two biggest GNU Lisp-oriented projects don't talk to each other very well.
2023-07-31 12:25:52 -0400 < mwnaylor> Meaning emacs and guile?
2023-07-31 12:26:30 -0400 < mwnaylor> One could get a headace bouncing between the lisp-2 and lisp-1. 😦
2023-07-31 12:26:40 -0400 < Zipheir> Yeah.
2023-07-31 13:40:22 -0400 < sham1> Well you'd just have two evaluators doing two different things
2023-07-31 13:40:28 -0400 < sham1> Of course you can express one within the other
2023-07-31 13:46:30 -0400 < drakonis> hm, so helix is using a scheme dialect now
2023-07-31 13:46:34 -0400 < wasamasa> fennel?
2023-07-31 13:46:41 -0400 < wasamasa> that's more like a clojure derivative
2023-07-31 13:47:42 -0400 < drakonis> no
2023-07-31 13:47:45 -0400 < drakonis> its steel
2023-07-31 13:47:48 -0400 < drakonis> apparently
2023-07-31 13:48:24 -0400 < wasamasa> oh, helix, I was thinking of something else
2023-07-31 13:48:34 -0400 < wasamasa> this one: https://github.com/rxi/lite
2023-07-31 13:48:46 -0400 < drakonis> https://github.com/mattwparas/helix-config
2023-07-31 13:48:57 -0400 < drakonis> https://github.com/mattwparas/steel and this is the implementation
2023-07-31 13:50:04 -0400 < wasamasa> > Steel is mildly opinionated in that there a few ways to define variables and functions. These choices are fairly arbitrary except for the shorthand function syntax, which I borrowed from Racket.
2023-07-31 13:50:05 -0400 < drakonis> https://github.com/helix-editor/helix/discussions/3806
2023-07-31 13:50:08 -0400 < drakonis> the relevant discussion
2023-07-31 13:50:31 -0400 < wasamasa> funny
2023-07-31 13:50:33 -0400 < drakonis> wasamasa: it is sure something
2023-07-31 13:50:40 -0400 < drakonis> i think i'd rather use fennel on neovim instead of that
2023-07-31 13:50:41 -0400 < wasamasa> well, I guess I gotta tell everyone who shilled the editor
2023-07-31 13:50:48 -0400 < wasamasa> "Eat my pants, it's using a Scheme now"
2023-07-31 13:50:58 -0400 < drakonis> lmao
2023-07-31 13:51:10 -0400 < leah2> > Limited syntax-rules style macros are supported
2023-07-31 13:51:12 -0400 < leah2> omg
2023-07-31 13:51:17 -0400 < wasamasa> after they were like "What even uses Scheme or Lisp?"
2023-07-31 13:51:31 -0400 < wasamasa> the editor you were excited to try, apparently
2023-07-31 13:52:08 -0400 < leah2> it also has tail calls
2023-07-31 13:52:12 -0400 < wasamasa> anyway, I don't think it's gonna matter in these kinda discussions
2023-07-31 13:53:16 -0400 < drakonis> lol the helix usage of it includes
2023-07-31 13:53:20 -0400 < drakonis> *checks notes* modes
2023-07-31 13:53:25 -0400 < drakonis> its turning into rust emacs isnt it
2023-07-31 13:54:09 -0400 < wasamasa> maybe
2023-07-31 13:54:16 -0400 < leah2> not full TCO :<
2023-07-31 13:54:32 -0400 < wasamasa> the point of rust seems to be to experiment with all kinds of exciting things, rather than replacing existing C/C++ software
2023-07-31 13:56:47 -0400 < DeeEff> that's sort of true and not true at the same time
2023-07-31 13:56:57 -0400 < DeeEff> depends on which sub-segment of "Rust" you look at
2023-07-31 13:57:12 -0400 < DeeEff> In robotics at least we are almost entirely trying to replace C++ software
2023-07-31 13:57:17 -0400 < wasamasa> some people are excited by the prospect of implementing their own idea of coreutils
2023-07-31 13:57:19 -0400  * DeeEff writes Rust professionally
2023-07-31 13:57:47 -0400 < wasamasa> others are excited by writing a spotify client circumventing their DRM
2023-07-31 13:57:53 -0400 < wasamasa> or new graphics drivers
2023-07-31 13:58:00 -0400 < DeeEff> yeah replacing coreutils isn't always the best move although I will say that stuff like ripgrep, dust, etc. are all great projects and definitely are valid replacements
2023-07-31 13:58:16 -0400 < wasamasa> it definitely felt more like a new take on it than replacement
2023-07-31 13:58:17 -0400 < DeeEff> but you don't need to rewrite everything
2023-07-31 13:58:28 -0400 < wasamasa> https://github.com/uutils/coreutils
2023-07-31 13:58:53 -0400 < wasamasa> similarly, this redox OS had some funny ideas like URLs everywhere (rather than files everywhere)
2023-07-31 13:59:03 -0400 < DeeEff> wasamasa: maybe what I'm trying to say is that line is a bit blurry. There's like: "rewrite all the old utils in Rust" but then you accidentally find out that the language / ecosystem allow for really cool things beyond what existed before
2023-07-31 13:59:23 -0400 < DeeEff> so of course you don't limit yourself because who even cares about POSIX grep anymore
2023-07-31 13:59:27 -0400 < wasamasa> yeah, for a long time I thought rust only fulfills its purpose if people properly replace existing software
2023-07-31 13:59:28 -0400 < DeeEff> or w/e the standard is
2023-07-31 13:59:39 -0400 < wasamasa> but it's not that binary
2023-07-31 14:01:19 -0400 < drakonis> begun, have, the editor wars
2023-07-31 14:04:21 -0400 < sham1> They never left
2023-07-31 14:06:52 -0400 < DeeEff> don't call it a comeback :P
2023-07-31 14:13:43 -0400 < wasamasa> ohno: https://github.com/mattwparas/helix-config/blob/master/init.scm#L41
2023-07-31 14:13:48 -0400 < wasamasa> why do they bring rust things into this
2023-07-31 14:13:54 -0400 < wasamasa> have these people no idea how scheme works
2023-07-31 14:14:24 -0400 < wasamasa> I'm kinda used to camel and snake casing in some wannabe scheme/lisp implementations, but this, unacceptable
2023-07-31 14:18:01 -0400 < sham1> I feel using.dots.like.this is worse
2023-07-31 14:20:00 -0400 < jcowan> None of it bothers me much, but if if I had to put something on the bottom of the list it would be UpperCamelCase or of course UPPERCASESCRIPTIOCONTINUA.
2023-07-31 14:20:51 -0400 < sham1> PascalCase
2023-07-31 14:21:02 -0400 < jcowan> in the first Lisp manual I ever read there were a number of excamples of symbols, one of which was EXTREMELYLONGSTRINGOFLETTERSANDSTUFF.
2023-07-31 14:21:11 -0400 < sham1> Gesundheit!
2023-07-31 14:22:25 -0400 < DeeEff> is the problem (unwrap-ok)?
2023-07-31 14:22:40 -0400 < DeeEff> I'd partially agree - don't bleed Rust's Result into Scheme, just wrap an exception around it
2023-07-31 14:22:54 -0400 < jcowan> I wrote a Forth interpreter once where names could be input however, but were internally stored as a length byte plus a fixed-length prefix of the name
2023-07-31 14:22:57 -0400 < DeeEff> although unwrapping something in general isn't always wrong
2023-07-31 14:23:49 -0400 < jcowan> so FRUIT and FRUITS were distinct, but TRASH and TRAPS were not if the prefix length was 3.
2023-07-31 14:23:57 -0400 < jcowan> (nowadays I'd make it 7)
2023-07-31 14:25:08 -0400 < sham1> Oh, like very old C compilers where you only had so many significant letters, which is why we ended up with creat
2023-07-31 14:25:31 -0400 < wasamasa> no, strstr
2023-07-31 14:25:39 -0400 < wasamasa> creat is something else
2023-07-31 14:26:06 -0400 < wasamasa> people aren't entirely sure about umount getting this treatment
2023-07-31 14:34:30 -0400 < drakonis> hm, steel's author says that the readme is out of date
2023-07-31 14:39:28 -0400 < jcowan> Pretty much the same: it was really _creat to the linker
2023-07-31 14:40:40 -0400 < jcowan> So this is a *little* more usable than that, as in the FRUIT/FRUITS example which are <5>FRU vs. <6>FRU.
2023-07-31 14:41:10 -0400 < wasamasa> _exit is a thing, but _creat, seriously?
2023-07-31 14:41:46 -0400 < jcowan> yes
2023-07-31 14:42:16 -0400 < jcowan> Because the namespace is flat, an extern C name was prefixed with _ to avoid confusion with labels used in asm code
2023-07-31 14:42:39 -0400 < jcowan> Fortran did the opposite: an extern Fortran name would be foo_.
2023-07-31 14:43:10 -0400 < jcowan> So you didn't type _creat in C, but you'd have to use it in handwritten assembler.
2023-07-31 14:44:29 -0400 < Dooshki> I have a feeling Windows still prefixes external symbols with _
2023-07-31 14:45:10 -0400 < wasamasa> yes, they do
2023-07-31 14:45:31 -0400 < wasamasa> for some reason they offer some standardized APIs prefixed with _
2023-07-31 14:46:23 -0400 < wasamasa> or hm: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
2023-07-31 14:46:23 -0400 < rudybot> https://teensy.info/mjOiZ5Genc
2023-07-31 14:46:26 -0400 < wasamasa> this stuff is so confusing
2023-07-31 14:46:28 -0400 < Dooshki> I think the standardized APIs prefixed with _ originally started out as "Microsoft Extensions"
2023-07-31 14:46:49 -0400 < Dooshki> e.g. ANSI C98 doesn't define snprintf(), but Microsoft does!
2023-07-31 14:46:52 -0400 < sham1> Windows also has a weird ABI in that their symbols end (or at least used to end) with an at-sign and then a number to indicate... arity IIRC
2023-07-31 14:47:04 -0400 < wasamasa> I'm sure they had a reason to do it that way
2023-07-31 14:47:12 -0400 < wasamasa> some very stupid backwards-compatibility reason
2023-07-31 14:47:33 -0400 < wasamasa> kinda happy that this stuff is slowly going away, but it's taking its time
2023-07-31 14:48:02 -0400 < Dooshki> It could make sense in case they suspected that the standard language would later introduce functions like snprintf(), but with slightly different behavior, thus breaking compatibility with existing code using the "pre-standard" version
2023-07-31 14:48:05 -0400 < sham1> Oh wait, the at-sign and the number indicate how many bytes are taken out of the stack
2023-07-31 14:48:19 -0400 < Dooshki> replace snprintf with any other thing they offer with a _
2023-07-31 14:48:55 -0400 < Dooshki> *ANSI C89 (whoops)
2023-07-31 14:49:12 -0400 < sham1> The at-sign business is apparently a part of the __stdcall ABI: https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170&redirectedfrom=MSDN
2023-07-31 14:49:20 -0400 < sham1> The "x64" ABI doesn't do that
2023-07-31 14:49:45 -0400 < sham1> Name-decoration convention	An underscore (_) is prefixed to the name. The name is followed by the at sign (@) followed by the number of bytes (in decimal) in the argument list. Therefore, the function declared as int func( int a, double b ) is decorated as follows: _func@12
2023-07-31 14:51:07 -0400 < Zipheir> Number of bytes in the argument list?!
2023-07-31 14:51:47 -0400 < sham1> yeah
2023-07-31 14:51:49 -0400 < sham1> It's wild
2023-07-31 14:52:17 -0400 < wasamasa> maybe they need it for better debugger support on production builds?
2023-07-31 14:53:13 -0400 < sham1> Maybe, but that's still a weird way to do it since you don't know what those bytes mean
2023-07-31 14:53:37 -0400 < sham1> I mean, both `int func(int a, double b)` and `int func(double a, int b)` would become _func@12. Have fun, debugging tools!
2023-07-31 14:56:39 -0400 < Zipheir> ABIs are rather wild in the first place.
2023-07-31 14:59:56 -0400 < fizzie> sham1: The calling convention that uses that name mangling is also a caller-cleans-up-the-stack one.
2023-07-31 15:00:09 -0400 < fizzie> So it's kind of... more critical than usual that the caller and callee agree on the number of bytes.
2023-07-31 15:00:20 -0400 < fizzie> Having it part of the name mangling makes it a link error if they don't.
2023-07-31 15:00:31 -0400 < fizzie> s/caller-cleans/callee-cleans/
2023-07-31 15:01:03 -0400 < fizzie> I don't know if that's really much of an explanation, but it's _something_.
2023-07-31 15:01:58 -0400 < sham1> Yes. IIRC Pascal stuff also used to use that
2023-07-31 15:02:19 -0400 < sham1> Which is why x86 and AMD64 have the fairly funky enter and leave instructions
2023-07-31 15:02:35 -0400 < fizzie> (It can't support variadic functions at all, of course.)
2023-07-31 15:11:28 -0400 < jcowan> wasamasa: The Windows underscores are to avoid stepping on ISO C names, though a good many of them just *are* ISO C names.
2023-07-31 15:16:06 -0400 < Dooshki> potentially introduced in Windows before they were standardized in ISO C
2023-07-31 15:16:11 -0400 < Dooshki> (from POSIX)
2023-07-31 15:29:58 -0400 < jcowan> Quite possibly
2023-07-31 15:51:42 -0400 < cow_2001> I am writing jlox in R7RS.  I call it Schlick.
2023-07-31 15:52:35 -0400 < cow_2001> Scheme Lick? Because Schlox doesn't make any sense.
2023-07-31 15:56:08 -0400 < cow_2001> I have a read-…-print loop.  Similar to the Underpants Gnomes' money making part of the plan, the eval part is yet to be implemented.
2023-07-31 18:13:45 -0400 < Zipheir> cow_2001: "Slick" would be more marketable. ;-)
2023-07-31 18:16:46 -0400 < cow_2001> Zipheir: I am trying to learn and keep myself entertained while at it.
2023-07-31 18:17:02 -0400 < cow_2001> The language is just a didactic tool.
--- Day changed Tue Aug 01 2023