--- Day changed Tue Aug 01 2023
2023-08-01 06:27:47 -0400 < lockywolf> Can someone recommend a book on Common Lisp for someone who can already do Scheme?
2023-08-01 06:29:32 -0400 < sham1> I don't think there is a book specifically for this, but I'd probably just read "Practical Common Lisp" and just skip the most basic "this is Lisp" parts, instead focusing on the parts that are more CL-specific
2023-08-01 06:36:50 -0400 < lockywolf> thanks
2023-08-01 06:36:54 -0400 < lockywolf> I heard about that book
2023-08-01 12:51:02 -0400 < mdhughes> Not a book, but I make notes whenever I play with CL: https://mdhughes.tech/scheme/schemer-in-common-lisp-land/
2023-08-01 12:58:16 -0400 < Zipheir> lockywolf: Land of Lisp?
2023-08-01 12:58:59 -0400 < Zipheir> It was more fun than Practical Common Lisp, and it fully admits that LOOP is a mess.
2023-08-01 12:59:34 -0400 < Zipheir> (LOOP is depicted as a wino in a trench coat on the seedy side of the CL city.)
2023-08-01 13:03:18 -0400 < sham1> A fairly accurate depiction of LOOP, I must say. Code walking macros are a bit odd
2023-08-01 13:05:28 -0400 < Zipheir> Code-walking?
2023-08-01 13:07:19 -0400 < ecraven> macros that analyse the code they are callod on
2023-08-01 13:07:19 -0400 < sham1> Yeah, you're basically "drilling" down the macro's arguments to do things like find specific forms and then act accordingly
2023-08-01 13:08:16 -0400 < Zipheir> Would you call 'do' a code-walker?
2023-08-01 13:08:34 -0400 < sham1> Not really, since do is implementable with syntax-rules
2023-08-01 13:08:35 -0400 < Zipheir> (Scheme's 'do' that is.)
2023-08-01 13:09:36 -0400 < dpk> i think CL's LOOP is probably implementable with syntax-rules as well
2023-08-01 13:10:00 -0400 < Zipheir> But you could implement "specific forms" with syntax-rules, surely. Or maybe I don't understand the idea.
2023-08-01 13:10:00 -0400 < dpk> modulo the fact that the keywords would need to be matched as syntax-rules literals
2023-08-01 13:10:21 -0400 < sham1> Like, I assume that if you really wanted to, you could implement these more "complex" macros with recursive syntax-rules, especially you have access to eager syntax-rules, but it's easier with DEFMACRO or syntax-case
2023-08-01 13:10:41 -0400 < dpk> either as bound syntax keywords like else, => etc., or as symbols but that won't work at all if someone has bound that name locally
2023-08-01 13:11:02 -0400 < ecraven> a nested version of cut could be code-walking.. (cut (+ (- 1 <>) 3)) would need to "walk down" the code to find the place where <> is used
2023-08-01 13:11:58 -0400 < ecraven> this of course leads to all kinds of problems, because the macro is called *before* the code inside the macro has been expanded..
2023-08-01 13:12:24 -0400 < ecraven> methinks we should just all start using NLAMBDA again :D
2023-08-01 13:13:37 -0400 < sham1> I feel that we should have a portable way for syntax-case transformers to call expand for syntax terms
2023-08-01 13:13:53 -0400 < sham1> That'd solve this
2023-08-01 13:13:55 -0400 < sham1> Well, sorta
2023-08-01 13:14:11 -0400 < Zipheir> Nested 'cut' would certainly have to deal with this issue.
2023-08-01 13:14:31 -0400 < Zipheir> But loop macros usually just look for their own subforms.
2023-08-01 13:14:56 -0400 < dpk> sham1: i've asked for a local-expand procedure for this but it would not have any reliable results across implementations
2023-08-01 13:15:38 -0400 < sham1> Oh why, because lambdas for example would expand into whatever nonsense the compiler does?
2023-08-01 13:15:56 -0400 < dpk> well, we could forbid them from expanding beyond lambda
2023-08-01 13:16:21 -0400 < dpk> but e.g. Guile does not consider let a macro unlike most Scheme implementations
2023-08-01 13:16:30 -0400 < dpk> in general, different implementation consider different syntax to be primitive
2023-08-01 13:16:50 -0400 < Zipheir> Which is fine.
2023-08-01 13:19:40 -0400 < Zipheir> It seems to me that code-walking macros are just fine, provided they don't need to treat unexpanded special forms specially.
2023-08-01 13:19:50 -0400 < Zipheir> e.g. nested cut is out.
2023-08-01 13:22:46 -0400 < dpk> nested cut is ‘fine’, it just won't do the right thing if the form within the cut happens to want to rebind <> anywhere
2023-08-01 13:22:59 -0400 < dpk> which … don't do that, kids
2023-08-01 13:23:09 -0400 < dpk> (rebind in the sense of shadow)
2023-08-01 13:25:43 -0400 < Zipheir> I suppose it could also do unexpected things if there's a macro somewhere in the nest: (cut (+ 2 <> (not-a-procedure <> 1)))
2023-08-01 13:26:20 -0400 < sham1> Yeah, because not-a-procedure could do its own stuff with <>
2023-08-01 13:26:43 -0400 < sham1> I mean, the easiest might just be `(cut (+ 2 <> (cut <> 1)))`
2023-08-01 13:42:19 -0400 < mdhughes> I prefer (λ (x) (+ 2 x)), and I haven't bound or used it yet, but that `rec` form from R3RS is pretty awesome for recursive functions.
2023-08-01 13:44:58 -0400 < jcowan> CL do is almost the same as Scheme do, except that Scheme rebinds the iteration vars whereas CL reassigns them.  Most of the time thsi doesn't mattr.
2023-08-01 13:55:04 -0400 < Zipheir> mdhughes: rec is a good idea.
2023-08-01 13:57:32 -0400 < sham1> R2RS is the one with rec
2023-08-01 13:58:46 -0400 < sham1> Or as it's amusingly written: RRRS
2023-08-01 14:02:01 -0400 < Zipheir> Also https://srfi.schemers.org/srfi-31/
2023-08-01 14:02:19 -0400 < Zipheir> Did that get voted into R7RS-large? I can't remember.
2023-08-01 14:02:59 -0400 < Zipheir> Looks like it.
2023-08-01 14:05:07 -0400 < sham1> That seems like it'd be fairly trivial to implement in terms of letrec
2023-08-01 15:00:46 -0400 < Zipheir> sham1: Conversely, you can use it as your recursive binding primitive.
2023-08-01 15:01:44 -0400 < Zipheir> (letrec becomes a simple macro if you've implemented rec already.)
2023-08-01 15:02:36 -0400 < sham1> Ah yes, because you can use rec to fix letrec
2023-08-01 15:20:45 -0400 < Zipheir> It would be fun to see how far you could get in a minimal Scheme with just lambda and rec.
2023-08-01 15:23:25 -0400 < gwatt> I thought one of the outcomes of lambda calculus is that you really only need lambda
2023-08-01 15:27:28 -0400 < sham1> All You Need is Lambda
2023-08-01 15:27:36 -0400 < sham1> The less well known hit single by The Beatles
2023-08-01 15:28:09 -0400 < Zipheir> Of course, but, as most Scheme implementations do, you can gain a lot of efficiency by implementing recursion as a primitive (i.e. not using combinators).
2023-08-01 15:28:39 -0400 < Zipheir> A micro-Scheme using lambda and rec could actually be usable.
2023-08-01 15:29:00 -0400 < sham1> I'd like to have a few more things in that, like... numbers for example
2023-08-01 15:29:10 -0400 < sham1> Church numerals are fun and all, but numbers are even more fun
2023-08-01 15:31:22 -0400 < Zipheir> Right, you'd probably want numbers.
2023-08-01 15:31:33 -0400 < dpk> with rec as a primitive, you can use the simply typed lambda calculus
2023-08-01 15:42:14 -0400 < sham1> It may not be turing complete, but should probably be enough
2023-08-01 15:42:40 -0400 < dpk> with rec it would be Turing complete
2023-08-01 15:43:16 -0400 < sham1> But would it be simply typed then
2023-08-01 15:43:24 -0400 < dpk> i believe so
2023-08-01 15:43:30 -0400 < sham1> Since it probably wouldn't be strongly normalizing
2023-08-01 15:43:44 -0400 < dpk> the issue is that a fixed-point combinator can't be typed *within* the simply-typed lambda calculus
2023-08-01 15:43:56 -0400 < dpk> but i think you can add it as an extra primitive and leave everything else as it is and it's fine
2023-08-01 15:44:34 -0400 < dpk> it is truly the ‘and then a miracle occurs’ of type systems
2023-08-01 16:19:56 -0400 < jcowan> gwatt: All you need is lambda, providedd you are willing to use the Z combinator
2023-08-01 16:20:05 -0400 < jcowan> (the eager version of the Y combinator)
2023-08-01 16:20:44 -0400 < sham1> So since we have the Y combinator and the Z combinator, I wonder what the X combinator would be
2023-08-01 16:32:25 -0400 < jcowan> It's λx (x S) K with the usual definitions of S and K
2023-08-01 16:35:27 -0400 < jcowan> https://en.wikipedia.org/wiki/Fixed-point_combinator
2023-08-01 17:07:32 -0400 < sham1> Oh, so X is just another form of Y
2023-08-01 17:18:13 -0400 < jcowan> I can't really read combinator-ese
2023-08-01 17:20:41 -0400 < wasamasa> X is just another form of twitter
2023-08-01 17:22:08 -0400 < sham1> Wrong X. Lest we also bring in X Windows
2023-08-01 17:33:57 -0400 < LeoNerd> There aren't even any good Chemistry jokes, because there's no element "X", just "Xe"
2023-08-01 17:43:10 -0400 < dpk> there’s an X in chemistry if you’re a photographer, where X is the flash synchronization you use with xenon flash lights
2023-08-01 17:43:52 -0400 < dpk> (in practice, X is the only flash synch mode you need today, and the only one offered on new cameras)
2023-08-01 17:48:37 -0400 < dpk> hey nice, that one guy managed to build his full replica Apple Lisa https://tech.lgbt/@DosFox/110816447016004950
--- Day changed Wed Aug 02 2023
2023-08-02 01:31:26 -0400 < flatwhatson> it seems like "do" is under-used vs. explicit recursion in the wild.  is it just me?  is this a conscious style decision?
2023-08-02 01:33:14 -0400 < sham1> I personally prefer explicitly recursing
2023-08-02 01:34:47 -0400 < sham1>  It's, well, explicit 
2023-08-02 01:36:02 -0400 < mdhughes> named let is much nicer, and for numeric ranges I just made a very short "for" macro that evaluates to named let.
2023-08-02 01:50:11 -0400 < flatwhatson> it's one of the more noticeable differences between scheme48 and guile codebases (~600 uses of "do" vs ~100)
2023-08-02 09:19:07 -0400 < DKordic> lockywolf: https://letoverlambda.com/ ?  
2023-08-02 09:20:15 -0400 < lockywolf> I have never used do
2023-08-02 09:20:47 -0400 < lockywolf> and since I have switched to C++, seldom used indexed for
2023-08-02 09:21:11 -0400 < lockywolf> DKordic: maybe :)
2023-08-02 09:22:29 -0400 < DKordic> IMHO given `S' and `K', that pair should be `&', and we also have `(& S K)'.  It would be pointless to call it `S&K'.  
2023-08-02 09:36:55 -0400 < gwatt> flatwhatson: IMO do is a nice replacement for C-style for loops, but any more complicated than that, I think some kind of explicit recursion is better.
2023-08-02 09:45:49 -0400 < dpk> #scheme: the only place where you will find consensus among programmers that recursion is preferable to iteration constructs
2023-08-02 09:49:12 -0400 < sham1> I don't know if this is the only place, I would guess that Erlang/Elixir community for example would agree alongside Haskell people 
2023-08-02 09:49:40 -0400 < sham1> So it's more FP versus everyone else
2023-08-02 09:58:03 -0400 < gwatt> dpk: I mean, certainly compared to scheme's "do". I typically don't prefer explicit recursion to using "map"
2023-08-02 10:10:12 -0400 < mdhughes> Obvs you'd use HOF if you possibly can, but when making your own, you don't reach for do, either.
2023-08-02 11:58:44 -0400 < Zipheir> Iteration *is* recursion.
2023-08-02 12:05:14 -0400 < Zipheir> I think the advantage of higher-order functions over loops is that they allow fine-grained decomposition of processes. Loops quickly become monolithic monsters.
2023-08-02 12:06:03 -0400 < Zipheir> Unfortunately, some compositions of HOFs can be inefficient without lazy evaluation.
2023-08-02 12:07:00 -0400 < andydude> I wish go had map
2023-08-02 12:08:04 -0400 < chandash> i think it would be easy enough to make your own functino that acts like map
2023-08-02 12:08:24 -0400 < chandash> depending on exactly what go datatype you have in mind, slice array or whatever
2023-08-02 12:08:34 -0400 < sham1> Nowadays yes, because Go finally has parametric polymorphism (generics), but before? Nah
2023-08-02 12:10:25 -0400 < chandash> sham1: not exactly, you could make your function only work with slices, or arrays, or another data type
2023-08-02 12:10:37 -0400 < sham1> Well sure
2023-08-02 12:10:47 -0400 < Zipheir> Does Go have a list library?
2023-08-02 12:10:52 -0400 < sham1> But before you couldn't even make it parametric over the types contained within the slices, arrays or whatever
2023-08-02 12:11:20 -0400 < chandash> oh yes, i think that is correct
2023-08-02 12:18:03 -0400 < fizzie> Nah, you would've just used reflection and made everything have `interface{}` ("anything") as its static type.
2023-08-02 12:19:05 -0400 < fizzie> Incidentally, there's a pending Go proposal for making a standard way to iterate over user-defined types (https://github.com/golang/go/discussions/56413), which is... well, it's not a map, but it's something in the same general direction.
2023-08-02 12:22:09 -0400 < Zipheir> I grew to dislike interface{} quite a bit in my Go days.
2023-08-02 12:22:32 -0400 < Zipheir> The type system is pretty primitive, in general.
2023-08-02 12:23:19 -0400 < gwatt> It's basically like if C had interfaces.
2023-08-02 12:24:11 -0400 < sham1> And tracing GC. And CSP as the central concurrency construct
2023-08-02 12:24:18 -0400 < Zipheir> I don't fully understand interfaces from a type-theory perspective. They aren't exactly first class types, but they act a bit like type families(?).
2023-08-02 12:28:35 -0400 < fizzie> I don't understand type theory. But that sounds plausible. Every "real" type has a method set, and interfaces let you refer to the collection of types whose method sets are a superset of the interface.
2023-08-02 12:32:56 -0400 < sham1> In Go, the interfaces are "structural", which means that any type that has the same "structure" is automatically an implementation of the interface. More commonly one would see a "nominal" type system where you'd instead declare that a type implements an interface explicitly
2023-08-02 12:33:44 -0400 < sham1> Structure IIRC in this case means that the functions/methods associated with a certain struct in Go match those of an interface
2023-08-02 12:34:19 -0400 < Zipheir> Which is odd, since those methods will have types that can't appear in the interface definitionsn.
2023-08-02 12:34:23 -0400 < Zipheir> *definitions
2023-08-02 12:34:26 -0400 < gwatt> Explicit implementation would be nice to have in go. 
2023-08-02 12:36:36 -0400 < Zipheir> I suspect existential quantification is sufficient to explain them.
2023-08-02 12:40:39 -0400 < Zipheir> Here's some work on the problem. https://www.cs.cornell.edu/andru/papers/familia/familia.pdf
2023-08-02 12:43:45 -0400 < Zipheir> So yes. "From a type-theoretic viewpoint, object types [of interfaces, i.e. "interface types"] are existential types..."
2023-08-02 12:44:22 -0400 < Zipheir> "A method call on an object (e.g. x.hashCode()) implicitly unpacks the existentially typed receiver."
2023-08-02 12:45:15 -0400 < sham1> Well yeah. To call hashCode on x, there must be a type that x is a member of, such that it has the method hashCode
2023-08-02 12:45:29 -0400 < Zipheir> Exactly.
2023-08-02 12:48:00 -0400 < Zipheir> A value of an existentially-quantified type is always a pair of a type and a value of that type, like (T, X : T), so you can see it as a primitive kind of "generic" feature.
2023-08-02 12:49:16 -0400 < Zipheir> The paper that supposedly helped start OOP, by Cardelli & Wegner (http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf), is more about quantified types and modules than it is about Objects.
2023-08-02 13:02:51 -0400 < fizzie> Well, you know... https://zem.fi/tmp/stop-doing-type-theory.pdf (from SIGBOVIK'2001 proceedings).
2023-08-02 13:04:23 -0400 < sham1> I didn't know that the original meme was old enough that this could be from 2001
2023-08-02 13:07:12 -0400 < Zipheir> That line of humor will never die, as long as there's hacker hostility to, well, math.
2023-08-02 13:09:07 -0400 < Zipheir> "Types provide the means / To put the meaning on machines"
2023-08-02 13:11:03 -0400 < fizzie> sham1: I tried to type 2021 but failed.
2023-08-02 13:11:32 -0400 < sham1> fair enough
2023-08-02 13:11:37 -0400 < fizzie> (I don't think there even was a SIGBOVIK 2001, it seems to have started in 2007.)
2023-08-02 13:19:42 -0400 < mdhughes> It's not hostility to math, but to mathematicians pretending a computer is a chalkboard and not a weird toaster.
2023-08-02 13:22:06 -0400 < Zipheir> Computing involves both chalkboards and toasters, and it always has.
2023-08-02 13:22:50 -0400 < Zipheir> "When someone says 'computer science is not X but Y', have pity on his graduate students." (Alan Perlis)
2023-08-02 13:24:45 -0400 < mdhughes> It's been mostly toasters since Maurice Wilkes had his realization. Chalkboards aren't good enough, you have to see how it runs.
2023-08-02 13:25:47 -0400 < mdhughes> https://paste.debian.net/1287713/
2023-08-02 13:25:57 -0400 < mdhughes> (I really need to put my quotes page back up)
2023-08-02 13:26:01 -0400 < Zipheir> Eh, I can't see this debate ever ending.
2023-08-02 13:30:02 -0400 < Zipheir> Wilkes's quote could just as well suggest that you need a better theory of how to write programs.
2023-08-02 13:30:33 -0400 < Zipheir> Types and structured programming were still a ways off in the EDSAC days.
2023-08-02 13:34:39 -0400 < mdhughes> But it turns out 70+ years later, we still find bugs in our programs, and I suspect (with a little study evidence) at nearly the same rate. Which suggests all the tooling won't change that, it's fundamental to Humans "thinking".
2023-08-02 13:35:43 -0400 < mdhughes> And if you make the tooling more complicated than the initial problem, like type systems do, then you're going to put your errors there, and it'll "validate" bullshit.
2023-08-02 13:36:12 -0400 < Zipheir> "We've been eating raw food for nearly a century! Surely it's a fact of human nature."
2023-08-02 13:37:50 -0400 < mdhughes> Cooking can improve the calorie content and digestion of food. It can also char it and leads to fried foods, which are tasty but lethal.
2023-08-02 13:38:13 -0400 < Oxyd> And then there's my cooking, which is lethal but not tasty.
2023-08-02 13:38:22 -0400 < mdhughes> Fire's the original weird toaster.
2023-08-02 13:38:34 -0400 < mdhughes> But no amount of cave painting will cook your food.
2023-08-02 13:39:08 -0400 < sham1> Except that theoretical computer science isn't like doing cave painting to cook food
2023-08-02 13:39:23 -0400 < Zipheir> There is a question of whether type-checking does very much for programming accuracy or correctness. But types are a basic part of programming; the only question is how much the interpreter/compiler knows about them.
2023-08-02 13:39:40 -0400 < Zipheir> No-one cares about truly untyped data.
2023-08-02 13:39:55 -0400 < sham1> Well for one, there is no such thing
2023-08-02 13:40:02 -0400 < Zipheir> Just as no-one cares about a typeless computation.
2023-08-02 13:40:29 -0400 < Zipheir> Because types are about meaning.
2023-08-02 13:41:21 -0400 < mdhughes> ASM has untyped data. It works fine, really. You just do things to addresses.
2023-08-02 13:41:45 -0400 < Zipheir> That just means that *you* have to supply the types.
2023-08-02 13:41:46 -0400 < sham1> No it doesn't. ASM works with words and the different sizes of word are a type of the data
2023-08-02 13:41:54 -0400 < mdhughes> It's a pain in the ass for other reasons, so most people don't do it now.
2023-08-02 13:42:09 -0400 < sham1> As well as whether the hardware thinks of the data as being for example floating-point vs integral vs whatever
2023-08-02 13:42:25 -0400 < ecraven> sham1: are they though? you can access the same data at different sizes (rax/eax/ax/ah/al)...
2023-08-02 13:42:32 -0400 < mdhughes> sham1: That's really not true. Often the data at an address is a string, or structure of "3 bits for level, 5 bits for y-coord", etc.
2023-08-02 13:42:53 -0400 < ecraven> mostly it depends on the *instruction* how the data is treated
2023-08-02 13:43:00 -0400 < Zipheir> You have to remember things like "this stuff is a string", "this is a binary buffer", etc.
2023-08-02 13:43:14 -0400 < sham1> Right, but the assembler doesn't know that. It just works on the assumption that the program is well-typed with respect to the opcodes chosen for the given words
2023-08-02 13:43:21 -0400 < Zipheir> (The types are there; the language just doesn't have a way to talk about them.)
2023-08-02 13:43:57 -0400 < ecraven> I'd argue that there are no types to the assembler, it's all just instructions working on registers or memory locations that contain bitns
2023-08-02 13:44:06 -0400 < ecraven> all the semantics come into play on a higher level
2023-08-02 13:44:18 -0400 < mdhughes> Then that's an untyped language. I can document my (ab)use of pair trees in Scheme, too, and there's no "tree" type.
2023-08-02 13:44:38 -0400 < sham1> Of course this also exists as an explicit idea: <https://en.wikipedia.org/wiki/Typed_assembly_language>
2023-08-02 13:45:23 -0400 < Zipheir> ecraven: What I mean is that you have to keep types in mind to do effective asm programming.
2023-08-02 13:45:36 -0400 < ecraven> whether the value in ax is a signed or unsigned integer depends on whether you call JAE or JGE
2023-08-02 13:45:56 -0400 < ecraven> Zipheir: yes, however it's very common to access the same data as different types at different times
2023-08-02 13:46:06 -0400 < ecraven> (well, maybe not very common, but not uncommon)
2023-08-02 13:46:31 -0400 < Zipheir> Sure. That's just casual type-punning.
2023-08-02 13:46:49 -0400 < ecraven> I don't remember very well, but doesn't SSE have both floating point and integer operations for the same set of registers? 
2023-08-02 13:46:52 -0400 < mdhughes> copies/clears esp don't care about "type", just bytes. You can't comfortably do that in a type system.
2023-08-02 13:47:27 -0400 < Zipheir> You can, in a type system that allows such things.
2023-08-02 13:47:48 -0400 < ecraven> void* to the rescue :D
2023-08-02 13:47:55 -0400 < Zipheir> Oh, that's a hack.
2023-08-02 13:48:29 -0400 < Zipheir> Type theory is not a straitjacket! The goal is to describe computations, not restrict them.
2023-08-02 13:48:44 -0400 < mdhughes> C doesn't really have a type system, you can see the truth if you cast to char*.
2023-08-02 13:48:48 -0400 < Zipheir> The problem is that some computations are really hard to describe.
2023-08-02 13:49:22 -0400 < mdhughes> Types absolutely are BDSM gimp suits (which may be an unkind comparison for the perverts; they mind their business better than typists).
2023-08-02 13:49:34 -0400 < Zipheir> Oh, come on.
2023-08-02 13:49:39 -0400 < ecraven> Zipheir: I think that depends on the exact implementation of the type system :P some are more straitjackety than others
2023-08-02 13:49:51 -0400 < Zipheir> Theory, not system.
2023-08-02 13:49:53 -0400 < mdhughes> The point is to prevent you from doing useful, fun things, because "they're not safe", "not approved".
2023-08-02 13:50:10 -0400 < Zipheir> That's not true.
2023-08-02 13:50:24 -0400 < mdhughes> Sure, the fun part can be dangerous. I can overwrite a thing I think is an array of ints with a string. OK.
2023-08-02 13:50:28 -0400 < ecraven> but I agree that the *intent* behind the program probably has types, normal assembly just doesn't allow you to keep track of them very well (just like Scheme, which also doesn't allow you to track the intended types by default)
2023-08-02 13:50:37 -0400 < Zipheir> Right.
2023-08-02 13:51:24 -0400 < ecraven> so, back to xapian :D it's just no fun to ffi-wrap c++ interfaces :-/
2023-08-02 13:51:42 -0400 < mdhughes> What do you think types are for, if not bondage? How can they "help" you except by preventing your actions?
2023-08-02 13:52:02 -0400 < Zipheir> mdhughes: If you like, a good application of type theory is to understand what the dangerous, fun things mean.
2023-08-02 13:52:38 -0400 < mdhughes> But you can't express those. Make a Haskell array that's also a string.
2023-08-02 13:53:10 -0400 < sham1> Okay
2023-08-02 13:53:12 -0400 < Zipheir> Like type-punning: what does it mean, in type terms, that I can cast a float as an unsigned integer, bit-twiddle it, and cast it back?
2023-08-02 13:53:23 -0400 < sham1> Just give me an IO and some stuff and I'll do that
2023-08-02 13:53:34 -0400 < sham1> In fact, an array that's also a string? That's just Text innit
2023-08-02 13:53:37 -0400 < gwatt> mdhughes: can I make a haskell List that's a string?
2023-08-02 13:53:41 -0400 < Zipheir> mdhughes: You can express this kind of thing in type theory. The sky's the limit.
2023-08-02 13:54:06 -0400 < Zipheir> "The essense of mathematics is freedom", as Cantor says.
2023-08-02 13:54:48 -0400 < mdhughes> It has to be a random-access array of ints, and also expressable as a string. That came to mind because I was making height-map ASCII-art dungeon maps that way.
2023-08-02 13:56:25 -0400 < mdhughes> Prototype's C, I'm planning to do it in a 6502 & Z80 ASM port on Atari & Spectrum. Types would require me to double memory which they don't have.
2023-08-02 13:56:38 -0400 < Zipheir> The current problem, again, is that some computations that people take for granted (big multi-thread GUI things) have (as far as anyone knows) insanely complicated types that are almost as hard to understand as the processes themselves.
2023-08-02 13:56:59 -0400 < Zipheir> Well, *a* current problem.
2023-08-02 13:57:08 -0400 < mdhughes> GUIs long predate that stuff, they were made in Pascal & 68000 ASM.
2023-08-02 13:57:31 -0400 < mdhughes> And not just "safe" Pascal, but lots of pointers Apple Pascal.
2023-08-02 13:57:49 -0400 < Zipheir> And crystals predated group theory.
2023-08-02 13:58:27 -0400 < mdhughes> …? I suppose they do, by maybe 13 billion years?
2023-08-02 13:59:35 -0400 < Zipheir> I mean, there are lots of things that we know how to do but don't have a strong description of.
2023-08-02 14:00:07 -0400 < mdhughes> Anyway, GUIs aren't complex in specifics. Points & rects are just 2- and 4-vectors. Bitmaps are a size point, and a bunch of bits, often encoded in weird bit-patterns.
2023-08-02 14:00:12 -0400 < Zipheir> (Describing those GUI processes with stacks of monad types isn't very pretty.)
2023-08-02 14:00:48 -0400 < mdhughes> It's a very short routine to figure out which window's on top of another, and not all systems even have that.
2023-08-02 14:00:55 -0400 < sham1> mdhughes: that's a very reductive way to look at GUIs and ties the widgets to their on-screen representation
2023-08-02 14:01:36 -0400 < mdhughes> Note: https://computerhistory.org/press-releases/chm-makes-apple-lisa-source-code-available-to-the-public-as-a-part-of-its-art-of-code-series/
2023-08-02 14:01:37 -0400 < rudybot> https://teensy.info/RObsb0jL7z
2023-08-02 14:02:55 -0400 < mdhughes> Modern GUIs are a horrible mess, tho under Apple's Cocoa is very low-level stuff still, I use that from C all the time.
2023-08-02 14:03:07 -0400 < gwatt> sham1: sure, but it's also a straightforward way to think about GUIs.
2023-08-02 14:03:42 -0400 < mdhughes> Bitmap processing still sucks exactly as much as it did in 1984.
2023-08-02 14:04:27 -0400 < mdhughes> Sometimes I can cheat and just call sips to turn shittyformat into RGBA TIFF.
2023-08-02 14:11:11 -0400 < Zipheir> I agree with sham1, we want to abstract the GUI logic from the graphical details.
2023-08-02 14:11:47 -0400 < Zipheir> But the graphics should also be as simple as possible.
2023-08-02 14:12:00 -0400 < sham1> Ideally you'd separate the representation from the content, whatever that might be
2023-08-02 14:12:08 -0400 < mdhughes> You really don't want to do that, because it's slower. And nowadays all graphics are sent to a GPU, which does these very simple operations faster.
2023-08-02 14:12:23 -0400 < sham1> The speed is an implementation detail
2023-08-02 14:12:38 -0400 < sham1> HTML and the DOM seem to do it just fine
2023-08-02 14:12:45 -0400 < mdhughes> Do you like how awful Wayland is? That's what you get when you try to put graphics locally but abstracted.
2023-08-02 14:13:12 -0400 < mdhughes> No, they really don't. HTML is an absurdly slow graphics API! We have Canvas and WebGL to get around that.
2023-08-02 14:13:14 -0400 < sham1> I'm actually writing some code for a Wayland compositor, funnily enough
2023-08-02 14:13:48 -0400 < sham1> And you don't use canvas or webgl for forms or whatever, which is what most UIs are
2023-08-02 14:14:28 -0400 < mdhughes> Forms don't need 60fps, but many other things do. Just accepting "oh everything is slow and horrible but it has a tidy API" is shitty UX.
2023-08-02 14:15:12 -0400 < sham1> Well again, that's an implementation detail. It doesn't have to be slow or horrible
2023-08-02 14:15:24 -0400 < mdhughes> Why not just go back to VT100 terminal forms if that's all you're doing?
2023-08-02 14:15:37 -0400 < sham1> Well that's just most Linux apps, innit
2023-08-02 14:15:57 -0400 < mdhughes> Yes, it really does. Every layer of nonsense you pile on top slows it down, say 10-50%. And these high level things bury it under many layers.
2023-08-02 14:16:12 -0400 < wasamasa> considering this whole typing latency thing and how badly a non-vanilla emacs does it
2023-08-02 14:16:26 -0400 < wasamasa> https://pavelfatin.com/typing-with-pleasure/
2023-08-02 14:16:38 -0400 < wasamasa> here's an argument against piling levels of abstraction
2023-08-02 14:17:11 -0400 < Zipheir> Well, you have to pile levels of abstraction to do any programming at all.
2023-08-02 14:17:23 -0400 < mdhughes> This is one reason I code mostly in Vim, when I have "nicer" editors. I can trivially outtype Atom, BBEdit, etc. with code highlighting on. Vim keeps up.
2023-08-02 14:17:24 -0400 < sham1> A computer itself is an abstraction
2023-08-02 14:17:45 -0400 < wasamasa> mdhughes: except when you're editing latex, lol
2023-08-02 14:17:55 -0400 < wasamasa> that's what made me switch to emacs, ironically enough
2023-08-02 14:17:59 -0400 < Zipheir> elvis is even faster, I've found.
2023-08-02 14:18:04 -0400 < mdhughes> I don't, really? I mean, I often work in nice cuddly Scheme, but I'm perfectly happy to drop to C or ASM when needed.
2023-08-02 14:18:34 -0400 < wasamasa> no idea what it is specifically, but vim's syntax highlighting definition for latex is terribly slow
2023-08-02 14:18:34 -0400 < mdhughes> I was never a LaTeX(+silly shifting I can't do), I used troff until HTML & markdown.
2023-08-02 14:18:55 -0400 < sham1> Well vim's syntax highlighting is regex-based
2023-08-02 14:19:22 -0400 < sham1> Neovim does tree-sitter grammars, but whether there's an implementation of a tree-sitter for TeX, I'm not sure
2023-08-02 14:19:32 -0400 < sham1> FWIW Emacs also supports tree-sitter
2023-08-02 14:19:45 -0400 < mdhughes> Also, Dan Luu's latency report: http://danluu.com/input-lag/
2023-08-02 14:19:52 -0400 < wasamasa> with emacs 29.1, there's finally some tunables to bail out when the line to be highlighted is too long
2023-08-02 14:20:00 -0400 < wasamasa> something vim had for a lot longer
2023-08-02 14:20:28 -0400 < sham1> mdhughes: genuine question, since we're talking about piling abstractions, why do you program in Scheme. You'd think that with enough of an aversion towards abstractions, Scheme wouldn't be the first choice of language
2023-08-02 14:21:18 -0400 < mdhughes> CHICKEN and Chez are pretty fast, and come down to native code easily. Almost any other high-level language for problem solving is always slow.
2023-08-02 14:21:44 -0400 < sham1> C is plenty fast, even as a high-level language
2023-08-02 14:21:48 -0400 < Zipheir> mdhughes: You should use a hex editor and a drum memory like Mel.
2023-08-02 14:22:13 -0400 < wasamasa> with scheme I have the choice between using a really bad sample SRFI implementation and a much faster non-portable implementation
2023-08-02 14:22:31 -0400 < mdhughes> Even aliexpress can't find me drum memory anymore, and anyway I have to ship on customer machines eventually.
2023-08-02 14:22:39 -0400 < wasamasa> and that is nice
2023-08-02 14:23:00 -0400 < Zipheir> wasamasa: Which sample implemntations have you found "really bad"? Can we fix them?
2023-08-02 14:23:28 -0400 < mdhughes> Yeah, rewriting a few functions from a SRFI is often a huge win, *after* performance testing.
2023-08-02 14:23:45 -0400 < Zipheir> Send a patch!
2023-08-02 14:24:00 -0400 < mdhughes> Which Chez does better, it's possible to use lldb or Instruments on a CHICKEN program but it's extremely unclear, and the benchmark egg I tried was laughable.
2023-08-02 14:24:25 -0400 < wasamasa> given the overall stance of this channel with really basic things like wrapping non-portable code in a cond-expand, I do not think I can fix them in a way the maintainers appreciate
2023-08-02 14:24:35 -0400 < wasamasa> meanwhile in CL land, they do that all the time
2023-08-02 14:24:37 -0400 < mdhughes> Chez's built in reporting is good enough to find the 90% bottlenecks.
2023-08-02 14:24:40 -0400 < sham1> Well I'd assume that in many cases the fastness comes from ignoring certain boundary conditions for the SRFI implementation, such that it works for the given situation but not necessarily elsewhere
2023-08-02 14:24:45 -0400 < wasamasa> yes
2023-08-02 14:24:58 -0400 < wasamasa> it's mostly about picking a lot less general design
2023-08-02 14:24:59 -0400 < sham1> That's one of the things explicit typing actually enables :)
2023-08-02 14:25:07 -0400 < wasamasa> sometimes skipping layers of abstraction while you're at it
2023-08-02 14:25:14 -0400 < Zipheir> sham1: You mean like error checking?
2023-08-02 14:25:26 -0400 < wasamasa> you could use the okvs SRFI which depends on a lot of SRFIs with sample implementations only
2023-08-02 14:25:28 -0400 < sham1> For example
2023-08-02 14:25:30 -0400 < wasamasa> or you could use sqlite
2023-08-02 14:25:54 -0400 < sham1> If your program has an invariant such that you'll never hit an error condition, you can eliminate the error checks
2023-08-02 14:25:57 -0400 < wasamasa> I think if I had to try this stuff again, I'd try to write a dbm SRFI
2023-08-02 14:26:08 -0400 < wasamasa> cut out all the silly layers of abstraction while I'm at it
2023-08-02 14:26:37 -0400 < wasamasa> no comparators particularly, these were the slowest part
2023-08-02 14:26:50 -0400 < mdhughes> sqlite or berkley db with just a thin FFI layer on top is the way to go, I think.
2023-08-02 14:26:55 -0400 < Zipheir> The hacker mentality, I think, is *always* to cut out layers of abstraction. But the challenge is to be judicious about what layers to cut.
2023-08-02 14:27:57 -0400 < Zipheir> Comparators, e.g., give you polymorphic equality functions. You can replace them with equal?, but that's no longer extensible.
2023-08-02 14:27:58 -0400 < wasamasa> recently I've seen a dbm-like implemented in elisp, lol
2023-08-02 14:28:21 -0400 < wasamasa> yeah, ideally I'd get rid of the whole need for comparing by having a kvs rather than the ordered kind with range queries
2023-08-02 14:29:11 -0400 < dpk> there’s now SQLite in Emacs too! no need to reimplement dbm
2023-08-02 14:29:27 -0400 < Oxyd> What's Emacs use SQLite for?
2023-08-02 14:29:29 -0400 < wasamasa> the code was what some people before me call Ancient Japanese Elisp
2023-08-02 14:29:41 -0400 < dpk> not actually sure why they added it
2023-08-02 14:29:41 -0400 < wasamasa> the point of it is working across a ridiculous range of emacs versions
2023-08-02 14:29:58 -0400 < dpk> there’s a basic sqlite-mode for opening and looking at what’s in databases
2023-08-02 14:30:23 -0400 < sham1> IIRC there's also an API to actually use an SQLite database to store stuff
2023-08-02 14:30:26 -0400 < wasamasa> yeah, I recall the discussions about adding a sqlite mode and several people assumed it would be mandatory as backing store for org or custom.el or such
2023-08-02 14:30:31 -0400 < wasamasa> including RMS
2023-08-02 14:30:46 -0400 < sham1> IIRC Magit or some such use SQLite for something
2023-08-02 14:30:56 -0400 < dpk> oh yeah, magit-forge uses it
2023-08-02 14:31:00 -0400 < sham1> Ah yes
2023-08-02 14:31:19 -0400 < dpk> <strike>but magit-forge is shite anyway</strike>
2023-08-02 14:32:01 -0400 < sham1> Oh I won't even strike that. I tried to like it, but it just didn't work for me
2023-08-02 14:32:17 -0400 < sham1> Couldn't properly do issues
2023-08-02 14:38:48 -0400  * dpk read the backscroll, regretted it
2023-08-02 14:39:38 -0400 < dpk> going to revise my statement from earlier: #scheme is the only place where programmers will agree that recursion is better than iteration constructs like for, but will also have a flame war about whether static types should exist or not
2023-08-02 14:40:29 -0400 < Zipheir> #scheme is a place where you'll find many different opinions.
2023-08-02 14:43:39 -0400  * mdhughes reencodes in binary for 8 hours
2023-08-02 14:44:02 -0400 < dpk> the coolest things in Emacs 29 are: tree-sitter (i’m surprised rms agreed to add it given someone could write a ~ proprietary ~ grammar), SQLite, a Haiku window system port, and pixel-scroll-precision-mode
2023-08-02 14:44:42 -0400 < dpk> the most irritating thing for me personally is: they added ‘dark mode’ support on Windows, after my patch for the same damn thing on Mac OS was rejected because it added features on a proprietary OS which aren’t supported on a free OS
2023-08-02 14:45:10 -0400 < Dooshki> ah, lovely politics
2023-08-02 14:45:20 -0400 < sham1> Lovely politics courtesy of RMS
2023-08-02 14:45:35 -0400 < sham1> Of course, what can one expect really
2023-08-02 14:45:44 -0400 < dpk> (although maybe the new pgtk port means it is now also supported on free windowing systems, i dunno)
2023-08-02 14:45:51 -0400 < Dooshki> one of the reasons why I've kinda distanced myself from the FSF / GNU, I just love tech, and cherishing and celebrating it :3  I'm not here to fight a war
2023-08-02 14:45:52 -0400 < LeoNerd> The fact that both emacs and nvim have picked up tree-sitter means it's now a useful "rallying point", a way for lots of work to happen in a nicely shareable way
2023-08-02 14:46:30 -0400 < dpk> i’m curious to see to what extent tree-sitter will replace þe olden Emacs syntax tables in general, in the long term
2023-08-02 14:47:26 -0400 < dpk> the only one i’ve tried so far is css-ts-mode, which seems to offer negigible benefits compared to regular css-mode
2023-08-02 14:47:40 -0400 < dpk> maybe for other languages it’s more worth making the switch
2023-08-02 14:48:36 -0400 < sham1> I recall someone making a tree-sitter for Scheme
2023-08-02 14:48:49 -0400 < LeoNerd> I've been writing tree-sitter-perl. I've no idea what emacs was like for that, but I know it's already way better than what syntax/perl.vim could do
2023-08-02 14:53:04 -0400 < dpk> hmm, there’s an html-ts-mode in the Emacs git repo but it doesn’t look like it actually shipped
2023-08-02 14:54:02 -0400 < dpk> iirc last time i looked at the tree-sitter HTML grammar it considered a document without a <head> tag to be completely malformed and refused to parse usefully any further
2023-08-02 15:05:34 -0400 < Zipheir> Isn't <head> required in XHTML?
2023-08-02 15:07:19 -0400 < sham1> I don't know if the lack of <head> leads to quirks mode or not
2023-08-02 15:07:29 -0400 < Zipheir> (I have no idea how important XHTML is these days. Modern Web design is beyond me.)
2023-08-02 15:07:40 -0400 < Oxyd> I believe it's required in HTML 5 as well.
2023-08-02 15:07:54 -0400 < dpk> nope, both start and end tags are omissible
2023-08-02 15:08:16 -0400 < dpk> a title element is mandatory for a document, but the parser will fill in the <head> and </head> tags if you leave them out
2023-08-02 15:08:19 -0400 < jackdaniel> xhtml was dumped in favor of more extinguishible web
2023-08-02 15:08:26 -0400 < jackdaniel> extensible, of course I've meant extensible
2023-08-02 15:08:35 -0400 < Zipheir> Hah.
2023-08-02 15:08:47 -0400 < dpk> HTML parsing is the last gasp of the magic of SGML
2023-08-02 15:09:00 -0400 < Zipheir> I guess the 'X' stood for something else.
2023-08-02 15:09:30 -0400 < sham1> I like to still write my HTML as polyglot XML+HTML
2023-08-02 15:10:38 -0400 < Zipheir> I was reading about that recently. It seems there was a lot of discussion of how to validate extended XHTML back in the early 2000s, but nothing recently.
2023-08-02 15:11:35 -0400 < Zipheir> So polyglot XML works, but validating is hard.
2023-08-02 15:13:31 -0400 < dpk> the annoying thing is that SGML had a solution for this, as well (architectural forms), which was suggested to be carried over into XML but was rejected in favour of URI-based namespaces
2023-08-02 15:13:34 -0400 < wasamasa> dpk: I'd hope dark mode is available via gtk
2023-08-02 15:13:47 -0400 < wasamasa> dpk: RMS did object to sqlite support allowing loading up proprietary stuff actually
2023-08-02 15:14:03 -0400 < dpk> *SQLite* support allowing loading proprietary stuff?
2023-08-02 15:14:30 -0400 < Zipheir> dpk: Interesting. I'll look up architectural forms.
2023-08-02 15:14:34 -0400 < wasamasa> yes, you can load up extensions via both C and SQL API
2023-08-02 15:14:57 -0400 < dpk> ahhh, a plugin-type thing
2023-08-02 15:14:59 -0400 < wasamasa> yes
2023-08-02 15:15:03 -0400 < dpk> i didn’t know SQLite had that
2023-08-02 15:15:37 -0400 < wasamasa> https://www.sqlite.org/loadext.html
2023-08-02 15:17:21 -0400 < wasamasa> I guess that's how they added encrypted database support
2023-08-02 15:21:05 -0400 < jcowan> Gemini will extinguish the Web.  Of course.
2023-08-02 15:22:01 -0400 < jcowan> Zipheir: Talk to me about architectural forms, but not now, I have to leave to meet a "prestidigitator who puts metal in my mouth while taking metal out of my pocket"
2023-08-02 15:22:18 -0400 < sham1> Related: <https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/>
2023-08-02 15:22:21 -0400 < dpk> have a nice time at the dentist
2023-08-02 15:22:22 -0400 < Zipheir> jcowan: OK. Good luck.
2023-08-02 15:22:51 -0400 < gwatt> jcowan: if your dentist is steve martin find a new dentist
2023-08-02 15:23:00 -0400 < Zipheir> Hah.
2023-08-02 15:25:23 -0400 < Zipheir> sham1: Good article.
2023-08-02 15:27:37 -0400 < Zipheir> Most of what I see about Gemini is strongly for or against. It's nice to see a careful analysis.
2023-08-02 15:28:44 -0400 < sham1> Makes sense for Daniel since he does cURL and I don't think he'd necessarily want to alienate people
2023-08-02 15:28:59 -0400 < dpk> XML is possibly the first example of the second
2023-08-02 15:29:12 -0400 < dpk> system effect which ended up smaller and less featureful than the first system
2023-08-02 15:29:34 -0400 < dpk> (possibly because SGML was itself actually the second system, the first being IBM GML)
2023-08-02 15:32:45 -0400 < Zipheir> I don't know much about XML (though I'm learning), but the core seems solid. I guess the validation issues could be fixed by better extensions.
2023-08-02 15:33:40 -0400 < ecraven> think about attributes vs. elements in XML :P when to use which, and then look into how actual programs decide to use them
2023-08-02 15:35:41 -0400 < Zipheir> I was thinking about them recently. I think they make sense. XML without attributes would be a tree in which user data only (other than node/tag names) appears in leaf nodes. For general use, it makes sense for all nodes to be able to carry data.
2023-08-02 15:36:19 -0400 < Zipheir> When to *use* attributes is another thing. I imagine people have made weird decisions.
2023-08-02 18:37:40 -0400 < jcowan> My 2-page take on elements vs. attributes: https://docs.google.com/document/d/1XDzZYY34ruPLi4aUXC1JOXhFsHGNtubjtwE8yLW0TSQ
2023-08-02 18:41:09 -0400 < jcowan> Zipheir, ecraven, dpk:
2023-08-02 18:41:26 -0400 < jcowan> oops, overflowed onto a 3rd page
2023-08-02 19:04:10 -0400 < flatwhatson> there was a minor snark above saying roughly "if you love low-level programming so much, why use scheme"
2023-08-02 19:04:55 -0400 < flatwhatson> it seems to me like scheme is one of the lowest-level high-level programming languages
2023-08-02 19:12:32 -0400 < flatwhatson> not in the sense that you're operating on bytes directly (though you can), but the simplicity of the built-in abstractions give a similar "close to the metal" feel imo
2023-08-02 19:15:37 -0400 < Zipheir> Indeed, Scheme is a popular language with low-level functional programmers.
2023-08-02 19:17:01 -0400 < Zipheir> "The metal" isn't the only axis you can be close to.
2023-08-02 19:17:30 -0400 < Zipheir> jcowan: Thanks.
2023-08-02 19:17:47 -0400 < flatwhatson> yeah, it's something like "the essence of computation", lambda calculus woo-woo and all that :)
2023-08-02 19:18:54 -0400 < flatwhatson> as a mostly low-level guy, i like that i can draw a straight line between my scheme code and how it runs
2023-08-02 19:30:12 -0400 < aeth> speaking of the essence of computation
2023-08-02 19:31:30 -0400 < aeth> computers have room to be a billion times more efficient. Well, as of 10 years ago. Maybe it's only 100 million now, but doubtful... they haven't really seemed to get more efficient, just more, in the past decade. https://en.wikipedia.org/wiki/Landauer%27s_principle
2023-08-02 19:31:43 -0400 < aeth> Not necessarily a billion times faster. Maybe 100x faster and the rest is just in lower power consumption
2023-08-02 19:35:15 -0400 < flatwhatson> nice to know we have some headroom :)
2023-08-02 20:30:58 -0400 < Urchin[emacs]> even more if you get off Earth: https://www.youtube.com/watch?v=HdpRxGjtCo0
2023-08-02 20:42:21 -0400 < jcowan> My Scheme code (2x) / See how it runs (2x) 
2023-08-02 20:44:53 -0400 < jcowan> MicroXML exhibits the third (or fourth) system effect
2023-08-02 20:45:11 -0400 < jcowan> John the Miller ground small, small, small / The king's son of Heaven will pay for all
2023-08-02 21:42:21 -0400 < mdhughes> I'm just waiting for the heat death of the Universe, when stored energy computation will be at its most efficient.
--- Day changed Thu Aug 03 2023
2023-08-03 02:42:57 -0400 < jackdaniel> Golem XIV suggested, that concious machines final stage of evolution is a black hole - to increase the computation capacity in order to understand the sense of the universe
2023-08-03 02:43:09 -0400 < jackdaniel> pfft, but we already know the answer -- 42
2023-08-03 03:21:00 -0400 < mdhughes> While black holes as safe havens have a long history in SF (Heechee, Al Reynolds), it's kinda hard to get anything out, you have to wait for X-ray decay.
2023-08-03 03:21:45 -0400 < mdhughes> And putting anything in requires it to survive tidal forces of a star's gravity over millimeters, which is rough on most electronics.
2023-08-03 03:24:05 -0400 < aeth> let's just settle for a Dyson swarm
2023-08-03 03:31:29 -0400 -!- rumraisin is now known as phileasfogg
2023-08-03 03:34:00 -0400 < jackdaniel> no no, Golem XIV said that they were just "above the horizon", until they collapsed unwittingly; but well, the machine explains it better
2023-08-03 03:39:53 -0400 < dpk> jcowan: useful guide, thanks
2023-08-03 03:40:26 -0400 < dpk> "If a piece of data should usually be shown to the user, use an element; if not, use an attribute." is the rule of thumb i usually use, though your expansion accounts for more exceptions
2023-08-03 03:40:44 -0400 < dpk> notably, HTML mostly follows this rule, though with occasional exceptions in both directions
2023-08-03 03:44:45 -0400 < ecraven> jcowan: thanks
2023-08-03 03:45:42 -0400 < jcowan> dpk: That can't be enough by itself, because some schemas don't contain data meant to be shown to users
2023-08-03 03:48:39 -0400 < dpk> i would say such schemas are probably doing things that shouldn’t be done in an SGML-alike and should consider something more like JSON :-)
2023-08-03 03:50:04 -0400 < jcowan> Probably yes.  I wrote that before JSON was in common use.
2023-08-03 16:52:59 -0400 -!- ced1 is now known as cedb
2023-08-03 17:33:45 -0400 < duncanm> in common lisp, is there a way to make a user-define class 'applyable'?
2023-08-03 17:33:56 -0400 < duncanm> is there a thing in the MOP to allow that? 
2023-08-03 17:34:56 -0400 < duncanm> I was reading https://www2.ccs.neu.edu/racket/pubs/scheme2009-fb.pdf and they talked about how Racket has applicable structure types
2023-08-03 18:13:35 -0400 < Zipheir> I think jcowan was discussing applicable records a while back.
2023-08-03 18:14:31 -0400 < jcowan> They can't be done portably, unlike mutable closures; on the other hand, mutable closures cannot have type predicates reliably.k
2023-08-03 18:16:08 -0400 < Zipheir> I'm not exactly sure what an applicable record is, aside from something like a lens (which can be described in other ways).
2023-08-03 18:25:44 -0400 < jcowan> It's a record that you can also call "apply" on; that is, it is both a procedure and a record.
2023-08-03 18:28:10 -0400 < Zipheir> What's the meaning of (apply some-random-record ...)?
2023-08-03 18:31:27 -0400 < Zipheir> I take it you have to supply the procedure body when you define the type.
2023-08-03 18:31:49 -0400 < jcowan> When you declare the record-type you specify the procedure that will be run if the record is invoked..
2023-08-03 18:38:08 -0400 < Zipheir> Does the procedure take the current field values as arguments as well as any actual parameters? e.g. (define-applicable-record point point? (x ...) (y ...) (lambda (x y . args) ...))
2023-08-03 18:38:37 -0400 < Zipheir> You've probably explained the idea before. I've just forgotten.
2023-08-03 18:41:30 -0400 -!- user__ is now known as mirai
2023-08-03 19:01:12 -0400 < dpk> jcowan: applicable records implemented in terms of SRFI 229 tagged procedures can have reliable predicates
2023-08-03 19:01:52 -0400 < dpk> Emacs is also experimenting with an interesting ‘open closure’ idea which is a kind of hybrid record and procedure
2023-08-03 19:04:31 -0400 < dpk> https://zenodo.org/record/6228797
2023-08-03 19:06:23 -0400 < dpk> i wonder if mnieper has ever read The Art of the Metaobject Protocol
2023-08-03 19:28:08 -0400 < Zipheir> I guess I don't understand why this couldn't be implemented by a procedure field and a small apply-foo-record to paste in the field values.
2023-08-03 19:35:01 -0400 < Zipheir> All of the talk of big-O Objects just seems to confuse the matter.
2023-08-03 19:41:28 -0400 < flatwhatson> this is how closures have been implemented in mainstream languages for half a century
2023-08-03 19:42:34 -0400 < flatwhatson> one problem with open closures is they limit the compiler's ability to eliminate closures
2023-08-03 19:45:16 -0400 < flatwhatson> there's something hugely ironic about implementing C++'s lambdas in lisps :D
2023-08-03 19:46:37 -0400 < flatwhatson> (ok, not the lambda syntax, but the "functor" pattern)
2023-08-03 19:48:51 -0400 < Zipheir> Yeah, I wonder about how open closures would affect compilation strategies.
2023-08-03 19:49:42 -0400 < Zipheir> Mutable open closures sound even nastier.
2023-08-03 20:00:18 -0400 < jcowan> (lambda (x) (let ((x2 x) (set! x x2) x2) is a mutable closure
2023-08-03 20:04:55 -0400 < Zipheir> I mean mutable "from the outside".
2023-08-03 20:06:11 -0400 < Zipheir> e.g. providing some kind of set-in-closure! mutator on procedures.
2023-08-03 20:07:06 -0400 < Zipheir> But that would mess up procedure semantics.
2023-08-03 20:57:17 -0400 < jcowan> yeah, of course that would be possible.  It's just a choice to say there are no operations on procedures except invocation.  We could write a procedure-busting SRFI if we wanted to
2023-08-03 20:58:35 -0400 < jcowan> (set-closure-var! p n) where n represents the nth argument of the lambda)
2023-08-03 20:59:08 -0400 < jcowan> you might need a dummy set! in the procedure to make sure the nth argument was mutable
2023-08-03 21:51:29 -0400 < flatwhatson> does anyone have a good example of a well-structured r6rs project in the wild?
2023-08-03 23:24:04 -0400 < duncanm> ah yes, they're called "funcallable objects"
2023-08-03 23:46:12 -0400 < jcowan> duncanm: Except we don't have or need funcall, so you can do it either way: the object is a valid argument to apply (map, for-each, etc.) or it also works in operand position.
2023-08-03 23:46:15 -0400 < jcowan> It's a choice.
--- Day changed Fri Aug 04 2023
2023-08-04 00:06:42 -0400 < duncanm> yeah, i'm just saying that in CL, that's the name
2023-08-04 00:07:10 -0400 < duncanm> the Open Closures paper from Stefan Monnier is interesting 
2023-08-04 00:52:04 -0400 < jcowan> thanks, I look forward to reading it
2023-08-04 04:27:46 -0400 < cedb> im debating gerbil vs nim for a nice high level language that interops well iwth C and produces native binaries 
2023-08-04 04:28:18 -0400 < cedb> i think i prefer gerbil a bit but nim is clearly much bigger in terms of community    
2023-08-04 05:26:54 -0400 -!- lockywolf is now known as oppressionprime
2023-08-04 05:31:59 -0400 -!- oppressionprime is now known as lockywolf
2023-08-04 10:59:03 -0400 < mfiano> Nim forked because the author doesn't even know what he's doing anymore.
2023-08-04 11:00:13 -0400 < mfiano> It's his personal playground with no emphasis on compiler bugs, just neat new shinies, like 7 (!) the last time I checked, garbage collectors.
2023-08-04 12:23:14 -0400 < ober> cedb: gerbil ftw
2023-08-04 18:01:20 -0400 < cedb> yeet
2023-08-04 18:01:45 -0400 < cedb> mfiano: lol i never thought gc options would be considered shiny 
2023-08-04 18:03:21 -0400 < cedb> idk about the community, its just one of the few languges that seemed to have : native comp to reasonable binaries, C interop, static types, metaprogramming, GC while being like "fast"
2023-08-04 18:04:23 -0400 < cedb> ober: gerbil looks awesome, ive played with it a bit, Im just almost like a bit sceptical? cause it has /all/ the features you could expect of a  modern dynamic lang and i appreciate the taste of the designer but like
2023-08-04 18:04:57 -0400 < cedb> a bit hard to believe it could check all those boxes while being maintained by like 2 super motivated people and have such a small userbase
--- Day changed Sat Aug 05 2023
2023-08-05 14:50:30 -0400 < cedb> https://gambitscheme.org/dev/manual/Building-from-source.html returns a 404
2023-08-05 15:03:38 -0400 < cedb> Zipheir: instead of mutating closures going to Meta-(+1) in something like black would probably be nicer and more general
2023-08-05 15:11:31 -0400 < cedb> mfiano: blasting nim cause nimskull is a bit weird, sounds like a couple of people werent happy with the recommended git commit msg convention http https://news.ycombinator.com/item?id=32021299 https://github.com/nim-lang/Nim/pull/19211#issuecomment-9859
2023-08-05 15:29:21 -0400 -!- justache is now known as reddit-boat
2023-08-05 15:29:25 -0400 -!- reddit-boat is now known as justache
2023-08-05 15:41:00 -0400 < Zipheir> cedb: I don't know what you mean by "going to Meta-(+1) in something like black".
2023-08-05 15:43:31 -0400 < Zipheir> Those commit messages are reminiscent of https://xkcd.com/1296/
2023-08-05 16:10:07 -0400 -!- elflng_ is now known as elflng
2023-08-05 17:38:24 -0400 < Guest11> i was trying to get sld2 bindings for chibi scheme but no luck... :(
2023-08-05 17:38:48 -0400 < Guest11> does anyone know of some r7rs library that chibi can use that can do some elementary graphics?
2023-08-05 17:39:08 -0400 < Guest11> I just need to draw simple coloured lines and shapes.
2023-08-05 17:40:17 -0400 < wasamasa> have you considered to emit SVG?
2023-08-05 17:40:51 -0400 < Guest11> i've made my own functions that generate svg
2023-08-05 17:41:01 -0400 < Guest11> but I want some stuff to move.
2023-08-05 17:41:17 -0400 < wasamasa> so you need SVG and JS, I see
2023-08-05 17:41:26 -0400 < Guest11> js?
2023-08-05 17:41:40 -0400 < wasamasa> the scheme-inspired browser scripting language, yes
2023-08-05 17:41:50 -0400 < Guest11> ah java
2023-08-05 17:41:53 -0400 < Guest11> i never used that
2023-08-05 17:42:08 -0400 < Guest11> can i do without it?
2023-08-05 17:42:26 -0400 < Guest11> for example, is there some way to use x11 from chibi?
2023-08-05 17:42:39 -0400 < Guest11> (make-window ...) etc for exmaple?
2023-08-05 17:42:42 -0400 < wasamasa> well, if you can do talk to sockets, you can talk X11
2023-08-05 17:42:50 -0400 < wasamasa> it will be pain of course, but it's doable
2023-08-05 17:43:05 -0400 < Guest11> i don't think i'll manage...
2023-08-05 17:43:07 -0400 < wasamasa> I did hack on some X11 library for CHICKEN recently
2023-08-05 17:43:21 -0400 < wasamasa> I bet it's less challenging to pick up some JS :D
2023-08-05 17:43:35 -0400 < Guest11> why is it so difficult do to anything graphics related?
2023-08-05 17:43:54 -0400 < Guest11> i.e. why don't we have functions to modify pixels directly out of the box
2023-08-05 17:44:06 -0400 < wasamasa> because nobody did the hard work yet
2023-08-05 17:44:59 -0400 < samplet> Other implementations have graphics libraries, but I’m not seeing anything for Chibi.
2023-08-05 17:45:01 -0400 < Guest11> but why is it so hard? if we can send all sort of arithemtical instructions for cpu to do whjy cannot we access the monitor's pixels directly?
2023-08-05 17:45:02 -0400 < wasamasa> traditionally modifying pixels interactively was done via fast memory manipulation and even these days you have to somehow interact with a low-level API
2023-08-05 17:45:18 -0400 < wasamasa> I mean, you could if you had access to the framebuffer device
2023-08-05 17:45:24 -0400 < wasamasa> then the challenge is to do it fast enough
2023-08-05 17:45:33 -0400 < wasamasa> and I doubt chibi is up to that
2023-08-05 17:45:41 -0400 < Guest11> :(
2023-08-05 17:45:52 -0400 < wasamasa> your best bet is to make SDL2 bindings work
2023-08-05 17:46:13 -0400 < Guest11> i would if i knew how to. i would make the bindings myself.
2023-08-05 17:46:31 -0400 < wasamasa> you write code in C
2023-08-05 17:46:46 -0400 < Guest11> i don't program much actually, just for my amusement and i like r7rs because I could read the specs!
2023-08-05 17:46:47 -0400 < wasamasa> this code needs to call SDL2 functions and be written in a way to integrate with chibi's scheme APIs
2023-08-05 17:48:06 -0400 < samplet> Guile has SDL2 bindings and an R7RS compatibility mode (the latter is mostly pretty good, but has a few issues).
2023-08-05 17:48:37 -0400 < Guest11> maybe i'll try guile
2023-08-05 17:49:04 -0400 < samplet> If it’s just for your amusement, maybe that would be the most amusing.  Not if you’re on Windows, though....
2023-08-05 17:49:25 -0400 < wasamasa> kawa works well on windows
2023-08-05 17:49:34 -0400 < wasamasa> downside is you now need to learn java APIs :D
2023-08-05 17:50:02 -0400 < mfiano> cedb: I left 2 years before, when paid contributors were also leaving, and when Araq admitted to us on IRC that he released 1.0 purely to get more users knowing it was far from ready.
2023-08-05 17:59:48 -0400 < samplet> Guest11: If you want to write bindings for Chibi, it has a special language for creating them.  (Though I would caution that writing bindings is not my idea of “amusing”.)  See https://synthcode.com/scheme/chibi/#h2_CFFI
2023-08-05 18:01:11 -0400 < Guest11> seems a bit comlicated...
2023-08-05 18:01:20 -0400 < wasamasa> well yes
2023-08-05 18:01:26 -0400 < Guest11> trying out guile sdl and that doesn't run for me either :(
2023-08-05 18:01:28 -0400 < wasamasa> fortunately you do this just once
2023-08-05 18:01:33 -0400 < wasamasa> on windows?
2023-08-05 18:01:35 -0400 < Guest11> keeps spouting some errors
2023-08-05 18:01:40 -0400 < Guest11> linux
2023-08-05 18:01:48 -0400 < wasamasa> what linux?
2023-08-05 18:01:53 -0400 < Guest11> opensuse
2023-08-05 18:02:41 -0400 < samplet> Tumbleweed or Leap?
2023-08-05 18:02:51 -0400 < Guest11> hm i don;t know
2023-08-05 18:02:58 -0400 < Guest11> how to check that?
2023-08-05 18:03:07 -0400 < wasamasa> try `uname -a`
2023-08-05 18:03:27 -0400 < wasamasa> or reading /etc/issue
2023-08-05 18:03:41 -0400 < wasamasa> or /etc/os-release
2023-08-05 18:03:58 -0400 < Guest11> it is tumbleweed
2023-08-05 18:04:22 -0400 < wasamasa> ok, so you can install kawa
2023-08-05 18:04:46 -0400 < wasamasa> there's also racket
2023-08-05 18:05:17 -0400 < samplet> Does OpenSUSE have a package for Guile SDL2?  I’m not seeing it in their package browser on the Web.
2023-08-05 18:05:46 -0400 < Guest11> might very well be my system is buggy. often it updates and then i have no video (some nvidia issue i suppose) and then i have to return to previous snapback etc. also yast keeps reporting various errors... maybe i'll have to reinstall the system at some point...
2023-08-05 18:06:05 -0400 < Guest11> if it hag guile doesn't it have all its stuff?
2023-08-05 18:06:11 -0400 < wasamasa> no
2023-08-05 18:06:31 -0400 < samplet> The SDL2 bindings are an external package: https://dthompson.us/projects/guile-sdl2.html
2023-08-05 18:06:59 -0400 < samplet> It might be tricky to set up, then.
2023-08-05 18:07:17 -0400 < wasamasa> author assumes you're using guix anyway
2023-08-05 18:07:31 -0400 < wasamasa> but you can build from source, too
2023-08-05 18:07:31 -0400 < samplet> wasamasa: Read the next listing.  :)
2023-08-05 18:07:41 -0400 < Guest11> i would if i could it seems interesting but i'm on suse
2023-08-05 18:08:01 -0400 < Guest11> maybe i'll just give up an use racket instead...
2023-08-05 18:08:05 -0400 < wasamasa> you can build software from source on suse, too
2023-08-05 18:08:38 -0400 < Guest11> in theory yes in practice it most likey doesn't compile, causes some problems etc.
2023-08-05 18:08:46 -0400 < Guest11> or at least i'm very poor at doing that.
2023-08-05 18:08:59 -0400 < Guest11> i like appimage
2023-08-05 18:09:10 -0400 < Guest11> would be nice if everything was appimage
2023-08-05 18:09:18 -0400 < wasamasa> not gonna lie, using scheme means you enjoy doing things the hard way
2023-08-05 18:09:27 -0400 < Guest11> not really
2023-08-05 18:09:31 -0400 < wasamasa> yes really
2023-08-05 18:09:36 -0400 < wasamasa> have you read SICP?
2023-08-05 18:09:46 -0400 < Guest11> i like it because i had lambda calculus
2023-08-05 18:09:50 -0400 < Guest11> i have
2023-08-05 18:09:57 -0400 < wasamasa> it exists as a text precisely so that people understand what's going on in those computers, not to obfuscate it with appimage
2023-08-05 18:09:59 -0400 < Guest11> great textbook
2023-08-05 18:10:58 -0400 < Guest11> well i don't really care about what is going on with procerssors etc. I like scheme for recursion and sometimes it solves some of my problems, sometimes it is better in prolog
2023-08-05 18:11:13 -0400 < Guest11> i mostly make little things that help me with my work
2023-08-05 18:11:41 -0400 < samplet> Guest11: If you get the SDL2 development libraries installed, building Guile SDL2 should work.  I’m happy to help, though I understand if you want to try Racket instead (it might be easier).
2023-08-05 18:11:57 -0400 < Guest11> thanks
2023-08-05 18:12:35 -0400 < Guest11> I'll probably try some more to set it up but if it takes too long i'll try doing what i want in racket
2023-08-05 18:14:11 -0400 < Guest11> well, thanks a bunch guys. gotta go offline now
2023-08-05 18:14:47 -0400  * samplet waves.
2023-08-05 21:43:48 -0400 < daviid> fwiw wrt to the above conversation - https://elephly.net/guile-picture-language/ - https://elephly.net/guile-picture-language/manual.html - then a customized emacs env to play with ... https://elephly.net/guile-studio/ 
2023-08-05 22:21:52 -0400 < mdhughes> The best starter wants to draw graphics solution is Racket, it has a bunch of nice game dev tools. They're slow, but it's fine for the same things you'd use pygame for.
2023-08-05 22:22:58 -0400 < mdhughes> Jumping right to SDL2 bindings is kind of a high bar. That's the "right" answer for my kind of needs, but normal people wouldn't think so.
2023-08-05 22:49:57 -0400 < daviid> i was answering 'I just need to draw simple coloured lines and shapes' - though these are for guile (not chibi), and not r7rs libs - and wrt that objective, the above will be perfect to the job ): - for game dev (that's a complete other story, might wana look at chickadee - https://dthompson.us/projects/chickadee.html (which uses sdl2, among other 'monster' libs, but provide consistent (and higher level) interfaces to those ...) -
2023-08-05 22:49:58 -0400 < daviid> again, fwiw
2023-08-05 23:02:26 -0400 < jcowan> ezd is a Chicken lib but can also be run as a stand-alone utility that can be invoked from language: you communicate with it using S-expressions.  So you build it in Chicken and then start it up and talk to it via a TCP or local (unix) port.
2023-08-05 23:02:57 -0400 < jcowan> you can play with it from its own REPL.
2023-08-05 23:14:26 -0400 < mdhughes> http://wiki.call-cc.org/eggref/5/ezd
2023-08-05 23:14:28 -0400 < mdhughes> Does not exist.
2023-08-05 23:19:05 -0400 < mdhughes> https://www.upyum.com/cgit.cgi/ezd/ has the project, but now someone has to git, build, hope Chicken install works
2023-08-05 23:19:22 -0400 < mdhughes> vs install Racket, run the examples that actually work.
2023-08-05 23:32:59 -0400 < jcowan> Chicken install works fine.  It's just that the wiki doesn't have a page, which is not the same as an egg not existing.
2023-08-05 23:36:09 -0400 < mdhughes> And someone's going to learn how to use it… how?
2023-08-05 23:36:35 -0400 < jcowan> When you install it, you get the docs.
2023-08-05 23:36:57 -0400 < mdhughes> You know where else you can get docs? https://docs.racket-lang.org/gui/
2023-08-05 23:38:41 -0400 < jcowan> see https://github.com/ProgrammerArchaeology/ezd/tree/master/doc
2023-08-05 23:40:43 -0400 < mdhughes> Oh, excellent, everyone likes running troff.
2023-08-05 23:40:59 -0400 < mdhughes> On a 7-year-old document, but hey. Maybe it hasn't changed since then.
2023-08-05 23:41:00 -0400 < jcowan> okay, https://web.archive.org/web/20230314234724/https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.pdf
2023-08-05 23:41:06 -0400 < jcowan> It hasn't.
2023-08-05 23:41:43 -0400 < jcowan> In fact, except for conversion from Scheme->C to Chicken, it hsan't changed since 1991
2023-08-05 23:46:32 -0400 < mdhughes> Great, no image formats.
2023-08-05 23:52:18 -0400 < jcowan> It's about drawing.
2023-08-05 23:55:53 -0400 < mdhughes> You may not know this, but people have been using images in drawing for some time now.
2023-08-05 23:57:10 -0400 < dave0> from now on we'll be spelling everything with letters
--- Day changed Sun Aug 06 2023
2023-08-06 00:15:18 -0400 < mdhughes> Right, may as well just use ANSI art.
2023-08-06 00:37:39 -0400  * elflng sings the pictograph song
2023-08-06 11:26:14 -0400 -!- mirai_ is now known as mirai
2023-08-06 14:13:06 -0400 < Zipheir> It probably wouldn't be too hard to add image format output to ezd. imlib2 is simple enough.
2023-08-06 14:14:19 -0400 < Zipheir> Or just X bitmaps, which can be piped to external image converters.
2023-08-06 14:28:56 -0400 < cow_2001> What was that fancy site with a search over all srfis and rnrses?
2023-08-06 14:29:11 -0400 < cow_2001> Kind of like Hoogle for Haskell.
2023-08-06 14:30:43 -0400 < Zipheir> Was that something amirouche put together?
2023-08-06 14:30:50 -0400 < wasamasa> nah, someone else
2023-08-06 14:31:35 -0400 < wasamasa> https://index.scheme.org/
2023-08-06 14:32:07 -0400 < wasamasa> it uses kawa and a bunch of java things
2023-08-06 14:32:31 -0400 < Zipheir> Useful.
2023-08-06 14:33:07 -0400 < Zipheir> Useful, though the floaty JS boxes are silly.
2023-08-06 14:35:37 -0400 < cow_2001> Strange that with-input-from-file doesn't have a with-input-from-string, but has an open-input-string.  Why is that?
2023-08-06 14:37:12 -0400 < cow_2001> wasamasa: Thank you.
2023-08-06 14:39:53 -0400 < Zipheir> cow_2001: It might be because string ports come from SRFI 6, originally, which only had the open- procs. https://srfi.schemers.org/srfi-6/srfi-6.html
2023-08-06 14:40:31 -0400 < jcowan> cow_2001: Indeed, I have a pre-SRFI that includes with-input-from-string.
2023-08-06 14:41:07 -0400 < jcowan> However, (with-input-port (open-input-string ...) ...) does the job
2023-08-06 14:41:21 -0400 < Zipheir> It's easy to roll your own if current-input-port is a parameter object (as in R7RS).
2023-08-06 14:41:32 -0400 < Zipheir> Or that, which is more concise.
2023-08-06 14:41:49 -0400 < Zipheir> Hmm, I forgot about with-input-port.
2023-08-06 14:42:50 -0400 < Zipheir> Where is that defined?
2023-08-06 14:42:52 -0400 < jcowan> It's a very nice feature for dialects that have additional port types, e.g. Gambit (I think it's Gambit) has open-directory-port
2023-08-06 14:43:00 -0400 < jcowan> R[67]RS
2023-08-06 14:43:42 -0400 < jcowan> Directory ports return objects rather than strings or bytes
2023-08-06 14:44:08 -0400 < Zipheir> I can't find with-input-port in R6 or R7.
2023-08-06 14:45:12 -0400 < Zipheir> I guess you could use it to replace all of the various with-input-... forms.
2023-08-06 14:47:00 -0400 < jcowan> Sorry, it's call-with-port I'm thinking of
2023-08-06 14:47:38 -0400 < Zipheir> Ah, OK.
2023-08-06 14:50:02 -0400 < cow_2001> Oh! (with-input-port (open-input-string …) …) looks good.
2023-08-06 14:50:09 -0400 < jcowan> but it should be easy to construct with-input-port and with-output-port from that
2023-08-06 14:52:04 -0400 < Zipheir> The with-* I/O forms are just conveniences, anyway.
2023-08-06 14:53:46 -0400 < jcowan> (define (with-input-port port thunk) (parameterize ((current-input-port port)) (call-with-port port (lambda (dummy) (thunk))))) should work, I think
2023-08-06 14:53:46 -0400 < cow_2001> Convenience?  Closes ports for you, you mean?
2023-08-06 14:54:20 -0400 < jcowan> Yes
2023-08-06 14:54:50 -0400 < jcowan> Does that code look right?
2023-08-06 14:55:11 -0400 < jcowan> (with-output-port would be the same with s/input/output/g)
2023-08-06 14:55:22 -0400 < Zipheir> cow_2001: Everything that uses (current-input-port) by default takes an optional port argument, so you don't need with-*.
2023-08-06 14:55:39 -0400 < Zipheir> jcowan: Looks good to me.
2023-08-06 14:56:14 -0400 < Zipheir> cow_2001: Arguably, explicit port arguments are clearer.
2023-08-06 14:57:34 -0400 < Zipheir> i.e. clearer than rebinding the implicit ports.
2023-08-06 14:58:12 -0400 < Zipheir> And if you use call-with-port, it does the tidying up for you.
2023-08-06 14:58:15 -0400 < cow_2001> Hmm.
2023-08-06 15:00:24 -0400 < samplet> I would not have guessed that ‘with-input-from-port’ would close the port....  On the other hand, ‘parameterize’ is clear enough if you don’t want to close it.
2023-08-06 15:02:06 -0400 < samplet> In Guile, it does not close it.  It just does ‘parameterize’.
2023-08-06 15:02:11 -0400 < cow_2001> I don't know yet what is parameterize.
2023-08-06 15:02:31 -0400 < Zipheir> Who knows about with-input-from-port, since it's not in the reports. with-(in|out)put-from-file are required to close the port in R[67]RS.
2023-08-06 15:02:41 -0400 < samplet> It temporarily changes the meaning of a ‘parameter’.
2023-08-06 15:03:11 -0400 < Zipheir> cow_2001: I think they were first described here. https://srfi.schemers.org/srfi-39/
2023-08-06 15:03:19 -0400 < cow_2001> samplet: Sounds suspiciously like dynamic typing.
2023-08-06 15:03:28 -0400 < cow_2001> err
2023-08-06 15:03:33 -0400 < samplet> So you can have the ‘current-input-port’ parameter, and procedures like ‘display’ will use it by default.  Using ‘parameterize’ lets you temporarily change what that default is.
2023-08-06 15:03:36 -0400 < cow_2001> dynamic.. what was it.
2023-08-06 15:03:45 -0400 < samplet> Yes!  “dynamic scope”.
2023-08-06 15:03:52 -0400 < cow_2001> Dynamic as opposed to lexical.
2023-08-06 15:03:59 -0400 < Zipheir> Pretty much.
2023-08-06 15:04:01 -0400 < jcowan> Right, but using objects instead of variables.
2023-08-06 15:04:44 -0400 < cow_2001> objects?
2023-08-06 15:04:45 -0400 < jcowan> (parameterize ((x y)) ...) refers to a variable x holding a parameter object.
2023-08-06 15:05:01 -0400 < samplet> One of the core ideas of Scheme is that variable scoping should be lexical.  However, parameters are an escape hatch for when you want dynamic scope.
2023-08-06 15:05:31 -0400 < samplet> (Er, you want to emulate some pattern used in Lisps that have dynamic scope or whatever.)
2023-08-06 15:05:49 -0400 < jcowan> It does not bind the variable x, it changes the value inside the referent of x
2023-08-06 15:05:59 -0400 < jcowan> (x) gets the value.
2023-08-06 15:08:30 -0400 < Zipheir> cow_2001: Procedure objects, basically. You invoke my-parameter to get its value.
2023-08-06 16:08:31 -0400 < cow_2001> Oh!  So you hold values inside these make-parameter things whose call value may be changed from outside using parameterize.  Alright.
2023-08-06 16:09:35 -0400 < cow_2001> And like a let, when you go out a parameterize, it's back to normal.
2023-08-06 16:12:57 -0400 -!- ced1 is now known as cedb
2023-08-06 16:17:50 -0400 < samplet> cow_2001: Exactly, with added bonus that it plays well with ‘call/cc’.  (If you roll your own parameters by mutating global variables, that would not be the case!)
2023-08-06 16:34:59 -0400 < cow_2001> I don't see an assq-set! anywhere in r7rs  + srfis :|
2023-08-06 16:35:11 -0400 < cow_2001> How do you change alists?
2023-08-06 16:36:54 -0400 < cow_2001> I only see delete-alist and friends
2023-08-06 16:37:09 -0400 < cow_2001> err……… alist-delete.
2023-08-06 16:38:41 -0400 < wasamasa> functionally
2023-08-06 16:39:17 -0400 < wasamasa> it's just a funny looking list, so any list manipulation resulting in a changed alist works
2023-08-06 16:39:24 -0400 < cow_2001> I am running a let loop with too many parameters and I thought it would be nice to just maybe set a single (let loop ((env some-alist)) …)
2023-08-06 16:40:00 -0400 < wasamasa> one alist-specific hack is to just prepend the different item
2023-08-06 16:41:14 -0400 < cow_2001> so (loop (alist-cons …)) inside the let loop.
2023-08-06 16:42:24 -0400 < cow_2001> And forget about deleting stuff.  It's a tiny number of iterations anyway.
2023-08-06 16:42:57 -0400 < cow_2001> Famous last aerospace words………
2023-08-06 16:43:47 -0400 < cow_2001> (NASA never loop an unbound number of times, I think)
2023-08-06 16:46:52 -0400 < wasamasa> again, just do your favorite list processing that happens to return a list without that item
2023-08-06 16:48:36 -0400 < wasamasa> the laziest solution would be something like (remove (lambda (item) (eqv? (car item) 'to-be-deleted)) alist)
2023-08-06 16:58:05 -0400 < Zipheir> cow_2001: alist-update should really be the first thing in an alist library.
2023-08-06 16:58:47 -0400 < Zipheir> I can't see any reason to mutate an alist. (Why, to make them less slow?)
2023-08-06 17:13:47 -0400 < cow_2001> so (define (alist-update key val alist) (cons (cons key val) (alist-delete key my-alist)))
2023-08-06 17:14:33 -0400 < cow_2001> err
2023-08-06 17:14:38 -0400 < cow_2001> minus my-
2023-08-06 17:14:49 -0400 < cow_2001> to err is human
2023-08-06 17:14:53 -0400 < cow_2001> to moo, bovine
2023-08-06 17:43:04 -0400 < Zipheir> cow_2001: Yup. You could also write a version that updates "in place" rather than moving the pair to the head of the list. That way, (alist-update 'b 2 '((a . 1) (b . 2))) doesn't re-order the list. It probably doesn't matter very much, though.
2023-08-06 17:44:37 -0400 < Zipheir> Returning an identical (in the sense of equal?) list on such an operation seems like a good property to satisfy.
2023-08-06 17:50:10 -0400 < cow_2001> Oh right ~_~
2023-08-06 18:11:47 -0400 < Zipheir> It's actually pretty compact as a fold: (fold-right (lambda (p alist) (if (eqv? (car p) old-key) (cons (cons new-key new-val) alist) (cons p alist)) '() old-alist)
2023-08-06 19:18:32 -0400 < Zipheir> Er, that's almost it. It's missing the add-a-new-binding case.
2023-08-06 20:20:05 -0400 < cow_2001> I have a problem.  Sometimes when seeing "input" and "output" I am not sure if the author means it is from the point of view of the program I am writing or the program I am interacting with.
2023-08-06 20:22:29 -0400 < cow_2001> :|
2023-08-06 20:22:59 -0400 < flatwhatson> yes that's often confusing when dealing with IPC
2023-08-06 20:23:01 -0400 < cow_2001> There are efferent and afferent nerves.  I can never ever remember which is which.
2023-08-06 20:23:50 -0400 < cow_2001> flatwhatson: Whew.  I thought it's my bad brain.
2023-08-06 20:24:04 -0400 < flatwhatson> especially if you're forking!  or forking with a pipe!
2023-08-06 20:24:11 -0400 < cow_2001> Oh boy.
2023-08-06 20:25:50 -0400 < flatwhatson> it's one of those things where you just have to recognize it as confusing and tread carefully
2023-08-06 20:27:03 -0400 < flatwhatson> but the "correct" naming is from the perspective of the port's owner
2023-08-06 20:28:08 -0400 < flatwhatson> you read from your own input, and write to someone else's input
2023-08-06 20:29:49 -0400 < cow_2001> I see.
2023-08-06 20:30:23 -0400 < cow_2001> there was something very confusing in Guile's pipes when dealing with subprocesses.
2023-08-06 20:30:37 -0400 < cow_2001> flatwhatson: Thank you.
2023-08-06 20:31:12 -0400 < flatwhatson> ah yes, the guile manual refers to "input port" and "output port" :D
2023-08-06 20:31:29 -0400 < cow_2001> I mean, dealing with which end is the input and which end is the output and from what point of view.
2023-08-06 20:31:31 -0400 < flatwhatson> so you have an output port to the child's input, and an input port from the child's output
2023-08-06 20:32:05 -0400 < flatwhatson> that's because "input port" and "output port" are type names, referring to something read from or written to respectively
2023-08-06 20:32:10 -0400 < cow_2001> Thankfully things fail and tell you what's what.
2023-08-06 20:37:11 -0400 < flatwhatson> just avoid IPC altogether
2023-08-06 20:37:26 -0400 < flatwhatson> agoraphobic programming
2023-08-06 21:54:06 -0400 < cow_2001> flatwhatson: Can you really avoid IPC?
2023-08-06 21:56:20 -0400 < flatwhatson> sure, just re-implement everything in scheme
2023-08-06 22:54:43 -0400 < cow_2001> flatwhatson: Sounds suspiciously like Rustlang………
2023-08-06 23:00:46 -0400 -!- mdhughes_ is now known as mdhughes
2023-08-06 23:58:44 -0400 < Zipheir> Putting everything into a single-language environment just passes the IPC buck to threads or something similar.
2023-08-06 23:59:08 -0400 < Zipheir> "Intra" isn't always easier than "inter".
--- Day changed Mon Aug 07 2023
2023-08-07 00:06:13 -0400 < flatwhatson> working with fibers or similar is definitely simpler than forking for parallelism
2023-08-07 00:06:36 -0400 < flatwhatson> but agreed that threads and mutexes are probably the worst of the lot
2023-08-07 00:12:42 -0400 < cow_2001> I had thought I needed a macro but it turned out to be a false alarm.  Used a procedure instead. ~_~
2023-08-07 01:14:39 -0400 < cow_2001> Still, alist instead of named arguments to a procedure is a bit of a pita, innit?
2023-08-07 01:15:08 -0400 < aeth> but why do processes need to exist?
2023-08-07 01:19:41 -0400 < aeth> maybe it makes sense to have four: the OS, the DE/WM, the text editor, and the inferior lisp.
2023-08-07 01:31:18 -0400 < Zipheir> cow_2001: Named arguments are nice, but there's no consensus on how to implement them.
2023-08-07 01:32:03 -0400 < Zipheir> cow_2001: Records are another option. Unlike alist arguments, they have "built-in validation".
2023-08-07 01:32:55 -0400 < Zipheir> (i.e. you can pass an alist with arbitrary keys, but you can't fill in field that isn't in the type.)
2023-08-07 01:33:03 -0400 < Zipheir> *a field
2023-08-07 01:45:52 -0400 < mdhughes> My `alref` function has a default key. But you can just as easily do (or (assoc 'foo alist) defval)
2023-08-07 01:47:27 -0400 < mdhughes> I don't really love making a new record & filling it in for a function call, and we still don't have named fields, so you rely on… positional args to the record constructor.
2023-08-07 01:49:56 -0400 < Zipheir> Yes. You end up moving the problem to the record constructor.
2023-08-07 01:50:24 -0400 < Zipheir> Records are how Haskell does it, and that works just fine for them, right? ;-)
2023-08-07 03:37:10 -0400 < lockywolf> Is there a registry of subdomains of scheme.org?
2023-08-07 07:35:13 -0400 -!- stultulo is now known as f8l
2023-08-07 07:41:22 -0400 < cow_2001> Zipheir: What do you mean by built-in validation?
2023-08-07 11:02:30 -0400 < cedb> sounds like nominal typing
2023-08-07 11:02:44 -0400 < cedb> so when are we gonna commit to a real static scheme
2023-08-07 11:03:41 -0400 < cedb> Zipheir: couldnt a hint be taken from ocaml folks? theyre handling of labels and optional params in curried functions is quite sophisticated (messy maybe)
2023-08-07 11:24:47 -0400 < flatwhatson> prescheme (from scheme48) exists, i think it counts as a "real" static scheme, though currently a bit limited and outdated
2023-08-07 11:33:12 -0400 < mfiano> It must be a new day. flatwhatson is mentioning prescheme ;)
2023-08-07 12:02:12 -0400 < cow_2001> cedb: Sigh.  Someone should add an SRFI for that.  SRFI-666.
2023-08-07 12:03:58 -0400 < cow_2001> mfiano: I almost wrote dynamic typing in Prescheme, but was too dumm to make cons that can contain cons.
2023-08-07 12:04:31 -0400 < cow_2001> the commits are still there, waiting for a tweak ~_~
2023-08-07 12:04:43 -0400  * cow_2001 stares at flatwhatson
2023-08-07 12:05:32 -0400 < cow_2001> mfiano: demo dynamic typic, just for didactic purposes
2023-08-07 12:05:49 -0400 < cow_2001> typing
2023-08-07 12:06:02 -0400 < flatwhatson> ah, i did dig into how scheme48vm does it, the answer is straightforward; just encode everything as tagged words/longs
2023-08-07 12:06:13 -0400 < cow_2001> O_O
2023-08-07 12:06:27 -0400 < mfiano> flatwhatson: did you ever figure out the guix build reproducibility thing?
2023-08-07 12:07:14 -0400 < flatwhatson> ie. there's no underlying struct for an s48_value, it's all encoded in 32/64-bit words with bitmasks
2023-08-07 12:07:58 -0400 < cow_2001> My low level C knowledge is almost nonexistent. ~_~
2023-08-07 12:08:43 -0400 < flatwhatson> mfiano: i've made a lot of progress, it's something to do with the order in which symbols are added to the symbol table, still chipping away at it
2023-08-07 12:08:56 -0400 < samplet> flatwhatson: What’s your opinion about PreScheme as a language?  Like, what’s the best feature and what’s the worst shortcoming?
2023-08-07 12:09:04 -0400 < mfiano> flatwhatson: Oh interesting
2023-08-07 12:09:38 -0400 < samplet> I’ve been following your work from a distance, and it’s cool, but sometimes I’m not sure I “get” it.  :)
2023-08-07 12:11:37 -0400 < flatwhatson> samplet: the most interesting thing to me about prescheme is the *potential* of the compiler, more-so than the current state of the language
2023-08-07 12:12:06 -0400 < samplet> Does it use that mind-blowing “Scheme as an intermediate language” trick?
2023-08-07 12:14:39 -0400 < samplet> I’ve been trying to decide if that approach could be used to simplify the Guix bootstrapping effort (GNU Mes and friends).
2023-08-07 12:17:02 -0400 < flatwhatson> yes, it's a scheme-flavoured syntax tree and uses a series of transformations to go from a "high-level" language to continuation & environment passing style, and then to "low-level" language which translates directly to C or (in theory) your machine code of choice
2023-08-07 12:19:36 -0400 < flatwhatson> the main problem is really tooling, it does whole-program compilation and infers types for everything, limited support for type declarations, limited support for modularization, limited support for monomorphization (only inlining) etc.
2023-08-07 12:19:57 -0400 < flatwhatson> most egregious is the lack of source locations for errors!
2023-08-07 12:22:15 -0400 < samplet> Ouch.  That’s no good.  The Scheme reader should provide those, but I guess you have to keep them as you go to lower-level representations.  (Since it’s an older code base, that could be hard!)
2023-08-07 12:25:46 -0400 < flatwhatson> yeah i think it's not that difficult to do, but i haven't dug into it yet.  the syntax tree is built of pretty straightforward record structures that come from the expander which should already have the source locations.  it might be a matter of adding some fields to the intermediate nodes & ensuring it's copied over during transformations
2023-08-07 12:29:54 -0400 < flatwhatson> i have a bunch of notes about the image format & memory representation of the scheme48vm from digging into this reproducibility bug
2023-08-07 12:31:06 -0400 < flatwhatson> i'll try to target cow_2001's level of bit-hacking knowledge when writing it up :)
2023-08-07 12:38:21 -0400 < Zipheir> cow_2001: What I meant by validation is that if you write a procedure that takes a record instead of named arguments, you don't have to worry about invalid names.
2023-08-07 12:40:55 -0400 < Zipheir> With named procedures, you have to consider what happens when the caller gives a bogus name.
2023-08-07 12:47:26 -0400 < cow_2001> Zipheir: Bogus should raise an error at compile time, no?
2023-08-07 12:51:39 -0400 < cow_2001> Oh boy. https://hackers.town/@devlogic/110843380784157782
2023-08-07 12:58:36 -0400 < Zipheir> cow_2001: Yes, but that means that the correct named arguments have to be statically knowable. You can't do that with symbols, for example.
2023-08-07 12:58:45 -0400 < Zipheir> Racket's keyword semantics get it right.
2023-08-07 13:02:35 -0400 < Zipheir> OK, you can have symbolic names available to the compiler if you have a special form, known to the compiler, for declaring named-argument procedures.
2023-08-07 15:32:29 -0400 < cow_2001> (display '(1 . '())) shows up as the weird (1 quote ())
2023-08-07 15:33:39 -0400 < Zipheir> Because you're quoting quote.
2023-08-07 15:34:09 -0400 < cow_2001> err.
2023-08-07 15:34:11 -0400 < Zipheir> '() is the same as (quote ())
2023-08-07 15:34:25 -0400 < cedb> so much sugar!
2023-08-07 15:34:43 -0400 < cow_2001> `(1 . ,'()) is (1)
2023-08-07 15:34:45 -0400 < sham1> om nom
2023-08-07 15:35:05 -0400 < cow_2001> Which is (cons 1 '()) more or less, I guess…
2023-08-07 15:35:15 -0400 < cedb> ok now do a recursive call-with-values
2023-08-07 15:35:23 -0400 < cow_2001> aaaaa
2023-08-07 15:35:27 -0400 < cow_2001> AAAAA
2023-08-07 15:35:39 -0400 < cedb> Zipheir: member that weird one liner?
2023-08-07 15:37:16 -0400 < Zipheir> cedb: Huh?
2023-08-07 15:41:30 -0400 < cedb> someone was trying to understand call/cc
2023-08-07 15:41:43 -0400 < cedb> and they posted the weirdest example, kept me for hours
2023-08-07 15:43:22 -0400 < cow_2001> Okay, to hell with `(…).  I am using (cons …).
2023-08-07 15:43:35 -0400 < cow_2001> and list.
2023-08-07 15:43:50 -0400 < Zipheir> cedb: Ah, got it.
2023-08-07 15:44:01 -0400 < cedb> yall seen this:http://www.iro.umontreal.ca/~feeley/papers/OLearyFeeleyMOREVMS23.pdf
2023-08-07 15:44:04 -0400 < cedb> looks pretty cute
2023-08-07 15:44:20 -0400 < Zipheir> cow_2001: Don't completely ditch `. It can be great with pattern-matching.
2023-08-07 15:44:27 -0400 < cedb> cow_2001: dont quasiquote unless it makes
2023-08-07 15:44:42 -0400 < cedb> ya pattern matching and datastructures with a bunch of atoms ala erlang
2023-08-07 15:45:01 -0400 < Zipheir> cedb: Interesting VM.
2023-08-07 15:45:33 -0400 < cow_2001> hmm.
2023-08-07 15:45:37 -0400 < cow_2001> Okay!
2023-08-07 15:45:38 -0400 < cedb> oh woups wrong paper, same vm but
2023-08-07 15:45:40 -0400 < cedb> http://www.iro.umontreal.ca/~feeley/papers/YvonFeeleyVMIL21.pdf
2023-08-07 15:45:54 -0400 < cedb> pretty neat
2023-08-07 15:46:08 -0400 < cedb> also the paper just before is about interop between gambit and Cpython hmmm
2023-08-07 15:46:36 -0400 < cedb> WERE GONNA MAKE IT
2023-08-07 15:47:19 -0400 < cow_2001> Is this The Year of The Lisp Desktop?
2023-08-07 15:47:47 -0400 < Zipheir> cow_2001: e.g. look at the 'parse' function in this little ANF transformer. http://ix.io/4CLw
2023-08-07 15:48:31 -0400 < Zipheir> Well, I used quasiquoting everywhere in that one, now that I look at it.
2023-08-07 15:49:07 -0400 < cow_2001> When I finish writing this scanner I will share the code and your eyes are going to bleed out of their sockets like they're a bunch of sunny side ups.
2023-08-07 15:50:29 -0400 < Zipheir> Writing a VM seems like a fun way to start a Scheme implementation.
2023-08-07 15:51:47 -0400 < cow_2001> This one's a c-style.
2023-08-07 15:54:24 -0400 < cow_2001> the one i am writing.  sorry.
2023-08-07 15:55:22 -0400 < cow_2001> cedb: are those yours?
2023-08-07 16:00:55 -0400 < cedb> i wish thats the gambit guy
2023-08-07 16:02:19 -0400 < cedb> have you looked at this https://www.youtube.com/watch?v=b3fhA12KS48&list=PLj_txzquIGNURTiL53z8k6AQlrIaWsdyy
2023-08-07 16:02:32 -0400 < cedb> i think im the only one excited lol 
2023-08-07 16:02:46 -0400 < cedb> ah woups i screwed the bot, title: CUE: a data constraint language and shoo-in for Go. Marcel van Lohuizen, Google.
2023-08-07 16:32:07 -0400 < aeth> from now on I'm writing `(a b c d . ,'()) instead of '(a b c d)
2023-08-07 16:32:15 -0400 < aeth> thanks, cow_2001
2023-08-07 16:32:39 -0400 < cow_2001> ~_~
2023-08-07 16:34:15 -0400 < aeth> for those who don't get it... dotted list syntax... and lists that end in nil in the cdr are just proper, undotted lists. A cons pair is '(a . b) but it can be extended to e.g. '(a b c . d) where the first part behaves like a list except for the final cons pair, in this case '(c . d)
2023-08-07 16:35:55 -0400 < aeth> '(a b c . d) being sugar for '(a . (b . (c . d)))
2023-08-07 16:37:08 -0400 < aeth> but now replace d with (d . ()) and you get a proper list via '(a . (b . (c . (d . ())))) or '(a b c d . ())
2023-08-07 16:38:11 -0400 < aeth> but the cow_2001 syntax is an even better way to write '(a b c d) because the quasiquote with an unquote lets you write ,'() where you unquote and then immediately requote instead of () which is already quoted by the form earlier
2023-08-07 16:38:35 -0400 < aeth> and that's the anti-tldr that everyone can skip that explains `(a b c d . ,'())
2023-08-07 16:48:10 -0400 -!- rgherdt__ is now known as rgherdt
2023-08-07 17:00:03 -0400 < Zipheir> If you're new to Scheme, disregard that.
2023-08-07 18:13:39 -0400 < flatwhatson> (list (cons (quasiquote a (unquote a))) (cons (quasiquote b (unquote b)))) to avoid any confusion
2023-08-07 18:13:44 -0400 < flatwhatson> syntax bad
2023-08-07 18:18:25 -0400 < mdhughes> https://interlisp.org/medley/using/running/online/ and hit fullscreen in it, and you've got your Lisp desktop.
2023-08-07 18:19:03 -0400 < mdhughes> (I wish the Mac version didn't require Xquartz, which is meh speed on my 5K monitor)
2023-08-07 20:28:19 -0400 < flatwhatson> lockywolf: re: scheme.org subdomains, they're listed here: https://servers.scheme.org/
--- Day changed Tue Aug 08 2023
2023-08-08 00:58:16 -0400 -!- Noisytoot is now known as Guest8310
2023-08-08 02:13:04 -0400 -!- Netsplit *.net <-> *.split quits: cognemo, rendar, sandra, teiresias, rudybot, Spawns_Carpeting, aoh, nrr_____, Oxyd, gwatt,  (+1 more, use /NETSPLIT to show all of them)
2023-08-08 02:17:51 -0400 -!- Netsplit over, joins: nrr_____
2023-08-08 02:17:57 -0400 -!- Netsplit over, joins: rudybot
2023-08-08 04:01:00 -0400 -!- rgherdt_ is now known as rgherdt
2023-08-08 04:35:19 -0400 < cow_2001> I have a scary idea.
2023-08-08 04:37:18 -0400 < cow_2001> (let* ((env '((some-list) (other-thing . 0))) (env (do-something env)) (env (do-something-else env))) (get-result env))
2023-08-08 04:37:50 -0400 < cow_2001> You keep it sort of functional and get imperative stuff.
2023-08-08 04:43:50 -0400 -!- mirai_ is now known as mirai
2023-08-08 04:52:45 -0400 < lockywolf> https://prg.is.titech.ac.jp/wp-content/uploads/2023/03/tanabe-phd-dissertation.pdf
2023-08-08 05:52:31 -0400 -!- Netsplit *.net <-> *.split quits: nerthus, bsima, phileasfogg, eMBee, dnm, dpk, gahr, mns, DragonMaus, rickbutton_,  (+2 more, use /NETSPLIT to show all of them)
2023-08-08 06:04:25 -0400 -!- Netsplit over, joins: phileasfogg, mns, cinerion, nerthus, bsima, eMBee, gahr, dpk, rickbutton_, dnm (+2 more)
2023-08-08 06:05:53 -0400 -!- rumraisin is now known as phileasfogg
2023-08-08 06:31:39 -0400 < flatwhatson> cow_2001: i wouldn't call that a scary idea, that's a perfectly fine way to do things
2023-08-08 06:31:54 -0400 < flatwhatson> let* the ultimate threading macro
2023-08-08 06:33:18 -0400 < sham1> let*-values
2023-08-08 06:33:41 -0400 < sham1> Or I suppose letrec*-values if that existed. That'd be the ultimate threading macro
2023-08-08 11:14:31 -0400 < Zipheir> cow_2001: Congratulations, you've invented a monad.
2023-08-08 11:16:14 -0400 < Zipheir> Er, discovered.
2023-08-08 11:22:13 -0400 < Zipheir> cow_2001: This is very similar to Haskell's 'do' macro.
2023-08-08 11:22:58 -0400 < cow_2001> Morelike "accidentally plagiarised".
2023-08-08 11:23:32 -0400 < cow_2001> It just sort of converged into that without me noticing.
2023-08-08 11:25:05 -0400 < cow_2001> I already saw how SICP weaves an environment variable in its procedure and "learned" a bit of Haskell
2023-08-08 11:26:13 -0400 < cow_2001> SICP takes current value and creates new value which it feeds into the next call.
2023-08-08 11:29:46 -0400 < Zipheir> Yes. This pattern has been discovered again and again. http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html
2023-08-08 11:30:09 -0400 < Zipheir> Sussman called it "hidden plumbing".
2023-08-08 12:19:37 -0400 < mfiano> threading macros is just this decade's reinvention of tacit/point-free programming.
2023-08-08 12:30:00 -0400 < gwatt> Maybe? They seem to more be about un-nesting parenthesized forms. Points-free is about not naming arguments and relying on function composition
2023-08-08 12:30:42 -0400 < Zipheir> You can write anything point-free, so I guess everything reinvents it.
2023-08-08 12:31:25 -0400 < Zipheir> I'm not sure it was ever a programming tool so much as a style.
2023-08-08 13:03:25 -0400 < jcowan> There are languages that are explicitly point-free, like J.
2023-08-08 13:19:34 -0400 < Zipheir> Right. Was J related to Backus's FP? That's another.
2023-08-08 13:27:41 -0400 < jcowan> Not that I know of; it's a successor to APL.
2023-08-08 13:28:05 -0400 < jcowan> Still, it steam-engines when it comes steam-engine time, as Aleister Crowley had it
--- Log closed Tue Aug 08 14:46:31 2023
--- Log opened Tue Aug 08 14:47:28 2023
2023-08-08 14:47:28 -0400 -!- Irssi: #scheme: Total of 195 nicks [0 ops, 0 halfops, 0 voices, 195 normal]
2023-08-08 14:47:30 -0400 -!- Irssi: Join to #scheme was synced in 8 secs
2023-08-08 16:36:01 -0400 -!- You're now known as Zipheir
2023-08-08 17:54:48 -0400 -!- teiresias2 is now known as teiresias
2023-08-08 18:43:30 -0400 < maisqn> I installed Maude and started reading Maude Primer but I still dont know what it is. Maybe you know? (I know its #scheme but schemers have open minds)
2023-08-08 18:47:03 -0400 -!- ced1 is now known as cedb
2023-08-08 19:03:56 -0400 < wasamasa> what
2023-08-08 19:06:23 -0400 < wasamasa> while I have seen people in here excited about haskell, agda, coq and such, I've yet to run into maude
2023-08-08 19:08:00 -0400 < wasamasa> have you considered to look up what category theory is?
2023-08-08 19:08:13 -0400 < wasamasa> or what maude's communities are?
2023-08-08 19:08:27 -0400 < wasamasa> the shotgun approach won't get you far I'm afraid
2023-08-08 19:14:02 -0400 < maisqn> At least you know about it now. No point writing about Haskell and Agda and Coq because everyone knowsabout it
2023-08-08 19:15:04 -0400 < wasamasa> honestly, I'll forget about it because category theory is not my jam
2023-08-08 19:16:33 -0400 < maisqn> Oh no, but i hope its different/better category theory than idris and agda and haskell...
2023-08-08 19:16:34 -0400 < maisqn> ok
2023-08-08 19:17:45 -0400 < Zipheir> Category theory's pretty much the same everywhere.
2023-08-08 19:18:01 -0400 < wasamasa> I'd expect that, too
2023-08-08 19:18:31 -0400 < Zipheir> It's like the initial object in the category of theories. :)
2023-08-08 19:21:02 -0400 < maisqn> "Maude is simple. Its semantics is based on the fundamentals of category theory, which is pretty intuitive and straightforward until a mathematician tries to describe it formally with symbols and Greek letters."
2023-08-08 19:21:17 -0400 < Zipheir> True.
2023-08-08 19:24:27 -0400 < Zipheir> No need to bash mathematicians. Some of them can explain it pretty clearly.
2023-08-08 19:40:04 -0400 < jcowan> It's not bashing mathematicians , just some of their notations.
2023-08-08 20:37:24 -0400 < daviid> mdhughes: nice, the interlisp/medley link ...
2023-08-08 20:46:08 -0400 -!- Spawns is now known as Spawns_Carpeting
2023-08-08 21:41:33 -0400 -!- oldf8l is now known as f8l
--- Day changed Wed Aug 09 2023
2023-08-09 02:17:34 -0400 < mnieper> maisqn: I'm a mathematician; as soon as you want to understand more than the *very* basics of category theory, you will be glad to have some kind of notation. :)
2023-08-09 02:17:53 -0400 < mnieper> I know Maude.
2023-08-09 02:19:06 -0400 < mnieper> It is a term-rewriting system. A very different kind of system compared to Haskell or Agda or Coq.
2023-08-09 02:23:38 -0400 < mdhughes> If only we had some system of combining symbols to make "words", and we could use those to explain our ideas clearly.
2023-08-09 02:24:11 -0400 < mdhughes> But no, ∆*(•) is much better.
2023-08-09 02:25:08 -0400 < mnieper> Things like sin, cos, tan, ... are (abbreviations of) words.
2023-08-09 02:25:46 -0400 < mnieper> Things like +, -, ... were written as words.
2023-08-09 02:26:30 -0400 < mnieper> You won't want to do this again.
2023-08-09 02:27:37 -0400 < mdhughes> (add1 x)
2023-08-09 02:28:27 -0400 < mdhughes> Repost time: https://arcanesentiment.blogspot.com/2015/01/if-scheme-were-like-scheme.html
2023-08-09 02:37:41 -0400 < mnieper> Feel free to use a number library like the one suggested. Scheme has inductive data types, so Peano numbers, in particular.
2023-08-09 02:38:18 -0400 < mnieper> Time to get rid of the string type and the character notation as well.
2023-08-09 03:01:03 -0400 < mdhughes> No, those use words for their commands, they're fine.
2023-08-09 03:02:13 -0400 < mdhughes> string-append is a little verbose, but the alternatives in other languages are pretty hideous, so… good enough.
2023-08-09 03:03:19 -0400 < mdhughes> The only one I like is REXX where making strings adjacent to values concatenates them. And that relies on everything being a string, which has a few drawbacks.
2023-08-09 03:03:51 -0400 < mdhughes> But the math version of that is inane: xy is (times x y), so you can't even have long names.
2023-08-09 03:05:10 -0400 < mdhughes> "Mathematicians make a language" has been tried, it's APL. The lack of widespread APL keyboards tells you how well it was received.
2023-08-09 03:07:23 -0400 < dave0> it's in unicode now :-)
2023-08-09 03:08:55 -0400 < dave0> we could swap / for ÷ if we wanted to
2023-08-09 03:16:24 -0400 < sham1> At least to me ÷ implies integer division instead of just general division 
2023-08-09 03:33:12 -0400 < mdhughes> It's very hard to tell ÷ and + apart at a distance. I'd rather use div for integer divide, / for floats.
2023-08-09 03:47:35 -0400 < flatwhatson> that article isn't wrong.  why do we have string=? but spell number=? as =
2023-08-09 03:48:31 -0400 < flatwhatson> a big part of scheme's appeal is sweeping out the dusty anachronisms of lisp
2023-08-09 03:49:11 -0400 < pony> probably because = is from maths
2023-08-09 03:50:16 -0400  * flatwhatson slides car/cdr/cons under the rug
2023-08-09 03:50:23 -0400 < pony> ?
2023-08-09 03:51:55 -0400 < dave0> ponycat?
2023-08-09 03:52:00 -0400 < pony> ye
2023-08-09 03:52:08 -0400 < dave0> hi!
2023-08-09 03:52:12 -0400 < pony> hey!
2023-08-09 03:52:29 -0400 < jcowan> The keyboard was not the issue with APL; J and K use ASCII.  The things that make APL hard are its over-terseness and its highly idiomatic style.
2023-08-09 04:01:19 -0400 < mdhughes> Well obvs the keyboard was a problem, since they had to make J to type APL-like language on a common keyboard.
2023-08-09 04:02:39 -0400 < mdhughes> The logic of the language is also a problem, it's just so weird solving any non-math problem.
2023-08-09 04:03:06 -0400 < mdhughes> A friend of mine was doing Advent of Code in J, and the solutions were so hard.
2023-08-09 05:00:54 -0400 < mnieper99> Good notation and good naming is very important if not the most important thing in maths.
2023-08-09 05:02:44 -0400 < mnieper99> It is not about terseness but to find the right abstractions and to allow the human brain to easily detect patterns.
2023-08-09 06:01:41 -0400 < dpk> we can gladly go back to writing mathematics in śloka as far as I’m concerned :D
2023-08-09 06:07:05 -0400 < dpk> flatwhatson: https://arcanesentiment.blogspot.com/2015/01/if-scheme-were-like-scheme.html
2023-08-09 06:15:58 -0400 < sham1> Writing mathematics in Sanskrit might just be a tad too inaccessible to be useful
2023-08-09 06:27:27 -0400 < dpk> oh, that article is what flatwhatson was actually responding to
2023-08-09 06:27:56 -0400 < flatwhatson> yes lol
2023-08-09 08:05:24 -0400 -!- Netsplit *.net <-> *.split quits: nerthus, bsima, eMBee, dnm, dpk, gahr, mns, DragonMaus, rickbutton_, cinerion,  (+1 more, use /NETSPLIT to show all of them)
2023-08-09 08:05:44 -0400 -!- Netsplit over, joins: mns, cinerion, nerthus, bsima, eMBee, gahr, dpk, rickbutton_, dnm, DragonMaus (+1 more)
2023-08-09 21:32:44 -0400 < flatwhatson> huh... i was browsing readscheme.org on the internet archive, but just realized this exists: https://github.com/schemedoc/bibliography
2023-08-09 21:58:05 -0400 < flatwhatson> this is a great starting point for building the schemer oracle
2023-08-09 21:59:42 -0400 < flatwhatson> next would be to scrape all of those into a text format, and load it all into a database with full-text index and embeddings
2023-08-09 22:02:07 -0400 < flatwhatson> then it's just a generic search-engine+chat-bot on top of that
--- Day changed Thu Aug 10 2023
2023-08-10 06:19:19 -0400 -!- Guest22 is now known as sam-d
2023-08-10 07:28:26 -0400 < lockywolf> Can someone point me to the famous rant about top level being broken?
2023-08-10 07:38:49 -0400 < lockywolf> nvm found it
2023-08-10 07:51:22 -0400 < jackdaniel> lockywolf: share with us :)
2023-08-10 08:22:57 -0400 -!- rgherdt_ is now known as rgherdt
2023-08-10 08:31:00 -0400 < rgherdt> jackdaniel: I guess what lockywolf means is the "Top level is hopeless" discussion (correct me if I'm wrong): https://gist.github.com/samth/3083053
2023-08-10 08:31:31 -0400 < lockywolf> yeah, that one
2023-08-10 08:41:59 -0400 < flatwhatson> how does r6rs change the behavior of the top level?
2023-08-10 08:46:23 -0400 < samth> flatwhatson: r6 does not describe the behavior of a top level
2023-08-10 08:52:53 -0400 < dpk> except confusingly it has a thing called a ‘top-level program’, which is not what samth and co mean when they talk about the ‘top level’ (they mean a REPL)
2023-08-10 08:59:36 -0400 < lockywolf> yes
2023-08-10 08:59:45 -0400 < lockywolf> I don't think it is that confusing.
2023-08-10 09:00:18 -0400 < lockywolf> Hm. Are there any plans to add eager syntax-rules to r7rs-large?
2023-08-10 09:01:05 -0400 < lockywolf> I haven't studies them in earnest, but they seem to be a useful, practical thing, not devoid of theoretical interest too.
2023-08-10 09:02:18 -0400 < dpk> no, R7 Large has syntax-case, obviating the need for em-syntax-rules
2023-08-10 09:02:51 -0400 < dpk> those stuck on small and needing portable pseudo-procedural macros can embed the SRFI 148 sample implementation
2023-08-10 09:11:43 -0400 < jackdaniel> rgherdt: thanks!
2023-08-10 09:40:55 -0400 < lockywolf> dpk: I do not see the connection
2023-08-10 09:41:12 -0400 < lockywolf> srfis are one of the ways the standard evolves
2023-08-10 09:44:33 -0400 < mfiano> I think his point is that procedural macros are where standard Scheme is heading. Having many different features first-class is not ideal, according to the first sentence of the report.
2023-08-10 11:43:26 -0400 < jcowan> I think that those who don't like syntax-case much will accept it as part of the large language, and those who do like it, will accept the R6RS form of it.
2023-08-10 11:44:39 -0400 < jcowan> mfiano: Note that with syntax-case, syntax-rules is no longer a primitive feature.
2023-08-10 11:45:01 -0400 < jcowan> ditto identifier-syntax, which is a feature I personally really do *not* like.
2023-08-10 11:45:28 -0400 < jcowan> But it would be arbitrary at this point to rule it out of the standard.
2023-08-10 11:52:37 -0400 < mnieper> What do you mean by R6RS form of syntax-case, jcowan?
2023-08-10 11:52:52 -0400 < jcowan> As opposed to other variants such as Racket's.
2023-08-10 12:11:29 -0400 < Zipheir> It seems to me that most of the remaining complaints about syntax-case come from implementers and maintainers.
2023-08-10 12:41:02 -0400 < jcowan> Sure.  It's a big bite to implement if you don't have it already.  I keep hoping that someone outside the core Chicken team will do a conforming implementation.
2023-08-10 13:05:48 -0400 < gwatt> Is mit-scheme going to implement syntax-case?
2023-08-10 13:06:12 -0400 < Zipheir> Libraries of some sort would also be nice.
2023-08-10 13:06:12 -0400 < jcowan> I doubt it.
2023-08-10 13:06:36 -0400 < jcowan> Supporting it as a back end for Unsyntax might make sense.
2023-08-10 13:07:26 -0400 < gwatt> I thought mit-scheme had r7rs small support?
2023-08-10 13:09:34 -0400 < Zipheir> I think it does, modulo the library system.
2023-08-10 13:10:12 -0400 < Zipheir> (Which is one of the most important advances over R5RS, IMHO.)
2023-08-10 13:11:40 -0400 < gwatt> ah, yeah. The inability to define your own libraries does seem pretty bad
2023-08-10 13:38:35 -0400 < jcowan> It was one of only two requirements the Steering Committee put on the R7RS-small language: appropriate-sized macros and modules. 
2023-08-10 13:53:16 -0400 < Zipheir> You'd think they would have required some way to raise an exception. IIRC R5RS didn't have that.
2023-08-10 13:53:43 -0400 < Zipheir> (s/exception/error/ as appropriate)
2023-08-10 14:12:37 -0400 < dpk> jcowan: why did WG1 design a completely incompatible library declaration?
2023-08-10 14:13:03 -0400 < dpk> over time i’ve come to see that as small’s biggest mistake, deepening the R5/R6 rift
2023-08-10 14:13:40 -0400 < dpk> even if define-library is more extensible, it’s rather incongruous that the headline feature in R7RS small is larger and more complex than its equivalent in R6RS
2023-08-10 14:13:43 -0400 < jcowan> R6RS was not extensible
2023-08-10 14:14:01 -0400 < jcowan> and I don't know why it was a mistake
2023-08-10 14:21:00 -0400 < jcowan> using a different keyword meant that an implementation that can't handle an R[67] library could reject it on the spot
2023-08-10 14:21:17 -0400 < jcowan> but it is straightforward to support both
2023-08-10 14:26:01 -0400 < dpk> R7RS would have been an ‘extended subset’ of R6RS if it had kept the same library declaration form (minus versioning and phasing). the extensibility of define-library is a plus, but i don’t think it was worth throwing away the groundwork for R6 compatibility for, and to be honest i don’t think i’ve seen any use of it so far that truly justifies its existence anyway
2023-08-10 14:26:30 -0400 < dpk> i think it served to confirm the impression of the R6RS community that R7RS was, as Dybvig put it, a reactionary effort
2023-08-10 14:28:50 -0400 < dpk> i could even play devil’s advocate and argue that the ‘extensibility’ of the R7RS form is an anti-feature compared to the R6RS one, but i’m not sufficiently convinced of that myself, so i won’t
2023-08-10 14:36:24 -0400 < Zipheir> Is there any difficulty in handling both?
2023-08-10 14:36:47 -0400 < dpk> admittedly, no
, but it’s cruft
2023-08-10 14:37:19 -0400 < dpk> the argument above (not the devil’s advocate one) is more a political argument than a technical one
2023-08-10 14:41:34 -0400 < Zipheir> Older Scheme implementations usually have their own module forms, so it's just one more form to juggle.
2023-08-10 14:41:51 -0400 < Zipheir> But it is unfortunate that there are two incompatible standard forms.
2023-08-10 15:06:14 -0400 < gwatt> How is r7rs' define-library more extensible than r6rs' library?
2023-08-10 15:12:24 -0400 < aeth> the solution is easy: have an r6rs2 that backports some stuff from r7rs that makes it easier to support both
2023-08-10 15:12:39 -0400 < aeth> (and now you have three standards!)
2023-08-10 15:26:55 -0400 < mdhughes> If you wanted to extend R6RS's library, you could just add another optional keyword to the prelude. Conflicts with existing names should be rare if you pick a specific-enough name.
2023-08-10 15:28:53 -0400 < mdhughes> Maybe (external-library foo) loads foo.so, foo.dll, etc. from appropriate locations. Even if you have a (define external-library ...) later, it's not going to be confused with the prelude entry.
2023-08-10 15:29:43 -0400 < Zipheir> gwatt: It's certainly less rigid.
2023-08-10 15:29:56 -0400 < mdhughes> So anyway now we have a mess of -chez.sls, -gambit.sld, -chicken.sld, etc.
2023-08-10 15:30:16 -0400 < mdhughes> Mmm. Chicken salad.
2023-08-10 15:33:11 -0400 < Zipheir> aeth: The "third standard" (which sounds like the Third Man) is supposed to be R7RS-large-core, or whatever the non-Batteries language is going to becalled.
2023-08-10 15:33:14 -0400 < Zipheir> *be called
2023-08-10 15:34:29 -0400 < aeth> but what about r7rs-huge
2023-08-10 15:34:35 -0400 < aeth> are we ever going to see r7rs-huge?
2023-08-10 15:34:35 -0400 < sham1> r7rs-mid
2023-08-10 15:37:12 -0400 < mdhughes> r7rs-pangaea
2023-08-10 15:37:51 -0400 < mdhughes> "third standard" is "third impact" from Neon Genesis Evangelion to me.
2023-08-10 15:38:57 -0400 < wasamasa> lol
2023-08-10 15:39:27 -0400  * mdhughes turns into Tang
2023-08-10 15:41:23 -0400 < gwatt> R7RS-Sagittarius-A*
2023-08-10 15:52:45 -0400 < mnieper> We shouldn't blame WG1 too much for incompatibilities with R6RS.  If there is someone to blame (and I very much believe there is), it is the Steering Committee by not adding the requirement of compatibility.
2023-08-10 15:53:24 -0400 < mnieper> Scheme would have more easily looked into a brighter future without the schism.
2023-08-10 15:54:18 -0400 < mnieper> On a technical level, an R7RS-small that is compatible with R6RS could have been as good as the existing R7RS-small is.
2023-08-10 15:57:06 -0400 < Zipheir> Water under the bridge.
2023-08-10 15:58:16 -0400 < mnieper> I would also like to bring to mind that the main virtue of the library systems of R6RS and R7RS-small is that the top-level environment can be fully customized and here they are equivalent.  Compared with this, all other features of the library system are superficial.
2023-08-10 15:59:06 -0400 < mnieper> Zipheir: I replied to dpk.
2023-08-10 15:59:20 -0400  * mnieper nods to dpk.
2023-08-10 16:01:06 -0400 < Zipheir> Still, it's way in the past. Blaming one faction or the other isn't much help now.
2023-08-10 16:10:17 -0400 < aeth> what kind of bridge, though?
2023-08-10 16:10:46 -0400 < mnieper> We still have the same Steering Committee, so their mindset can still be relevant.  Understanding the past (even through blunt language) can help guide us making better decisions in the future.
2023-08-10 16:21:11 -0400 < Zipheir> Ah, OK. I wasn't sure how much of the original Steering Committee was still active.
2023-08-10 16:43:03 -0400 < mnieper> Zipheir: This is another - good - question.
--- Log closed Thu Aug 10 17:21:29 2023
--- Log opened Thu Aug 10 17:21:42 2023
2023-08-10 17:21:42 -0400 -!- Irssi: #scheme: Total of 198 nicks [0 ops, 0 halfops, 0 voices, 198 normal]
2023-08-10 17:21:43 -0400 -!- Irssi: Join to #scheme was synced in 7 secs
2023-08-10 19:08:04 -0400 -!- mirai_ is now known as mirai
2023-08-10 19:55:34 -0400 < cow_2001> Is there such a thing as if __name__ == "__main__": in R7RS?
2023-08-10 19:56:13 -0400 < cow_2001> That is how you run stuff in Python only if it is the main script being run, and not an imported module.
2023-08-10 20:00:33 -0400 < flatwhatson> not in r7rs, but there might be something implementation-specific
2023-08-10 20:00:52 -0400 < flatwhatson> just write a library, and a script which calls the library
2023-08-10 20:01:12 -0400 < flatwhatson> or just run your software from the repl and forget about this library/script nonsense
2023-08-10 20:02:56 -0400 < wasamasa> cow_2001: there isn't even consensus how libraries are stored on disk, what file names to use and where to look them up
2023-08-10 20:04:51 -0400 < cow_2001> Sigh. ~_~
2023-08-10 20:05:09 -0400 < cow_2001> Why is it so hard to form consensus?
2023-08-10 20:05:21 -0400 < wasamasa> remember, scheme is supposed to be minimal
2023-08-10 20:05:21 -0400 < flatwhatson> my abacus doesn't have disks or files
2023-08-10 20:05:27 -0400 < cow_2001> Various file schemes?
2023-08-10 20:05:49 -0400 < wasamasa> it may seem simple to you, but the mere existence of windows does complicate this
2023-08-10 20:06:00 -0400 < cow_2001> UNIX-likes have their structures, Windows, Mac?
2023-08-10 20:06:30 -0400 < wasamasa> honestly, I think it's great the standard does not have to concern itself with the notion of path separators
2023-08-10 20:07:12 -0400 < cow_2001> Mac is a UNIX, innit?
2023-08-10 20:07:30 -0400 < wasamasa> or max path lengths
2023-08-10 20:07:38 -0400 < wasamasa> or forbidden/allowed characters in paths
2023-08-10 20:07:45 -0400 < cow_2001> Oh boy.  Max path lengths.
2023-08-10 20:07:59 -0400 < flatwhatson> symbolic links
2023-08-10 20:08:00 -0400 < cow_2001> Oooh boy.
2023-08-10 20:08:25 -0400 < cow_2001> I am getting anxious just thinking about thinking of that.
2023-08-10 20:08:30 -0400 < flatwhatson> filesystems suck
2023-08-10 20:09:18 -0400 < Zipheir> Why do you want to determine whether something is an imported name or not?
2023-08-10 20:09:39 -0400 < flatwhatson> Zipheir: that pattern in python lets you use one file as both a library and a script
2023-08-10 20:10:09 -0400 < cow_2001> Zipheir: I just wanted to run some dumb tests.  I will just write a separate file that imports the real source.
2023-08-10 20:10:10 -0400 < wasamasa> or more practically speaking, include directories and how to specify them, what precedence they have, etc.
2023-08-10 20:10:25 -0400 < cow_2001> Zipheir: Should use test files anyway.
2023-08-10 20:10:26 -0400 < flatwhatson> it uses a top level check of the current module/namespace to determine whether to run the entrypoint
2023-08-10 20:10:42 -0400 < Zipheir> Ah, I think I see.
2023-08-10 20:11:06 -0400 < Zipheir> cow_2001: Test files are the usual convention.
2023-08-10 20:11:13 -0400 < flatwhatson> in python, the namespace is implicit from the filename.  this approach doesn't work so well in schemes that declare the namespace explicitly
2023-08-10 20:11:19 -0400 < cow_2001> Was thinking: If I run the lib directly, run tests.  If imported, don't.
2023-08-10 20:11:31 -0400 < Zipheir> That's messy semantics.
2023-08-10 20:11:48 -0400 < cow_2001> I agree.  Just write test files.
2023-08-10 20:12:22 -0400 < flatwhatson> fwiw, you can write your library as a library, then use command-line args of your interpreter to run the entry-point
2023-08-10 20:12:44 -0400 < cow_2001> Oh, right. ~_~ Forgot about that.
2023-08-10 20:13:00 -0400 < cow_2001> -e main or somesuch in Guile manual
2023-08-10 20:13:01 -0400 < flatwhatson> eg. guile -e
2023-08-10 20:13:18 -0400 < flatwhatson> -e FUNCTION  after reading script, apply FUNCTION to command line arguments
2023-08-10 20:14:12 -0400 < cow_2001> Thank you.
2023-08-10 20:39:50 -0400 < flatwhatson> well, it seems like edwin48 isn't in a working state, and afaics wasn't ever in a working state, just a work-in-progress port
2023-08-10 21:22:43 -0400 < flatwhatson> > Common Lisp compatibility. We believe that T will be general enough to be useful as an implementation vehicle for
2023-08-10 21:22:43 -0400 < flatwhatson> Common Lisp. We expect programs which adhere to the Common Lisp specification to run transparently in a Common Lisp subsystem implemented within T. Determining the difficulty of this task will need to wait until the Common Lisp language specification has stabilized.
2023-08-10 21:23:22 -0400 < flatwhatson> i wonder if anyone ever did implement a common lisp on a scheme?
2023-08-10 21:27:38 -0400 < aeth> Guile iirc basically has the capabilities because they want to implement elisp on it
2023-08-10 21:28:08 -0400 < aeth> but it's easier to go the other way around because Scheme's the smaller language and CL's the larger one, so your implementation of CL-on-Scheme is probably not going to be portable, but vice versa can be
2023-08-10 23:15:29 -0400 -!- Noisytoot_ is now known as Noisytoot
--- Day changed Fri Aug 11 2023
2023-08-11 02:06:51 -0400 < flatwhatson> stumbled across commander-s today: https://www.deinprogramm.de/scheme-2005/05-knauel/05-knauel.pdf
2023-08-11 02:09:31 -0400 < flatwhatson> lots of 404s when digging into dependencies but thankfully softwareheritage has backups of the relevant repos
2023-08-11 03:12:15 -0400 < mnieper`> cow_2001: wasamasa: Scheme is no exception when it comes to non-specifying the mapping from library names to file names.
2023-08-11 03:12:45 -0400 < mnieper`> The same is true for the C language, which is said to be one of the most portable languages.
2023-08-11 03:13:11 -0400 < mnieper`> It is a question of the build system, not the language.
2023-08-11 03:14:01 -0400 < mnieper`> Separation of concerns! :)
2023-08-11 03:15:20 -0400 < mnieper`> This is also one reason why I think R6RS's library (mentioned by dpk yesterday) is the better form than R7RS's define-library (and there was no fundamental reason why the R6RS form had to be replaced).
2023-08-11 07:37:43 -0400 -!- pony is now known as no-n
2023-08-11 09:57:33 -0400 < sham1> Why would define-library be any different from library in that sense?
2023-08-11 09:59:11 -0400 < sham1> The mapping from the library name to wherever the define-library not-quite-Scheme-form is would still be implementation-specific
2023-08-11 10:02:55 -0400 < sham1> And if anything, define-library separates concerns even better because usually the implementation file is a separate thing from the library file
2023-08-11 10:09:31 -0400 < Zipheir> Yes. For better or worse, R7RS has 'include'.
2023-08-11 10:11:10 -0400 < Zipheir> Well, it's probably silly to say "for better or worse" because *every* implementation (AFAIK) has 'include'.
2023-08-11 10:19:45 -0400 < mnieper`> sham1: define-library/library are the same as far as the mapping from library names to file names is concerned.  
2023-08-11 10:20:27 -0400 < mnieper`> How a library is stored is a question of the (specific) Scheme system, but not of the Scheme language.
2023-08-11 10:20:54 -0400 < mnieper`> The boundary is pretty much the R6RS library form.
2023-08-11 10:21:13 -0400 < sham1> Right
2023-08-11 10:21:18 -0400 < sham1> So why would define-library be worse
2023-08-11 10:21:19 -0400 < mnieper`> define-library blurs it because include suddenly talks about file names.
2023-08-11 10:21:53 -0400 < mnieper`> And also the cond-expand shenanigans are outside the boundary.
2023-08-11 10:22:24 -0400 < Zipheir> So isn't it 'include' that makes things complicated?
2023-08-11 10:23:15 -0400 < Zipheir> R6RS with 'include' has to solve many of the same problems.
2023-08-11 10:23:52 -0400 < mnieper`> An R6RS library form is self-contained; an R7RS define-library form is, in general, as I see it, just a recipe for the system to assemble an actual library.
2023-08-11 10:24:41 -0400 < mnieper`> Zipheir: It's true that one can write an include form with R6RS's syntax-case. But then one has complete control how the file name is located (on the disk, in the network, ...).
2023-08-11 10:25:36 -0400 < mnieper`> Something much more powerful than cond-expand can also be written using syntax-case.
2023-08-11 10:25:42 -0400 < Zipheir> So perhaps 'include' isn't general enough.
2023-08-11 10:26:18 -0400 < mnieper`> Speaking of piling of features, some of R7RS-small can be stripped away once a procedural macro system is in place.
2023-08-11 10:26:34 -0400 < Zipheir> (Which is not to say that 'include' should be deprecated by any standard; it's not going anywhere.)
2023-08-11 10:26:49 -0400 < mnieper`> Zipheir: R7RS's include (on the file, not library level) is not even well-specified.
2023-08-11 10:26:58 -0400 < Zipheir> Oh, no.
2023-08-11 10:27:12 -0400 < mnieper`> Firstly, it is not clear how the file is looked up on a specific system.
2023-08-11 10:27:18 -0400 < Zipheir> But it's ubiquitous, and standards should try to account for ubiquitous forms.
2023-08-11 10:27:55 -0400 < mnieper`> Secondly, it is unclear how it behaves in conjunction with hygienic identifier renaming.
2023-08-11 10:28:34 -0400 < Zipheir> That's interesting.
2023-08-11 10:29:22 -0400 < mnieper`> If you do (include "bla.scm"), how are the identifiers coloured?
2023-08-11 10:30:19 -0400 < Zipheir> I don't know how the various implementations handle that.
2023-08-11 10:30:29 -0400 < Zipheir> The interactions could be pretty horrendous.
2023-08-11 10:31:02 -0400 < mnieper`> Library-level include does not have this problem.
2023-08-11 10:33:38 -0400 < sham1> Well at least the spec has a non-normative note
2023-08-11 10:33:50 -0400 < sham1> Saying that the inclusion should be relative to the file that's doing the including
2023-08-11 10:33:52 -0400 < Zipheir> mnieper`: Library-level? I haven't seen that.
2023-08-11 10:35:26 -0400 < sham1> As to how the identifiers are coloured, since "read the contents of the files in the specified order as if by repeated applications of `read`, and effectively replace the `include` or `include-ci` expression with a `begin` expression containing what was read from the files."
2023-08-11 10:35:37 -0400 < sham1> So that's probably how you'd colour them. I.e. like everything else
2023-08-11 10:36:29 -0400 < mnieper`> sham1: "Relative to the file..." assumes that the code comes from a file, which it outside the actual scope of the Scheme language.
2023-08-11 10:37:00 -0400 < mnieper`> This is an example of what I meant by not paying attention to the separation of concerns.
2023-08-11 10:37:17 -0400 < mnieper`> Zipheir: library-level: include as part of define-library.
2023-08-11 10:38:08 -0400 < mnieper`> sham1: Source code consists of syntax objects, not datum values. There are identifiers, not symbols.
2023-08-11 10:39:02 -0400 < mnieper`> When you read the file, you have a datum value, but you have to apply (in syntax-case language) datum->syntax on it to get a syntax object you can actually replace th include form with.
2023-08-11 10:39:16 -0400 < mnieper`> Now what is the template identifier of this application of datum->syntax?
2023-08-11 10:39:39 -0400 < Zipheir> mnieper`: Is there a spec for library-level include?
2023-08-11 10:40:18 -0400 < mnieper`> ??? I just mean what's in 5.6.1 of R7RS.
2023-08-11 10:41:21 -0400 < Zipheir> Oh, duh.
2023-08-11 10:41:53 -0400 < Zipheir> I forgot that 'include' is specified in two places in R7RS-small.
2023-08-11 10:44:04 -0400 < sham1> mnieper`: that's for the implementation to figure out, although since the idea is that the included forms effectively replace the `include` syntax application, the natural place would be to use the `include` identifier itself. Just like how the example from R6RS does
2023-08-11 10:52:02 -0400 < mnieper`> sham1: I would have specified include in this way. 
2023-08-11 10:52:02 -0400 < Zipheir> Maybe the best solution is to just keep library-level include.
2023-08-11 10:53:40 -0400 < mnieper`> sham1: But it isn't, so it is implementation-defined at best and not very useful for portable code.
2023-08-11 10:54:23 -0400 < Zipheir> In theory, no, but in practice, include works well enough.
2023-08-11 10:54:46 -0400 < Zipheir> I've used it in pretty much every piece of portable Scheme I've written.
2023-08-11 10:54:56 -0400 < mnieper`> If you write for specific impls, then yes
2023-08-11 10:55:02 -0400 < sham1> This definition is compatible, so it could be clarified in Foundations
2023-08-11 10:55:07 -0400 < sham1> Or maybe as an erratum
2023-08-11 10:55:16 -0400 < Zipheir> Foundations, that was the name.
2023-08-11 10:55:35 -0400 < sham1> We *wouldn't* break compatibility
2023-08-11 10:56:17 -0400 < mnieper`> Zipheir: do you use non-define-library include often?
2023-08-11 10:56:37 -0400 < Zipheir> mnieper`: Not at all, AFAIR.
2023-08-11 10:57:24 -0400 < sham1> Yeah, I think that Marc agrees that include works in define-library, the discussion is about include as a separate piece of syntax
2023-08-11 10:57:39 -0400 < Zipheir> Right.
2023-08-11 10:57:40 -0400 < mnieper`> yep
2023-08-11 10:58:15 -0400 < mnieper`> The other form can probably be deprecated and few would notice.
2023-08-11 10:58:47 -0400 < mnieper`> If any.
2023-08-11 11:00:13 -0400 < gwatt> I actually use the non-library include.
2023-08-11 11:01:40 -0400 < mnieper`> On which system?
2023-08-11 11:01:51 -0400 < mnieper`> And for which purpose?
2023-08-11 11:02:37 -0400 < Zipheir> I have used it on CHICKEN, but only because that impl. seems to lack a good way to use private modules without installing them.
2023-08-11 11:04:13 -0400 < Zipheir> (My solution is to define a module [library] in foo-module.scm and then 'include' it in my main program source.)
2023-08-11 11:08:31 -0400 < mnieper`> Zipheir: For R7RS-large, I suggest Chez Scheme-style modules.
2023-08-11 11:14:59 -0400 < gwatt> mnieper`: For chez, and to avoid using a library so as to not pollute the the library namespace
2023-08-11 11:16:33 -0400 < Zipheir> That's the annoying thing. "Private" libraries are extremely useful and should be easy to use in all implementations.
2023-08-11 11:17:29 -0400 < mnieper`> gwatt: Use Chez's modules instead.
2023-08-11 11:17:32 -0400 < Zipheir> e.g. I want to be able to break a program up into a small main file and a number of libraries and to have that work without putting those libraries into the implementation's global library namespace.
2023-08-11 11:18:53 -0400 < mnieper`> Zipheir: (zipheir foo ...) is your personal library namespace. You can put whatever you want there.
2023-08-11 11:19:01 -0400 < mnieper`> A file on the disk is no more private.
2023-08-11 11:19:35 -0400 < Zipheir> True.
2023-08-11 11:19:52 -0400 < gwatt> mnieper`: I still need the module to be in a separate file as it's shared by a couple of things and I can't invoke load
2023-08-11 11:22:22 -0400 < Zipheir> gwatt: 'import' doesn't work?
2023-08-11 11:30:03 -0400 < mnieper`> You can export the module from some private library.
2023-08-11 11:31:10 -0400 < gwatt> Zipheir: importing modules doesn't do any kind of file resolution. The module name is a lexically bound identifier, so the module has to exist in scope already
2023-08-11 11:32:03 -0400 < gwatt> mnieper`: but then I'm back to having a library, which I don't want
2023-08-11 11:33:37 -0400 < Zipheir> gwatt: OK.
2023-08-11 11:33:49 -0400 < Zipheir> I guess I don't understand the distinction between modules and libraries in Chez.
2023-08-11 11:37:04 -0400 < mnieper`> Zipheir: a module is a library at the language level.
2023-08-11 11:37:21 -0400 < mnieper`> Instead of a library name, you have an identifier bound to the module.
2023-08-11 11:37:25 -0400 < gwatt> mnieper`: This is a very specific use-case, for chez-exe. I don't want to pollute the library namespace, because if someone else wants to have that same library name, it will break. I can probably get away with making a ludicrous library name and saying no-one is allowed to use it, but "include" works just fine
2023-08-11 11:38:14 -0400 < mnieper`> gwatt: Just at an UUID to your library name and you are done.
2023-08-11 11:38:19 -0400 < mnieper`> s/at/add
2023-08-11 11:38:29 -0400 < mnieper`> s/an/a
2023-08-11 11:38:43 -0400 < gwatt> I also don't want a library because I want to be able to do "scheme --program compile-chez-program.ss -- compile-chez-program.ss" to build itself, which will load the library _before_ turning on generate-wpo-files 
2023-08-11 11:41:02 -0400 < gwatt> Zipheir: I believe since modules are lexically scoped, you can generate a module with a macro, but you cannot generate a library with a macro
2023-08-11 11:41:11 -0400 < Zipheir> Ah, interesting.
2023-08-11 11:42:30 -0400 < mnieper`> gwatt: You can always reload a library. What's the purpose of chez-exe?
2023-08-11 11:43:33 -0400 < gwatt> to produce a self-contained executable that you can distribute
2023-08-11 11:44:39 -0400 < mnieper`> On Windows?
2023-08-11 11:44:49 -0400 < gwatt> on anything chez-scheme supports
2023-08-11 11:44:58 -0400 < gwatt> windows is one of the supported targets
2023-08-11 11:45:24 -0400 < mnieper`> For Unix, I compile everything into a #!/... file.
2023-08-11 11:46:55 -0400 < gwatt> And that requires the target system has chez-scheme installed at all, and is a compatible version to the compiled program file. chez-exe completely sidesteps those requirements
2023-08-11 11:47:41 -0400 < mnieper`> gwatt: Sure, but I don't want to distribute the binary with all my files.
2023-08-11 11:47:56 -0400 < gwatt> that's fair. it is big.
2023-08-11 11:48:02 -0400 < mnieper`> I don't distribute glibc either.
2023-08-11 11:50:58 -0400 < gwatt> There typically aren't the same versioning issues there though. If you have a program compiled with chez scheme 9.5, it will not run on anything except 9.5. glibc version compatibility is typically much more permissive
2023-08-11 11:59:04 -0400 < mnieper`> If this is a problem and your target system doesn't handle versioning of such executables well, then you can always install your private chezscheme (as a separate file).  We have tar to package two files into one for distribution.
2023-08-11 12:00:33 -0400 < ober> will chez or chicken allow for fully static binaries?
2023-08-11 12:01:57 -0400 < mnieper`> What do you mean by "fully static"?
2023-08-11 12:02:14 -0400 < mnieper`> And what is the goal?
2023-08-11 12:14:11 -0400 < mnieper`> ... or use case?
2023-08-11 12:21:34 -0400 < mnieper`> weinholt: Speaking of versioning of chezscheme. Could you modify the Debian package so that chezscheme (and petite) is installed under chezscheme.X.Y.Z (or similar) with symbolic links as it is done with shared objects/libtool libraries?
2023-08-11 12:21:34 -0400 < ober> as in generating a binary with zero dynamic libs linked.
2023-08-11 12:23:07 -0400 < mnieper`> ober: Chez does not generate an ELF executable (and does not use the systems dynamic loader). Instead it uses its own loader.
2023-08-11 12:23:23 -0400 < ober> ahh ok
2023-08-11 12:23:38 -0400 < mnieper`> There are no dynamic libs in the narrow sense, but the mechanism is the same.
2023-08-11 12:23:59 -0400 < mnieper`> Someone else has to speak for CHICKEN.
2023-08-11 12:24:01 -0400 < ober> so you need the loader and your vm?
2023-08-11 12:24:13 -0400 < ober> </sbcl terms>
2023-08-11 12:24:35 -0400 < mnieper`> ober: Every system will have its runtime (which you may mean by VM).
2023-08-11 12:25:20 -0400 < ober> sure, but say helloworld.scm -> helloworld elf binary which ships with the runtime
2023-08-11 12:26:10 -0400 < ober> for purposes of distribution of a single binary vs a runtime +
2023-08-11 12:26:27 -0400 < mnieper`> For the official Chez way (not chez-exe) it is: helloworld.ss -> helloworld (non-elf!) binary, which needs Chez's loader (/usr/bin/chezscheme).
2023-08-11 12:27:14 -0400 < ober> gotcha
2023-08-11 12:27:33 -0400 < mnieper`> This is the same as for dynamically linked ELF binaries.
2023-08-11 12:27:49 -0400 < mnieper`> In principle.
2023-08-11 12:28:13 -0400 < mnieper`> $ file /usr/bin/ls
2023-08-11 12:28:13 -0400 < mnieper`> /usr/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6e45645c07d892b7b01c04b0522cf5b0e10c9e52, for GNU/Linux 3.2.0, stripped
2023-08-11 12:28:13 -0400 < mnieper`>  
2023-08-11 12:28:21 -0400 < mnieper`> (output from my system)
2023-08-11 12:28:31 -0400 < mnieper`> See the reference to the interpreter.
2023-08-11 12:29:05 -0400 < mnieper`> The Linux kernel doesn't handle the dynamic loading of the shared libraries.
--- Day changed Sat Aug 12 2023
2023-08-12 01:06:03 -0400 -!- Netsplit *.net <-> *.split quits: motersen, madage, mirai, ec, adanwan_
2023-08-12 01:07:25 -0400 -!- Netsplit over, joins: motersen
2023-08-12 09:40:32 -0400 -!- ozspt is now known as hiro_protagonist
2023-08-12 12:11:55 -0400 < haugh> Hello friends. I've been working with multi-value combinators, that is, functions which accept multiple funtions which return disparate and unknown numbers of values. My documentation is very clunky.
2023-08-12 12:13:14 -0400 < haugh> I've read R7RS, TSPL4, and the Guile manual, but my notes on multiple values are scant or inconsistent. What word would you use to describe a funciton with an as-yet-unknown number of return values?
2023-08-12 12:17:58 -0400 < leah2> badly designed? ;)
2023-08-12 12:18:28 -0400 < Zipheir> haugh: Co-variadic, I guess.
2023-08-12 12:19:22 -0400 < leah2> oh, if it depends on the number of arguments
2023-08-12 12:20:38 -0400 < Zipheir> The usual term for a procedure's number of return values is its coarity, so covariadic sounds right (if horrible) to me.
2023-08-12 12:22:10 -0400 < Zipheir> haugh: Have you seen https://srfi.schemers.org/srfi-210/srfi-210.html ?
2023-08-12 13:10:10 -0400 < haugh> Zipheir, thanks much, this is pointing me in exactly the right direction
2023-08-12 13:30:33 -0400 < mnieper> I begin to endorse ML's decision to only have functions that accept one value and return one value.
2023-08-12 13:45:42 -0400 < Zipheir> haugh: Great.
2023-08-12 13:46:24 -0400 < sham1> ML's decision is nice in some way, but it wouldn't work for Lisps
2023-08-12 13:46:56 -0400 < Zipheir> mnieper: That's perfectly fine for statically-typed languages, but I've come to think that multiple values are idiomatic in dynamic typing.
2023-08-12 13:47:06 -0400 < sham1> You'd either have to do currying, which wouldn't be nice ((((foo bar) baz) quux) quinx)
2023-08-12 13:47:20 -0400 < sham1> Or you'll have to cons up an explicit argument list, which isn't all that fun either
2023-08-12 13:48:00 -0400 < Zipheir> And then you'd have to return a list or vector.
2023-08-12 13:48:26 -0400 < sham1> Well yeah, but you'd already be probably returning these kinds of container types if you're doing stuff like Maybe or Either
2023-08-12 13:48:45 -0400 < Zipheir> mnieper: I'm surprised, since you've done so much work on making multiple values easier to use in Scheme.
2023-08-12 13:49:27 -0400 < Zipheir> sham1: Yes. I proposed a bunch of functions returning Maybe/Either for some SRFIs, but mnieper talked me out of it.
2023-08-12 13:50:56 -0400 < Zipheir> You can always replace those containers with CPS, and I reluctantly believe that CPS is more idiomatic in Scheme (at least unless or until Maybe/Either are made part of the language).
2023-08-12 13:51:50 -0400 < sham1> Eh, I personally don't really like the CPS approach either. Like I understand why they're appealing and why they're idiomatic, but it's also just weird to me
2023-08-12 13:51:59 -0400 < sham1> It's like I'm doing the compiler's job for it
2023-08-12 13:52:12 -0400 < sham1> I'm having to explicitly do join points
2023-08-12 13:53:02 -0400 < Zipheir> I suppose.
2023-08-12 13:53:37 -0400 < Zipheir> sham1: Do you prefer returning a Maybe to the (proc ... failure) approach?
2023-08-12 13:53:58 -0400 < sham1> They feel a tad too primitive to me. So yeah, I'd probably prefer a maybe, or multiple values where the first one indicates success or some such
2023-08-12 13:54:07 -0400 < mnieper> Scheme has multiple arguments, that's why I am in favour of multiple values.
2023-08-12 13:55:21 -0400 < mnieper> If I were to design Scheme from scratch, I would remove multiple arguments and values.
2023-08-12 13:55:21 -0400 < mnieper> It does work with Lisp because macros.
2023-08-12 13:55:53 -0400 < Zipheir> sham1: OK. My complaint about CPS was in (more complicated) cases where the caller is passed a procedure that *must* be tail-called. (If the call isn't in tail position, the results are unpredictable.)
2023-08-12 13:56:16 -0400 < mnieper> (f a b c) would be expanded to (f [a b c]) where [...] is pseudo-code for a tuple constructor.
2023-08-12 13:56:19 -0400 < sham1> Well yeah, that's also a hurdle
2023-08-12 13:56:40 -0400 < sham1> And well, you can absolutely have a macroless lisp
2023-08-12 13:56:57 -0400 < mnieper> It will be up to the compiler to unbox; this is well-studied for ML compilers.
2023-08-12 13:57:00 -0400 < Zipheir> mnieper: That could be nice.
2023-08-12 13:57:42 -0400 < sham1> Having a nice way to create thunks would alleviate the some of the problems that you'd need macros for since you could define your conds and like in terms of thunks
2023-08-12 13:57:45 -0400 < Zipheir> And, arguably, multiple return values aren't necessary or convenient if you have a good pattern-matching macro.
2023-08-12 13:58:18 -0400 < sham1> There's some syntax you mightn't be able to define, but for most things it'd be fine. Just like how syntax-rules is just fine for most things
2023-08-12 13:58:31 -0400  * dpk looks to see if she wrote down her ideas for a fexpr-based one-argument one-return-value Lisp somewhere … seems not
2023-08-12 13:58:45 -0400 < Zipheir> fexprs! Always the promises.
2023-08-12 13:58:55 -0400 < sham1> They seem to never go away
2023-08-12 13:58:59 -0400 < mnieper> Zipheir: You can use SRFI 226 to detect whether a procedure has been tail-called or not.
2023-08-12 13:59:11 -0400 < Zipheir> sham1: They're like the microkernels of Lisp. :)
2023-08-12 13:59:17 -0400 < dpk> well, the idea of that Lisp was to explore the fundamentals of computation regardless of actual efficiently on a Von Neumann machine
2023-08-12 13:59:24 -0400 < dpk> *efficiency
2023-08-12 14:00:07 -0400 < Zipheir> mnieper: Yes, but do we want to make e.g. SRFI 146 depend on SRFI 226 to ensure that mapping-search is used correctly?
2023-08-12 14:00:20 -0400 < Zipheir> dpk: I'm just teasing.
2023-08-12 14:00:23 -0400 < dpk> if you don’t care about efficiency, fexprs are the natural choice of primitive means of combination
2023-08-12 14:02:31 -0400 < sham1> Zipheir: but I like microkernels
2023-08-12 14:03:12 -0400 < mnieper> dpk: Not necessarily when you also want to reason easily about what your code does.
2023-08-12 14:03:54 -0400 < mnieper> Zipheir: I hope that the next Scheme standard will include continuation marks.
2023-08-12 14:04:46 -0400 < mnieper> In an R7RS-small context where we have UB everywhere, it won't be necessary to add such test to, say, SRFI 146.
2023-08-12 14:05:50 -0400 < mnieper> Alternatively, change the API by making the continuation procedures true continuations and.
2023-08-12 14:07:42 -0400 < Zipheir> mnieper: I like the redesign (fxmapping-alter) that we did for SRFI 224 more, since it doesn't require any tail-calls. I'm afraid it's too complicated for anyone to use, though.
2023-08-12 14:08:23 -0400 < mnieper> API with true continuations: as in https://paste.debian.net/plain/1288745
2023-08-12 14:08:34 -0400 < mnieper> Zipheir: I have to reread that part of SRFI 224.
2023-08-12 14:09:07 -0400 < haugh> mnieper, is there a dependency graph for your multi-values SRFIs? I don't need a lot of detail, I'm just trying to see the big picture
2023-08-12 14:11:03 -0400 < mnieper> haugh: I think there is only MV boxes (SRFI 195?) and SRFI 210.
2023-08-12 14:11:15 -0400 < Zipheir> mnieper: That's a clever call/cc trick.
2023-08-12 14:11:42 -0400 < haugh> Yes it's 195. Thanks.
2023-08-12 14:13:27 -0400 < mnieper> Zipheir: Now that I refreshed my knowledge, I again congratulate us for our discussions on fxmapping-alter :)
2023-08-12 14:14:08 -0400 < mnieper> The first example (with the additional boolean value) is a good use case.
2023-08-12 14:16:25 -0400 < mnieper> Committee C may want to see that all the other success/failure continuation procedures in other SRFIs are updated accordingly.
2023-08-12 14:16:52 -0400 < Zipheir> That would be nice.
2023-08-12 14:35:16 -0400 < acdw> what's an fexpr
2023-08-12 14:38:08 -0400 < mnieper> acdw: a (far too) simplified explanation:
2023-08-12 14:38:23 -0400 < mnieper> A "procedure" that receives its arguments unevaluated.
2023-08-12 14:39:03 -0400 < mnieper> A macro is a particular type of fexpr, namely one that tail-calls eval. 
2023-08-12 14:39:12 -0400 < acdw> ohhhh
2023-08-12 14:39:49 -0400 < mnieper> (A Scheme macro just "returns" an expression and the Scheme system does the call to eval, so to speak.)
2023-08-12 14:39:54 -0400 < acdw> so guixs g expressions are kind of a pun of that? I know very little about gexprs or fexprs but from what little I've read 
2023-08-12 14:40:57 -0400 < mnieper> I think it is a pun on s-expression.
2023-08-12 14:40:59 -0400 < acdw> so like an unrevaled macro?
2023-08-12 14:41:00 -0400 < acdw> oh lol
2023-08-12 14:41:58 -0400 < mnieper> acdw: I am goint to give you an example in a minute.
2023-08-12 14:42:05 -0400 < acdw> thanks!
2023-08-12 14:42:16 -0400 < acdw> . I'm also reading the wiki article 
2023-08-12 14:49:35 -0400 < mnieper> Some code: https://paste.debian.net/plain/1288752
2023-08-12 14:49:52 -0400 < mnieper> The first definition is a traditional Scheme macro. 
2023-08-12 14:50:16 -0400 < mnieper> (implementing part of the form of SRFI 239.)
2023-08-12 14:50:29 -0400 < mnieper> (https://srfi.schemers.org/srfi-239/)
2023-08-12 14:50:57 -0400 < mnieper> You effectively write a compiler/transpiler for a mini-language whose output is Scheme code.
2023-08-12 14:51:09 -0400 < mnieper> The second definition is a hypothetical Scheme fexpr.
2023-08-12 14:52:05 -0400 < mnieper> Here, you are very explicit. It is like writing an interpreter.
2023-08-12 14:52:32 -0400 < mnieper> Writing an interpreter is usually simpler than writing a compiler.
2023-08-12 15:09:50 -0400 < acdw> hmmm
2023-08-12 15:10:20 -0400 < acdw> sadly those are both a bit over my head lol. but thank you! I'm sure that as I get more into scheme macros and such I'll run into some understanding 
2023-08-12 15:11:00 -0400 < acdw> syntax-case is the one that is more powerful than syntax-rules but not standardized right?
2023-08-12 15:11:13 -0400 < sham1> It's standardised in R6RS
2023-08-12 15:11:19 -0400 < sham1> And also will be standardised in R7RS-large
2023-08-12 15:12:15 -0400 < acdw> ohhh nice 
2023-08-12 15:28:16 -0400 < mnieper> I wrote the first macro with syntax-case on purpose so that it is procedural as the fexpr.
2023-08-12 15:34:48 -0400 < Zipheir> So what's the big deal? It seems like you can have fexprs in Scheme trivially with syntax-case (or, indeed, with any of the old unhygienic procedural systems).
2023-08-12 15:40:18 -0400 < mnieper> No, you can't.
2023-08-12 15:40:23 -0400 < mnieper> The output of a macro is implicitly evaluated.
2023-08-12 15:40:31 -0400 < Zipheir> Oh, right.
2023-08-12 15:41:00 -0400 < Zipheir> Correction: You can have it trivially if you chop of eval and just do expansion. :)
2023-08-12 15:41:06 -0400 < Zipheir> *chop off
2023-08-12 15:41:27 -0400 < Zipheir> And eval when explicitly used.
2023-08-12 15:41:31 -0400 < ecraven> hm.. so r7rs-large will have syntax-case, and not sc/rsc/er/ir or is that all still open for debate (as in under serious consideration)?
2023-08-12 15:41:34 -0400 < mnieper> What do you mean?
2023-08-12 15:42:01 -0400 < mnieper> By changing the Scheme semantics?
2023-08-12 15:43:09 -0400 < sham1> ecraven: this was voted on... year or so ago
2023-08-12 15:44:14 -0400 < Zipheir> mnieper: Yes. I'm not being serious.
2023-08-12 15:44:50 -0400 < mnieper> ecraven: All the alternatives have serious deficiencies.
2023-08-12 15:45:01 -0400 < Zipheir> ecraven: IIRC implicit/explicit rewrite systems lost out by a few votes.
2023-08-12 15:45:25 -0400 < Zipheir> Were syntactic closures on the ballot? I don't remember.
2023-08-12 15:45:37 -0400 < ecraven> a pity :-/ I still like all the others more.. but maybe I just need to bite the bullet and get to know syntax-case better
2023-08-12 15:46:38 -0400 < mnieper> No. But they are also not powerful enough and do not play well with syntax-rules.
2023-08-12 15:47:05 -0400 < mnieper> (was answer to Zipheir)
2023-08-12 15:47:37 -0400 < sham1> ecraven: well just because one was "blessed" as the standard macro system doesn't mean that others won't or can't exist
2023-08-12 15:47:49 -0400 < sham1> Of course there are some efficiency concerns, but w/e
2023-08-12 15:48:41 -0400 < mnieper> ecraven: You should feel happy about the outcome. See SRFI why the others do not allow to write sound unhygienic macros.
2023-08-12 15:48:57 -0400 < mnieper> SRFI 211, I mean.
2023-08-12 15:49:08 -0400 < ecraven> I'll read that, thanks
2023-08-12 15:49:25 -0400 < Zipheir> mnieper: Thanks.
2023-08-12 15:49:28 -0400 < sham1> I mean, I personally do like the relative elegance of IR macros but I understand why syntax-case is better and I voted accordingly 
2023-08-12 15:49:53 -0400 < sham1> IR macros seem simple, kinda like the traditional Lisp macros but with hygiene built in
2023-08-12 15:50:08 -0400 < Zipheir> sham1: Have you heard of this new-fangled thing called syntax-rules?
2023-08-12 15:50:42 -0400 < sham1> Well clearly syntax-rules can't do all the things you need procedural macros for. Otherwise we wouldn't have this discussion now would we ;)
2023-08-12 15:51:12 -0400 < Zipheir> OK. I guess there is a little niche of macros that can't be done with syntax-rules and that are a bit clumsy with syntax-case.
2023-08-12 15:51:41 -0400 < sham1> And we also wouldn't have some unnamed CL people historically saying that Scheme macros are deficient 
2023-08-12 15:52:24 -0400 < mnieper> Zipheir: what is clumsy about syntax-case? 
2023-08-12 15:52:51 -0400 < mnieper> Syntax-rules are just a very thin layer on top.
2023-08-12 15:52:59 -0400 < Zipheir> mnieper: I meant that there may be some macros which make IR look nice (compared with syntax-case or syntax-rules).
2023-08-12 15:53:10 -0400 < Zipheir> But usually IR doesn't seem much better.
2023-08-12 15:53:18 -0400 < mnieper> No, there aren't.
2023-08-12 15:53:55 -0400 < mnieper> Challenge my claim by giving an example.
2023-08-12 15:54:11 -0400 < Zipheir> Hmm.
2023-08-12 15:54:29 -0400 < Zipheir> I've only used IR in CHICKEN to get around their lack of syntax-case.
2023-08-12 15:55:53 -0400 < mnieper> Let us hope that the CHICKEN people change their opinion.
2023-08-12 15:57:13 -0400 < sham1> I'd stress that IR especially seems better for example if one is familiar with DEFMACRO specifically 
2023-08-12 15:57:34 -0400 < sham1> Because that's basically what it is, DEFMACRO with implicit hygiene which you'll have to explicitly opt out of
2023-08-12 15:57:37 -0400 < Zipheir> Maybe sham1 can give a nice example. All the IR macros I've written look like garbled syntax-case.
2023-08-12 15:58:03 -0400 < sham1> I'm not really arguing this position as if I personally believe it, I prefer syntax-case 
2023-08-12 15:59:21 -0400 < Zipheir> At first syntax-case seemed very complicated, but I've come around to it.
2023-08-12 15:59:33 -0400 < mnieper> sham1: If one really needs to caddaddr their macros, one can easily provide this with syntax-case.
2023-08-12 16:01:29 -0400 < mnieper> Just define a procedure unwrap* that takes a syntax object and returns a fully unwrapped version (only wraps at the leaves)
2023-08-12 16:03:01 -0400 < sham1> Right. And I do recall that sometimes you'd just use something like TRIVIA when doing CL macros (TRIVIA being basically *the* pattern matching macro for CL stuff) but at that point you'll just be doing syntax-case without the hygiene
2023-08-12 16:05:02 -0400 < mnieper> Yes.
2023-08-12 16:05:19 -0400 < mnieper> Use a macro in Chibi syntactically wrongly and the error messages you get (or the lack thereof) are a good indication for what happens with cddaddaring.
2023-08-12 16:07:01 -0400 < Zipheir> Oof, yes. I've gotten many mysterious 'car' and 'cdr' error messages in chibi.
2023-08-12 16:07:49 -0400 < Zipheir> (And sometimes from vanilla procedures, not just from macros.)
2023-08-12 16:08:13 -0400 < acdw> cdadadaddaddaddadadadddddadadddaddadadr
2023-08-12 16:08:15 -0400 < Zipheir> Usually it's due to the budget opt-args handling. But anyway.
2023-08-12 16:08:41 -0400 < acdw> I've got some weird errors from chicken.  but then I'm trying to do weird stuff w chicken
2023-08-12 16:09:43 -0400 < sham1> When I was trying to reproduce the `(equal? '#1=(#1# . #1#) '#2=(#2# . #2#))` in various Schemes, Chicken of course doesn't support datum labels and the errors it spits out are interesting to say the least
2023-08-12 16:10:47 -0400 < samplet> I’ve always found it kind of muddled to have two ways to do templating: ‘quasiquote’ and ‘syntax’.  It works in practice, but it feels like duplication in the design space.
2023-08-12 16:11:10 -0400 < Zipheir> That's an interesting way to look at it.
2023-08-12 16:11:36 -0400 < mnieper> They are constructors of different objects.
2023-08-12 16:12:23 -0400 < mnieper> One constructs datums, the other syntax objects.
2023-08-12 16:12:53 -0400 < samplet> Are the objects so different that they need completely different constructors?
2023-08-12 16:13:00 -0400 < sham1> I think the "issue" here is that in some way the difference between syntax objects and datum feels arbitrary, yeah
2023-08-12 16:13:16 -0400 < mnieper> With hygiene it is not.
2023-08-12 16:13:37 -0400 < mnieper> That's the difference between Scheme and CL.
2023-08-12 16:13:37 -0400 < Zipheir> Right.
2023-08-12 16:15:24 -0400 < Zipheir> mnieper: Vaguely related: do you know of any work treating "the type of syntax objects" as a monad?
2023-08-12 16:15:44 -0400 < samplet> I’m not saying that they should be unified.  Just that they should have the same “style”.  (Pick either splicing and ‘map’ or ellipses, i.e.)
2023-08-12 16:15:44 -0400 < mnieper`> No.
2023-08-12 16:15:49 -0400 < Zipheir> Hmm.
2023-08-12 16:16:01 -0400 < sham1> The difference is meaningful, BUT it can also seem weird if you're not used to it. Basically you're duplicating quote, quasiquote, unquote, and unquote-splicing and basically just adding those same things but with syntax instead. It makes sense but at first glance I understand why it'd feel strange
2023-08-12 16:16:06 -0400 < mnieper`> Zipheir: Why should there be a relation to monads?
2023-08-12 16:17:51 -0400 < mnieper`> samplet: See SRFI 241 for an extended quasiquote, which also has ....
2023-08-12 16:18:07 -0400 < Zipheir> (syntax ...) has always *felt* very much like monadic pure to me.
2023-08-12 16:18:21 -0400 < sham1> But then you'd either need bind or join
2023-08-12 16:18:40 -0400 < Zipheir> Other people have commented on the similarity to me, but I haven't worked out anything seriously.
2023-08-12 16:18:41 -0400 < mnieper`> sham1: #, and #,@ are not absolutely necessary and could be replaced by , and ,@.
2023-08-12 16:19:01 -0400 < mnieper`> But then it is less convenient to write macros whose output contains , and ,@
2023-08-12 16:19:27 -0400 < Zipheir> sham1: I'm not sure how hygiene would interact with a join operation.
2023-08-12 16:19:53 -0400 < sham1> I'm more just thinking about what the join operator would be
2023-08-12 16:20:13 -0400 < mnieper`> There is an important difference between #' and ' in that #' checks whether the identifiers in its form are bound to pattern variables while ' is dumb and just copies symbols.
2023-08-12 16:20:26 -0400 < sham1> I can't really think of any obvious definition
2023-08-12 16:21:01 -0400 < mnieper`> We want this behaviour of #' so that we have syntax-rules-like semantics; we can't change the behaviour of ' because of compatiblity.
2023-08-12 16:21:46 -0400 < Zipheir> sham1: I don't know either. It seems like an interesting parallel, though.
2023-08-12 16:21:53 -0400 < mnieper`> Zipheir: (syntax ...) is syntax (no pun intended); a "pure" should be a procedure.
2023-08-12 16:22:46 -0400 < Zipheir> Well, of course.
2023-08-12 16:23:25 -0400 < samplet> mnieper`: Oh cool!  I didn’t know about SRFI 241.  That’s getting at what I’m talking about, for sure.
2023-08-12 16:23:46 -0400 < Zipheir> I'm thinking of these as arrows involving the type of syntax objects, which is probably foolish as I don't understand the category.
2023-08-12 16:25:45 -0400 < mnieper`> What does "these" refer to?
2023-08-12 16:26:18 -0400 < Zipheir> 'syntax' and the notional join on syntax objects.
2023-08-12 16:27:15 -0400 < mnieper`> Changing the topic: what I don't like about IRC is that messages become lost on every reconnection (I am currently sitting in a train and it happens regularly).  Couldn't we move to some other protocol (Matrix??? - don't know much about it)?
2023-08-12 16:28:11 -0400 < Zipheir> This is a topic I've been meaning to bring up, with Libera's Matrix bridges shutting down.
2023-08-12 16:28:46 -0400 < Zipheir> It was previously possible to connect to #scheme through Matrix, although I don't know what Matrix rooms were bridged with #scheme or who maintains them.
2023-08-12 16:30:09 -0400 < Zipheir> If you're losing messages, there is the channel log, of course. (See /TOPIC)
2023-08-12 16:30:46 -0400 < mnieper`> Yes, but this is rather inconvenient.
2023-08-12 16:31:04 -0400 < sham1> I recommend getting a bouncer going
2023-08-12 16:31:52 -0400 < mnieper`> Another annoyance is that one cannot be logged in from two places (notebook, mobile, work, ...) at the same time.
2023-08-12 16:32:25 -0400 < Zipheir> Does Matrix have a solution to that?
2023-08-12 16:32:45 -0400 < Zipheir> (It does far more than I can remember. The protocol spec is enormous.)
2023-08-12 16:33:20 -0400 < mnieper`> A Telegram group would also work. And would be very convenient.
2023-08-12 16:35:02 -0400 < Zipheir> Of course, I have no problem with more Scheme chat groups. The challenge is bridging them.
2023-08-12 16:35:29 -0400 < sham1> You can be logged from multiple devices in Matrxi
2023-08-12 16:35:32 -0400 < sham1> matrix*
2023-08-12 16:35:33 -0400 < Zipheir> OK.
2023-08-12 16:36:18 -0400 < Zipheir> Bridges can really suck, especially when there's a flamewar going on across protocols.
2023-08-12 16:37:07 -0400 < Zipheir> Still, I'm open to trying to bridge a Matrix channel here.
2023-08-12 16:37:25 -0400 < Zipheir> (If people want to try that.)
2023-08-12 16:38:30 -0400 < mnieper`> Or completely move on to a newer protocol.
2023-08-12 16:40:24 -0400 < Zipheir> Oh, I'm not willing to *move* the channel when we regularly have hundreds of nicks here. #scheme's got a 20-year history on IRC.
2023-08-12 16:40:54 -0400 < Zipheir> (I also prefer the IRC protocol to these newer behemoths.)
2023-08-12 16:42:44 -0400 < aeth> losing messages on reconnect is a client issue
2023-08-12 16:43:33 -0400 < aeth> though in 2023, networks should probably just integrate a bouncer because it can't cost that much to store and host
2023-08-12 16:43:54 -0400 < aeth> I think they mostly don't because of privacy and regulatory issues. And because of inertia (using ancient ircd's architectured for a certain way of doing things 15 years ago)
2023-08-12 16:44:28 -0400 < aeth> Integrated bouncers could also mean that a channel could invite a LogServ just like it can invite a ChanServ. In this case, to make it clear that it's being logged in public.
2023-08-12 16:50:07 -0400 < Zipheir> aeth: Exactly. I don't think this is a protocol issue, but rather a choice that networks make.
2023-08-12 16:50:31 -0400 < ecraven> mnieper: sorry if these are stupid questions, feel free to ignore.. so my understanding is that the critique of ER is in notes 1 to 4 towards the end. my (possibly entirely incorrect) understanding of those points is that ER (and also SC) only allow *two* (usage/global and "other") environments, whereas you would need *three* to correctly write unhygienic macros. is that correct?
2023-08-12 16:52:00 -0400 < aeth> Zipheir: the problem is that anyone who can make a better ircd instead chooses to take a few hundred million in VC funding and launches fully proprietary chat app #432
2023-08-12 16:52:03 -0400 < mnieper> How can I not lose messages when I am offline for a few minutes?
2023-08-12 16:52:36 -0400 < aeth> Zipheir: with the exception of... maybe just irccloud?
2023-08-12 16:52:41 -0400 < aeth> there's probably 2-3 in reality
2023-08-12 16:53:14 -0400 < mnieper> ecraven: infinitely many
2023-08-12 16:53:40 -0400 < mnieper> For each (nested) macro expansion one.
2023-08-12 16:54:31 -0400 < Zipheir> aeth: It's rather surprising that that didn't happen with Matrix.
2023-08-12 16:54:49 -0400 < Zipheir> Although it's rapidly becoming a single-implementation (Element) protocol.
2023-08-12 16:55:07 -0400 < mnieper> SC works better than ER (it does work for some unhygienic macros) but the resulting macros don't work with syntax-rules macros.
2023-08-12 16:57:15 -0400 < haugh> Zipheir, no idea your experience level but you can still bridge libera.chat/matrix.org via a "plumbed room".
2023-08-12 16:57:40 -0400 < ecraven> mnieper: so there *is* in fact no alernative to syntax-case?
2023-08-12 16:58:19 -0400 < mnieper> But already R6RS's define-record-type cannot be implemented with SC.
2023-08-12 16:58:25 -0400 < ecraven> mnieper: use a "bouncer" (a proxy that is always online) :D [now of course if *that* goes offline, you have the same problem]
2023-08-12 16:59:41 -0400 < Zipheir> haugh: That's what I meant. I haven't heard from anyone who wants to use #scheme through Matrix, though.
2023-08-12 16:59:42 -0400 < ecraven> mnieper: thanks for explaining this. have you written down an explanation of *why* SC and syntax-rules don't work together well?
2023-08-12 16:59:57 -0400 < haugh> I'm using a hosted bouncer, the laziest possible IRC solution afaik, and I'm still frustrated by complexity
2023-08-12 17:00:11 -0400 < haugh> I was very happily bridged through matrix.org until the happening
2023-08-12 17:00:24 -0400 < Zipheir> Ah, OK.
2023-08-12 17:00:25 -0400 < ecraven> I run znc on a server, set it up once, has worked fine every since. that however assumes you have some always-on server
2023-08-12 17:03:32 -0400 < Zipheir> haugh: I'll investigate how difficult it would be to maintain a Matrix room bridged to IRC.
2023-08-12 17:04:27 -0400 < Zipheir> haugh: If I can moderate both without juggling clients, that would be best. Otherwise we'd need a Matrix op.
2023-08-12 17:05:22 -0400 < mnieper> That you need a bouncer and your own server and that a bouncer lies about your online status tells me that IRC is not the right tool for the job...
2023-08-12 17:06:03 -0400 < mnieper> ecraven: I don't think I have written it up outside some mailing list remark.
2023-08-12 17:06:26 -0400 < haugh> Zipheir I sincerely appreciate it but don't stress; regardless it looks like I'll be stuck using both for the near future 
2023-08-12 17:07:11 -0400 < mnieper> [21:59]  mnieper: ecraven: Racket's macro system would be an alternative.
2023-08-12 17:07:56 -0400 < mnieper> [21:59]  mnieper: But then we would lose compatibility with RnRS.
2023-08-12 17:08:07 -0400 < mnieper> [22:00]  mnieper: And then one can ask the question why not use Racket directly.
2023-08-12 17:08:10 -0400 < Zipheir> I can't and won't be on IRC at all times of the day, so I miss some messages when I'm AFK; c'est la vie.
2023-08-12 17:08:52 -0400 < aeth> I'm in close to 30 channels, of course I'll miss most messages unless I'm directly mentioned in a way that my client recognizes (so, "aeth: "?)
2023-08-12 17:08:59 -0400 < haugh> yes I've heard arguments about the ephemeral nature of the IRC culture but personally I really like the option to scroll up for context
2023-08-12 17:09:08 -0400 < mnieper> ecraven: so there were not really any alternatives on the R7RS-large poll
2023-08-12 17:09:17 -0400 < dpk> simply crowning Racket as R7RS Large would save us a lot of effort!
2023-08-12 17:09:57 -0400 < Zipheir> But of course I'm always logging, so I can see the context if need be.
2023-08-12 17:10:01 -0400 < aeth> but I thought it was r6rs-ginormous?
2023-08-12 17:10:11 -0400 < dpk> the existence of #!r6rs and the R7RS small #lang in Racket means we technically don’t break any WG2 charter requirements! :D
2023-08-12 17:10:54 -0400 < mnieper> Racket's kernel is small and well-documented.
2023-08-12 17:11:06 -0400 < Zipheir> haugh: IRC is stateful, it's just that the state is scattered over the logs of a bunch of clients (and the channel log).
2023-08-12 17:12:41 -0400 < haugh> Indeed. For me it's currently moot since I need IRC for some greybeard-oriented tech communities and Matrix for E2EE and ad-hoc group chats
2023-08-12 17:14:09 -0400 < haugh> grognards!
2023-08-12 17:14:44 -0400 < Zipheir> IRC must be the grognard's protocol of choice, unless it's Usenet. Or the telegraph.
2023-08-12 17:15:05 -0400 < haugh> Solar signals!
2023-08-12 17:16:56 -0400 < mnieper> ecraven: I have to write up an example where an unhygienic SC macro does not work well with a syntax-rules macro. But not now as I am typing on my mobile.
2023-08-12 17:17:01 -0400 < aeth> IRC actually is stateful, in the sense that any useful client or bot is going to have to track which nicks are in which channel because NICK and QUIT are global (but nothing else?)
2023-08-12 17:17:14 -0400 < aeth> kind of annoying
2023-08-12 17:17:30 -0400 < sham1> AWAY is global
2023-08-12 17:17:40 -0400 < aeth> yeah, but AWAY usually isn't displayed
2023-08-12 17:17:59 -0400 < sham1> Also some IRCv3 things are global such as you logging into your NickServ account or whatever
2023-08-12 17:35:22 -0400 < haugh> let's just use torches https://books.google.com/books?id=DPRCAQAAMAAJ&pg=PA45
2023-08-12 17:37:20 -0400 < haugh> unfortunately polybius' system broke down because the greeks couldn't decide whether 5,5 should correspond to a space or a tab
2023-08-12 18:42:32 -0400 -!- cow_2001 is now known as cop_2001
2023-08-12 18:42:58 -0400 -!- cop_2001 is now known as cow_2001
2023-08-12 21:41:11 -0400 < mdhughes> I wouldn't use a language without multiple arguments. It's literally worse in every use case. ADDING TWO NUMBERS would cons? Fuck that nonsense.
2023-08-12 21:41:38 -0400 < mdhughes> Multiple returns are meh, they're useful in some cases, but you can live without them easier.
2023-08-12 21:41:51 -0400 < cow_2001> Is this true or false or some melange of both? https://www.marktarver.com/bipolar.html
2023-08-12 21:43:18 -0400 < cow_2001> mdhughes: Multiple returns look to me indistinguishable from returning a list, no?
2023-08-12 21:44:21 -0400 < mdhughes> I do moderately often miss the Objective-C idiom of NSError *error; id retval=[obj someMethod:... error:(NSError *)error]; if ( ! retval) { do stuff with error }
2023-08-12 21:44:43 -0400 < mdhughes> And in Scheme, that's just a multi-return of retval, error. Nicer, but logically identical.
2023-08-12 21:46:49 -0400 < mdhughes> Exceptions aren't the right solution to that in many cases, because A) they can go unchecked, and B) crashing your program because of an error is the most user-hostile, incompetent result possible. Don't do that.
2023-08-12 21:47:51 -0400 < aeth> cow_2001: multiple returns don't necessarily cons which is good for some niche ≤ 16 and especially ≤ 4 results.
2023-08-12 21:48:25 -0400 < cow_2001> Hmm.
2023-08-12 21:48:26 -0400 < samplet> Somehow Java ruined checked exceptions for everyone.
2023-08-12 21:49:18 -0400 < cow_2001> aeth: Is it some CPU memory magic?
2023-08-12 21:49:28 -0400 < aeth> cow_2001: register magic, actually
2023-08-12 21:49:36 -0400 < aeth> although continuations might complicate that in Scheme
2023-08-12 21:49:37 -0400 < cow_2001> aeth: Hmm!
2023-08-12 21:50:03 -0400 < aeth> although if your language supports, say, 128 multiple return values, then at some point it will cons
2023-08-12 21:50:08 -0400 < aeth> just not ≤ 4 and probably not ≤ 32
2023-08-12 21:51:31 -0400 < cow_2001> You are all so damned smart. :|
2023-08-12 21:51:42 -0400 < cow_2001> damned? damn?
2023-08-12 21:52:18 -0400 < mdhughes> Yeah, it's slightly efficient. And I like "language encourages the practices you want", so you have to handle the multiple values there.
2023-08-12 21:53:34 -0400 < mdhughes> It's more "tired and scarred from learning these the hard way". Like your 4-fingered wood shop teacher.
2023-08-12 21:55:28 -0400 < mdhughes> IRC works fine for me offline, because LimeChat logs everything, and reconnects quickly. If I'm in bed and want to check IRC, I shell into my machine, `less` the log. Can't easily post from there, tho.
2023-08-12 21:56:12 -0400 < mdhughes> I should write a bit of AppleScript to tell "LimeWire" ... whatever commands it accepts to select channel & post.
2023-08-12 21:56:55 -0400 < mdhughes> s/Wire/Chat/
2023-08-12 21:57:28 -0400 < mdhughes> Uuuugh, it's not scriptable. I'd have to do UI events.
2023-08-12 23:11:32 -0400 < acdw> oh shit the still wait
2023-08-12 23:12:01 -0400 < acdw> I thought they still did limewire 
2023-08-12 23:41:06 -0400 < mdhughes> LimeWire's been dead since 2010, fucking cops shut it down.
2023-08-12 23:41:48 -0400 < mdhughes> But torrents will live forever, I use Transmission for that.
2023-08-12 23:42:35 -0400 < acdw> hell yeah
2023-08-12 23:42:43 -0400 < acdw> I should get back into texting
2023-08-12 23:42:51 -0400 < acdw> torenting
2023-08-12 23:42:52 -0400 < aeth> the world's #1 Linux ISO downloader
2023-08-12 23:43:02 -0400 < acdw> with...a vpn
2023-08-12 23:43:08 -0400 < acdw> lmao aeth
2023-08-12 23:43:27 -0400 < aeth> easily the #1 legal use case for it
2023-08-12 23:45:02 -0400 < mdhughes> Everything on archive.org can be grabbed by torrent.
--- Day changed Sun Aug 13 2023
2023-08-13 00:12:18 -0400 < acdw> dope af
2023-08-13 00:12:27 -0400 < acdw> what if .... we changed the laws
2023-08-13 00:12:47 -0400 < acdw> I don't super  believe in the utility of ip
2023-08-13 00:14:59 -0400 -!- no-n is now known as pony
2023-08-13 00:39:57 -0400 < lockywolf> Is it true that MIT-Scheme and Chez conflict on the who is the boss?
2023-08-13 00:40:56 -0400 < lockywolf> Chez seems to install itself into /usr/bin/scheme, MIT installs itself as /usr/bin/mit-scheme, but adds a symlink /usr/bin/scheme
2023-08-13 00:41:51 -0400 < aeth> that's the job for distros to fix
2023-08-13 00:42:07 -0400 < aeth> sounds easy (don't do the symlink)
2023-08-13 00:42:19 -0400 < aeth> more annoying is C# and Chicken Scheme both using `csi`
2023-08-13 01:12:15 -0400 < lockywolf> yah
2023-08-13 01:13:01 -0400 < lockywolf> acdw: ip is much better than ifconfig, has much cleaner semantic
2023-08-13 01:13:53 -0400 < acdw> lol
2023-08-13 02:21:25 -0400 < mdhughes>  /usr/local/bin/scheme -> /usr/local/Cellar/chezscheme/9.5.8/bin/chez
2023-08-13 02:22:58 -0400 < mdhughes> Dybvig's said something like his muscle memory's too ingrained to ever change the command name.
2023-08-13 02:25:03 -0400 < sham1> Well he could always have it as an alias or such
2023-08-13 03:37:22 -0400 < mnieper`> Too many multiple values would likely be stored in a vector, not in a consed list.
2023-08-13 03:37:46 -0400 < aeth> you'd think so, yes (although that's still "consed", just one consed object instead of dozens)
2023-08-13 03:38:17 -0400 < mnieper`> In a language with just a single argument, implementations will have a record elimination pass.
2023-08-13 03:38:39 -0400 < mnieper`> So efficiency is not an argument for multiple arguments.
2023-08-13 03:38:57 -0400 < aeth> but ime, Scheme really took over the §2.2.4 "Totally Inappropriate Data Structures" part of the Lisp culture as talked about in the Worse Is Better essay. https://dreamsongs.com/WIB.html
2023-08-13 03:38:59 -0400 < mnieper`> Semantically, having just a single argument is simpler.
2023-08-13 03:39:01 -0400 < aeth> more than any other Lisp
2023-08-13 03:39:06 -0400 < aeth> (i.e. lists-for-everything)
2023-08-13 03:40:24 -0400 < aeth> and, yes, the issue isn't what can and can't be done, it's what should be done... and in languages with multiple values, you kind of need to use them
2023-08-13 03:40:35 -0400 < aeth> because you optimize what's idiomatic
2023-08-13 03:41:07 -0400 < ecraven> mnieper`: thanks, if you ever find the time to write such an example for SC, that would be interesting :D
2023-08-13 03:41:46 -0400 < mnieper`> lists-for-everything already fails because of set-cdr!
2023-08-13 03:42:38 -0400 < mnieper`> aeth: Thanks for WIB.html. I am going to take a closer look.
2023-08-13 03:42:43 -0400 < aeth> my personal rule of thumb is 4 values... beyond that it's probably overkill (Common Lisp has one such as a built-in, which returns time as 9 values)
2023-08-13 03:43:12 -0400 < aeth> (I don't think r7rs has any built-ins with multiple return values that I can think of at the moment... maybe < 5)
2023-08-13 03:44:20 -0400 < aeth> mnieper`: it's talking about Lisp, mostly Common Lisp, in 1991... and is a famous essay.
2023-08-13 03:44:28 -0400 < shawnw> There's some integer division ones like floor/ and truncate/
2023-08-13 03:44:53 -0400 < aeth> shawnw: ah, yes, I wasn't sure if they were that way or not
2023-08-13 03:45:11 -0400 < MrLambda> hello
2023-08-13 03:46:26 -0400 < aeth> hi
2023-08-13 03:46:33 -0400 < mnieper`> When you write loops, you can have in general roughly the same number of values as arguments.
2023-08-13 03:46:52 -0400 < mnieper`> This is where more than two MVs usually appear.
2023-08-13 03:46:55 -0400 < MrLambda> any one use akku on apple sillicon?
2023-08-13 03:47:23 -0400 < mnieper`> SRFI 242's machinery relies on MVs and hides them from (it gives them names).
2023-08-13 03:48:15 -0400 < aeth> Personally, I like using multiple values for short mathematical vectors (such as the 2-4 length ones in computer graphics) when I don't want to cons up a bunch of temporary ones. Although it's not an issue in a sufficiently smart language.
2023-08-13 03:48:46 -0400 < aeth> With macros you can generate massive amounts of boilerplate to do different forms (mv and vector-based)
2023-08-13 03:49:57 -0400 < mnieper`> Returning MVs for mathematical vector components sounds reasonable if there's no need to package them.
2023-08-13 03:50:23 -0400 < aeth> Right, it's about having another option.
2023-08-13 03:51:14 -0400 < mnieper`> Of course, having another options make a language more complicated. You have to decide...
2023-08-13 03:51:29 -0400 < aeth> Yes, but without macros, the code gen or repetition would make a mess of it
2023-08-13 03:51:30 -0400 < mnieper`> ... and need to know what's best for your impl, etc.
2023-08-13 03:52:03 -0400 < aeth> MrLambda: I think there are some Apple users in here
2023-08-13 03:52:11 -0400 < shawnw> *the fifth most standard Lisp was Scheme, which ran on a few different kinds of machine, but very few people wanted to use it* Ouch. Granted, 1980's scheme landscape was very different from today...
2023-08-13 03:53:28 -0400 < aeth> shawnw: Amusingly, Lisp is more fragmented than ever before. Common Lisp, Emacs Lisp, Clojure, Scheme (r5rs/r7rs, r6rs, Racket)... and the Schemes are kind of an incompatibility with each other in themselves
2023-08-13 03:54:18 -0400 < ecraven> aeth: when was Lisp ever not fragmented?
2023-08-13 03:54:20 -0400 < aeth> And yet that doesn't really seem to be an issue that's worth talking about since they're all basically their own thing (except for the semi-compatibility of CL and elisp)
2023-08-13 03:55:23 -0400 < aeth> ecraven: apparently, 1991, as mentioned in https://dreamsongs.com/WIB.html
2023-08-13 03:56:08 -0400 < shawnw> Things are (slowly) converging though. It's getting easier and easier to write non-trivial scheme code that runs on multiple implementations.
2023-08-13 03:56:20 -0400 < ecraven> well, there was interlisp and zetalisp and lots of smaller dialects then. I think there was the *hope* that CL would unify them all
2023-08-13 03:56:43 -0400 < aeth> The state of Lisps in the early 1990s would have been: Most historic Lisps had consolidated into Common Lisp, a few other standardization attempts would never take off (Le Lisp, EuLisp, ISLISP, etc.), Emacs Lisp probably wasn't seen as a big thing yet, and Scheme didn't seem like a language family, but rather a language. And newer ones like Clojure weren't out yet.
2023-08-13 03:56:58 -0400 < aeth> So you could have basically simplified the Lisp family down to just Common Lisp and Scheme
2023-08-13 03:57:14 -0400 < aeth> especially with the failure of the Lisp Machines (and thus Lisp Machine Lisp)
2023-08-13 03:57:42 -0400 < ecraven> well, even interlisp and the zetalisp side were implementing CL (though neither completed that)
2023-08-13 03:57:53 -0400 < aeth> Lisp Machines as well
2023-08-13 03:58:39 -0400 < MrLambda> is there any package manager for chez scheme?
2023-08-13 03:59:51 -0400 < aeth> at a minimum, there's the portable libraries
2023-08-13 03:59:52 -0400 < ecraven> sorry, zetalisp is what I call the lisp machine lisp dialect (because that's what it sometimes called itself)
2023-08-13 04:01:57 -0400 < mnieper`> MrLambda: You have Akku
2023-08-13 04:02:14 -0400 < aeth> MrLambda: the first thing to look for in any implementation would be SRFIs... https://srfi.schemers.org/
2023-08-13 04:02:14 -0400 < mnieper`> The question is whether you really need a package manager.
2023-08-13 04:02:19 -0400 < aeth> or in this case, https://github.com/arcfide/chez-srfi
2023-08-13 04:02:23 -0400 < aeth> at least, that's the first result
2023-08-13 04:02:55 -0400 < MrLambda> I have a trouble when run akku on apple sillicon machine
2023-08-13 04:03:07 -0400 < mnieper`> Chez does not work there.
2023-08-13 04:03:17 -0400 < aeth> looks like Akku takes r7rs libraries from snow fort
2023-08-13 04:03:27 -0400 < aeth> maybe you can get snow to work directly? https://snow-fort.org/
2023-08-13 04:03:45 -0400 < aeth> this appears to be Akku, for those following along. https://akkuscm.org/
2023-08-13 04:04:44 -0400 < mnieper`> The problems with (newer) SRFIs is that they were usually written with R7RS in mind.
2023-08-13 04:05:30 -0400 < mnieper`> Instead of initially using SRFIs, I would first try to do it a Chez/R6RS way.
2023-08-13 04:06:04 -0400 < ecraven> SomeOne™ create a good R7RS shim for Chez already :P :D
2023-08-13 04:06:30 -0400 < MrLambda> @mnieper it can run on apple sillicon machine
2023-08-13 04:06:54 -0400 < mnieper`> I thought the processor is not supported?
2023-08-13 04:07:48 -0400 < mnieper`> ecraven: Why would one want an R7RS(-small) shim for Chez when R6RS is better designed?
2023-08-13 04:07:51 -0400 < MrLambda> the racket fork ass support for it  https://github.com/racket/ChezScheme
2023-08-13 04:08:04 -0400 < MrLambda> add
2023-08-13 04:08:19 -0400 < mnieper`> MrLambda: Are you sure Akku uses that fork?
2023-08-13 04:08:26 -0400 < ecraven> mnieper`: not everyone shares that opinion :P
2023-08-13 04:08:47 -0400 < ecraven> also, if you want to work on other R7RS schemes, it'd be nice if you could run your code (including for example the `define-library' parts) on chez too
2023-08-13 04:09:21 -0400 < mnieper`> ecraven: Then I would use a shim for R7RS systems to support R6RS. :)
2023-08-13 04:09:54 -0400 < mnieper`> MrLambda: Why don't you just use Racket then?
2023-08-13 04:10:12 -0400 < mnieper`> It comes with a package manager and can also run R6RS.
2023-08-13 04:10:16 -0400 < ecraven> mnieper`: that's only an option if you prefer R6Rs :P
2023-08-13 04:10:33 -0400 < mnieper`> ecraven: People who do not thing that bigger numbers are better prefer R6RS :)
2023-08-13 04:10:36 -0400 < MrLambda> mnieper: I am not sure , just for fun
2023-08-13 04:10:40 -0400 < mnieper`> s/thing/think
2023-08-13 04:11:23 -0400 < ecraven> mnieper`: that's a rather provocative statement :P :D there are quite a few Scheme implementations that have *not* implemented R6RS, but *did* implement R7RS, are they all that kind of people?
2023-08-13 04:11:44 -0400 < mnieper`> ecraven: For implementers, I see a reason to implement only R7RS.
2023-08-13 04:12:08 -0400 < mnieper`> Not everyone has the time to write a compliant R6RS impl.
2023-08-13 04:12:23 -0400 < ecraven> from what I've read, this is more about the inclination, not so much about the time
2023-08-13 04:13:39 -0400 < mnieper`> When just comparing languages (independent of impls), I don't see any reason why a user (practical programmer) should prefer R7RS-small.
2023-08-13 04:13:47 -0400 < shawnw> R6 would probably have been better received if it was the spec for a brand new language than the next version of an existing one. But it just had too many differences from R5. R7-small is a much more sensible incremental improvement.
2023-08-13 04:13:49 -0400 < mnieper`> (not talking about -large, which is still do be done)
2023-08-13 04:14:08 -0400 < mnieper`> shawnw: R6 is compatible with R5.
2023-08-13 04:14:29 -0400 < mnieper`> (as much as R7 is compatible with R5)
2023-08-13 04:16:01 -0400 < mdhughes> The changes to R6 aren't that much, it's mostly stuff everyone uses in SRFIs already, like hashtables.
2023-08-13 04:18:05 -0400 < mnieper`> Some people spread a lot of FUD when R6RS came out.  I agree with mdhughes.  R6RS is R5RS+what people expect to be in a practical programming language.
2023-08-13 04:18:22 -0400 < shawnw> If only the R6RS hash tables had been based on the SRFI-69 API, which was already in widespread use...
2023-08-13 04:18:51 -0400 < mnieper`> shawnw: If this is important to you, you can easily provide SRFI 69 on top of R6RS hashtables.
2023-08-13 04:20:28 -0400 < mnieper`> Just because there is a SRFI that is used by some impls, doesn't mean that it is necessarily a good idea to include it in a standard as is.
2023-08-13 04:21:57 -0400 < shawnw> No thanks. I just use schemes that provide SRFI-69 (Ot preferrably these days SRFI-146 hash maps to get immutable tables)
2023-08-13 04:22:46 -0400 < mnieper`> shawnw: You can get SRFI 69 for R6RS schemes, so what's the problem?
2023-08-13 04:24:04 -0400 < mnieper`> But its core API is worse than the one of R6RS hashtables.
2023-08-13 04:25:18 -0400 < shawnw> How is it worse? R6 tables don't have half the functionality of -69. To say nothing of the SRFIs that build on it.
2023-08-13 04:25:31 -0400 < mnieper`> CORE API
2023-08-13 04:26:32 -0400 < mnieper`> I didn't say that R6RS covers the size of a full library collection.
2023-08-13 04:27:01 -0400 < mnieper`> But it provides the solid foundation to build one.
2023-08-13 04:28:39 -0400 < shawnw> I think I read that backwards
2023-08-13 04:28:41 -0400 < mnieper`> One problem with the core of SRFI 69 is that make-hash-table relies on procedure equality, which is not computable, so one only gets an approximation (works on R[57]RS when one understands the limitations, doesn't work on R6RS).
2023-08-13 04:33:14 -0400 < mdhughes> The only visible differences are hash-table-walk, hash-table-fold, hash-table->alist , which are all easy enough to write (and kind of dumb when you have hashtable-entries)
2023-08-13 04:36:06 -0400 < mdhughes> Now, what none of the specs address is putting hashtables in write/read syntax. And that's slightly difficult, since they aren't consistent in memory, do you sort keys or is every save going to be quasi-random?
2023-08-13 04:36:48 -0400 < mnieper`> SRFI 69's hash-table-fold is also limited because you can only pass one value per iteration.
2023-08-13 04:37:23 -0400 < mdhughes> Same with records; in R6 if you set nongenerative and a name, you *can* write/read, but that's impl-specific trick, not clearly stated.
2023-08-13 04:37:46 -0400 < mnieper`> mdhughes: How would you serialize the hash function or comparison predicate?
2023-08-13 04:38:00 -0400 < mnieper`> mdhughes: See SRFI 237 for a proposal to serialize records.
2023-08-13 04:38:09 -0400 < mdhughes> You'd have to save the function name and hope it's pre-defined.
2023-08-13 04:38:35 -0400 < mnieper`> mdhughes: https://dreamsongs.com/WIB.html
2023-08-13 04:38:43 -0400 < mdhughes> It's a solveable problem since other languages manage it, just not easy.
2023-08-13 04:39:01 -0400 < mnieper`> Thanks to aeth for giving me the link.
2023-08-13 04:39:35 -0400 < mdhughes> Yeah, I love worse is better. Even if Gabriel's kind of an ass about "Common Lisp is the One True Faith".
2023-08-13 04:39:36 -0400 < mnieper`> The question is: does one really need to read/write records/hashtables?
2023-08-13 04:40:21 -0400 < mdhughes> Oh yeah. I load/save files all the time, and I'm back in the "good old days" of hand-coding every serialization.
2023-08-13 04:41:07 -0400 < mdhughes> ->alist or JSON is generally "fine", but not ideal, I have to reach into some structure and remap it to a hashtable on load.
2023-08-13 04:41:07 -0400 < mnieper`> mdhughes: I am a mathematician, so you can guess what I love. :)
2023-08-13 04:42:18 -0400 < mdhughes> In Python or JavaScript, I very often just put all my stuff in deeply nested dict/objects and serialize it in/out.
2023-08-13 04:44:53 -0400 < mnieper`> If you want error checking when reading, you need a custom deserializer anyway.
2023-08-13 04:45:57 -0400 < mnieper`> I would propose some macro sublanguage to define (mutually recursive) inductive data types.  Each such data type would get a macro-generated reader/writer.
2023-08-13 04:46:16 -0400 < mnieper`> This is type-safe and clear.
2023-08-13 04:46:43 -0400 < mnieper`> So, basically, you just give the "grammar" in code, which also serves as documentation. 
2023-08-13 04:48:23 -0400 < mdhughes> It's not that hard to write recursive serializers, it's just tedious. Used to automate writing NSCoding methods for Objective-C.
2023-08-13 04:49:59 -0400 < mnieper`> -> macros! :)
2023-08-13 04:50:25 -0400 < mnieper`> Write it once (and publish a SRFI so others can easily use it as well).
2023-08-13 05:44:55 -0400 < flatwhatson> ASN1 for scheme?
2023-08-13 06:05:50 -0400 < ecraven> well, there's protobuffers and captn proto and lots of others, right? BER would be useful for ldap, too
2023-08-13 06:28:34 -0400 < mdhughes> I hate non-textual data formats. If you can't scan it with vim, grep, awk, etc., it's no good.
2023-08-13 06:35:29 -0400 < mfiano> Amen
2023-08-13 06:38:47 -0400 < ecraven> mdhughes: you still need them to interface with "stuff" :-/
2023-08-13 06:39:14 -0400 < sham1> I wish more interchange formats had an actual way to specify the schema for the data
2023-08-13 06:39:31 -0400 < sham1> Like I can only think of XML and ASN.1 with explicit schemas
2023-08-13 06:40:57 -0400 < sham1> Like with protobufs and the like you have schemas but in order to actually read the data you need to know the schema
2023-08-13 06:41:03 -0400 < sham1> Or even JSON
2023-08-13 07:06:05 -0400 < flatwhatson> well JSON Schema and OpenAPI are a thing these days
2023-08-13 07:17:34 -0400 < mdhughes> Yeah, all the stuff I talk to now is JSON. It's fine.
2023-08-13 07:29:01 -0400 < sham1> Neither JSON Schema nor OpenAPI are a part of JSON proper
2023-08-13 12:55:41 -0400 < Zipheir> I haven't seen much use of JSON Schema. Is there a validator that speaks it?
2023-08-13 12:57:15 -0400 < Zipheir> I think JSON and XML (and SXML) were intended to serve very different purposes.
2023-08-13 13:10:30 -0400 < dpk> that’s semi-true
2023-08-13 13:11:26 -0400 < dpk> XML was an evolution of SGML, which was an evolution of GML, which was a glorified word processor for IBM mainframes. both GML and SGML were designed for document processing and were very good at it, especially SGML
2023-08-13 13:12:06 -0400 < dpk> if it makes sense to print the data out into a book or report or something, and the characters on the printed page would be the same as in the markup without tags, SGML is an excellent choice
2023-08-13 13:13:32 -0400 < dpk> HTML was supposed to be an application of SGML, but TimBL screwed it up early with some non-SGML-conformant features, and no browser ever used a proper SGML processor anyway. (fun fact: things like </> to close the most recently opened tag, and <div /null end-tag syntax/, are perfectly valid HTML 4. no browser ever understood that, though)
2023-08-13 13:15:28 -0400 < dpk> XML was the result of conflicting forces in the W3C who nonetheless more-or-less agreed that the tag soup of the 1990s web needed ‘cleaning up’, and also wouldn’t it be nice if we had a way in which people *could* add their own tags to HTML
2023-08-13 13:16:38 -0400 < dpk> so XML is supposed to be a ‘simplified’ SGML (in reality, they just created a concrete syntax that didn’t require a DTD to be parsed unambiguously, left a load of other cruft like processing instructions in, and then later crummed it up with their own new towers of complexity like URI-based namespaces for tags)
2023-08-13 13:17:12 -0400 < dpk> but then very early on, it got turned into a bandwagon where people were trying to serialize all kinds of data, not just text documents, in XML
2023-08-13 13:18:06 -0400 < dpk> so you got stuff like XML-RPC, where something not too far from JSON was encoded in XML syntax
2023-08-13 13:18:53 -0400 < dpk> which turned into SOAP, the model example for the rule of thumb that ‘technologies with the word ”simple” in the name aren’t’
2023-08-13 13:20:46 -0400 < Zipheir> dpk: Thanks.
2023-08-13 13:22:50 -0400 < dpk> since most programmers are dealing with data arranged roughly like JSON anyway, JSON eventually took over for most of the misuses of XML-as-data-serialization. but equally, because only a small fraction of the people who used XML knew what it was actually originally meant for, the name ‘XML’ has a bad reputation
2023-08-13 13:23:12 -0400 < Zipheir> Yes, I'm learning that.
2023-08-13 13:24:29 -0400 < dpk> and there are a number of XML-based technologies still floating around which should not really have gone with XML
2023-08-13 13:24:51 -0400 < Zipheir> I've been reading an old O'Reilly book on XML that covers things like XLink which, apparently, never got much support. I suppose that's part of XML becoming a ill-suited serialization format.
2023-08-13 13:25:20 -0400 < Zipheir> Sure. I've never understood why e.g. XMPP used it.
2023-08-13 13:27:14 -0400 < dpk> SVG is my favourite example, where the primitive drawing command – the <path> element – has its own non-human-readable syntax for describing where the path should be drawn, which gets stuffed into an attribute value, instead of the true ‘XML way’ which would have been to have elements for each of the path nodes. that was too obviously overly verbose, presumably
2023-08-13 13:28:06 -0400 < Zipheir> Yeah, I'm also doubtful about the treeification of images.
2023-08-13 13:28:50 -0400 < Zipheir> But the SVG designers really punted with all of those attributes.
2023-08-13 13:29:39 -0400 < dpk> (in SGML they could have had it so the parser could have read something not too dissimilar from their custom syntax and turned it into a series of node elements as it read. but markup minimization was not allowed any more in XML, except for its variant of the null end tag, the /> thing)
2023-08-13 13:33:36 -0400 < dpk> XLink is an interesting case. i think its ‘failure’ is probably largely linked to that of XHTML 2.0, which was the big ‘let’s clean up all the cruft out of HTML and make it extensible’ effort. but i’m not actually 100% sure whether XLink was going to be used there, either. it’s a long time since i looked at what the XHTML 2.0 goons wanted to pull over on us (with apologies to the XHTML 2.0 goon who is here in the channel for this 
2023-08-13 13:33:36 -0400 < dpk> wording), but iirc one of their headline features was going to be that you could attach an href attribute to any element to turn it into a link. (the HTML 5 people decided it was easier just to relax the restriction on where the <a> element could go: the underlying problem was that it couldn’t be placed around block-level elements in HTML 4, iirc)
2023-08-13 13:37:29 -0400 < Zipheir> There were also arcs and other things that HTML 5 has nothing analogous to.
2023-08-13 13:38:15 -0400 < Zipheir> Though you might see XLink as the ultimate second-systeming of HTML's <a>.
2023-08-13 15:10:14 -0400 < dpk> man, this guy is still going http://sgmljs.net
2023-08-13 15:11:42 -0400 < dpk> i remember finding him like ten years ago, single-handedly trying to make SGML a thing again, for new projects
2023-08-13 15:12:54 -0400 < dpk> i support the goal, and hey, i’m not going to complain about a new actively-maintained SGML processor (from the docs, it even seems to have some features OpenSP is lacking), but i’ll be amazed if it he ever makes it past being a one-man SGML tribute band
2023-08-13 15:15:32 -0400 < dpk> wow, he’s even implemented a Markdown-a-like in SHORTREF
2023-08-13 16:03:36 -0400 < leah2> recently i found someone writing a ditroff renderer in js...
2023-08-13 17:02:30 -0400 < jcowan> Eager syntax-rules helps, though
2023-08-13 17:03:27 -0400 < sham1> And how eager are we to add those?
2023-08-13 17:03:45 -0400 < sham1> Because it seems that we're really not all that eager for them
2023-08-13 17:05:05 -0400 < Zipheir> Eager syntax-rules to be implemented lazily.
2023-08-13 17:24:00 -0400 < jcowan> sham1: If you only have syntax-rules, then eager syntax-rules are a convenient notation composable macros.
2023-08-13 17:24:15 -0400 < sham1> Sure
2023-08-13 17:26:14 -0400 < sham1> But punnage aside, I don't know if it'll be adopted to r7-large. It'd be nice, but I'm not sure. Of course for implementations that don't want the large language or even a fully compliant Scheme of any sort, having only syntax-rules in both the lazy and eager forms would work fine
2023-08-13 17:32:00 -0400 < jcowan> I can't see adding it to the Batteries
2023-08-13 17:33:04 -0400 < jcowan> If we didn't have syntax-case, then I'd say yes, but it seems clear that we need syntax-case (even apart from needing it for R6RS)
2023-08-13 19:55:53 -0400 < Zipheir> Is there a spec for eager syntax-rules?
2023-08-13 20:02:50 -0400 < cow_2001> You have defined a new record type.  You want to take an existing instance of it, and create a new instance with only one of the fields of the original changed.  Do you have to go (make-a-record (a-record-field-1 old) (a-record-field-2 old) new-field-3-value)?
2023-08-13 20:05:15 -0400 < cow_2001> Do I have to create an update (how do you call a procedure which takes an old thing and makes a new thing out of it without changing the old thing?) procedure per field?
2023-08-13 20:06:52 -0400 < flatwhatson> cow_2001: assuming guile, you can use define-immutable-record-type which provides pure functional setters
2023-08-13 20:06:55 -0400 < cow_2001> (define (update-field-1 rec val) (make-a-record val (a-record-field-2 rec) (a-record-field-3 rec)))
2023-08-13 20:07:05 -0400 < cow_2001> flatwhatson: R7RS :|
2023-08-13 20:07:11 -0400 < cow_2001> + SRFI
2023-08-13 20:07:49 -0400 < cow_2001> Am I bonkers trying to R7RS using Guile?
2023-08-13 20:08:16 -0400 < flatwhatson> no, but you might be making your life unnecessarily difficult
2023-08-13 20:08:25 -0400 < cow_2001> Should I just give up and………
2023-08-13 20:08:47 -0400 < dTal> you're already dangerously close to "idealistic" just by trying to use scheme at all instead of a sensible language like java
2023-08-13 20:08:58 -0400  * dTal ducks
2023-08-13 20:08:59 -0400 < cow_2001> Embrace non-standard GNUisms into my heart.
2023-08-13 20:10:10 -0400 < cow_2001> dTal: Hmm.
2023-08-13 20:11:57 -0400 < flatwhatson> cow_2001: define-immutable-record-type is quite a nice extension, which closely resembles SRFI-9, and could probably be SRFI'd itself if someone were to bother
2023-08-13 20:12:26 -0400 < cow_2001> Ah!
2023-08-13 20:12:32 -0400 < flatwhatson> SRFI-9 records have no introspection so you can't "bolt on" that functionality without defining a wrapper macro (which is what define-immutable-record-type is)
2023-08-13 20:12:55 -0400 < flatwhatson> so i think calling it a "GNUism" isn't doing it justice
2023-08-13 20:13:20 -0400 < cow_2001> Sorry.
2023-08-13 20:14:29 -0400 < cow_2001> Will read the manual.
2023-08-13 20:14:58 -0400 < Zipheir> This is what lenses are good for.
2023-08-13 20:15:29 -0400 < cow_2001> (srfi srfi-9 gnu)
2023-08-13 20:15:34 -0400 < cow_2001> Zipheir: ?!
2023-08-13 20:15:48 -0400 < Zipheir> define-immutable-record-type is one approach, but it doesn't generalize beyond records. Lenses solve the general problem.
2023-08-13 20:16:26 -0400 < Zipheir> Racket has a lens library: https://docs.racket-lang.org/lens/index.html  I'm not sure if Guile does.
2023-08-13 20:16:37 -0400 < cow_2001> The basic scheme is that the primary light-gathering element, the objective (1) (the convex lens or concave mirror used to gather the incoming light), focuses that light from the distant object (4) to a focal plane where it forms a real image (5).
2023-08-13 20:18:01 -0400 < Zipheir> :-|
2023-08-13 20:18:08 -0400 < Zipheir> https://docs.racket-lang.org/lens/lens-intro.html#%28tech._lens%29
2023-08-13 20:18:22 -0400 < Zipheir> "A lens is a value that composes a getter and a setter function to produce a bidirectional view into a data structure. This definition is intentionally broad—lenses are a very general concept, and they can be applied to almost any kind of value that encapsulates data."
2023-08-13 20:18:26 -0400 < cow_2001> I giggled.
2023-08-13 20:20:39 -0400 < Zipheir> A lens SRFI for Scheme would be nice.
2023-08-13 20:21:35 -0400 < flatwhatson> lenses are nice, but i don't see how they help to write functional setters for srfi-9 records?
2023-08-13 20:23:37 -0400 < Zipheir> flatwhatson: See the struct-lens constructor in Racket. https://docs.racket-lang.org/lens/lens-reference.html#%28part._struct-reference%29
2023-08-13 20:24:05 -0400 < Zipheir> This kind of thing could probably work with R6RS RTDs.
2023-08-13 20:25:13 -0400 < cow_2001> Okay, this is a rabbit hole for now.  I will use (srfi srfi-9 gnu) for now.
2023-08-13 20:25:20 -0400 < Zipheir> This isn't much help *now* in Scheme, but it's a good solution to a common problem.
2023-08-13 20:26:56 -0400 < flatwhatson> the way i see it, with r6rs rtd's you can probably generate functional setters for all fields, and yes lenses can be built on top of that
2023-08-13 20:27:56 -0400 < flatwhatson> but they don't really "solve the problem" on their own.  to generate those setters in a macro you need to be able to iterate the record's fields
2023-08-13 20:27:57 -0400 < Zipheir> Right.
2023-08-13 20:28:11 -0400 < Zipheir> It may not be possible portable.
2023-08-13 20:28:14 -0400 < Zipheir> *portably.
2023-08-13 20:28:57 -0400 < Zipheir> The power of lenses is really their compositionality. The setters aren't exciting on their own.
2023-08-13 20:30:40 -0400 < cow_2001> Not portassible.
--- Day changed Mon Aug 14 2023
2023-08-14 00:20:12 -0400 < acdw> I just spent far too long trying to write a portable r7rs library and just gave up, oof
2023-08-14 00:32:29 -0400 < sham1> Portability is built on unportable assumptions
2023-08-14 00:33:13 -0400 < acdw> sadly I've learned that now
2023-08-14 00:48:12 -0400 < mnieper> What kind of library?
2023-08-14 01:16:47 -0400 < acdw> trying to combine all r7rs built in libraries into one for easier importing
2023-08-14 01:17:31 -0400 < acdw> git.acdw.net/chicanery if you're. interested. I've gone back to a chicken only approach 
2023-08-14 01:23:20 -0400 < pony> hi
2023-08-14 01:23:24 -0400 < pony> im thinking of picking up racket
2023-08-14 01:23:37 -0400 < pony> though some say it's not really scheme
2023-08-14 01:24:00 -0400 < Zipheir> It's a lot like Scheme.
2023-08-14 01:24:09 -0400 < pony> ok
2023-08-14 01:24:11 -0400 < pony> dat's good
2023-08-14 01:25:00 -0400 < Zipheir> Don't worry too much about standard Scheme until you decide you like the language.
2023-08-14 01:25:12 -0400 < pony> all right :)
2023-08-14 01:25:19 -0400 < Zipheir> And remember:
2023-08-14 01:25:24 -0400 < Zipheir> rudybot: ultimate programming language virus
2023-08-14 01:25:24 -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-08-14 01:25:49 -0400 < pony> nice
2023-08-14 01:27:12 -0400 < Zipheir> If you're looking for Racket books, a lot of people seem to like HtDP.
2023-08-14 01:27:24 -0400 < Zipheir> And Realm of Racket looks amusing.
2023-08-14 01:27:44 -0400 < pony> I will take a look at those thx
2023-08-14 01:28:01 -0400 < mnieper`> It is fair to say that Racket is a Scheme, just not an RnRS Scheme.
2023-08-14 01:28:10 -0400 < mnieper`> Maybe it is a better Scheme.
2023-08-14 01:29:13 -0400 < pony> cool
2023-08-14 01:29:16 -0400 < Zipheir> Maybe its slogan should be "more R6 than R6". :)
2023-08-14 01:29:27 -0400 < pony> I am interested in language design and implementation so Beautiful Racket should be a fun book too
2023-08-14 01:30:51 -0400 < mnieper`> Zipheir: It is not nearer to R6 than to R7 anymore.
2023-08-14 01:30:51 -0400 < Zipheir> If you're interested in language design and know the basics, the Racket guys also did _Semantics Engineering with PLT Redex_, which (eventually) makes good use of Racket.
2023-08-14 01:31:06 -0400 < mnieper`> It has a different expander than the R6 s-c expander and has immutable pairs.
2023-08-14 01:31:19 -0400 < mnieper`> The module system is also different.
2023-08-14 01:31:21 -0400 < Zipheir> I was joking.
2023-08-14 01:31:52 -0400 < mnieper`> acdw: Looking at Chicanary right now.
2023-08-14 01:32:14 -0400 < mnieper`> How do you want to implement `defined?' portably?
2023-08-14 01:32:52 -0400 < sham1> Wait, what expander does racket even use
2023-08-14 01:32:59 -0400 < sham1> Isn't it just s-c?
2023-08-14 01:34:47 -0400 < Zipheir> s-c ≡ syntax-case ?
2023-08-14 01:34:57 -0400 < mnieper`> https://users.cs.utah.edu/plt/scope-sets/
2023-08-14 01:35:06 -0400 < mnieper`> sham1: ^^
2023-08-14 01:35:10 -0400 < mnieper`> Zipheir: Yes
2023-08-14 01:35:49 -0400 < Zipheir> Thanks.
2023-08-14 01:35:50 -0400 < mnieper`> acdw: You set list-define <- define here: https://git.acdw.net/chicanery/tree/extras.scm?h=multiple-impls#n3
2023-08-14 01:36:32 -0400 < mnieper`> And later you redefine define.  Not that defines on the same level are recursive.
2023-08-14 01:36:44 -0400 < mnieper`> s/redefine define/redefine append
2023-08-14 01:37:04 -0400 < sham1> I was under the impression that the use of syntax scopes is equivalent to using substitutions and marks
2023-08-14 01:37:26 -0400 < mnieper`> acdw: So list-append will end up to be your (generic) append
2023-08-14 01:37:58 -0400 < mnieper`> Also, an .sld file should contain a library definition define-library.
2023-08-14 01:38:09 -0400 < mnieper`> sham1: Not fully.
2023-08-14 01:38:47 -0400 < mnieper`> Otherwise, it would have been an option for the large language (although, personally, I think that the s+m model is easier).
2023-08-14 01:39:15 -0400 < sham1> I'm the opposite, I feel that the scopes are way more intuitive than substitutions and marks
2023-08-14 01:39:38 -0400 < sham1> Even after reading the dygvib paper
2023-08-14 01:40:37 -0400 < sham1> Although that might be just my familiarity with compiler design for more C-like languages
2023-08-14 01:42:34 -0400 < mnieper`> sham1: See 2.5 in https://users.cs.utah.edu/plt/scope-sets/pattern-macros.html#(part._pattern-ambiguous) for a semantic difference.
2023-08-14 01:42:52 -0400 < sham1> I'll take a look
2023-08-14 01:44:49 -0400 < mnieper`> Section 2.4 shows IMO why the principle simplicity of the scope set model breaks down "in the real language" when internal definitions must be taken into account as well. 
2023-08-14 01:46:23 -0400 < sham1> Hmm
2023-08-14 01:47:01 -0400 < mnieper`> dpk and I have started to change the language of the marks&substitutions model to make it easier to grasp and more intuitive.
2023-08-14 01:49:10 -0400 < sham1> Nice
2023-08-14 01:50:16 -0400 < mnieper`> Under this explanation, an identifier has a (symbolic) name, an introduction time and a lexical environment.
2023-08-14 01:51:18 -0400 < mnieper`> Identifiers can be present in the source (they have the same introduction time) or be injected into the source by a macro use (in which case they are introduced at another time).
2023-08-14 01:55:18 -0400 < sham1> And I suppose that this introduction time and lexical environment is the wrap of a syntax object
2023-08-14 01:59:46 -0400 < haugh> cow_2001, if you're still around, check out the `procedure with setter' index in the guile manual
2023-08-14 02:02:26 -0400 < mnieper> sham1: of an identifier
2023-08-14 03:06:02 -0400 < dpk> i am still not convinced that we shouldn’t explain it in terms of the sets of scopes model instead
2023-08-14 03:06:41 -0400 < dpk> the ‘ambiguous’ pattern is highly contrived, and it’s probably debatable whether the marks and subsitutions model does the Right Thing in that case
2023-08-14 03:17:11 -0400 < dpk> i would also point out that, afaik, there is only one implementation of a fully R6RS-compliant syntax-case expander actually in use, psyntax, and several ‘R6RS’ Scheme implementations use expanders known to be non-compliant (van Tonder-style in Larceny and Kawa, plus Racket’s #!r6rs that uses the sets of scopes model)
2023-08-14 03:18:09 -0400 < dpk> which is why i likewise still have lingering doubt about whether we shouldn’t switch to the van Tonder style, either
2023-08-14 03:18:15 -0400 < dpk> or at least allow it
2023-08-14 03:21:11 -0400 < mnieper`> dpk: Don't open this can of worms again.
2023-08-14 03:21:49 -0400 < mnieper`> Unsyntax should also be fully compliant.
2023-08-14 03:22:14 -0400 < mnieper`> Chez does not use psyntax itself.
2023-08-14 03:24:33 -0400 < mnieper`> *Also* allowing the Van Tonder model gives us the worst of both systems for portable code (the R6RS library system has a similar problem when it can't decide between implicit and explicit phasing).
2023-08-14 03:31:32 -0400 < mnieper`> sham1: The question of wrapped/unwrapped is semantically somewhat orthogonal to name+introduction time+lexical env.
2023-08-14 03:32:42 -0400 < mnieper`> This should be covered independently because it has nothing to do with hygiene. The R6RS write-up does not do this separation.
2023-08-14 03:33:53 -0400 < dpk> syntax-case was one of the most controversial features of R6RS, to judge by the formal comments. the mark and substitution algorithm was found too complicated and lacking theoretical motivation. maybe we can fix that with a better explanation, but politically, it smacks of extreme arrogance to say that not only are we keeping the same algorithm which people hated in R6RS, we’re also saying to a bunch of implementors who currently believe in 
2023-08-14 03:33:53 -0400 < dpk> good faith that they have a correct implementation of it that they actually don’t and they need to re-do it basically from scratch. and we’re saying that even though, in practice, those edge cases mean that a *practically* portable R6RS program or library can’t use macros written in the style which doesn’t work in the van Tonder model, because neither Larceny nor Kawa (nor others?) will support it
2023-08-14 03:34:45 -0400 < dpk> i will want to gather formal comments on the reformulated explanation of the mark and substitution model before making a decision
2023-08-14 03:37:59 -0400 < mnieper`> dpk: R6RS links Oscar Waddell's PhD thesis for theoretical foundations.
2023-08-14 03:38:25 -0400 < mnieper`> Also, most hate against s-c was not because of the underlying expansion model.
2023-08-14 03:38:35 -0400 < mnieper`> That was already in the appendix of R4RS.
2023-08-14 03:41:18 -0400 < mnieper`> I would also like to ask you to tone down your voice. "Extreme arrogance" is very strong language IMO.
2023-08-14 03:53:06 -0400 < mnieper`> As for "the ‘ambiguous’ pattern is highly contrived, and it’s probably debatable whether the marks and subsitutions model does the Right Thing in that case": as far as I read the definition of hygiene in R7RS (only given in prose), Racket does not faithfully implement R7RS's syntax-rules. 
2023-08-14 03:53:28 -0400 < mnieper`> (Note that the "ambiguous example" just uses syntax-rules.)
2023-08-14 03:53:58 -0400 < mnieper`> We would also break R5RS compatibility.
2023-08-14 03:54:45 -0400 < mnieper`> SRFI 148 probably relies on these "edge cases" to be correct as well.
2023-08-14 03:58:23 -0400 < mnieper`> (This is why we cannot really do the switch to sets of scopes; this is unrelated to R6RS vs. Van Tonder, which both implement syntax-rules correctly.)
2023-08-14 04:00:25 -0400 < mnieper`> Back to how s-c in R6RS was perceived: People discussed "wrapped" vs. "fully unwrapped" a lot, but this has nothing to do with the semantic differences in the resulting macros.
2023-08-14 04:04:17 -0400 < mnieper`> Whatever, until we make the fundamental decision whether we want the large language to be compatible with R6RS (meaning that it is an implementation of it as it is an implementation of R7RS-small) or not, we are going in circles and will fail to deliver any standard.
2023-08-14 04:05:23 -0400 < mnieper`> I thought we had made the decision that R7RS-large is an implementation of both R6RS and R7RS-small, but these discussions prove me wrong.
2023-08-14 04:20:46 -0400 < dpk> i have expressed my view on R6RS compatibility. it remains unchanged
2023-08-14 04:22:33 -0400 < dpk> but there is R6RS as written and R6RS as implemented. ultimately, i think the latter is more relevant, or we don’t just alienate the anti-R6RS crowd but everyone in the pro-R6RS crowd except maybe users of Chez Scheme
2023-08-14 04:23:16 -0400 < dpk> in any case, my energy level for these kinds of discussions is currently quite depleted, and i don’t have the patience at the moment to play diplomat. so i’m going to withdraw from this for now
2023-08-14 04:23:26 -0400 < mnieper`> As I have my view.  We just have to come to a consensus on what shall hold for R7RS-large.
2023-08-14 04:23:47 -0400 < mnieper`> Because otherwise, I fully agree with you: it is too exhausting.
2023-08-14 04:24:43 -0400 < mnieper`> dpk: You probably forgot Guile and Loko.
2023-08-14 04:25:15 -0400 < sham1> I don't think Guile really cares about standard Scheme
2023-08-14 04:26:51 -0400 < mnieper`> Larceny, Kawa (and Guile) have deeper problems with R6RS support (like not raising exception when they must or different (top-level) binding semantics).
2023-08-14 04:28:20 -0400 < mnieper`> For these implementations nothing would change if R6RS isn't diluted.
2023-08-14 04:28:37 -0400 < mnieper`> So I don't quite see the point.
2023-08-14 04:28:54 -0400 < mnieper`> (that was in response to dpk).
2023-08-14 04:59:23 -0400 < mnieper`> Re "sets of scopes": See also https://users.cs.utah.edu/plt/scope-sets/hygiene.html
2023-08-14 05:00:56 -0400 < mnieper`> The difference between Racket and RnRS is that in Racket it is well-defined what a core form is and that the expander can therefore map syntax objects to syntax objects.
2023-08-14 05:01:26 -0400 < mnieper`> In RnRS, the expander maps syntax objects to some internal AST.
2023-08-14 05:01:57 -0400 < mnieper`> Definition of RnRS hygiene in Racket's model does not seem to be straightforward (or clear).
2023-08-14 05:03:04 -0400 < mnieper`> The "ambiguous example" becomes probably non-hygienic in the "sets of scopes" model of Racket.
2023-08-14 05:03:26 -0400 < mnieper`> It has to be in RnRS because it only uses syntax-rules, which must not produce unhygienic macros.
2023-08-14 05:42:31 -0400 < sham1> mnieper`: I'm looking at the newest issue in codeberg. What do you mean by "anticipating r8rs"? That if there ever is an R8RS that it'll be based on Foundations?
2023-08-14 05:45:41 -0400 < mnieper`> That if the Foundations are of a particular shape, they may be a candidate for R8RS (if there is going to be such a thing).
2023-08-14 05:46:55 -0400 < mnieper`> particular shape = encompassing R6RS, R7RS-small, errata, and stuff needed to build R7RS-large portably on top of them.
2023-08-14 05:47:46 -0400 < mnieper`> Even if we don't ask for the name R8RS, it can give an idea of what the scope of the Foundations can be.
2023-08-14 06:02:00 -0400 < mnieper`> Re Van-Tonder model: I added extra information to the relevant Codeberg issue: https://codeberg.org/scheme/r7rs/issues/115#issuecomment-1040446
2023-08-14 06:02:36 -0400 < mnieper`> One doesn't even have to cite the m&s algorithm for that (as I did previously).
2023-08-14 06:05:36 -0400 < mnieper`> dpk: Whatever you meant by "good faith" above, but implementers either didn't read the hygiene definition or chose to ignore it.  The latter may be true for Larceny's expander because basically a suitably modified SRFI 72 expander is used and SRFI 72 has never been intended to be compatible with what SRFI 93 describes.
2023-08-14 06:16:37 -0400 < mnieper`> According to what the author of Kawa says, it has actually always implemented SRFI 72, so it being an R6RS implementation would have been by accident.
2023-08-14 08:10:23 -0400 -!- rgherdt__ is now known as rgherdt
2023-08-14 08:18:54 -0400 < acdw> mnieper`: thanks for the comments!
2023-08-14 08:38:42 -0400 < mnieper`> acdw: You are welcome!
2023-08-14 08:39:12 -0400 < mnieper`> If problems persist, feel free to ask again.
2023-08-14 08:41:32 -0400 < acdw> questions: is defined? not portable? I was wanting to have scheme append available via list-append but append itself be generic. any way I can do that? I think you might be looking at the chicken-only branch? sld and define library and making that work with everything is quite confusing and annoying
2023-08-14 08:41:38 -0400 < acdw> thanks!
2023-08-14 08:44:23 -0400 < mnieper`> Can you link your definition of `defined?' here?
2023-08-14 08:46:21 -0400 < mnieper`> In R[67]RS, you would import `append' from the base library into your "prelude" library.  There, you define a `generic-append'.  In the export declaration of your library, you rename `append' to `list-append' and `generic-append' to `append'.
2023-08-14 08:47:48 -0400 < mnieper`> Like in (define-library (c...) (export (rename append list-append) (rename generic-append append) ...) (import (scheme base) ...) (begin ...)).
2023-08-14 08:50:28 -0400 < mnieper`> NB: Personally, I don't think that such a generic append (or map or whatever) is a good idea.  You lose type safety; this is a way to make a dynamically typed language into a weakly typed one.
2023-08-14 08:51:16 -0400 < mnieper`> A generic append may have its place when it is generic over all types of collections (and not just a fixed subset).
2023-08-14 08:51:32 -0400 < mnieper`> Fixed subset here means lists, strings, vectors.
2023-08-14 08:55:49 -0400 < acdw> yeah... that's definitely one of the not as good ideas lol. I just feel bad for vectors and strings because lists got the "default" append
2023-08-14 08:57:08 -0400 < acdw> https://git.acdw.net/chicanery/tree/extras.scm?h=multiple-impls#n104 there is defined?. also the branch where I was trying to support multiple implementations
2023-08-14 09:12:49 -0400 < dpk> happy phi day, apparently. (61.8% of the way through the year)
2023-08-14 09:17:11 -0400 < mnieper`> dpk: :)
2023-08-14 09:17:29 -0400 < mnieper`> Is this a real thing or your today's invention?
2023-08-14 09:17:49 -0400 < dpk> someone in a different channel pointed it out!
2023-08-14 09:18:16 -0400 < dpk> i don’t know how much of a ‘real thing’ it is, but i‘m not the one who invented it
2023-08-14 09:18:44 -0400 < mnieper`> acdw: defined? only tests whether something is defined in the interaction environment.
2023-08-14 09:18:54 -0400 < mnieper`> Most R7RS programs don't touch this at all.
2023-08-14 09:19:26 -0400 < mnieper`> I would also add a guard against a non symbol value. 
2023-08-14 09:19:54 -0400 < mnieper`> Because of (defined? '(blow-up-my-computer!))
2023-08-14 09:20:54 -0400 < mnieper`> Also note that R7RS allows all identifiers to be bound in the interaction environment.
2023-08-14 09:21:18 -0400 < mnieper`> So on some impls, it can be that `defined?' always returns #t.
2023-08-14 09:27:31 -0400 < mnieper`> acdw: Only in Scheme/Lisp, lists get the "default" append; in Visp and Sisp, it is different.
2023-08-14 09:48:33 -0400 < ecraven> mnieper`: how does a generic `append' lose type safety? you get errors when passing in incorrect arguments, just like you get errors *now* with non-generic append, when passing in incorrect arguments?
2023-08-14 09:51:42 -0400 < mnieper`> ecraven: My point is the following: If I know I should have string values, I can use string-append. If I use generic-append (where generic = list/vector/string) but have a programming error that produces vectors instead of strings, the error will surface late.
2023-08-14 09:52:28 -0400 < mnieper`> And if I do not necessarily have a string vector but just some container (e.g. when I program some generic algorithm), I want to have an append that is not restricted to just the three types.
2023-08-14 10:00:41 -0400 < mnieper`> ecraven: I believe in procedures that have simple types.  It is always a good idea trying to write down the type formally (and whether it would be reasonably expressible in standard static type systems).
2023-08-14 10:03:35 -0400 < mnieper`> For example, I can give `integer-list-length` a type in ML: int list -> int
2023-08-14 10:03:58 -0400 < mnieper`> Likewise, I can give a fully generic `list-length` a type: 'a list -> int
2023-08-14 10:04:26 -0400 < mnieper`> But I have a problem with integer/real-list-length, which either takes a list of integers or a list of reals.
2023-08-14 10:06:43 -0400 < ecraven> thanks for the explanation.
2023-08-14 10:06:55 -0400 < ecraven> so, we'd need a "protocol" for generic sequences, then we could have append? ;D
2023-08-14 10:08:55 -0400 < acdw> hm that is. good point mnieper` 
2023-08-14 10:09:14 -0400 < acdw> same w defined? I was only using that for some other kludge that didn't work anyway lol
2023-08-14 10:09:15 -0400 < mnieper`> ecraven: You mean what I could have! :D You are free to have what you want. 
2023-08-14 10:10:59 -0400 < ecraven> I'm conflicted with generic functions anyway.. one one hand, they are great, on the other, things get really complex and "unpredictable" very fast... (you import some library, it adds some new methods to a generic function, things go awry..)
2023-08-14 10:11:26 -0400 < mnieper`> But, yes, a generic append for general container types makes a lot more sense IMO.
2023-08-14 10:11:41 -0400 < mnieper`> See SRFI 225 for generic dictionaries where things are predictable.
2023-08-14 10:12:00 -0400 < ecraven> well, but then you have questions like: what should the type of the result be, if the arguments have different types
2023-08-14 10:12:11 -0400 < mnieper`> I do not agree with everything in SRFI 225 but it is much better than registering types at runtime IMO.
2023-08-14 10:12:33 -0400 < mnieper`> ecraven: For example, for append, you mean?
2023-08-14 10:13:37 -0400 < mnieper`> acdw: `defined?' should IMO be syntax so that it also works for locally lexically bound identifiers. You can build a version that works with SRFI 213.
2023-08-14 10:15:35 -0400 < ecraven> mnieper`: well, just because some library author thinks it's a good idea to add a method (append (number? x) (string? y)) where (append 123 "foo") -> "123foo" doesn't mean *I* want that in all my code...
2023-08-14 10:18:28 -0400 < ecraven> the fact that generic functions are (usually) global state and adding methods changes them globally is .. non-ideal.. but 
2023-08-14 10:18:38 -0400 < ecraven> I haven't seen any good alternatives to it so far :-/
2023-08-14 10:20:46 -0400 < acdw> mnieper`: that makes sense
2023-08-14 10:21:39 -0400 < mnieper`> ecraven: What do you think of SRFI 225's approach?
2023-08-14 10:22:16 -0400 < mnieper`> It would be (append type seq1 seq2 ... seqn)
2023-08-14 10:22:27 -0400 < mnieper`> (under a different name, of course).
2023-08-14 10:23:01 -0400 < mnieper`> "type" would describe the sequence type.
2023-08-14 12:44:01 -0400 < ecraven> mnieper`: that just packs all the relevant functions into `dto', and passes that around everywhere, right? I'm not a very big fan of that... (car <list> x) just doesn't seem right :P
2023-08-14 12:44:48 -0400 < ecraven> I'll look around, but I'd probably prefer some way to say *which* methods the generic function should actually have (but in some way that allows libraries to add the ones I *want* to see).. no idea whether / how that would be possible
2023-08-14 12:45:37 -0400 < ecraven> also, this won't work for functions that take multiple different types of objects (unless you pass in `(,dto0 ,dto1 ,dto2) and that's ... not cool :P)
2023-08-14 12:46:43 -0400 -!- mode/#scheme [+o Zipheir] by ChanServ
2023-08-14 12:46:55 -0400 -!- Irssi: No bans in channel #scheme
2023-08-14 12:50:52 -0400 -!- mode/#scheme [+b *!*cognemo@*.static.amis.net] by Zipheir
2023-08-14 12:50:52 -0400 -!- cognemo was kicked from #scheme by Zipheir [Excess JOIN/QUIT. Please fix your bouncer.]
2023-08-14 12:51:05 -0400 -!- mode/#scheme [-o Zipheir] by ChanServ
2023-08-14 13:35:40 -0400 < ecraven> hm.. I want (optionally) namespaced (as in not exported from a library) methods for generic functions :D
2023-08-14 13:35:45 -0400 < mnieper`> ecraven: Yes, it would be (car <list> x). 
2023-08-14 13:36:05 -0400 < mnieper`> But I think there is a solution to your issue (albeit not in SRFI 225).
2023-08-14 13:37:07 -0400 < mnieper`> A macro (import-sequence <list>) that expands into a bunch of definitions for the "sto" (sequence type object) <list>.
2023-08-14 13:38:02 -0400 < mnieper`> One of the definitions would be (define (car x) (generic-car sto x))
2023-08-14 13:38:46 -0400 < mnieper`> import-sequence would be unhygienic because car, ... are introduced as identifiers.
2023-08-14 13:39:04 -0400 < ecraven> but then car wouldn't be generic any more?
2023-08-14 13:39:04 -0400 < mnieper`> This is a Scheme approach to ML modules.
2023-08-14 13:39:48 -0400 < mnieper`> The locally (!) bound car no longer.
2023-08-14 13:40:19 -0400 < mnieper`> Say you want to define a generic procedure `generic-cadr'.
2023-08-14 13:40:55 -0400 < mnieper`> (define (generic-cadr sto seq) (import-sequence sto) (car (cdr seq)))
2023-08-14 13:40:57 -0400 < ecraven> hm.. I think what I'm pondering is some way to have *methods* exported from namespaces, and if you import them, they automagically create a *local* (non-exported) generic function, with all the methods for that GF that are imported put together.. so in each library you only see the methods that are actually imported into it (or defined explicitly in it)
2023-08-14 13:41:10 -0400 < ecraven> so the generic function itself would *not* be exported or shared
2023-08-14 13:41:14 -0400 < ecraven> that sounds insane though...
2023-08-14 13:42:28 -0400 < mnieper`> You mean something like importing string-length, vector-length and length should give you a locally define generic-length?
2023-08-14 13:42:32 -0400 < sham1> Doesn't guile do something akin to local generic procedures in GOOPS?
2023-08-14 13:43:02 -0400 < ecraven> mnieper`: exactly. so if you explicitly import bytevector-length, that is also added, but if you don't (but it is indirectly used somewhere), it doesn't end up polluting *your* generic-length
2023-08-14 13:43:04 -0400 < sham1> IIRC it does and it does some tricks to do stuff to avoid collisions
2023-08-14 13:43:13 -0400 < sham1> Like when importing from two libraries 
2023-08-14 13:43:47 -0400 < mnieper`> ecraven: But then your generic-length has again a complex type and would be untypeable in many static systems.
2023-08-14 13:44:33 -0400 < mnieper`> Besides, I don't see a use case here.
2023-08-14 13:46:53 -0400 < ecraven> hm.. the type would be completely specified by the sum of all imported methods for that library
2023-08-14 13:47:19 -0400 < ecraven> there's no way to change it at runtime (unlike "normal" generic functions)
2023-08-14 13:47:28 -0400 < mnieper`> ecraven: By why?
2023-08-14 13:48:00 -0400 < ecraven> hm.. however, this would now mean that I *cannot* actually add methods that other libraries see, without changing their import list.. :-/
2023-08-14 13:48:11 -0400 < ecraven> mnieper`: to prevent some arbitrary code adding 
2023-08-14 13:48:18 -0400 < ecraven> methods that I don't *want* to see
2023-08-14 13:48:39 -0400 < mnieper`> Example?
2023-08-14 13:49:41 -0400 < ecraven> you want (append (number? x) (string? x)) to implement your library, I want your library, but *not* that method
2023-08-14 13:49:48 -0400 < ecraven> (because it's bonkers :P)
2023-08-14 13:50:54 -0400 < ecraven> methods of generic functions "leak" outside of the library (by design, but there's no way to prevent it)
2023-08-14 13:53:45 -0400 < mnieper`> I understand the problem of leaking.
2023-08-14 13:54:04 -0400 < Zipheir> What is the meaning of 'method' here?
2023-08-14 13:54:08 -0400 < ecraven> maybe there could be a way of specifying *which* methods are meant to leak
2023-08-14 13:54:10 -0400 < ecraven> methods of generic functions
2023-08-14 13:54:19 -0400 < mnieper`> But your append example is indeed bonkers, so I would not make it easier to create such atrocities.
2023-08-14 13:54:22 -0400 < Zipheir> Which are what?
2023-08-14 13:55:03 -0400 < Zipheir> Specializations of a generic function to specific types?
2023-08-14 13:55:37 -0400 < ecraven> (define-generic-function append) (define-method (append (string? a) (string? b)) (string-append a b)) (define-method (append (vector? a) (vector? b)) (vector-append a b)) (define-method (append (list? a) (list? b)) (list-append a b))
2023-08-14 13:55:51 -0400 < ecraven> yes, but those aren't normally called specializations but methods, afaik
2023-08-14 13:56:14 -0400 < Zipheir> OK. I'm only familiar with methods of objects/classes.
2023-08-14 13:56:25 -0400 < Zipheir> OOP terminology is confusing to me.
2023-08-14 13:56:39 -0400 < ecraven> methods here are attached to generic functions (and can thus specialise on *any* parameter, not just the first), unlike the normal OOP you see
2023-08-14 13:59:13 -0400 < Zipheir> I see. So if you import a generic procedure, you get all of its (possibly crazy) specific implementations.
2023-08-14 13:59:36 -0400 < ecraven> well, anyone can add methods to it, you don't have any control over which ones you want to see
2023-08-14 13:59:47 -0400 < ecraven> and if you need one locally, there's no way to add it only locally
2023-08-14 14:00:15 -0400 < Zipheir> I suppose you'd just implement a wrapper or new procedure, in that case.
2023-08-14 14:00:29 -0400 < dpk> this was allegedly the main reason Racket rejected a (message receiver arg1 arg2 …) syntax for its OO system
2023-08-14 14:00:53 -0400 < dpk> despite the fact the syntax is orthogonal to the semantics
2023-08-14 14:01:17 -0400 < sham1> I'd probably look towards some version of CLOS if we want something like this, but I'm also biassed
2023-08-14 14:01:19 -0400 < dpk> (mostly!)
2023-08-14 14:01:31 -0400 < ecraven> dpk: hm.. how does this solve that?
2023-08-14 14:01:39 -0400 < ecraven> sham1: I don't think CLOS solves this in any way
2023-08-14 14:01:40 -0400 < Zipheir> ML-style module functors are one of my favorite solutions.
2023-08-14 14:02:11 -0400 < Zipheir> (To *one* problem of polymorphism.)
2023-08-14 14:02:20 -0400 < sham1> CLOS itself probably doesn't, but one could imagine a situation where a CLOS-like system would be able to do this
2023-08-14 14:02:23 -0400 < mnieper`> The approach to generic methods that ecraven describes does not work for methods with no arguments.
2023-08-14 14:02:29 -0400 < sham1> If anything, such a system would be quite scheme-y
2023-08-14 14:02:46 -0400 < mnieper`> Like a constructor for an empty sequence.
2023-08-14 14:03:00 -0400 < ecraven> mnieper`: sorry, I wasn't so much proposing as just idly thinking 
2023-08-14 14:03:56 -0400 < dpk> ecraven: the developers associated the syntax with ‘message‘ being a mutable generic function and thus having this stuff associated with it where you get a load of someone else’s behaviour attached to the function when you import their library
2023-08-14 14:04:28 -0400 < dpk> (in practice, CL users don’t seem to have any real problems with this, i should note, but if you’re a functional programming language ideologically, and want to optimize things statically, it’s less than ideal)
2023-08-14 14:04:57 -0400 < dpk> so Racket makes you use a ‘send’ macro to send a message, with single dispatch: (send receiver message arg1 arg2 …)
2023-08-14 14:05:05 -0400 < dpk> but it’s just syntax, really!
2023-08-14 14:05:39 -0400 < sham1> ((get-method 'name receiver) args ...)
2023-08-14 14:05:43 -0400 < Zipheir> It's all just syntax, really.
2023-08-14 14:05:46 -0400 < dpk> you can have the behaviour of a message statically attached to the class like they want, without reinventing the function-application wheel
2023-08-14 14:06:28 -0400 < sham1> The way I propose with the above is quite smalltalk in many ways
2023-08-14 14:07:15 -0400 < dpk> fwiw, i think you could solve the problem of other libraries importing random behaviour on top of your generic function with something like identifier properties
2023-08-14 14:07:21 -0400 < dpk> except they’d have to exist at run time, hmm
2023-08-14 14:08:20 -0400 < dpk> but you should be able to set things up so that you only get the methods you define or explicitly import for a given generic function in your library, while someone else’s library can have their own methods on the same generic function that don’t risk clobbering yours
2023-08-14 14:08:44 -0400 < dpk> (but, again, CLOS doesn’t seem to suffer this problem in practice, so it’s probably not worth thinking about it too much)
2023-08-14 14:08:53 -0400 < ecraven> well, you could introduce some sort of "parent" generic function, so if you want a method only locally, you create a child generic function, add the method, and it'll dispatch to the parent for anything but your local method...
2023-08-14 14:09:08 -0400 < ecraven> yea, this seems to not be a problem in reality
2023-08-14 14:09:30 -0400 < ecraven> it just feels.. strange to have so many things *not* have global state, and then generic functions (which can be so useful) *have* to have it :-/
2023-08-14 14:10:34 -0400 < dpk> something like Haskell’s type classes would be a more principled solution
2023-08-14 14:10:52 -0400 < ecraven> dpk: I was just reading up on those two hours ago ;)
2023-08-14 14:11:08 -0400 < mnieper`> At runtime, this is SRFI 225.
2023-08-14 14:12:42 -0400 < ecraven> we don't have records types that can be extended in r7rs-large, only in r6rs, right?
2023-08-14 14:13:07 -0400 < dpk> in Large, this is not yet decided
2023-08-14 14:13:07 -0400 < mnieper`> Depends on R6RS-subset-of-R7RS-large question.
2023-08-14 14:13:27 -0400 < dpk> small does not have record inheritance
2023-08-14 14:13:29 -0400 < mnieper`> No more questions on R7RS-large until this is decided, please.
2023-08-14 14:13:37 -0400 < mnieper`> :0
2023-08-14 14:13:40 -0400 < mnieper`> :)
2023-08-14 14:15:12 -0400 < mnieper`> ecraven: Until then just use R6RS.
2023-08-14 14:15:53 -0400 < dpk> some R7RS small implementations, like Chibi, also support SRFI 99, which provides inheritance in way similar to SRFI 9/R7RS small define-record-type
2023-08-14 14:16:08 -0400 < dpk> most of them, actually, according to https://docs.scheme.org/srfi/support/
2023-08-14 14:19:18 -0400 < dpk> surprised to see a check under MIT Scheme for SRFI 228 in that table
2023-08-14 14:23:24 -0400 < dpk> huh, indeed! not in a release yet, but it’s in the tree https://git.savannah.gnu.org/cgit/mit-scheme.git/commit/?id=b2c983aaa9e2142f49bbc5366417de9d16633dce
2023-08-14 14:23:32 -0400 < sham1> A vote on whether Foundations will be an R6RS implementation will be such a mess
2023-08-14 14:23:35 -0400 < sham1> I can already tell
2023-08-14 14:31:56 -0400 < Zipheir> Is that going to happen this year or next?
2023-08-14 14:32:17 -0400 < Zipheir> I can't remember when the last WG2 vote was.
2023-08-14 14:33:27 -0400 < sham1> I think it might have actually been the macro system one
2023-08-14 14:33:47 -0400 < dpk> i think it will be a little while yet before any major, final decisions are made about the Large language. we have some more procedural issues coming up, unfortunately
2023-08-14 14:33:48 -0400 < mnieper`> Problem with SRFI 99 is still its incompatibilty to R7RS-small.
2023-08-14 14:33:58 -0400 < dpk> mnieper`: this is true
2023-08-14 14:34:22 -0400 < dpk> nonetheless, pretty much every R7RS-small implementation supports it :D
2023-08-14 14:39:32 -0400 < mnieper`> dpk: Which procedural issues do you mean?
--- Day changed Tue Aug 15 2023
2023-08-15 01:56:58 -0400 < mnieper`> dpk: Which procedural issues do you mean?
2023-08-15 03:45:42 -0400 < dpk> mnieper`: there are personal issues involved, which i can’t discuss. as i said yesterday, my energy level for argument is currently not great. i think for the next few weeks it would probably be good for everyone involved in Large to focus on things that don’t require major decisions to be made about the overall direction of the language
2023-08-15 03:46:23 -0400 < dpk> semi-related: why is POSIX such a disaster
2023-08-15 03:46:44 -0400 < dave0> it's so very old
2023-08-15 03:46:49 -0400 < dpk> grumble grumble, Worse is Better, insert Lisp Machine rant here
2023-08-15 03:47:43 -0400 < dpk> it would be nice if we could have a way to isolate the current working directory in Scheme per-thread, like parameters
2023-08-15 03:49:38 -0400 < dpk> when i proposed that for my pared-down SRFI 170, jcowan pointed out an issue with that approach: if we ask implementations to simulate the current directory by a parameter, what happens if the directory is renamed or deleted by another process after the parameter is set, but before the Scheme process does a file operation dependent on the current working directory
2023-08-15 03:49:42 -0400 < mdhughes> At OS level I think that's per process.
2023-08-15 03:49:49 -0400 < dpk> POSIX is to blame, it turns out https://srfi.schemers.org/srfi-170/srfi-170.html#node_sec_3.5
2023-08-15 03:49:56 -0400 < dpk> mdhughes wins 5 points
2023-08-15 03:49:59 -0400 < sham1> We *can* but we'd have to emulate it in software just like Emacs for example does
2023-08-15 03:50:12 -0400 < dpk> sham1: how does Emacs solve that problem?
2023-08-15 03:50:43 -0400 < sham1> All commands and file operations work relative to current-directory
2023-08-15 03:50:51 -0400 < dpk> i was considering a (with-current-directory <path> <body>) form if a parameter object is an inviable approach, but the issue is unchanged
2023-08-15 03:51:08 -0400 < dpk> sham1: i mean how does it solve the problem of what if the directory disappears in the meanwhile?
2023-08-15 03:51:35 -0400  * dpk tests it in her Emacs
2023-08-15 03:53:01 -0400 < sham1> Could always hold a reference to a directory while it's in use, so even if it gets removed or moved, you won't get screwed over
2023-08-15 03:53:25 -0400 < dpk> is there a way in POSIX to change to a directory you hold a handle to?
2023-08-15 03:53:56 -0400 < dpk> oh, yes, there is!
2023-08-15 03:53:59 -0400 < dpk> fchdir(2)
2023-08-15 03:54:13 -0400 < dpk> so maybe this is workable after all
2023-08-15 03:54:19 -0400 < mnieper`> dpk: Use a SRFI 226 parameter-like object for the current directory.
2023-08-15 03:54:47 -0400 < mnieper`> It won't be per thread.
2023-08-15 03:55:08 -0400 < mnieper`> Leave further abstraction to the user.
2023-08-15 03:55:59 -0400  * dpk tries out what happens if you fchdir to a directory you hold a handle to, but which no longer exists in the filesystem tree
2023-08-15 03:57:57 -0400 < lockywolf> just don't let it disappear
2023-08-15 03:58:11 -0400 < lockywolf> does anyone here speak Maxima?
2023-08-15 03:58:12 -0400 < jcowan> mnieper`: It does not make sense for zero-argument functions to be generic, as they have nothing to dispatch on.
2023-08-15 03:58:43 -0400 < jcowan> I know of no system in which constructors are generic
2023-08-15 03:59:06 -0400 < sham1> Also for instantiation you'd expect to be able to name the concrete type 
2023-08-15 04:00:09 -0400 < lockywolf> dpk: I think that as long as anyone is holding a handle, the directory will not be garbage-collected
2023-08-15 04:00:11 -0400 < jcowan> At one point, CL had fngeric-function-let and anonymous-generic-function, but they were removed because they don't give you anything useful
2023-08-15 04:00:31 -0400 < lockywolf> maxima has extremely weird scoping rules
2023-08-15 04:02:12 -0400 < mdhughes> As long as something has an open handle, the node for the directory won't be deleted, it's just unlinked.
2023-08-15 04:02:28 -0400 < sham1> Yeah, same as files
2023-08-15 04:02:41 -0400 < sham1> Of course in older UNIXes, directories *were* files
2023-08-15 04:02:42 -0400 < mdhughes> As soon as you close, it'll be GC'd/wiped depending on your filesystem.
2023-08-15 04:02:45 -0400 < dpk> jcowan: it appears sham1 has found a solution to the problem of making the Scheme current directory isolatable per-thread
2023-08-15 04:03:06 -0400 < mnieper`> jcowan: IMO handling genericity in this way (without type objects) is just wrong.  Abstract types (like sequences, dictionaries, ...) do have constructors (possibly of zero arguments) and it is important to have then in a generic fashion because the general generic algorithm needs them.
2023-08-15 04:03:16 -0400 < dpk> it’ll be somewhat involved to GC that file handle on the Scheme side, given the presence of continuations, but not beyond the wit of Lispers
2023-08-15 04:03:31 -0400 < dpk> mnieper`: have you ever used CLOS or a Scheme clone of it?
2023-08-15 04:03:37 -0400 < jcowan> Of course, except that when you spawn a process from a thread, you cannot be sure that the new process will inherit the correct current directory.
2023-08-15 04:03:45 -0400 < mnieper`> dpk: No.
2023-08-15 04:04:09 -0400 < mnieper`> dpk: I am not a CLer.
2023-08-15 04:04:22 -0400 < dpk> mnieper`: oh, this reminds me i recently thought you might like to read The Art of the Metaobject Protocol. it’s more about this kind of multi-dispatch thing, but you might find it relevant to your work on record types
2023-08-15 04:04:41 -0400 < dpk> jcowan: how do you mean?
2023-08-15 04:05:10 -0400 < jcowan> [RPG:] The reason that lexical generic functions are relatively less useful than lexical functions is that with a generic function you are expecting that someone will extend it when they extend the ontology of the world, and you want to get a hold of those extensions for free.  The mechanism for the for-freeness is the global namespace for generic function names. When you make those names lexical you lose this feature. Presumably this 
2023-08-15 04:05:10 -0400 < jcowan> is the primary nice feature of OOP.
2023-08-15 04:05:25 -0400 < mnieper`> An approach to generic interfaces in Scheme should not fall behind what can be done with Haskell type classes or ML functors.
2023-08-15 04:05:38 -0400 < sham1> If you spawn a process, you'll just set the cwd of the process to the cwd indicated by the parameter
2023-08-15 04:05:54 -0400 < sham1> mnieper`: and CLOS overtakes those 
2023-08-15 04:06:22 -0400 < jcowan> There is no reason to expect one to be able to emulate the other.  The approach taken in SRFI 225 is Haskellish, the approach taken by chibi-generic and fast-generic is Javaish.  Both have their uses.
2023-08-15 04:08:40 -0400 < lockywolf> jcowan: what is "fast-generic"?
2023-08-15 04:09:01 -0400 < jcowan> A generic function library available on Chicken.
2023-08-15 04:09:16 -0400 < lockywolf> chibi-generic is extremely simple, even though I had difficulties with using (next-method) in macros
2023-08-15 04:10:05 -0400 < jcowan> The main issue with either of them is that they don't deal with inheritance.
2023-08-15 04:10:49 -0400 < jcowan> (not just record inheritance, but inheritance in general; a generic function defined on integer? is subsumed by a generic function defined on number?.
2023-08-15 04:10:53 -0400 < jcowan> )
2023-08-15 04:11:37 -0400 < jcowan> That of course has to be declared, it can't be inferred.
2023-08-15 04:11:54 -0400 < sham1> Then again, I'd probably want for the integer? one to be dispatched when the argument is an integer for example due to efficiency 
2023-08-15 04:12:51 -0400 < jcowan> Just so.  And not merely for efficiency, but for correctness.
2023-08-15 04:13:48 -0400 < sham1> By liskov substitution principle I probably should be able to have the number? version be correct even for integers
2023-08-15 04:13:51 -0400 < jcowan> (I can never keep straight whether number? subsumes integer? or the other way around.)
2023-08-15 04:14:10 -0400 < sham1> integer? <: number?
2023-08-15 04:14:12 -0400 < lockywolf> I guess, neither of those
2023-08-15 04:14:28 -0400 < lockywolf> like, square is not a subclass of rectangle
2023-08-15 04:15:01 -0400 < jcowan> It depends.  Mutable squares are not a subclass of mutable rectangles, but immutable squares are a subclass of immutable rectangles.
2023-08-15 04:15:27 -0400 < lockywolf> perhaps, it is different for numbers too?
2023-08-15 04:15:39 -0400 < jcowan> Well, numbers are immutable by definition.
2023-08-15 04:15:44 -0400 < lockywolf> hm...
2023-08-15 04:16:06 -0400 < jcowan> Liskov doesn't deal with immutable objects, so the LSP isn't applicable to them.
2023-08-15 04:16:09 -0400 < lockywolf> in Scheme, or in general?
2023-08-15 04:16:49 -0400 < jcowan> In general, unless you are writing in a language in which (set! 5 3) makes sense
2023-08-15 04:17:05 -0400 < jcowan> (an early Fortran compiler had just such a bug)
2023-08-15 04:18:00 -0400 < sham1> Well I'd expect for a number to be substitutable by an integer
2023-08-15 04:19:41 -0400 < sham1> We can even see this in type theory. Integers are a proper subtype of numbers after all
2023-08-15 04:20:51 -0400 < dpk> jcowan: what did the Fortran compiler do when asked to set 5 to 3?
2023-08-15 04:21:54 -0400 < sham1> LSB just says that you can substitute a subtype's value for a supertype. Which is why the circle-ellipse problem exists specifically for mutable circles and ellipses and why in those cases you'd probably prefer to not have them be in an inheritance relation
2023-08-15 04:22:48 -0400 < jcowan> More precisely, it worked like this.  Fortran uses call-by-reference, so if we have a subroutine a(i) that says i = 5, then a call on a passing in the variable j will cause j to be set to 5.
2023-08-15 04:23:40 -0400 < jcowan> Now if what is passed is not a variable but an arbitrary expression, a nameless variable is created and that is passed in, so the i = 5 does not alter anything in the caller.
2023-08-15 04:24:24 -0400 < jcowan> The bug, however, would use the same location for 5 that would be used to hold any constant 5, so that after the call, the constant would be munged.
2023-08-15 04:26:12 -0400 < sham1> And this is why "pass-by-reference" by default is bad
2023-08-15 04:27:40 -0400 < jcowan> No, it's perfectly fine as long as random constants are not assimilated to constant arguments of the same value.
2023-08-15 04:32:59 -0400 < mnieper`> For single argument dispatch, I can live with generics. In this case, responsibilities are clear. Specializations of methods are defined where the type is defined.
2023-08-15 04:35:04 -0400 < jackdaniel> I've found this post about OOP very illuminating at the time: https://groups.google.com/g/comp.lang.lisp/c/FMvNGxgd8Dk/m/_rN9cGrD9GAJ
2023-08-15 04:36:01 -0400 < jackdaniel> (at the time I've read it, not when it was written; I've picked CL in 2010s)
2023-08-15 04:36:11 -0400 < sham1> I expected Naggum and wasn't disappointed 
2023-08-15 04:49:58 -0400 < mdhughes> The OOP I like best is either Self, which JS copied, or Julia's model. You bind methods with argument types, so foo(object) does the generic thing, foo(Integer) specific to Integers.
2023-08-15 04:50:43 -0400 < lockywolf> "try to combine static typic and object-orientation, which is in fact theoretically unsound"
2023-08-15 04:50:58 -0400 < lockywolf> C++ left chat in tears
2023-08-15 04:51:06 -0400 < mdhughes> Julia uses its type system but it's very loosey-goosey. Any other impl just needs a registry for overloading method names by predicates.
2023-08-15 04:51:29 -0400 < lockywolf> the definition of OOP is what C++ has
2023-08-15 04:51:42 -0400 < sham1> lockywolf: I don't think C++ cares much about being unsound
2023-08-15 04:51:43 -0400 < mdhughes> Simula may disagree.
2023-08-15 04:53:07 -0400 < dpk> https://gitlab.com/dpk/presrfis/-/blob/master/per-thread-current-directory.md
2023-08-15 04:53:33 -0400 < dpk> if anyone knows any POSIX wizards who might be able to look at this and tell us if there’s anything disastrously wrong with it, please send it to them
2023-08-15 04:54:12 -0400 < dpk> i’ve tried to word it so that it makes sense to non-lispers
2023-08-15 04:55:25 -0400 < lockywolf> " It can be very hard to deal with freedom if what you were looking for in an OO system was a way to cage yourself in." <- this is an interesting ideological statement, but usually we want to "cage" not just ourselves, but our teammates
2023-08-15 04:55:35 -0400 < jackdaniel> lockywolf: I've got disillusioned with C++ as OOP language when I've realized, that I can't effectively subclass a class defined in a shared library
2023-08-15 04:56:00 -0400 < lockywolf> c++ classes are compile-time thing, not a runtime thing
2023-08-15 04:56:34 -0400 < jackdaniel> and?
2023-08-15 04:56:45 -0400 < lockywolf> how can you subclass something which does not exist?
2023-08-15 04:56:53 -0400 < jackdaniel> I know how it works (more or less, I doubt there are many people who really know how c++ truly works in detail)
2023-08-15 04:57:12 -0400 < jackdaniel> well, that's what I'm saying -- OOP in C++ does not exist :)
2023-08-15 04:57:20 -0400 < lockywolf> I mean, I do not mean do defend C++
2023-08-15 04:57:51 -0400 < lockywolf> OOP in C++ exists via a "worse is better" paradigm
2023-08-15 04:58:19 -0400 < lockywolf> moreover, it makes people supply libraries in code, not in binary, which is nice for code freedom
2023-08-15 04:58:44 -0400 < jackdaniel> that depends where you set the bar of "having oop"
2023-08-15 04:58:52 -0400 < dpk> if you’d wanted to make people supply libraries in code, rather than in binary, you’d have used a Lisp Machine instead of Unix
2023-08-15 04:59:03 -0400 < mdhughes> dpk: Seems OK, I'm not sure what the performance implications are. I'm very dubious that GC will run & release the FD anytime soon; it really needs to be guarded, and we ought to have real finalizers to do this.
2023-08-15 04:59:04 -0400 < dpk> (also acceptable: Smalltalk)
2023-08-15 04:59:05 -0400 < jcowan> dpk: you want to use openat
2023-08-15 04:59:17 -0400 < sham1> Yeah, openat is explicitly made for this
2023-08-15 04:59:30 -0400 < sham1> WinAPI also has an equivalent system which is nice
2023-08-15 04:59:47 -0400 < jcowan> sorry, ww
2023-08-15 05:00:15 -0400 < lockywolf> jackdaniel: well, I think that seeing OOP as a way to "cage" your teammates is fairly useful
2023-08-15 05:01:52 -0400 < dpk> ahhh, yes, thanks
2023-08-15 05:02:08 -0400 < mdhughes> OOP isn't a cage, silly things like Java's "private" and "final" are just self-harm. It's supposed to just be a way to make black box components with behavior.
2023-08-15 05:02:17 -0400 < lockywolf> I mean, the main selling point of OOP a long time ago was basically "make each colleague responsible for a class, and only make meetings about class interfaces"
2023-08-15 05:02:36 -0400 < sham1> For most things you wouldn't even need fchdir. Although when doing subprocesses you'd want that
2023-08-15 05:02:39 -0400 < mdhughes> Like physical things do; we make a model car, and push it, and it keeps rolling because that's what the internal state says to do. Push a jack in a box, and it bounces around.
2023-08-15 05:03:11 -0400 < lockywolf> mdhughes: you only need black boxes if you base your work on the principle of the separation of labour
2023-08-15 05:03:27 -0400 < lockywolf> like, "work methodology"
2023-08-15 05:03:37 -0400 < mdhughes> No, even for solo projects, it helps isolate behavior in one place instead of hundreds of global variables.
2023-08-15 05:03:51 -0400 < sham1> Which is also what you want because it makes cooperation easier
2023-08-15 05:04:04 -0400 < lockywolf> I just love how OOP happened to come to China
2023-08-15 05:04:21 -0400 < mdhughes> Coworkers are a silly thing, too, but I can't help you with those. I quit having them.
2023-08-15 05:05:35 -0400 < lockywolf> The brilliant guy who was translating the material looked in the dictionary for the translation of "object",  and found the word "对象"
2023-08-15 05:06:22 -0400 < lockywolf> Which means "objective"
2023-08-15 05:06:33 -0400 < lockywolf> "objective", as in "target, goal, aim"
2023-08-15 05:07:05 -0400 < lockywolf> So, in China, there is no "object-oriented programming", there is "goal-oriented programming"
2023-08-15 05:19:57 -0400 < dpk> lockywolf: heh!
2023-08-15 05:22:11 -0400 < dpk> comp.lang.lisp in 2002, where you could find people saying things like ‘Lisp actually *is* an object oriented language, unlike Java’
2023-08-15 05:22:58 -0400 < jackdaniel> isn't the truth a quality that is independent of time? ;)
2023-08-15 05:26:48 -0400 < dpk> a truth independent of time: smug lisp weenies being smug lisp weenies
2023-08-15 05:29:59 -0400 < jackdaniel> cliche phrases are also independent of time it seems!
2023-08-15 05:37:42 -0400 < dpk> jcowan, mnieper: keeping an eye out on how Lassi responds to my request not to continue fighting an argument he lost last year. if he gets more aggressive (i’ve tried to keep the temperature of my response as low as possible to avoid that), i propose to ban him from the issue tracker. it’s perhaps a little hasty, but it’s not as if we haven’t heard all this exact stuff before on the wg2 mailing list, and also on some SRFI lists (i had 
2023-08-15 05:37:42 -0400 < dpk> to ask him to pipe down on the SRFI 228 list, iirc)
2023-08-15 05:45:56 -0400 < mnieper`> dpk: Should the Foundations encompass enough so that they can serve as a language on their own (R7RS-mid as sham1 coined it), Lassi should have everything he needs to pursue his vision. What I mean is that there would be nothing to fight for him.
2023-08-15 05:47:31 -0400 < dpk> i said as much, that we want to support alternative preludes and standard libraries. as you say, in reality, we would have to take active steps to *prevent* such things being possible, which we won’t do because it would be silly. but having that wish, phrased more positively, on our agenda is better, i think
2023-08-15 05:47:45 -0400 < mnieper`> (I think I see how he arrives at his points, but I certainly do not see why he foresees the future in such absolute terms. But this is maybe just the way he writes.)
2023-08-15 05:54:47 -0400 < lockywolf> dpk: what are you talking about?
2023-08-15 05:59:02 -0400 < lockywolf> dpk: if you are talking about the issue 127, then I would say that it is you who is overly aggressive there, not him, especially since it is a "pie-in-the-sky" issue
2023-08-15 05:59:12 -0400 < lockywolf> *are
2023-08-15 06:00:25 -0400 < mnieper`> dpk: What do you think of moving the discussion about "Scheme Live/Batteries/whatever" just to some new issue where everyone who wants can let off steam?
2023-08-15 06:00:55 -0400 < lockywolf> Scheme seems to be trying to have a cake and eat it. Be a "small easy to implement language", but have large batteries nevertheless. This contradiction inherently cannot be resolved.
2023-08-15 06:00:57 -0400 < mnieper`> It is not really what I had in mind with R\omegaRS.
2023-08-15 06:01:11 -0400 < mnieper`> That discussion, I mean.
2023-08-15 06:01:16 -0400 < lockywolf> however, we already had a language which tried to solve the same problem, this language is called C++
2023-08-15 06:02:08 -0400 < lockywolf> STL _is_ a part of standard C++
2023-08-15 06:02:27 -0400 < lockywolf> that may be an argument that can convince Lassi of the necessity of Batteries in the standard
2023-08-15 06:02:51 -0400 < lockywolf> however, there are less STL implementations, than there are C++ compilers
2023-08-15 06:03:43 -0400 < dave0> isnt rust the new language du jour?
2023-08-15 06:04:13 -0400 < lockywolf> correct me if I am wrong, but Java EE, and Erlang's OTP are the same thing, so, seemingly, Scheme is not at all the first language to hit this problem
2023-08-15 06:05:47 -0400 < lockywolf> r6rs is also split into the core and the libraries
2023-08-15 06:06:01 -0400 < sham1> Well J2EE no longer really exists as such, but the point is of course that even though the batteries wouldn't be part of the *base* language as such, they'd be part of the platform
2023-08-15 06:06:02 -0400 < dpk> mnieper`: that’s probably a good idea
2023-08-15 06:06:06 -0400 < lockywolf> for some reason people do not seem to mention it
2023-08-15 06:06:50 -0400 < lockywolf> sham1: there is that "jakarta ee" thingy
2023-08-15 06:07:15 -0400 < sham1> Yeah, but it's not part of Java anymore as such
2023-08-15 06:07:39 -0400 < sham1> That's why it was renamed to Jakarta EE when it was transferred to the Eclipse Foundation 
2023-08-15 06:07:50 -0400 < lockywolf> wasn't r7rs planned to be designed in the similar way? r7rs small being the core, and r7rs-large being the batteries?
2023-08-15 06:08:16 -0400 < sham1> Well the thing with R7-Large is that many of the batteries we want also need stuff in the core
2023-08-15 06:08:53 -0400 < lockywolf> I think that the original scope is better
2023-08-15 06:09:07 -0400 < sham1> That's why I use the language of R7-small for the small stuff, R7-mid/Foundations for the "core" stuff in R7RS and then R7-Large for Foundations+Batteries
2023-08-15 06:09:31 -0400 < sham1> So R7-small is the core of the core
2023-08-15 06:09:33 -0400 < lockywolf> I don't think that this is clear
2023-08-15 06:09:36 -0400 < sham1> Inner core
2023-08-15 06:09:49 -0400 < lockywolf> the "core of the core" is not the idea I can find justifiable
2023-08-15 06:10:11 -0400 < lockywolf> This problem cannot be solved
2023-08-15 06:10:35 -0400 < lockywolf> the evolution of the core should not be called r7rs
2023-08-15 06:10:51 -0400 < lockywolf> if the core needs to evolve, it should be called r8rs-small
2023-08-15 06:10:52 -0400 < sham1> Well the idea was always that the small language would essentially just be R5RS with some adjustments, which would be used for education and such, and R7RS-large would expand on thst
2023-08-15 06:11:33 -0400 < lockywolf> java2me
2023-08-15 06:11:45 -0400 < sham1> Essentially 
2023-08-15 06:11:57 -0400 < lockywolf> I don't think it should be called r7rs any more
2023-08-15 06:12:15 -0400 < lockywolf> again, it is fine to provide a "stripped-down" profile of a language for teaching
2023-08-15 06:12:21 -0400 < sham1> Well that's why it's "small"
2023-08-15 06:12:33 -0400 < lockywolf> no, this name is already taken
2023-08-15 06:12:45 -0400 < lockywolf> java2se was not built on top of java2me
2023-08-15 06:12:58 -0400 < lockywolf> even though java2ee was built on top of java2se
2023-08-15 06:13:02 -0400 < sham1> Well Scheme is also not Java
2023-08-15 06:13:36 -0400 < lockywolf> no, but making mistakes just because we want to not learn on other people's experience is stupid
2023-08-15 06:14:01 -0400 < dpk> the suggestion keeps coming up, but i have no idea why anyone thinks that renaming this to R8RS would solve anything at all
2023-08-15 06:14:20 -0400 < lockywolf> dpk: renaming "what exactly"?
2023-08-15 06:14:22 -0400 < dpk> changing the name doesn’t change any of the underlying conflicts
2023-08-15 06:14:32 -0400 < lockywolf> changing the name of what?
2023-08-15 06:14:52 -0400 < sham1> R7-large
2023-08-15 06:14:52 -0400 < dpk> 12:10:51 <lockywolf> if the core needs to evolve, it should be called r8rs-small
2023-08-15 06:14:59 -0400 < lockywolf> making it easy for people to understand what is going without digging in peculiar language is important
2023-08-15 06:15:28 -0400 < dpk> R7RS small and R7RS Large serve such different needs that the ‘core’, as you put it, has to be evolved in the latter
2023-08-15 06:15:59 -0400 < dpk> R7RS small defines almost no situations in which an error is guaranteed to be signalled, for example
2023-08-15 06:16:29 -0400 < lockywolf> because people have assumptions
2023-08-15 06:16:30 -0400 < dpk> e.g. an R7RS small implementation where bounds checking is not done, like in C, is perfectly compliant with the small specification
2023-08-15 06:16:50 -0400 < lockywolf> dpk: where are the batteries for r7rs-small?
2023-08-15 06:16:51 -0400 < sham1> An important part is also that Foundations provides R7RS-small as part of itself
2023-08-15 06:16:52 -0400 < dpk> for the large language intended to be useful for writing large-scale applications in, this is obviously not ideal
2023-08-15 06:17:10 -0400 < lockywolf> again, where are the batteries for r7rs-small?
2023-08-15 06:17:15 -0400 < sham1> SRFI process
2023-08-15 06:17:16 -0400 < dpk> what are you talking about?
2023-08-15 06:17:20 -0400 < sham1> Also snow
2023-08-15 06:17:28 -0400 < dpk> there are quite a few ‘batteries’ in the small spec
2023-08-15 06:18:05 -0400 < dpk> if you want a purist idea of the ‘core’, there’s no reason the small spec needs to include map or for-each, for example. you have cons, car, and cdr. write it yourself
2023-08-15 06:18:21 -0400 < lockywolf> I don't want to have a purist idea of the core
2023-08-15 06:18:30 -0400 < lockywolf> the core is already there and it is set in stone
2023-08-15 06:19:31 -0400 < lockywolf> I want OTP 7.0, which is "batteries which can be piled on top of r7rs-small to get a practical system, without evolving the core"
2023-08-15 06:20:00 -0400 < sham1> But how would you provide certain batteries without syntax-case for example 
2023-08-15 06:20:15 -0400 < lockywolf> sham1: I would not
2023-08-15 06:20:20 -0400 < lockywolf> that is the point
2023-08-15 06:20:30 -0400 < dpk> many SRFIs work on R7RS small, as sham1 says. your favourite small language implementation probably includes a decent number of them
2023-08-15 06:20:42 -0400 < sham1> Well in that case the large language would be quite underwhelming 
2023-08-15 06:21:14 -0400 < lockywolf> sham1: of course! which is fine, because stl 0.99 was also underwhelming
2023-08-15 06:21:50 -0400 < sham1> R7RS-small is an unfortunate (political) compromise 
2023-08-15 06:22:01 -0400 < lockywolf> which incurs expenses
2023-08-15 06:22:09 -0400 < sham1> Because some people thought R6RS too big
2023-08-15 06:22:10 -0400 < lockywolf> compromises are not free
2023-08-15 06:22:29 -0400 < dpk> lockywolf: this is an approach we rejected as unworkable last year. i have no interest in rehashing those arguments. the small language is not there to do what you think it’s there to do. (well, at least as far as i can tell what you think it’s there to do.) if you’re not implementing Scheme as a school project, or for an environment like a microcontroller, the small language spec is not what you are looking for
2023-08-15 06:22:53 -0400 < lockywolf> dpk: which is fine, since there is r6rs
2023-08-15 06:23:06 -0400 < lockywolf> which is already split into r6rs and r6rs-lib
2023-08-15 06:23:35 -0400 < sham1> R7RS-large would probably also have R6RS as part of it. At least that seems like there is some consensus there
2023-08-15 06:24:00 -0400 < sham1> We haven't had a vote for it, but it seems more likely than not
2023-08-15 06:25:00 -0400 < lockywolf> if you want a pedagogical justification, then it is the following: your student is implementing r7rs, and you are having a carrot before his nose "when you finish your r7rs-small implementation, you will be able to run all that well crafted and self-consistent set of batteries on top of it, and instantly make your tiny school-level interpreter practical"
2023-08-15 06:27:12 -0400 < sham1> Well as stated, the small language is useful even outside of the pedagogical setting. For example in embedded systems, assuming you wouldn't use X, Assembly or Forth there
2023-08-15 06:27:14 -0400 < lockywolf> you won't save much work if you jump from "batteries which can work on top of r7rs-small" to "batteries which work on r7rs-foundations"
2023-08-15 06:27:15 -0400 < sham1> C*
2023-08-15 06:27:27 -0400 < lockywolf> sham1: I see no problem
2023-08-15 06:28:23 -0400 < sham1> Well I do. It's not like you could strip down R6RS for microcontrollers even though you could argue all kinds of environmental constraints 
2023-08-15 06:28:44 -0400 < sham1> You also couldn't do that with R7RS-Large or Foundations
2023-08-15 06:28:46 -0400 < dpk> lockywolf: r6rs and r6rs-lib are interdependent in a way that R7RS Foundations and Batteries will not be. nothing in the Batteries will change the semantics of the Foundations, unlike r6rs-lib where syntax-case, set-c[ad]r! etc. cannot be implemented in terms of r6rs
2023-08-15 06:29:11 -0400 < lockywolf> dpk: which seems the right thing to do
2023-08-15 06:29:30 -0400 < lockywolf> sham1: how does c++ for microcontrollers work?
2023-08-15 06:29:47 -0400 < sham1> It doesn't 
2023-08-15 06:29:48 -0400 < dpk> doing it this way means that if you implement the Foundations, the Batteries will come for free through portable sample implementations. implementors may have their reasons for rejecting the sample implementations and coming up with their own, but they won’t need to
2023-08-15 06:29:50 -0400 < mnieper`> lockywolf: A C++ compiler can be a cross-compiler.
2023-08-15 06:29:51 -0400 < lockywolf> it does
2023-08-15 06:29:52 -0400 < sham1> It's not C++
2023-08-15 06:29:56 -0400 < dpk> that’s about the last i can be bothered saying on this subject
2023-08-15 06:30:05 -0400 < mnieper`> For Scheme with procedural macros and eval, it is not the case.
2023-08-15 06:30:14 -0400 < sham1> For example many of those compilers disable core language features such as exceptions
2023-08-15 06:30:28 -0400 < lockywolf> sham1: so do that
2023-08-15 06:30:40 -0400 < lockywolf> this is the right approach
2023-08-15 06:31:02 -0400 < mnieper`> The charters for R7RS-small and -large assume(d) that both languages are developed in parallel.
2023-08-15 06:31:08 -0400 < mnieper`> This did not happen.
2023-08-15 06:31:41 -0400 < mnieper`> If it had happened, R7RS-small might have become what now the Foundations are going to be.
2023-08-15 06:32:35 -0400 < lockywolf> I seriously suggest re-naming it to r8rs
2023-08-15 06:32:51 -0400 < mnieper`> Without the Foundations as intermediate "glue", the relation between R7RS-small and -large is as the relation between R6RS and "R6RS-lib"
2023-08-15 06:33:12 -0400 < mnieper`> As dpk described above.
2023-08-15 06:34:20 -0400 < lockywolf> again, I don't see how admitting that r7rs-large failed, and starting it "from scratch, but with its experience in mind" would be a bad thing
2023-08-15 06:34:38 -0400 < sham1> As I said last night, the vote on whether Foundations will also include R6RS, will be a mess. I think we're now seeing some prelude on that 
2023-08-15 06:34:51 -0400 < lockywolf> why would you want that?
2023-08-15 06:34:52 -0400 < mnieper`> lockywolf: re R8RS: We don't have to do the renaming or foresee one right now.
2023-08-15 06:35:07 -0400 < mnieper`> These are just names, after all.
2023-08-15 06:35:31 -0400 < lockywolf> mnieper`: Schemers are expected to be picky about naming hygiene :)
2023-08-15 06:35:49 -0400 < mnieper`> If, when the product is ready, we decide that Foundations = R8RS and Foundations + Batteries = R8RS-large, this does not mean that R7RS-large has failed.
2023-08-15 06:36:01 -0400 < mnieper`> On the contrary, the process will have delivered a product.
2023-08-15 06:37:24 -0400 < lockywolf> how hard would it be to actually review and typeset an unofficial "r7rs-large-beta", based only on what r7rs-small can do in the core, and including as much libraries voted in during the docket voting period?
2023-08-15 06:37:27 -0400 < mnieper`> lockywolf: Because the Foundations will have to be as large as R6RS anyway, because it can be a way to heal the schism, and because R6RS is not worse than R7RS-small.
2023-08-15 06:37:45 -0400 < lockywolf> Vincent Manis did the typesetting for Red,  I think? or maybe for Orange too?
2023-08-15 06:37:56 -0400 < mnieper`> (was answer to why would you want it)
2023-08-15 06:38:07 -0400 < sham1> Seems to me that we've just given up on dockets, honestly
2023-08-15 06:39:07 -0400 < lockywolf> I mean, I do see why it might be painful to do the job of selecting libraries, and typesetting the report only for it to be superseded by the new F+B standard very soon
2023-08-15 06:39:50 -0400 < lockywolf> mnieper`: sorry, I don't yet understand why only F has to cover r6rs, not F+B
2023-08-15 06:40:38 -0400 < mnieper`> NB: It is my personal opinion that the Foundations should encompass R7RS-small and R6RS on an equal footing.  I see why it can make sense to call the resulting product R8RS.
2023-08-15 06:41:02 -0400 < mnieper`> lockywolf: What do you exactly mean?
2023-08-15 06:42:28 -0400 < lockywolf> mnieper`: I do not see why Foundations should cover r6rs, not Foundations+Batteries should cover r6rs. Presumably, implementations which already provide r6rs, are ready for the "large language", and will be likely providing Batteries
2023-08-15 06:43:20 -0400 < mnieper`> R6RS is smaller than the Foundations.  So pure R6RS impls won't be able to support the Batteries.
2023-08-15 06:43:46 -0400 < lockywolf> ?
2023-08-15 06:44:13 -0400 < sham1> Foundations isn't *just* R6RS
2023-08-15 06:44:40 -0400 < lockywolf> and?
2023-08-15 06:44:41 -0400 < sham1> It will also have R7RS-small inside, as well as some other more primitive stuff, such as ephemerons
2023-08-15 06:44:58 -0400 < sham1> So an R6RS implementation would have to implement all of that as well
2023-08-15 06:45:07 -0400 < lockywolf> so?
2023-08-15 06:45:15 -0400 < lockywolf> like, how is this related to my question?
2023-08-15 06:45:42 -0400 < sham1> Like this: I do not see why Foundations should cover r6rs, not Foundations+Batteries should cover r6rs.
2023-08-15 06:46:01 -0400 < lockywolf> I still do not see how this answers my question
2023-08-15 06:46:02 -0400 < sham1> You simply can't split it r6 into foundations and batteries
2023-08-15 06:46:08 -0400 < lockywolf> and even so
2023-08-15 06:46:18 -0400 < sham1> Split ry*
2023-08-15 06:46:23 -0400 < sham1> Hm
2023-08-15 06:46:30 -0400 < lockywolf> of course, r6rs implementation will have to evolve to support the new standard
2023-08-15 06:46:31 -0400 < sham1> Keyboard does weird stuff again
2023-08-15 06:46:31 -0400 < mnieper`> lockywolf: I still don't understand the second part of your question, lockywolf 
2023-08-15 06:48:20 -0400 < lockywolf> mnieper`: my question is the following: r6rs implementations are guys, who like the idea of a "large language". we can safely assume that they will provide both Foundations, and Batteries, and a lot more on top of that, so as long as Foundations+Batteries cover what is currently r6rs, it is irrelevant how exactly Foundations and Batteries are split among them
2023-08-15 06:48:46 -0400 < lockywolf> so when the separation between F and B is considered, why would we _ever_ need to consider r6rs?
2023-08-15 06:50:33 -0400 < dpk> hmm, there are more xat variants of x system calls than i thought
2023-08-15 06:50:59 -0400 < dpk> a lock is still needed for some operations, though (jcowan mentioned posix_spawn)
2023-08-15 06:51:13 -0400 < lockywolf> the only people who care about the Foundations and Batteries not being the same thing, are people who want to write as little code as necessary, that is, students and microcontroller guys, people who want to only implement Foundations
2023-08-15 06:53:43 -0400 < mnieper`> lockywolf: I believe your assumption about R6RS implementers/users is quite wrong.
2023-08-15 06:53:50 -0400 < lockywolf> okay, fine
2023-08-15 06:53:55 -0400 < mnieper`> R6RS is small when compared to R7RS-large.
2023-08-15 06:54:00 -0400 < sham1> dpk: you could also use fork and exec manually, but that's gross
2023-08-15 06:54:08 -0400 < mnieper`> R6RS is, in fact, not much larger than R7RS-small.
2023-08-15 06:54:21 -0400 < dpk> yes, and that doesn’t work on Windows, and it’s slow on some kernels
2023-08-15 06:55:12 -0400 < dpk> (i know this because Mac OS aliased vfork (fast) to fork (slow) a couple of releases ago, which made Magit dog slow until someone patched Emacs to use posix_spawn where possible)
2023-08-15 06:56:21 -0400 < mnieper`> The Foundations can be for users/implementers who want a language as precise as R6RS, who want to do things they can do in R7RS-small and in R6RS and who want to be able to run the portable (or customized) implementation of the Batteries.
2023-08-15 06:57:20 -0400 < sham1> dpk: well on Windows you can actually set the working directory for a process you spawn
2023-08-15 06:57:21 -0400 < jcowan> The R6RS spec is about three times as big as the R7RS-small spec
2023-08-15 06:57:34 -0400 < sham1> Different systems are of course gonna do these things differently 
2023-08-15 06:57:47 -0400 < jcowan> I caall that quite a bit larger
2023-08-15 06:58:09 -0400 < mnieper`> The number of pages is far from being a good metric.
2023-08-15 06:58:36 -0400 < jcowan> Well, what metric do you propose?
2023-08-15 06:58:44 -0400 < mnieper`> I didn't say the R6RS is as small as R7RS-small. But the difference is small when taking R7RS-large into account.
2023-08-15 06:59:28 -0400 < sham1> dpk: CreateProcessW takes lpCurrentDirectory, which specifies the working directory. While on POSIX you'd use fork/exec because this is one of those cases where posix_spawn is unfortunately not good enough
2023-08-15 06:59:37 -0400 < mnieper`> jcowan: List the things that are in it. R6RS has hashtables, which -small doesn't have, but the number of new procedures is tiny compared to what gets into the large language for hash tables.
2023-08-15 06:59:57 -0400 < mnieper`> R7RS-small has some vector/list procedures, R6RS doesn't have, but again, the number is small.
2023-08-15 07:00:39 -0400 < dpk> sham1: ah, handy!
2023-08-15 07:00:40 -0400 < mnieper`> A lot of words in R6RS are needed to leave less things unspecified.
2023-08-15 07:02:36 -0400 < jcowan> Syntax-case, the bytevector library, procedural records, record inspection, record inheritance, port I/O, fixnums, flonums, bitwise, conditions, enumerations.
2023-08-15 07:03:48 -0400 < leah2> luckily, posix_spawn_file_actions_addchdir is in posix-next
2023-08-15 07:04:12 -0400 < sham1> Well that will be good once that becomes a thing 
2023-08-15 07:04:23 -0400 < leah2> and implemented on all relevant platforms already afaiu
2023-08-15 07:04:55 -0400 < lockywolf> mnieper`: no, sorry, I am not convinced that my assumption is wrong
2023-08-15 07:05:09 -0400 < lockywolf> if anything, maybe experimenting would be the right thing to do
2023-08-15 07:05:40 -0400 < mnieper`> What do you mean by the latter?
2023-08-15 07:05:53 -0400 < lockywolf> message the respective developer teams, and ask them about their opinion on whether they might want to implement Foundations only, or Foundations+Batteries
2023-08-15 07:06:20 -0400 < sham1> The point is that they don't need to implement Batteries either way
2023-08-15 07:06:30 -0400 < sham1> That's the entire point of the batteries Vs foundations
2023-08-15 07:07:11 -0400 < lockywolf> they _already_ implement (or provide) a lot of the batteries
2023-08-15 07:08:32 -0400 < mdhughes> R6RS + R6RS-lib = 161 pages, R7RS = 88 pages, because it's ir-rationale. So "twice as large" is closer to accurate.
2023-08-15 07:09:28 -0400 < mnieper`> lockywolf: Do you suggest that R6RS is part of F+B? And what is F in your suggestion?
2023-08-15 07:09:47 -0400 < mdhughes> I wouldn't mind seeing a cleaned-up R7RS-small as R8RS or whatever name, that brings back Unicode, exceptions, etc. base functionality, and then build Foundations on *that*.
2023-08-15 07:10:20 -0400 < mdhughes> Arguing about the names is pretty much the most pointless activity possible.
2023-08-15 07:11:21 -0400 < sham1> This is quite literally what the term bikeshedding was coined for
2023-08-15 07:11:21 -0400 < mdhughes> Those who can, do. Those who can't, teach. Those who can't teach, write specs on committees all day.
2023-08-15 07:11:32 -0400 < lockywolf> mnieper`:  I don't like the word "part", but yes, F+B should provide everything r6rs provides, and, perhaps, something else. F is then the evolution of r7rs-small, designed in a way that "some reference implmentation of B" can run on top of it, unmodified
2023-08-15 07:11:41 -0400 < mdhughes> ^sham1
2023-08-15 07:11:59 -0400 < dpk> leah2: i thought you were joking, but web search tells me you’re not. who comes up with these names??
2023-08-15 07:12:07 -0400 < dpk> (anyway, this is good news)
2023-08-15 07:12:07 -0400 < sham1> POSIX
2023-08-15 07:12:12 -0400 < dpk> oh, right
2023-08-15 07:12:16 -0400 < dpk> see also: disaster
2023-08-15 07:12:18 -0400 < sham1> It's a glorious mess
2023-08-15 07:12:31 -0400 < mdhughes> I do miss compilers that only too initial 6 chars.
2023-08-15 07:12:36 -0400 < mdhughes> *took
2023-08-15 07:12:41 -0400 < leah2> back when they called it psxspwnaddchdir people complained too
2023-08-15 07:13:03 -0400 < sham1> PosixSpawnEx
2023-08-15 07:13:18 -0400 < dpk> it’s four characters longer than call-with-current-continuation, which people used to complain about in Scheme
2023-08-15 07:13:23 -0400 < mdhughes> I wrote a *lot* of productive code under Atari ST compilers with that limit, and I turned out fine.
2023-08-15 07:14:54 -0400 < mnieper`> lockywolf: In order to support B, F will have to contain roughly everything R6RS contains now (in principle), especially if F+B has to be able to provide everything that R6RS provides.
2023-08-15 07:15:25 -0400 < mnieper`> So, technically, there is no reason for F not to encompass R6RS.
2023-08-15 07:15:49 -0400 < lockywolf> mnieper`: what is your definition of "roughly", and what is the difference between "R6RS contains" and "R6RS provides"?
2023-08-15 07:16:51 -0400 < mnieper`> roughly in principle contains = primitives equivalent in total to what can be done with R6RS.
2023-08-15 07:17:09 -0400 < mnieper`> e.g. a macro system equivalent to s-c, etc.
2023-08-15 07:17:25 -0400 < mnieper`> It is a political, not a technical question.
2023-08-15 07:17:38 -0400 < lockywolf> 🤔
2023-08-15 07:17:50 -0400 < lockywolf> to me seems pretty technical
2023-08-15 07:18:28 -0400 < mnieper`> Unicode is not displayed here.
2023-08-15 07:18:42 -0400 < lockywolf> seems like "we have not come up with anything better than s-c, but there are people who see s-c as not good enough to get into the standard"
2023-08-15 07:19:09 -0400 < lockywolf> mnieper`: sorry, I can't connect to your computer remotely and make it display unicode
2023-08-15 07:22:48 -0400 < mdhughes> Unicode and that emoji works mostly for me, but different clients are limited.
2023-08-15 08:01:08 -0400 < jcowan> I have just resigned as chair of the R7RS-large effort
2023-08-15 08:03:14 -0400 < sham1> Does this mean that we have no chair or was there a contingency 
2023-08-15 08:04:36 -0400 < jcowan> You have no chair.  It will be up to the Steering Committee to appoint one or to abandon the project.
2023-08-15 08:05:49 -0400 < dpk> this also is the moment when we find out whether the Steering Committee still exists. (none of them contributed anything last year when we created the new procedure, iirc)
2023-08-15 08:07:02 -0400 < jcowan> I just sent the letter to the WG1 and WG2 mailing lists
2023-08-15 08:08:01 -0400 < sham1> This is an unfortunate but understandable development 
2023-08-15 08:14:32 -0400 < jackdaniel> what happened? (if you don't want to answer then it is fine, I'm just curious)
2023-08-15 08:14:40 -0400 < mnieper``> This is said to hear. 
2023-08-15 08:15:24 -0400 < mnieper``> You won't reconsider? Maybe we are too many people coming from too many directions (or wanting to go into too many directions).
2023-08-15 08:15:58 -0400 < mnieper``> And if you describe your vision in enough details and see who follows?
2023-08-15 08:16:39 -0400 < mnieper``> (What would have been special about 21st?)
2023-08-15 08:16:41 -0400 < dpk> the chair’s role is (ideally) facilitator, not visionary
2023-08-15 08:17:02 -0400 < dpk> jcowan has performed in that role admirably, and i’m sad about his decision
2023-08-15 08:17:27 -0400 < dpk> i also acknowledge the deep rifts and acrimony which led to this
2023-08-15 08:17:53 -0400 < jcowan> Arthur asked me to wait until then
2023-08-15 08:17:56 -0400 < sham1> Same. I can at least say for my own part that I've been quite satisfied with the stewardship even though there have been some difficulties and disagreements
2023-08-15 08:18:01 -0400 < dpk> i’m no longer sure myself that *anyone* can heal the Scheme community: our attempt has turned into pouring more fuel on the fire
2023-08-15 08:18:32 -0400 < jcowan> I never did have a personal vision.
2023-08-15 08:18:32 -0400 < dpk> (i still think R7RS Large is *probably* deliverable, though)
2023-08-15 08:18:38 -0400 < sham1> You did what you could and that's all we can ever ask for
2023-08-15 08:18:51 -0400 < jcowan> And I agree that there are too many people coming form / going in too many directions
2023-08-15 08:23:22 -0400 < mnieper``> When I wrote "vision" above, I mean that if R7RS-large is sketched in more detail (by whoever, but jcowan is the best person we have for this IMO), a more similarly aligned group of people may follow and may produce a standard. This may not be the standard for everyone working on it at the moment, but it will at least be one (and it will suit some of us and may persuade the rest).
2023-08-15 08:24:05 -0400 < jcowan> My observation is that the more detail we go into, the less we agree.
2023-08-15 08:24:47 -0400 < mnieper``> If all that it takes are fewer directions, knowing that I represent one, I am happy to step back into the ranks.
2023-08-15 08:24:54 -0400 < dpk> i hope Arthur Gleckler doesn’t mind me mentioning here that i thought he would be the best replacement for John, but he doesn’t want the job. other than Arthur, i can’t think of anyone else suitable who is currently active in the Scheme community
2023-08-15 08:25:22 -0400 < dpk> if one of the Steering Committee wanted to take on the chair job, maybe that could be workable
2023-08-15 08:27:31 -0400 < mnieper``> The SC seems to be mostly in retirement.
2023-08-15 08:28:40 -0400 < mdhughes> jcowan: Sorry to hear it.
2023-08-15 08:47:07 -0400 < mnieper``> We still have the SRFI process and all SRFIs that were spawned by R7RS-large (probably more than 50% of the existing) aren't gone.
2023-08-15 08:49:48 -0400 < jcowan> Yes.  I will continue to contribute SRFIs.
2023-08-15 08:50:35 -0400 < mnieper``> That's great to hear; we (or some group of like-minded people) can come back to the question of assembling them to a standard proposal later.
2023-08-15 08:52:03 -0400 < mnieper``> Even such a standard proposal can first be a SRFI XYZ. This hopefully leaves most of the politics/disagreements outside because a SRFI XYZ is solely its author's responsibility.
2023-08-15 08:52:25 -0400 < mnieper``> s/author's/authors'
2023-08-15 08:52:40 -0400 < jcowan> Oh, on tail recursion and debugging, see http://funcall.blogspot.com/2011/03/tail-recursion-and-debugging.html
2023-08-15 08:54:42 -0400 < sham1> I was scrolling through the page and was just looking at it "yeah, I think you made your point"
2023-08-15 08:54:48 -0400 < sham1> That wa funny
2023-08-15 08:55:53 -0400 < flatwhatson> lol!
2023-08-15 08:56:55 -0400 < mnieper``> Eliminating previous values when variable contents are overwritten doesn't do anything for the algorithmic complexity of the code, but it does make debugging a lot harder.
2023-08-15 08:59:47 -0400 < sham1> Nothing says that you can't have "debug frames" in debug mode while also doing tail calls
2023-08-15 09:53:09 -0400 < lockywolf> ;(
2023-08-15 10:09:43 -0400 < mdhughes> Ah, my favorite task, reading giant log4j files full of repeated stack frames.
2023-08-15 10:11:40 -0400 -!- rgherdt_ is now known as rgherdt
2023-08-15 10:39:42 -0400 < lockywolf> Is there something like a "maxima" written in Scheme?
2023-08-15 10:42:56 -0400 < lockywolf> SICP has the section "symbolic algebra" in chapter 2 dedicated to such a CAS, but I wonder if it has been actually implemented by anyone?
2023-08-15 10:43:06 -0400 < lockywolf> Like, not as a toy
2023-08-15 10:45:38 -0400 -!- nckx_ is now known as nckx
2023-08-15 10:47:16 -0400 < klovett> lockywolf: https://www.gnu.org/software/guile/manual/html_node/JACAL.html
2023-08-15 10:47:36 -0400 < lockywolf> klovett: thanks!
2023-08-15 12:01:45 -0400 < Zipheir> That's unfortunate news, but I understand. Maybe it will at least get the Steering Committee to take some action.
2023-08-15 12:32:48 -0400 < dpk> mnieper: a use case for Guile’s quote-syntax: it would let us implement er-macro-transformer in terms of syntax-case. (this might already be possible, but the ‘easiest’ way i just came up with would involve expanding the er-macro-transformer invocation into something that passes its own keyword to a procedure which would use it to create the ‘rename’ argument)
2023-08-15 12:37:14 -0400 < dpk> okay, yeah, i think you need quote-syntax to do this, but this use case doesn’t require the read-write invariance you mentioned as a problem because the quote-syntax’d identifier is immediately passed to another macro transformer, after which it disappears
2023-08-15 12:37:23 -0400  * dpk notes this in Codeberg
2023-08-15 12:39:15 -0400 < mnieper``> I am not sure I can follow. Why not something like this: https://paste.debian.net/plain/1289030?
2023-08-15 12:40:09 -0400 < dpk> that renamer will inject, won’t it, rather than renaming hygienically?
2023-08-15 12:40:25 -0400 < dpk> no, wait
2023-08-15 12:40:29 -0400 < dpk> argh, too much Scheme today
2023-08-15 12:40:53 -0400 < cow_2001> Lesson: Trying to be clever by using (and learning) a new technique A while one's goal is actually learning how to do B is a good way to go crazy.
2023-08-15 12:40:58 -0400 < dpk> yes, that renamer will inject, not rename
2023-08-15 12:44:24 -0400 < cow_2001> There is a lot in favour of Golang's "boring is better than clever" design philosophy.
2023-08-15 12:44:32 -0400 < mnieper``> You are right, of course. Replace #'k by #'*
2023-08-15 12:45:18 -0400 < Zipheir> cow_2001: But Go's boringness makes you be extra clever.
2023-08-15 12:45:45 -0400 < mnieper``> Injecting you have to do with the result of calling proc.
2023-08-15 12:46:32 -0400 < Zipheir> cow_2001: Standard Scheme certainly has simpler semantics than Go, in any case.
2023-08-15 12:47:01 -0400 < taylan> Boringness is indeed a very good thing IMO.  Believe it or not, I've come to love Java after doing Android development with it for a while (now about 5 years), and have no intention of switching to Kotlin. :D
2023-08-15 12:48:03 -0400 < Zipheir> Boringness is in the eye of the beholder.
2023-08-15 12:48:31 -0400 < Zipheir> Java was super exciting in the late '90s, at least for some people.
2023-08-15 12:49:04 -0400 < Zipheir> (Not me. All programming languages were deep magic to me then.)
2023-08-15 12:50:02 -0400 < mnieper``> dpk: Can you sketch your quote-syntax use case? Does it work better than my (corrected) sketch?
2023-08-15 12:50:59 -0400 < jcowan> Writing code is (for the most part) boring enough without adding extra doses of boredom.  Writing Java, or doing Scrum, or both, are called "ceremonies" for a reason.
2023-08-15 12:51:18 -0400 < dpk> mnieper``: am doing so now
2023-08-15 12:51:51 -0400 < jcowan> but I'm grieving (as if losing my wife wasn't enough), so don't mind me.
2023-08-15 12:52:29 -0400 < dpk> your corrected sketch will also rename in the context where er-macro-transformer was defined, not where it was invoked, i think?
2023-08-15 12:53:50 -0400 < mnieper``> Yes, you are right again. (I shouldn't do two things in parallel.)
2023-08-15 12:54:10 -0400 < mnieper``> My er-macro-transformer has to be syntax.
2023-08-15 12:54:20 -0400 < mnieper``> And #'* is the keyword of er-macro-transformer.
2023-08-15 12:54:44 -0400 < mnieper``> So you want the er-macro-transformer to be a procedure, then.
2023-08-15 12:57:31 -0400 < dpk> mnieper``: https://codeberg.org/scheme/r7rs/issues/119#issuecomment-1043208
2023-08-15 13:01:03 -0400 < mnieper``> Thanks? Why the indirection? (I am slow today.)
2023-08-15 13:01:23 -0400 < mnieper``> Why not inline er-macro-transformer*?
2023-08-15 13:02:27 -0400 < dpk> is that one question or two?
2023-08-15 13:02:28 -0400 < mnieper``> And is the quote-syntax you need here more than Racket's version?
2023-08-15 13:02:41 -0400 < mnieper``> I think it is one question. 
2023-08-15 13:03:15 -0400 < dpk> one could indeed inline er-macro-transformer*, i simply chose not to
2023-08-15 13:03:55 -0400 < mnieper``> And if you do, you don't need quote-syntax, do you?
2023-08-15 13:04:16 -0400 < dpk> doch
2023-08-15 13:06:44 -0400 < dpk> somehow, the er-macro-transformer keyword has to be, effectively, available to the procedure which is the argument to er-macro-transformer
2023-08-15 13:12:51 -0400 < dpk> maybe it’s possible to do this without Guile’s quote-syntax, but if so, it’s eluding me at the moment exactly how
2023-08-15 13:32:08 -0400 < mnieper``> Sorry, dinner was ready.
2023-08-15 13:41:18 -0400 < mnieper``> So this is my corrected version: https://paste.debian.net/plain/1289044
2023-08-15 13:41:48 -0400 < mnieper``> The only problem could occur if the identifier k in #'k were interpreted as a pattern variable.
2023-08-15 13:42:13 -0400 < dpk> which it would be, no?
2023-08-15 13:42:21 -0400 < mnieper``> But this cannot be the case at the macro use site because there k is a keyword bound to er-macro-transformer.
2023-08-15 13:43:04 -0400 < dpk> okay, let me try your version later. dinner is nearly ready here too :-)
2023-08-15 13:43:16 -0400 < mnieper``> And if it would, the inner #' could be replaced by Racket's quote-syntax. 
2023-08-15 13:43:25 -0400 < mnieper``> For which, I hope, I gave a correct portable s-c impl.
2023-08-15 13:43:35 -0400 < mnieper``> dpk: Guten Appetit!
2023-08-15 13:52:00 -0400 < mnieper`> The exact semantics are, of course, not defined for the ER macro transformer. What is the transformer environment? The lexical environment of the er-macro-transformer identifier or the lexical environment of the keyword that is defined or the lexical environment of the identifiers define-syntax, let-syntax, ...
2023-08-15 13:52:04 -0400 < mnieper`> ?
2023-08-15 13:52:28 -0400 < mnieper`> Is er-macro-transformer supposed to be a procedure in fact?
2023-08-15 13:54:45 -0400 < mnieper`> Our reflections on how to implement it also exhibit ER's inconvenience that all identifiers introduced free in the output must be defined in the transformer environment (whatever it is).
2023-08-15 13:56:13 -0400 < mnieper`> This makes it impossible to truly modularize large macro transformers and move syntax-generating code into helper libraries without the having to know the imports of the helper library.
2023-08-15 14:23:01 -0400 < dpk> Clinger’s paper does not define whether ‘transformer’ is a macro or a procedure
2023-08-15 14:23:28 -0400 < mnieper`> Maybe it is neither.
2023-08-15 14:23:51 -0400 < dpk> in MIT Scheme, it seems to be neither a procedure nor a macro, but something special. (the error you get for using it as a bare keyword is different from the one for using a macro as a bare keyword, and calls it a ‘Classifier’)
2023-08-15 14:23:56 -0400 < dpk> in Chibi, it is a procedure
2023-08-15 14:23:59 -0400 < mnieper`> Outside s-c, the right-hand side of define-syntax does not have to be an expression
2023-08-15 14:24:24 -0400 < mnieper`> Ah, I see, this may then be the case with MIT
2023-08-15 14:24:28 -0400 < dpk> in Chicken, it appears to also be a procedure
2023-08-15 14:24:53 -0400 < mnieper`> And what lexical environment is taken?
2023-08-15 14:25:41 -0400 < dpk> i can’t test on Larceny because it doesn’t run on 64-bit Mac OS, and since it JITs (i think?) i’m not sure it will run on ARM Mac OS even under Rosetta
2023-08-15 14:27:13 -0400 < dpk> anyway, the point here is to have something we can point er-macro-transformer users to and say ‘look, you can use that too in R7RS Large’, even if it only 99.5% matches what they’re used to
2023-08-15 14:27:26 -0400 < dpk> (and takes quadratic time to expand their macro)
2023-08-15 14:30:12 -0400 < mnieper`> Clinger's paper speaks about the "standard transformer environment".  What is this?
2023-08-15 14:30:50 -0400 < dpk> looks like it’s defined in the R4RS appendix: ‘In what follows, the environment in which transformers are executed is called the standard transformer environment and is assumed to be a standard Scheme environment’
2023-08-15 14:30:52 -0400 < mnieper`> (The loop and while macros given as examples are, of course, broken.)
2023-08-15 14:30:53 -0400 < dpk> https://people.csail.mit.edu/jaffer/r4rs_12.html
2023-08-15 14:31:02 -0400 < mnieper`> dpk: Thanks!
2023-08-15 14:31:27 -0400 < mnieper`> I would be interested to hear your opinion about v3 of my sketch. :)
2023-08-15 14:33:24 -0400 < dpk> i think the ‘standard transformer environment’ is defined is because R4RS doesn’t really have an idea of phasing (in macro transformer definitions, you get to use the standard Scheme language with the extensions from the appendix, and that’s it: no procedures or variables of your own)
2023-08-15 14:35:46 -0400 < mnieper`> Oh, yes, that makes a lot of sense.
2023-08-15 14:42:30 -0400 < dpk> question for Scheme historians: was there a ‘sample implementation’ or proof-of-concept for the R4RS macro system (including the low level)? who was the last person to implement it before mnieper` added it to Unsyntax?
2023-08-15 14:43:06 -0400 < mnieper`> Kent Dybvig?
2023-08-15 14:44:00 -0400 < ecraven> hm.. was there ever any discussion about making syntax-case *not* just take over (define-syntax x *procedure*), but instead like all the other macro systems use some sort of macro itself?
2023-08-15 14:45:49 -0400 < mnieper`> ecraven: There were plenty of discussions.
2023-08-15 14:45:53 -0400 < dpk> yes, but if we want to have R6RS compatibility, we can’t do that
2023-08-15 14:46:31 -0400 < dpk> (this is true for any of options 2–4 on mnieper`’s menu of what ‘R6RS compatibility’ could mean)
2023-08-15 14:46:50 -0400 < mnieper`> It is also not necessary if an implementation wants to support all macro systems out there.
2023-08-15 14:51:45 -0400 < mnieper`> The good thing about not having a (n effectively superfluous) wrapper is that only then syntax-rules expands into a procedure, which can then be debugged as any other procedure.
2023-08-15 15:06:29 -0400 < ecraven> I quite liked the fact that all the different macro systems were clearly recognizable
2023-08-15 15:09:29 -0400 < mnieper`> If it doesn't start with er- sc- or ir-, it is syntax-case. :)
2023-08-15 15:09:54 -0400 < mnieper`> Except if er-, sc-, ir-, ... is also implemented by syntax-case.
2023-08-15 15:10:48 -0400 < gwatt> I tried to implement syntactic-closures on top of syntax-case and ran away, pretty early on
2023-08-15 15:10:59 -0400 < ecraven> yea, I still dislike that this gives a vibe of "this is the last macro system that'll ever be invented, nothing better can come along ever.."
2023-08-15 15:11:43 -0400 < mnieper`> It is not the macro system that is on the right of define-syntax; it is a transformer (expression).
2023-08-15 15:12:12 -0400 < dpk> ecraven: in fact, it is the opposite. ‘this was the first low level macro system we had, so it gets to claim “lambda” as its only transformer constructor for itself’ ;-)
2023-08-15 15:12:24 -0400 < dpk> (not syntax-case per se, but the same idea of syntax objects)
2023-08-15 15:12:39 -0400 < ecraven> dpk: other schemes had defmacro-like things before syntax-case :P
2023-08-15 15:12:47 -0400 < sham1> But that's defmacro
2023-08-15 15:12:58 -0400 < sham1> And also, that's unhygienic
2023-08-15 15:13:02 -0400 < dpk> first low level *hygienic* macro system, then :D
2023-08-15 15:13:02 -0400 < mnieper`> ecraven: What s-c does is that it specifies that this expression is a procedure from syntax objects to syntax objects, while other systems leave this open.
2023-08-15 15:13:23 -0400 < mnieper`> sham1 is right; we are talking about the rhs of define-syntax and not defmacro.
2023-08-15 15:13:48 -0400 < mnieper`> But a map stx.obj -> stx.obj is close to the universal thing.
2023-08-15 15:13:54 -0400 < ecraven> mnieper`: I understand, I still dislike the fact that at a glance it isn't obvious that the macro is written as syntax-case (which is in fact not a problem right now, as there *is* no other macro system that has deemed it ok to just write the transformer directly without wrapping it :P :D)
2023-08-15 15:13:56 -0400 < gwatt> Also, there's nothing inherently bad about being the last macro system ever invented, hypothetically speaking.
2023-08-15 15:13:56 -0400 < mnieper`> Regardless of the underlying machinery.
2023-08-15 15:14:05 -0400 < ecraven> gwatt: if indeed it is, then no
2023-08-15 15:14:33 -0400 < mnieper`> Newer macro systems have been invented like Racket's current one.
2023-08-15 15:14:35 -0400 < ecraven> I really must grok syntax-case fully, maybe I'm just wasting everybody's time and s-c *is* perfection
2023-08-15 15:14:54 -0400 < mnieper`> It is as "perfect" as R6RS is "perfect".
2023-08-15 15:15:02 -0400 < sham1> Perfection is impossible, but s-c is quite good
2023-08-15 15:15:32 -0400 < gwatt> mnieper`: syntax-parse is still very close to syntax-case. I think it's more an evolution than a different approach entirely
2023-08-15 15:15:34 -0400 < ecraven> mnieper`: what does that mean? how is syntax-case related to r6rs? can't it be seen as its own thing?
2023-08-15 15:16:03 -0400 < mnieper`> gwatt: syntax-parse/syntax-case is on a different level.
2023-08-15 15:16:14 -0400 < sham1> syntax-case was officially specified in R6RS
2023-08-15 15:16:24 -0400 < mnieper`> That level is about destructuring syntax objects.
2023-08-15 15:16:36 -0400 < mnieper`> What I mean is sets of scopes vs marks and substs.
2023-08-15 15:16:46 -0400 < mnieper`> gwatt: ^^
2023-08-15 15:16:50 -0400 < gwatt> ah, that's right
2023-08-15 15:17:21 -0400 < gwatt> The interfaces of syntax-{parse,case} are superficially similar
2023-08-15 15:17:32 -0400 < sham1> Although IIRC the Dybvig paper is before R6RS, of course. <https://legacy.cs.indiana.edu/~dyb/pubs/bc-syntax-case.pdf>
2023-08-15 15:17:52 -0400 < mnieper`> I was referring to the famous Felleisen post. 
2023-08-15 15:18:35 -0400 < gwatt> There was a HOPL/POPL/???? video by Will Clinger talking about the history of scheme macro systems. Though I looked for it a bit ago and couldn't find it again
2023-08-15 15:18:37 -0400 < mnieper`> I wanted to say that it is unprobably that the macro system of R6RS will be the last and best we will ever see.
2023-08-15 15:19:02 -0400 < mnieper`> s/unprobably/unprobable
2023-08-15 15:19:46 -0400 < mnieper`> But it is perfect in that it does not have the flaws of IR/ER/SC/...
2023-08-15 15:20:07 -0400 < dpk> gwatt: the paper you’re referring to is probably this one https://dl.acm.org/doi/10.1145/3386330 though i’ve never seen the video
2023-08-15 15:21:21 -0400 < gwatt> That certainly sounds correct.
2023-08-15 15:21:29 -0400 < gwatt> video: https://www.pldi21.org/prerecorded_hopl.13.html 
2023-08-15 15:24:04 -0400 < mnieper`> Note that section 12.3.2 is not quite right (https://codeberg.org/scheme/r7rs/issues/115).
2023-08-15 15:25:07 -0400 < dpk> is it an error in the R6RS syntax-rules spec that fenders are not allowed, or an error in the sample implementation given in the standard libraries that they are allowed there (and used by the sample identifier-syntax implementation)?
2023-08-15 15:25:42 -0400 < mnieper`> (And the title of the section is a bit misleading because the Explicit Renaming in this section incorporates parts of s-c to be able to support it (a la Van Tonder).)
2023-08-15 15:25:52 -0400 < mnieper`> dpk: Fenders are not allowed.
2023-08-15 15:26:05 -0400 < mnieper`> They would make s-r procedural.
2023-08-15 15:26:26 -0400 < dpk> oh, the R6RS errata contains a correction that changes the identifier-syntax implementation to be based on syntax-case instead
2023-08-15 15:26:28 -0400 < gwatt> The fenders probably come from Dybvig, because syntax-rules in chez-scheme does allow them.
2023-08-15 15:26:48 -0400 < dpk> but the corresponding error in the syntax-rules definition which allows them is not fixed
2023-08-15 15:30:41 -0400 < mnieper`> dpk: Which error in the s-r definition?
2023-08-15 15:31:09 -0400 < mnieper`> gwatt: Chez exports a different s-r through (chezscheme) than through (rnrs).
2023-08-15 15:31:15 -0400 < dpk> in the same section (12.8) of the R6RS libraries report
2023-08-15 15:31:40 -0400 < dpk> no wait, i misread
2023-08-15 15:31:43 -0400 < dpk> false alarm
2023-08-15 15:32:03 -0400 < dpk> (i read [(k . p) t] as [(k . p) . t] or something)
2023-08-15 15:33:30 -0400 < mnieper`> s-r is in the base library; pattern variables and the syntax form only comes later. Without them, however, fenders don't make much sense.
2023-08-15 15:34:30 -0400 < mnieper`> The history is that SRFI 93's version is still Chez 7's (with fenders).
2023-08-15 15:35:29 -0400 < mnieper`> The editors of R6RS removed fenders (which was a good decision IMO to make s-r pure-templating, non-procedurally again), but some text of SRFI 93 was copied without correction into the report.
2023-08-15 15:35:32 -0400 < mnieper`> Thus the errata.
2023-08-15 15:51:41 -0400 < mnieper`> dpk: So do we need quote-syntax?
2023-08-15 15:52:52 -0400 < dpk> i don’t know, yet. i’m going to leave my comment with the quote-syntax explicit renaming implementation there for now and experiment more another time
2023-08-15 17:03:35 -0400 < pony> is there anything similar to Euterpea but for Scheme?
2023-08-15 17:08:29 -0400 < dpk> ooh, i found an R7RS erratum
2023-08-15 17:09:01 -0400 < dpk> page 23, the first ‘formal’ condition for pattern matching is not followed by an ‘or’
2023-08-15 17:09:04 -0400 < dpk> (okay, this one is a nitpick)
2023-08-15 17:09:40 -0400 < dpk> pony: looking at nothing but the search result summary for what Euterpea is, there’s Common Music
2023-08-15 17:09:58 -0400 < dpk> https://commonmusic.sourceforge.net
2023-08-15 17:11:11 -0400 < pony> thanks
2023-08-15 17:12:11 -0400 < pony> hmm, cool
2023-08-15 17:13:03 -0400 < Zipheir> pony: I'm glad you asked that. I was working on such a thing
2023-08-15 17:13:28 -0400 < pony> :O
2023-08-15 17:13:29 -0400 < Zipheir> It was specifically intended for music in just intonation.
2023-08-15 17:16:17 -0400 < pony> oh, man, I tried launching timidity on Ubuntu and it segfaulted xD
2023-08-15 17:16:22 -0400 < pony> maybe I'll do this on Windows
2023-08-15 17:16:24 -0400 < Zipheir> pony: Here it is. It runs on CHICKEN and compiles S-expression scores to CSound, which can then turn them into music. http://chiselapp.com/user/Zipheir/repository/scheme-score/dir?ci=tip
2023-08-15 17:16:51 -0400 < pony> Zipheir: thanks :)
2023-08-15 17:16:56 -0400 < Zipheir> I'd like to revive it, there's a lot of work to do.
2023-08-15 17:17:58 -0400 < Zipheir> Hmm, for some reason I was using immutable lists. I guess I was really a zealot for immutability back in '19.
2023-08-15 17:18:14 -0400 < pony> hehe
2023-08-15 17:18:44 -0400 < cow_2001> No assv-ref in R7RS.  assv does exist, maybe.  Forgot.
2023-08-15 17:19:39 -0400 < Zipheir> A Euterpea-clone for MIDI or CSound output in Scheme would be straightforward. The music algebra that Haskore/Euterpea is based on is really quite simple.
2023-08-15 17:20:18 -0400 < Zipheir> cow_2001: assv-ref ?
2023-08-15 17:20:31 -0400 < cow_2001> ………
2023-08-15 17:21:04 -0400 < Zipheir> You mean something like (cond ((assv foo lis) => cdr) (else #f)) ?
2023-08-15 17:21:31 -0400 < cow_2001> What's =>?!
2023-08-15 17:22:06 -0400 < Zipheir> "cond arrow". It passes the value of the test expression to whatever's on the left hand (which must be a procedure).
2023-08-15 17:22:06 -0400 < cow_2001> use value in provided procedure
2023-08-15 17:22:39 -0400 < Zipheir> It is a fantastic piece of syntactic sugare, I've found.
2023-08-15 17:22:50 -0400 < Zipheir> *sugar
2023-08-15 17:22:58 -0400 < cow_2001> Fancy.  So I don't need those annoying lets that litter my conds.
2023-08-15 17:23:13 -0400 < Zipheir> Not if you've got cond-arrow.
2023-08-15 17:24:00 -0400 < cow_2001> I am supposed to be walking.
2023-08-15 17:24:13 -0400 < Zipheir> It's in R6RS and R7.
2023-08-15 17:24:19 -0400 < cow_2001> Midnight walk.
2023-08-15 17:24:24 -0400 < Zipheir> Sounds nice.
2023-08-15 18:12:12 -0400 -!- mirai_ is now known as mirai
2023-08-15 18:16:15 -0400 < acdw> no u
2023-08-15 18:40:58 -0400 < cow_2001> It was SO HOT out there.
2023-08-15 18:41:06 -0400 < cow_2001> Everywhere I go is a sauna.
2023-08-15 18:56:14 -0400 < acdw> yeah
2023-08-15 18:57:11 -0400 < diod> Is there a document for scheme indentation? A few different editors seem to do the same thing so I wondered if there was one.
2023-08-15 18:59:02 -0400 < Zipheir> diod: https://www.sigwinch.xyz/misc/riastradh-lisp-style.txt is pretty opinionated, but it's close to the de-facto-standard style.
2023-08-15 19:00:02 -0400 < Zipheir> The only universally accepted rule is, as wasamasa says, "don't spill the Pringles".
2023-08-15 19:00:12 -0400 < diod> what does that mean?
2023-08-15 19:03:12 -0400 < Zipheir> Don't put close or open parens on their own lines, for one thing.
2023-08-15 19:03:35 -0400 < Zipheir> This is quite different from the usual way of writing C or Java, for example.
2023-08-15 19:04:43 -0400 < Zipheir> Riastradh's guide says: "Absolutely do *not* place closing brackets on their own lines.
2023-08-15 19:04:47 -0400 < Zipheir> *"
2023-08-15 19:08:36 -0400 < diod> oh ok
2023-08-15 19:11:33 -0400 < Zipheir> Some people *do* put spaces in groups of parens, e.g. (let-values ( ((x yz) ...) ) ... ), but I think that's unusual.
2023-08-15 19:12:24 -0400 < Zipheir> And then there's the debate about square brackets.
2023-08-15 19:18:19 -0400 -!- mode/#scheme [+o Zipheir] by ChanServ
2023-08-15 19:18:27 -0400 -!- mode/#scheme [-b *!*cognemo@*.static.amis.net] by Zipheir
2023-08-15 19:18:30 -0400 -!- Irssi: No bans in channel #scheme
2023-08-15 19:18:40 -0400 -!- mode/#scheme [-o Zipheir] by ChanServ
2023-08-15 19:19:35 -0400 < diod> That is unusual. I have this idea I can make a scheme editor
2023-08-15 19:20:16 -0400 < diod> so I guess I'll have to formalize this document somehow
2023-08-15 19:25:31 -0400 < cow_2001> I wrote a bunch of code, hoping that one day Bob would deal with the unimplemented stuff.  Now I am stuck with perplexing errors emitted by Guile.
2023-08-15 19:26:05 -0400 < cow_2001> (it is just a wee grumble, not really asking for help)
2023-08-15 19:27:08 -0400 < Zipheir> rudybot: seen Bob
2023-08-15 19:27:08 -0400 < rudybot> Zipheir: bob was seen joining in #emacs one week ago, and then bob was seen changing their nick to bobjkfhsk in dyndsl-095-033-083-028.ewe-ip-backbone.de one week ago
2023-08-15 19:31:03 -0400 < diod> is bob a real person?
2023-08-15 19:41:05 -0400 < cow_2001> O_o
2023-08-15 19:41:37 -0400 < cow_2001> I should have maybe left notes for Bob.
2023-08-15 19:41:55 -0400 < cow_2001> Bob is another name for future me, in this case present me.
2023-08-15 19:42:11 -0400 < cow_2001> His name was Robert Paulson.
2023-08-15 19:47:06 -0400 < Zipheir> Bob is like George, who you might know from SICP. He's the lucky person who figures out how to implement everything you've hand-waved.
2023-08-15 19:48:09 -0400 < cow_2001> Okay, seems like I hand waved compose where there is none
2023-08-15 19:48:13 -0400 < cow_2001> .
2023-08-15 19:49:17 -0400 < cow_2001> ((compose h g f) x) is sort of like (f o g o h)(x)
2023-08-15 19:49:32 -0400 < cow_2001> err oops
2023-08-15 19:49:49 -0400 < cow_2001> ((compose f g h) x) is sort of like (f o g o h)(x)
2023-08-15 19:50:39 -0400 < cow_2001> Looking in the r7rs small pdf I do not see such a thing.  Not in an SRFI, either?
2023-08-15 19:50:43 -0400 < Zipheir> Compose is in https://srfi.schemers.org/srfi-210/srfi-210.html
2023-08-15 19:50:57 -0400 < Zipheir> It's there because it has to handle multiple values.
2023-08-15 19:51:24 -0400 < cow_2001> O_O
2023-08-15 19:52:03 -0400 < Zipheir> Well, if f returns three values, then it has to do an implicit call-with-values to pass those to g.
2023-08-15 19:52:09 -0400 < cow_2001> Was looking in the fancy web index's R7RS-Large + SRFIs
2023-08-15 19:52:17 -0400 < cow_2001> .
2023-08-15 19:52:22 -0400 < Zipheir> Hmm, it should be there.
2023-08-15 19:53:13 -0400 < Zipheir> Oh, hurr durr. It's compose-left / -right.
2023-08-15 19:53:20 -0400 < cow_2001> O_o
2023-08-15 19:53:45 -0400 < Zipheir> If your Scheme has 'compose', it's probably compose-right.
2023-08-15 19:54:35 -0400 < cow_2001> I don't see SRFI-210 in the list of searchable SRFIs.  That might be it.
2023-08-15 19:54:52 -0400 < Zipheir> Maybe Lassi missed one.
2023-08-15 19:55:27 -0400 < Zipheir> Looks like there are a number missing.
2023-08-15 19:55:58 -0400 < cow_2001> Okay, next time just go to the proper SRFI documentation site if I cannot find it on the fancy index.
2023-08-15 19:57:13 -0400 < cow_2001> Hmm.  Looking up "compose" did not show SRFI-210.
2023-08-15 19:58:03 -0400 < cow_2001> Oh wow.  It was only started in 2020!
2023-08-15 19:59:07 -0400 < Zipheir> Yes. It's surprising that we didn't have some of those basic MV forms SRFIfied until Marc started 210.
2023-08-15 19:59:53 -0400 < cow_2001> No SRFI-210 here. :|
2023-08-15 19:59:57 -0400 < cow_2001> Alas.
2023-08-15 20:00:05 -0400 < Zipheir> Which Scheme?
2023-08-15 20:00:17 -0400 < cow_2001> Guile.
2023-08-15 20:00:30 -0400 < Zipheir> Just download the implementation. All it needs is syntax-case, IIRC.
2023-08-15 20:00:51 -0400 < Zipheir> https://github.com/scheme-requests-for-implementation/srfi-210
2023-08-15 20:01:52 -0400 < Zipheir> No, it doesn't even need syntax-case, just a post-R5RS syntax-rules.
2023-08-15 20:02:07 -0400 < Zipheir> *That's* why I couldn't get it to run on CHICKEN.
2023-08-15 20:08:25 -0400 < cow_2001> Wow.
2023-08-15 20:09:09 -0400 < cow_2001> Zipheir: Why not Chicken?
2023-08-15 20:10:27 -0400 < Zipheir> CHICKEN's syntax-rules doesn't support (var1 ... . var*) patterns, IIRC.
2023-08-15 20:11:12 -0400 < Zipheir> Or at least it didn't the last time I checked.
2023-08-15 20:15:10 -0400 < Zipheir> "post-R5RS" sounds like a genre of pretentious underground Scheme.
2023-08-15 20:15:39 -0400 < Zipheir> But no, it's mainstream.
2023-08-15 20:36:15 -0400 < quidnunc> What's the best resource for learning continuations?
2023-08-15 20:36:42 -0400 < Zipheir> Good question. The Seasoned Schemer has a decent section on them.
2023-08-15 20:38:42 -0400 < Zipheir> Matt Might has also written some good introductory material, although his posts are more about CPS than continuations in practical use. e.g. https://matt.might.net/articles/by-example-continuation-passing-style/
2023-08-15 20:40:45 -0400 < cow_2001> Behold!  It is buggy!  And contains profanity euphemisms! https://0x0.st/HLND.txt
2023-08-15 20:42:37 -0400 < quidnunc> Zipheir: thanks, I'll take a look at those
2023-08-15 20:43:49 -0400 < Zipheir> cow_2001: That alist in is-single-char-token? ...
2023-08-15 20:44:00 -0400 < cow_2001> ………
2023-08-15 20:44:03 -0400 < Zipheir> Time to JESUS some numbers!
2023-08-15 20:44:14 -0400 < cow_2001> :|
2023-08-15 20:44:28 -0400 < cow_2001> Explain…?
2023-08-15 20:45:15 -0400 < Zipheir> (#\+ . JESUS)
2023-08-15 20:45:24 -0400 < cow_2001> Oh, I thought you were about to say something about how I should have done it some other way.
2023-08-15 20:45:45 -0400 < Zipheir> cow_2001: Typically, procedures with names ending in ? return booleans in all cases.
2023-08-15 20:46:33 -0400 < cow_2001> Oh boy.
2023-08-15 20:47:31 -0400 < Zipheir> It's not a big deal, but it might cause momentary confusion when is-single-char-token? returns a symbol or pair.
2023-08-15 20:47:43 -0400 < cow_2001> How would you name such a maybe returning procedure?
2023-08-15 20:48:29 -0400 < Zipheir> I would call it char->token or something. It's kosher for a such a procedure to return #f on failure; see string->number, e.g.
2023-08-15 20:48:43 -0400 < cow_2001> Ah!
2023-08-15 20:50:29 -0400 < cow_2001> Now will AFK for meditation.
2023-08-15 20:50:47 -0400 < Zipheir> cow_2001: When you get back, check that you want assv there and not assv-ref.
2023-08-15 21:06:01 -0400 < diod> This project https://www.larcenists.org/ is still active?
2023-08-15 21:19:02 -0400 < cow_2001> Zipheir: I think I couldn't find assv-ref.
2023-08-15 21:46:23 -0400 < cow_2001> I like assv.  It is either a cons with the result, or a #f.
2023-08-15 21:47:27 -0400 < cow_2001> assv-ref is dangerous.  Either it is who knows what, possibly a #f, or #f.
2023-08-15 21:47:54 -0400 < Zipheir> cow_2001: If you want an unambiguous assv-ref, give it a failure continuation.
2023-08-15 21:48:23 -0400 < Zipheir> Or, following list-ref, have it raise an exception on failure. That's probably the most consistent choice.
2023-08-15 21:48:26 -0400 < cow_2001> I don't know continuations. :|
2023-08-15 21:48:44 -0400 < Zipheir> In this case, "continuation" just means a procedure that you invoke on failure.
2023-08-15 21:49:27 -0400 < Zipheir> (assv-ref 'foo lis (lambda () (error "not found!"))) would be a simple use.
2023-08-15 21:49:50 -0400 < cow_2001> Oh?!  There is an optional third argument?!
2023-08-15 21:50:01 -0400 < Zipheir> If you define it that way. :-p
2023-08-15 21:50:05 -0400 < cow_2001> ~_~
2023-08-15 21:50:17 -0400 < Zipheir> C'mon, it's basically two lines.
2023-08-15 21:51:20 -0400 < Zipheir> (define (assv-ref key lis failure) (cond ((assv key lis) => cdr) (else (failure))))  A little more if you want the failure cont to be optional.
2023-08-15 21:51:31 -0400 < cow_2001> Hmm.  But is there really that much of a difference?
2023-08-15 21:52:03 -0400 < Zipheir> From assv?
2023-08-15 21:52:14 -0400 < cow_2001> I guess having it this way is more structured.
2023-08-15 21:52:39 -0400 < Zipheir> I think char->token should return a token, not a pair with one redundant element.
2023-08-15 21:52:47 -0400 < Zipheir> But it's your choice, of course.
2023-08-15 21:56:36 -0400 < cow_2001> Doing it now.
2023-08-15 21:57:10 -0400 < cow_2001> Hmmmmm.  (define (assv-ref key lis . failure) …)?
2023-08-15 21:57:37 -0400 < Zipheir> Sure, that's the classic way. You can use case-lambda etc.
2023-08-15 21:57:48 -0400 < cow_2001> Hmmmmmmm.
2023-08-15 21:59:43 -0400 < cow_2001> What would happen if there is no key and no provided failure?
2023-08-15 22:00:09 -0400 < cow_2001> (assv-ref 'x '())
2023-08-15 22:00:30 -0400 < cow_2001> Just a regular ol' dang kaboom?
2023-08-15 22:00:53 -0400 < Zipheir> The default failure should be to call 'error'/raise an exception.
2023-08-15 22:00:57 -0400 < Zipheir> (IMHO)
2023-08-15 22:00:59 -0400 < cow_2001> Ah!
2023-08-15 22:01:16 -0400 < cow_2001> Okay!
2023-08-15 22:01:17 -0400 < Zipheir> That's what list-ref does, anyway.
2023-08-15 22:04:32 -0400 < cow_2001> Something like: (didn't test) https://0x0.st/HLqP.txt
2023-08-15 22:06:19 -0400 < Zipheir> Looks good to me.
2023-08-15 22:06:46 -0400 < cow_2001> Thank you!
2023-08-15 22:08:28 -0400 < Zipheir> You're welcome! It's a useful library function.
2023-08-15 22:15:17 -0400 < cow_2001> Oh no.  Now it explodes instead of saying there was nothing there.  I need to write a predicate.
2023-08-15 22:16:21 -0400 < Zipheir> Just pass (lambda () #f) as the failure arg to get the old behavior back.
2023-08-15 22:21:04 -0400 < Zipheir> This is one reason why the "optional failure argument" is a good pattern, I think; it gives you the "default failure value" version for free.
2023-08-15 22:21:11 -0400 < cow_2001> https://0x0.st/HLqT.txt
2023-08-15 22:21:56 -0400 < cow_2001> But the default value might also be in the success.
2023-08-15 22:22:19 -0400 < cow_2001> It is not like Haskell's Maybe
2023-08-15 22:22:30 -0400 < Zipheir> Good, but if is-single-char-token? is a predicate, it should be (and (assv-ref ...) #t) so that you get a boolean in both cases.
2023-08-15 22:22:45 -0400 < cow_2001> Woops.
2023-08-15 22:22:49 -0400 < Zipheir> (Pedantic detail.)
2023-08-15 22:22:56 -0400 < Zipheir> #t is almost useless in Scheme.
2023-08-15 22:23:53 -0400 < cow_2001> Pedantry is good in software.
2023-08-15 22:24:49 -0400 < aeth> #t is very useful in Scheme. What would you use for generic true otherwise? 1? Then people might assume that 0 is equivalent to #f when in fact it's truthy.
2023-08-15 22:24:50 -0400 < cow_2001> Keeps martian probes from burning on landing.
2023-08-15 22:25:28 -0400 < Zipheir> aeth: Everything is truthy but #f. It barely matters.
2023-08-15 22:25:32 -0400 < aeth> Arguably, since Scheme is an expression-based language, every procedure that returns no useful value and has no useful value to return should return #t to at least make it clear that everything is working
2023-08-15 22:25:51 -0400 < aeth> e.g. all of the forms that return something like #<unspecified> because they're not specified
2023-08-15 22:27:02 -0400 < Zipheir> That they return an unspecified value is to indicate that they're not "really" expressions.
2023-08-15 22:28:08 -0400 < Zipheir> Scheme doesn't have statements, so I guess we have to call things like (vector-set! v 0 'foo) pseudo-expressions.
2023-08-15 22:30:13 -0400 < Zipheir> But I agree, you might as well have them evaluate to #t instead of some bogus #<unspecified> value.
2023-08-15 22:30:28 -0400 < Zipheir> (Since the only thing you can say about #<unspecified> is that it's truthy.)
2023-08-15 22:30:38 -0400 < aeth> seems to me to be one of the few places where Scheme is more inelegant than Common Lisp, although Common Lisp usually implicitly returns NIL (i.e. #f) where there's no reasonable return value while I'd propose the exact opposite
2023-08-15 22:33:29 -0400 < Zipheir> I think the Reports got it right with "an unspecified value", but the literal #<unspecified> is annoying.
2023-08-15 22:36:07 -0400 < aeth> the danger of something more is that it might become a null
2023-08-15 22:36:18 -0400 < aeth> best to keep null as a symbol when interfacing with things like JSON or SQL
2023-08-15 22:36:23 -0400 < aeth> and not a part of the language
2023-08-15 22:36:52 -0400 < Zipheir> Yes.
2023-08-15 22:37:36 -0400 < Zipheir> Haskell opened that can of worms with 'undefined'.
2023-08-15 22:38:15 -0400 < Zipheir> Well, maybe not. Undefined is absurd, which is not the same as nothing.
2023-08-15 22:48:26 -0400 < acdw> petition to change the language in the scheme reports from "an unspecified value" to "an absurd value"
2023-08-15 22:48:58 -0400 < acdw> honestly I think those procedures should return a void value, and have a void? predicate 
2023-08-15 22:55:33 -0400 < cow_2001> FIXED A BUG!!!
2023-08-15 22:56:47 -0400 < Zipheir> That would have a meaning in Pie (a dependently-typed Scheme-like language) where Absurd is the type of absurdities.
2023-08-15 22:57:29 -0400 < cow_2001> Nearly completed the lexer. https://0x0.st/HLqu.txt
2023-08-15 22:58:57 -0400 < acdw> Zipheir: peefect
2023-08-15 23:03:52 -0400 < Zipheir> cow_2001: Looks good.
2023-08-15 23:21:36 -0400 < acdw> with assv-ref, why key lis and not lis key?
2023-08-15 23:23:52 -0400 < jcowan> diod: generally you want to do whatever Emacs does
2023-08-15 23:25:19 -0400 < diod> makes sense
2023-08-15 23:25:49 -0400 < diod> it's surprising there isn't as much emacs forks
2023-08-15 23:27:36 -0400 < dave0> like fudd there isn't.. http://www.finseth.com/emacs.html
2023-08-15 23:29:11 -0400 < diod> oh ...
2023-08-15 23:35:47 -0400 < Zipheir> acdw: Either order works. You can follow the assv family and put the key first, or list-/vector-ref and put the "index" second.
2023-08-15 23:36:36 -0400 < acdw> mmm yeah 
2023-08-15 23:37:17 -0400 < acdw> I guess jey first so I can apply it ...
2023-08-15 23:47:12 -0400 < cow_2001> acdw: Oh non
2023-08-15 23:47:14 -0400 < cow_2001> err
2023-08-15 23:47:16 -0400 < cow_2001> acdw: Oh no.
2023-08-15 23:48:32 -0400 < acdw> oh?
2023-08-15 23:49:35 -0400 < cow_2001> acdw: Just recalled it is backwards.  Good spotting!
2023-08-15 23:50:21 -0400 < acdw> oh lol I changed mine around
2023-08-15 23:50:44 -0400 < cow_2001> All those *-ref are structure first key second.
2023-08-15 23:51:35 -0400 < cow_2001> assv is key first structure second.
2023-08-15 23:53:17 -0400 < cow_2001> They should drop all pretences and just define a procedure named ass.
2023-08-15 23:53:49 -0400 < cow_2001> You must have heard all these dumb jokes a thousand times before.
2023-08-15 23:57:57 -0400 < Zipheir> No, the channel was pretty much free of them. Until now.
--- Day changed Wed Aug 16 2023
2023-08-16 00:02:13 -0400 < mdhughes> I laugh every time I write an assq or assv, but it doesn't lend itself to longer setup/punchline jokes.
2023-08-16 00:34:10 -0400 < daviid>  anyone knows how this <property name="accelerator">&lt;ctrl&gt;f</property> should be written in an sxml file? i mean the &lt;ctrl&gt;f, cause i try 
2023-08-16 00:34:52 -0400 < daviid> (property (@ (name "accelerator")) "&lt;ctrl&gt;f"), sxml->xml is ok but i get Gtk-Warning Failed to parse &lt;ctrl&gt;f, part of accelerator '&lt;ctrl&gt;f'
2023-08-16 00:36:40 -0400 < flatwhatson> daviid: i'd guess the content should just be "<ctrl>f"
2023-08-16 00:36:51 -0400 < acdw> mdhughes: heheh same
2023-08-16 00:36:55 -0400 < daviid> ah let me try, tx
2023-08-16 00:37:40 -0400 < daviid> flatwhatson: perfect, thanks
2023-08-16 00:37:51 -0400 < flatwhatson> np :)
2023-08-16 00:57:48 -0400 < lockywolf> How do I make pull-requests on Savannah?
2023-08-16 01:29:43 -0400 < daviid> lockywolf: #savannah - but i don't think it's possible
2023-08-16 01:35:09 -0400 < lockywolf> okay. just sent them a git send-email instead
2023-08-16 01:38:26 -0400 < mnieper`> lockywolf: patch files.
2023-08-16 01:38:41 -0400 < mnieper`> via email to their mailing list.
2023-08-16 01:39:13 -0400 < mnieper`> acdw: What do you mean by "void instead of unspecified"?
2023-08-16 01:39:45 -0400 < mnieper`> Zipheir: The unspecified value can be #f.
2023-08-16 01:39:52 -0400 < mnieper`> Doesn't have to be truthy.
2023-08-16 01:40:10 -0400 < mnieper`> The value can be a different one everytime the procedure returns.
2023-08-16 01:41:06 -0400 < mnieper`> Although most Schemes define a specific value that is always returned by expressions like (if #f #f), this is not always the case.
2023-08-16 01:44:50 -0400 < mnieper`> The RIGHT THING(TM) would be to return no values.
2023-08-16 02:05:33 -0400 < Zipheir> mnieper`: Yes, but I meant that the unique #<unspecified> values that some implementations return are truthy.
2023-08-16 02:05:57 -0400 < sham1> Well it's not #f so it'll have to be true
2023-08-16 02:06:05 -0400 < Zipheir> Right.
2023-08-16 02:06:36 -0400 < sham1> If you made the unspecified value falsy, you'd need an additional branch
2023-08-16 02:06:38 -0400 < Zipheir> I think a falsy dummy object wouldn't comply with any RnRS.
2023-08-16 02:08:27 -0400 < Zipheir> At least as far back as R4RS.
2023-08-16 02:11:04 -0400 < Zipheir> No values would be the Right Thing iff Scheme continuations didn't usually expect one value.
2023-08-16 02:11:29 -0400 < Zipheir> s/iff/if/
2023-08-16 02:16:01 -0400 < mdhughes> I'd prefer if all functions/procedures/forms/callable thingies had to return a real value, like (set! x y) => y, but that's a long-past-sailed ship.
2023-08-16 02:17:26 -0400 < mdhughes> Yes, I also dislike "void" return in C-likes, procedures in Pascal, etc., but at least those don't pretend to be functional.
2023-08-16 02:18:24 -0400 < mdhughes> The main advantage of a return is you can compose it in map, (or (foo x) y), (if (foo x) y) etc.
2023-08-16 02:19:36 -0400 < mdhughes> As it is, I sometimes have to compose with an extra lambda.
2023-08-16 02:20:43 -0400 < Zipheir> Although I just noticed that (begin (values) ...) is fine, per the R6RS semantics.
2023-08-16 02:20:54 -0400 < Zipheir> So maybe "no values" could work.
2023-08-16 02:21:54 -0400 < Zipheir> mdhughes: Then you've got to decide on what useful value things like 'display' return.
2023-08-16 02:22:05 -0400 < mdhughes> (if (values) 'yes 'no) Exception: returned zero values to single value return context
2023-08-16 02:22:08 -0400 < mdhughes> But: 
2023-08-16 02:22:24 -0400 < mdhughes> I'm happy with just #t for "did the thing".
2023-08-16 02:22:41 -0400 < mnieper`> Zipheir: Even more. "No values" does not only work, but does work better.
2023-08-16 02:23:17 -0400 < mnieper`> Because everytime there is a continuation expecting one value where your "statement" only delivers one, you have very likely a programmer's error.
2023-08-16 02:23:58 -0400 < Zipheir> That seems likely, although I wonder if there are exceptions.
2023-08-16 02:24:25 -0400 < Zipheir> Sorry, it's late here. I'll be back on in the morning EDT to read the scrollback. :)
2023-08-16 02:24:25 -0400 < mnieper`> I don't think so.
2023-08-16 02:24:36 -0400 < mnieper`> Sleep well.
2023-08-16 02:24:40 -0400 < Zipheir> Thanks!
2023-08-16 02:38:09 -0400 < mnieper`> dpk: Posted my ER solution without quote-syntax to Codeberg #119.
2023-08-16 02:40:24 -0400 < mnieper`> There exists, however, still a different problem. The rename procedure in our code only takes a symbol.
2023-08-16 02:40:40 -0400 < mnieper`> In the ER system as described by Clinger it can take any identifier.
2023-08-16 02:51:04 -0400 < mnieper`> I don't yet see a pretty fix.
2023-08-16 03:01:44 -0400 -!- ced1 is now known as cedb
2023-08-16 03:56:41 -0400 < mnieper`> mdhughes: (set! x y) => y would contradict your other idea of returning #t for "did the thing".
2023-08-16 04:03:54 -0400 < mdhughes> All values are true except #f. And if I'm testing on that value, like (or (set! x #f) other), I want other.
2023-08-16 04:14:05 -0400 < mnieper`> Bit them 
2023-08-16 04:14:23 -0400 < mnieper`> But set! "did the thing".
2023-08-16 04:18:22 -0400 < mnieper`> Returning zero values enforces the separation of pure and impure code a bit (which may pique Zipheir's interest). It would be harder to use impure procedures in "expression context" where the order of evaluation should not matter. Instead, it encourages to use impure "statements" inside `begin' with its clear evaluation order, mimicking Haskell's monads (of type <void>).
2023-08-16 04:30:41 -0400 < mdhughes> "did the thing" is only for functions that do nothing with a real return value, like display.
2023-08-16 04:31:03 -0400 < mdhughes> Tho you could follow C's example and return chars written, as well.
2023-08-16 04:33:08 -0400 < sham1> Which no one checks
2023-08-16 04:33:18 -0400 < sham1> So what'd be the point
2023-08-16 04:33:27 -0400 < mdhughes> As it is, esp when I'm dealing with native functions, I do a lot of (if (let ((y (expensivefunc z))) (set! localcopy y) y) ...) which is far more of a pain in the ass.
2023-08-16 04:33:56 -0400 < mdhughes> In C you often do count the chars from print functions, so you know where you are on the screen.
2023-08-16 04:34:32 -0400 < mdhughes> Or how much Content-Length to report for HTTP, etc.
2023-08-16 04:39:36 -0400 < mdhughes> Scheme's a dirty hybrid of Algol, Lisp, and in production problems a lot of C. Purity rarely shows up here, and has a real bad weekend when it does.
2023-08-16 04:40:18 -0400 < mdhughes> There's probably a "pure FP" subset possible to extract, but it's not really useful for much, any more than Haskell is, and GHC's a better Haskell.
2023-08-16 04:50:50 -0400 < mnieper`> mdhughes: I would write your let example as:
2023-08-16 04:51:38 -0400 < mnieper`> (cond [(expensivefunc z) => (lambda (y) (set! localcopy y) ...)])
2023-08-16 04:51:53 -0400 < mnieper`> Or use SRFI 2's and-let*.
2023-08-16 04:53:55 -0400 < mnieper`> And check twice whether you really need to use set!.  Scheme's pure FP subset works pretty well; it would be easier to use with a good loop macro.
2023-08-16 04:55:42 -0400 < mdhughes> Doesn't do the same thing, it needs to assign to localcopy if it's #f, might be checking for an event or device which isn't there yet. No stale data!
2023-08-16 04:58:32 -0400 < mdhughes> And it'd be very bad to get something like that and not cache it, even if I mainly use it immediately. You load an image and forget to cache it, you're gonna be wasting 10-100ms or more you shouldn't.
2023-08-16 05:00:24 -0400 < mnieper`> mdhughes: Then add an else clause as well.
2023-08-16 05:01:01 -0400 < mdhughes> Violates Don't Repeat Yourself.
2023-08-16 05:01:44 -0400 < mnieper`> Not necessarily if you write the second "set!" as (clear-cache!), which is also clearer.
2023-08-16 05:03:01 -0400 < mnieper`> Still, even if you have to cache things, you can hold them in a local variable that is rebound on the next load iteration.
2023-08-16 06:37:45 -0400 < mnieper`> Re generic methods and all this stuff: Time to reread Harper's https://existentialtype.wordpress.com/2011/04/16/modules-matter-most/!
2023-08-16 06:44:06 -0400 < ecraven> thanks
2023-08-16 06:44:45 -0400 < ecraven> hehe, that'll need some studying..
2023-08-16 07:05:30 -0400 -!- Netsplit *.net <-> *.split quits: lloda, phileasfogg, cky, abcdw, johnjaye, pinoaffe, tessier, flatwhatson, ncf, lagash,  (+1 more, use /NETSPLIT to show all of them)
2023-08-16 07:05:30 -0400 -!- abcdw_ is now known as abcdw
2023-08-16 07:06:06 -0400 -!- Netsplit over, joins: ncf
2023-08-16 08:11:44 -0400 < acdw> mnieper`: like chicken has a (void) value
2023-08-16 08:12:47 -0400 < acdw> I'm also thinking that sometimes it'd be good to check whether a function returns some value or nothing
2023-08-16 08:13:21 -0400 < acdw> like, really the procedures that return an unspecified value in the spec return nothing, why not specify that
2023-08-16 08:13:31 -0400 < acdw> I'm guessing there's a good reason
2023-08-16 08:15:14 -0400 < mnieper`> (void) is #<unspecified>, not (values), isn't it?
2023-08-16 08:15:48 -0400 < mnieper`> acdw: The reason is that there were no multiple values (including zero values) in dialects before R5RS.
2023-08-16 08:16:45 -0400 < mnieper`> R6RS opened the door by allowing implementations to return zero values when previous reports talked about an unspecified value.
2023-08-16 08:17:15 -0400 < mnieper`> Unfortunately (as with some other decisions), R7RS-small turned back history.
2023-08-16 08:38:21 -0400 < sham1> And I suppose this would be big enough that we couldn't just have an errata
2023-08-16 08:38:26 -0400 < sham1> Erratum*
2023-08-16 08:50:41 -0400 < mnieper`> Yep. Unless we move forward again.
2023-08-16 08:51:59 -0400 < sham1> Well if the Committee doesn't appoint a new chair for WG2…
2023-08-16 09:09:08 -0400 < mnieper`> At this point, sticking to 15-year old charter without at least reconsidering it wouldn't be a very good idea IMO.
2023-08-16 09:10:40 -0400 < dpk> i would rate the probabilities of various outcomes at present thus: 50% chance the steering committee either fails to take any action or dissolves the working group, ending R7RS Large; 40% chance i am named the new chair; 10% chance someone else is named the new chair. (these probabilities assume nobody else explicitly invites the SC to consider them a potential new chair)
2023-08-16 09:13:17 -0400 < mnieper`> Where does "WG2 not dissolved, but provided with an updated charter" fit into your numbers?
2023-08-16 09:15:34 -0400 < dpk> that would fall into either of the latter two possibilities
2023-08-16 09:16:16 -0400 < dpk> since realistically, a new chair would have to agree to the new charter
2023-08-16 09:16:55 -0400 < dpk> (if chair, i wouldn’t rule out any changes to the charter, but i don’t see any need for them unless we want to formalize the Foundations + Batteries split in some way)
2023-08-16 09:17:32 -0400 < dpk> (but even that would need a reason *why* we want to formalize it in the charter)
2023-08-16 09:17:52 -0400 < acdw> yuh oh what happened 
2023-08-16 09:18:31 -0400 < acdw> mnieper`: thanks for the info btw
2023-08-16 09:19:01 -0400 < mnieper`> Yes, I wonder whether it makes sense to repeat the idea of WG1+WG2. WG1 developing Foundations (formerly R7RS-small, then R8RS) and WG2 developing Batteries (then R8RS-Complete or whatever).
2023-08-16 09:19:24 -0400 < dpk> acdw: jcowan has resigned as chair of WG2. the steering committee – whom nobody has heard from since 2013 – now has to appoint a successor, or else dissolve WG2
2023-08-16 09:19:45 -0400 < dpk> but since nobody has heard from them since 2013, it seems possible that they will just … not do anything
2023-08-16 09:20:32 -0400 < dpk> (to be clear, we’ve heard from the *individuals* on the steering committee, but they have not spoken as a body since 2013)
2023-08-16 09:23:18 -0400 < mnieper`> I received these words from Jonathan Rees this year: "Over time all steering committee members have become unresponsive to email, other than Will who has recently retired and moved far away. [...] the first order of business in setting up a new entity is to determine its rules for dissolution. The steering committee did not do this."
2023-08-16 09:23:27 -0400 < mnieper`> Interpret this as you wish.
2023-08-16 09:23:34 -0400 < dpk> hmm
2023-08-16 09:26:30 -0400 < dpk> given the Scheme Steering Committee has existed since, i think, R4RS, the steering committee completely failing to take any action – not even announcing a new steering committee election, say – would essentially be the end of Scheme standardization
2023-08-16 09:26:31 -0400 < mnieper`> At some point, we have to or even should take matters in our own hands. Presumably, we are more interested in the concrete advancement of the Scheme standard than a group that is losing its authority the more the longer they are silent.
2023-08-16 09:27:01 -0400 < dpk> at that point, probably only Guy Steele has the authority to take action, as it is still his language originally
2023-08-16 09:27:45 -0400 < mnieper`> The SC was founded for standardization of R6RS: https://www.r6rs.org/charter/charter-mar-2006.txt
2023-08-16 09:33:51 -0400 < dpk> the main issue is, though, that if WG2 fails because of the rift in the Scheme community, it’s not clear what any successor committee could do to heal that rift. we tried our best, and at a certain point, if the task is impossible, it’s not our fault that we failed
2023-08-16 09:34:32 -0400 < dpk> and the steering committee is perfectly within its rights to say that they think the task is impossible, especially if it appears (as John said in his resignation email) that the disagreements are only getting worse
2023-08-16 09:35:41 -0400 < mnieper`> After R6RS had been ratified, Will Clinger (together with others) invited Schemers to work on ERR5RS.  If that had produced a final result, it would have been an inofficial standard.  But if it had been accepted by the community, it could have become a de facto standard, possibly named R7RS.
2023-08-16 09:37:15 -0400 < ecraven> well, in the end, the scheme standard is whatever implementations follow, even if a completely new steering committee appears, right?
2023-08-16 09:38:12 -0400 < ecraven> so *iff* everybody (as in most/all? of the major implementations) agrees on R7RS-Large (or even R8RS), then who's to say it's not legitimate?
2023-08-16 09:38:22 -0400 < mnieper`> ecraven: I think there has to be some kind of pseudo-formal agreement between number of people to call it a standard.
2023-08-16 09:38:55 -0400 < acdw> dpk: oh jeez
2023-08-16 09:39:07 -0400 < mnieper`> Or would you call a SRFI a standard?
2023-08-16 09:40:20 -0400 < ecraven> mnieper`, yes, but that's my point. if enough people agree, it is at least a de-facto standard.. given that there *is* no de-jure, well... :D 
2023-08-16 09:41:26 -0400 < ecraven> I'm not saying that's the best way forward, of course it would be best if the steering committee weighed in, but even if they dissolve WG2, that doesn't actually mean very much.. iff dpk feels the call to work on this, and if enough implementations follow along, all the better... as there is no BDFL and no succession rules, everything seems a bit murky :-/
2023-08-16 09:50:35 -0400 < mnieper`> ecraven: I agree.
2023-08-16 09:50:57 -0400 < mnieper`> If the next standard is called SRFI 330, then so it be.
2023-08-16 09:51:08 -0400 < mnieper`> s/called/initially called
2023-08-16 09:52:40 -0400 < sham1> That SRFI would be bloody huge
2023-08-16 09:53:23 -0400 < sham1> The cats that are being herded for this might just be too large and fast for this kind of standard process sadly
2023-08-16 09:53:38 -0400 < sham1> And it seems that most major implementations don't really care
2023-08-16 09:54:03 -0400 < mnieper`> It is hard for them if they don't know what they have to implement! :)
2023-08-16 09:54:20 -0400 < ecraven> sham1: that's the political part (which is probably the huge majority of the work)
2023-08-16 09:54:31 -0400 < mdhughes> Infamously, that's how Python did 3.0: https://peps.python.org/pep-3000/
2023-08-16 09:54:45 -0400 < mdhughes> And while it was a decade of backstabbing and feudal warfare, it worked.
2023-08-16 09:55:24 -0400 < ecraven> given there is no *actual* standardisation process, where you have to pay get a stamp of "your implementation meets the standard", everything we call a standard is just a social agreement anyway :P
2023-08-16 09:55:43 -0400 < mdhughes> Almost everyone now uses Python 3.0, but there's still a few savages in the hills using 2.x
2023-08-16 09:56:09 -0400 < ecraven> mdhughes: I think all the major distributions have abandoned python 2, it's getting very hard to actually *run* python2 code
2023-08-16 09:56:44 -0400 < sham1> mnieper`: well the old standards still exist. And de facto what we have is "R^{Guile}RS", "R^{CHICKEN}RS" and such, which do use whatever RnRS as the basis but have deviated sometimes quite radically from the standard
2023-08-16 09:56:49 -0400 < mdhughes> So, write up what you think an actual Next Scheme would need as SRFI whatever. At least it's better than arguing about names.
2023-08-16 09:58:09 -0400 < sham1> Of course implementations also share ideas and constructs in an unofficial manner
2023-08-16 09:58:36 -0400 < sham1> On top of which the SRFIs are basically just a formality 
2023-08-16 09:59:05 -0400 < mnieper`> As for failing/healing the rift: I don't feel that further progress is hopeless.  Fix the unanimously perceived mistakes of R6RS and extend the standard so that it supports R7RS-small as well (minus crazy stuff like circular structure in syntax objects).  Small implementations will still have R5RS or R7RS-small.
2023-08-16 10:00:51 -0400 < mnieper`> Call it Common Scheme. :D
2023-08-16 10:01:26 -0400 < mnieper`> A process for a large language will then just need some registry for curated libraries.
2023-08-16 10:02:17 -0400 < sham1> A point of comparison could indeed be CL because while CL has the ANSI standard as the common grounding for the common lisp, the different implementations also can do things in quite different ways wherever the ANSI CL standard wasn't specified, like threading for example 
2023-08-16 10:02:37 -0400 < mnieper`> sham1: I see a big difference between RnRS/SRFIs on the one hand side and R^{Guile}RS or R^{CHICKEN}RS on the other hand side.
2023-08-16 10:03:05 -0400 < mnieper`> The former has written specifications meant as specifications. And these don't change (much) over time.
2023-08-16 10:04:09 -0400 < mnieper`> Common Scheme was insofar a joke as Schemes have diverted so much that the common denominator won't be more than R5RS.
2023-08-16 10:04:19 -0400 < mnieper`> Which is fine because we have R5RS.
2023-08-16 10:04:24 -0400 < sham1> Right. What I'm thinking is that maybe we could benefit from a more fluid standards process. In some sense I find myself agreeing with Lassi wrt. the idea that having a more "living" standard would allow for better iteration in terms of the language constructs and such
2023-08-16 10:04:39 -0400 < mnieper`> My "Common" meant R6RS and R7RS-small. :)
2023-08-16 10:05:44 -0400 < sham1> Of course I understand that Lassi's other outputs can be divisive and a tad brash in some aspects
2023-08-16 10:07:08 -0400 < sham1> Maybe there's a language barrier there, who knoes
2023-08-16 10:10:08 -0400 < mnieper`> Some people like to speak in superlatives and binary terms, others like to speak defensively and undecidedly.
2023-08-16 10:12:28 -0400 < mnieper`> Language barriers and cultural barriers cannot be neglected, for sure.  The biggest problem, I see, however, is that we only talk via text and not via speech and facial expressions.
2023-08-16 10:19:19 -0400 < acdw> schemecon!
2023-08-16 10:30:30 -0400 < mnieper`> sham1: RS (1975), RRS (1978), R2RS (1985), R3RS (1986), R4RS (1991), R5RS (1998), R6RS (2007) 
2023-08-16 10:31:02 -0400 < mnieper`> 9 years was the longest period without a new report. Some came a lot faster.
2023-08-16 10:31:45 -0400 < mnieper`> By these numbers, R8RS is overdue (R7RS is from 2013).
2023-08-16 10:32:13 -0400 < mnieper`> What do these numbers mean on a scale between living and dead? 
2023-08-16 10:34:52 -0400 < jackdaniel> 20 scheme standards during a lifetime if we are optimistic
2023-08-16 10:35:07 -0400 < jackdaniel> 7 standards otherwise
2023-08-16 10:35:19 -0400 < jcowan> mnieper`: You know, it's annoying when you misrepresent history by saying that R7RS-small "turned back history".  The history of programming languages is a tree, not a straight line.  Did C "turn back history" relative to Algol 68?
2023-08-16 10:35:20 -0400 < jackdaniel> 8 *
2023-08-16 10:36:44 -0400 < mnieper`> jcowan: People coming from the outside read 7 > 6.
2023-08-16 10:38:27 -0400 < jcowan> I was in fact opposed to reusing the same old stale joke "Revised revised revised revised revised revised revised report" and thought we should have a new naming tradition
2023-08-16 10:38:50 -0400 < jcowan> but the will of WG1 prevailed.
2023-08-16 10:38:53 -0400 < flatwhatson> call the next one Scheme 24
2023-08-16 10:39:24 -0400 < jcowan> better 2x, as we don't know if we can deliver it in 2024.
2023-08-16 10:39:37 -0400 < jcowan> and then change it up after delivery, as C/C++ do
2023-08-16 10:39:44 -0400 < sham1> Scheme 2024. Please, let's not repeat the mistakes of other languages that use only the decade-year for the standard number
2023-08-16 10:39:51 -0400 < sham1> Scheme 202x
2023-08-16 10:40:01 -0400 < acdw> Scheme Warty Warthog
2023-08-16 10:42:30 -0400 < mnieper`> jcowan: As I wrote earlier, I don't blame WG1 for individual decisions to disregard inventions of R6RS. It was not dictated by their charter to produce the next standard linearly in the line (and you hinted at that it would not have been looked upon favourably by the SC). I think it was the fault of the SC to disregard R6RS. Maybe the split was already incurable in 2008, but who knows.
2023-08-16 10:42:31 -0400 < ecraven> mnieper`: the lisps at CL time were much more different than the schemes are now
2023-08-16 10:42:47 -0400 < ecraven> I still have no idea how CL was ever ratified and *implemented* by almost everyone!
2023-08-16 10:43:05 -0400 < mnieper`> Industry and money was behind it, wasn't it?
2023-08-16 10:44:44 -0400 < ecraven> yes, but Interlisp and Zetalisp (Lisp Machine Lisp) were much more different than anything we see in Scheme-Land
2023-08-16 10:45:10 -0400 < mnieper`> R7RS literally means Revised R6RS (if the "Revised" operation is associative), so I fully understand jcowan that a better could have been chosen.
2023-08-16 10:45:19 -0400 < ecraven> so if *they* could convene on a common standard, the Schemes surely *could* :D (of course as you said the motivation was different as well)
2023-08-16 10:45:42 -0400 < mnieper`> *insert "name" after "better"
2023-08-16 10:46:39 -0400 < ecraven> well, even if you call it scheme2024, then people will assume that scheme2027 is the later version, and not a side-branch.. that won't give you anything, right?
2023-08-16 10:47:44 -0400 < ecraven> I'm guessing there has been discussion about making r6rs compatible with r7rs-small, is there any written communication on that?
2023-08-16 10:47:45 -0400 < mnieper`> I claim that the idea of branching is inherently bad.
2023-08-16 10:47:54 -0400 < ecraven> well, r6rs "branched" r5rs, imho
2023-08-16 10:48:08 -0400 < ecraven> and r7rs continued r5rs :P but opinions differ here
2023-08-16 10:48:25 -0400 < mnieper`> R6RS was an existing ratified de-facto standard.
2023-08-16 10:48:50 -0400 < ecraven> it never was de-facto, because so many implementations never implemented it (and said so vocally)
2023-08-16 10:48:53 -0400 < dpk> ecraven: there is more or less consensus that R7RS Large will be in some sense ‘compatible’ with both R7RS small and R6RS
2023-08-16 10:48:54 -0400 < ecraven> it was de-iure, in some ways
2023-08-16 10:49:19 -0400 < dpk> the exact shape of that has been the main source of contention the last week or several
2023-08-16 10:49:53 -0400 < mnieper`> ecraven: I meant "de facto" in that the standard was not cured by an nationally or internationally recognised body.
2023-08-16 10:50:03 -0400 < ecraven> dpk: but has anyone ever discussed "taking out" or "modifying" the parts of r6rs that are not compatible with r7rs-small?
2023-08-16 10:50:22 -0400 < ecraven> mnieper`: sorry, I interpreted incorrectly then
2023-08-16 10:50:46 -0400 < dpk> as part of my invitation to the steering committee, i propose we take the consensus that exists – that we at least won’t do anything that’s blatantly *in*compatible with R6RS – and write the damn report on that basis, and let the steering committee decide what position R6RS has in relation to the new standard, or let the Scheme community hash it out in the comment and ratification stages
2023-08-16 10:50:47 -0400 < mnieper`> What you mean by "not de facto" I would have called "dead standard".  But R6RS is implemented.
2023-08-16 10:51:19 -0400 < mnieper`> Which parts of R6RS are not compatible with R7RS-small, ecraven ?
2023-08-16 10:51:30 -0400 < jcowan> ecraven: Pressure from the U.S. Department of Defense, which wanted a single Lisp.
2023-08-16 10:51:46 -0400 < ecraven> mnieper`: `library` vs. `define-library` is the first I really noticed ;) 
2023-08-16 10:52:04 -0400 < mnieper`> These can coexist.
2023-08-16 10:52:16 -0400 < ecraven> mnieper`: they shouldn't though, there should be *one* way to define libraries, no?
2023-08-16 10:52:34 -0400 < dpk> i have started to write the first fascicle of what i hope would become the Foundations report under my possible chairmanship, and have written in comments appropriate to either R6RS being part of R7RS Large, or R6RS being compatible with R7RS but not part of it, etc.
2023-08-16 10:53:13 -0400 < mnieper`> ecraven: You can explain one in terms of the other using macros.
2023-08-16 10:53:21 -0400 < dpk> thus far the only places that has been relevant is when explaining that, if (rnrs … (6)) is provided by the implementation or the standard, that a certain form has to be exported under the same binding from both the R6RS library and the eventual R7RS library
2023-08-16 10:53:34 -0400 < dpk> (or, alternatively, explaining why it can’t be the same binding)
2023-08-16 10:55:16 -0400 < ecraven> the difference in `map' and `for-each' is complicated too.. (early-termination if the lists are unequal lengths)
2023-08-16 10:55:30 -0400 < jcowan> The present SC was elected because the previous (R6RS-era) SC resigned, and the people who were elected were mostly opposed to R6RS.  You couldn't expect them to find it a controlling precedent.
2023-08-16 10:55:40 -0400 < dpk> ecraven: R6RS allows that behaviour, although discourages it
2023-08-16 10:56:01 -0400 < dpk> besides which, if it were a problem, an implementation could have two versions of ‘map’ etc in different libraries
2023-08-16 10:56:11 -0400 < ecraven> dpk: that doesn't help me if my program doesn't work because that specific implementation has chosen to implement it differently.. I don't need a standard that *doesn't* specify behaviour :P
2023-08-16 10:56:13 -0400 < dpk> (that will be the situation with bytevector-copy!)
2023-08-16 10:56:31 -0400 < sham1> Implementation-specific behaviour
2023-08-16 10:56:38 -0400 < sham1> And then we also get undefined behaviour
2023-08-16 10:56:51 -0400 < ecraven> I would much prefer if there were *one* version in the standard (and maybe some sort of compatibility shim, but with a clear mark that this is not the right thing to use for new code)
2023-08-16 10:56:57 -0400 < sham1> While not as nasal demon-ey as in for example C, it can still be tricky to deal with
2023-08-16 10:57:05 -0400 < mnieper`> dpk: Honestly, I think we should really clarify the point around which we have been circling for weeks first, namely the status of R6RS inside R7RS-large. Then people will know what to expect and many other discussions will be avoided (like about records, etc.).
2023-08-16 10:57:16 -0400 < ecraven> sham1: well, if the behaviour of `map' on lists of different size is undefined, the language isn't worth much, imho :-/
2023-08-16 10:57:22 -0400 < jcowan> The main difference between R6RS and R7RS-small is what Will Clinger called "preposterous MUSTard"
2023-08-16 10:57:34 -0400 < sham1> That's pretty funny
2023-08-16 10:57:59 -0400 < mnieper`> No, this is venom.
2023-08-16 10:58:02 -0400 < ecraven> #u8 vs. #vu8 is also not good.. (but then, so is #f vs. #false, and *that* made it in :P)
2023-08-16 10:58:28 -0400 < sham1> #u8 vs #vu8 can be solved with a bit of #!r6rs and #!r7rs
2023-08-16 10:58:50 -0400 < jcowan> The issue with lexical syntax has always been data files, not code
2023-08-16 10:58:51 -0400 < mnieper`> ecraven: What's the problem of two different procedures named map but in two different libraries?
2023-08-16 10:59:00 -0400 < ecraven> yea, but do you really want a standard that defines both #u8 and #vu8?
2023-08-16 10:59:16 -0400 < mnieper`> ecraven: RnRS has a lot of historical baggage.
2023-08-16 10:59:22 -0400 < mnieper`> A lot of it is hidden.
2023-08-16 10:59:25 -0400 < ecraven> mnieper`: I don't see the point (except for backward compatibility, and I don't see the previous RnRs seeing that as the most important thing, given they changed lots)
2023-08-16 10:59:34 -0400 < sham1> jcowan: then maybe we shouldn't write our programs in the data format. But wait, that's kinda why s-expressions became the actual syntax for Lisps in the first place, because it was easier to do than to implement the m-expressions
2023-08-16 11:00:00 -0400 < mnieper`> ecraven: R6RS's map is arguably the more useful one.
2023-08-16 11:00:04 -0400 < ecraven> it's fine to have #!r6rs, which gives you r6rs, but there's no reason to have #!r7rs *also* be compatible with r6rs, is there?
2023-08-16 11:00:14 -0400 < jcowan> ecraven: In fact there aren't that many incompatibilities, partly because R5RS is a relativly loosey-goosey standard
2023-08-16 11:00:24 -0400 < ecraven> mnieper`: I've been happy about the r7rs way a few times :D
2023-08-16 11:01:04 -0400 < mnieper`> ecraven: #vu8, #vu16, #vf32, ... has the advantage that the # namespace is kept relatively tidy.
2023-08-16 11:01:12 -0400 < ecraven> jcowan: I just read through the appendix of r7rs.pdf again, most of these seem resolvable by just saying #!r6rs gives you the old behaviour.. but then, that is a very file-centered approach, and I love my REPL...
2023-08-16 11:01:14 -0400 < jcowan> Another big difference between R6RS and R7RS is "SRFIs are irrelevant" vs. "Some SRFIs matter a lot".
2023-08-16 11:01:24 -0400 < sham1> Well the idea of #!r7rs is that it'd explicitly be the R7RS mode where we can be incompatible with R6RS lexical syntax and stuff like having to quote vectors
2023-08-16 11:01:25 -0400 < acdw> i'm pretty happy about r7rs-small how i've been using it ... i wish there was a more "blessed" package repository tho, with good clients for it
2023-08-16 11:01:27 -0400 < ecraven> mnieper`: I'm fine with either, I just don't want *both*
2023-08-16 11:01:44 -0400 < sham1> acdw: no, we don't want a shotgun marriage with any single ecosystem
2023-08-16 11:02:00 -0400 < mnieper`> sham1: Vector quoting has nothing to do with lexical syntax
2023-08-16 11:02:01 -0400 < ecraven> but don't we want in on the leftpad fun too? :P XD
2023-08-16 11:02:01 -0400 < acdw> ah. well a package "format" then .. or something
2023-08-16 11:02:01 -0400 < sham1> Also you can certainly do the reader shebangs/directives even in repls
2023-08-16 11:02:34 -0400 < acdw> then a bigger spec then i guess lol (that's what we're talking about )
2023-08-16 11:02:36 -0400 < ecraven> sham1: indeed, but I need to intersperse them at the right places, I don't think anyone particularly likes that..
2023-08-16 11:02:51 -0400 < jcowan> It's annoying that the Racket REPL doesn't accept #lang
2023-08-16 11:02:54 -0400 < ecraven> however, imho Scheme has been moving in a less repl-friendly direction for some time, so maybe that's just what people want...
2023-08-16 11:03:12 -0400 < dpk> mnieper`: well, continuing on the basis of the loose consensus we have is, one could say, my ‘platform’ for being selected as new chair. unless the steering committee explicitly instructs me to resolve the issue before making further progress, i would consider their selecting me on that basis a vote of support for my approach. my plan is for the first part of the report to be on macros, where i perceive there to be the greatest consensus. 
2023-08-16 11:03:12 -0400 < dpk> after that i would probably move on to matters of general Scheme syntax and semantics (formal grammar, lambda, basic syntax like let, etc.), and then probably control features (i.e. plagiarizing SRFI 226 :P). somewhere in the middle will also come things which are not at all controversial, like the number library. records, as a point of particular contention, would probably come quite late as well
2023-08-16 11:03:38 -0400 < jcowan> That was yet another diffference between R6 and R7: "the top level is a mess" vs. "the top level matters a lot"
2023-08-16 11:04:18 -0400 < mnieper`> ecraven: When you confine R6RS syntax to #!r6rs, you do not reconcile the language but just say that an implementation must offer an R6RS mode as well.
2023-08-16 11:04:25 -0400 < ecraven> jcowan: that is probably the one thing I dislike most about R6RS though I haven't been able to articulate *what* exactly my problem is
2023-08-16 11:04:40 -0400 < ecraven> mnieper`: you don't have to, but you can't run #!r6rs code then..
2023-08-16 11:04:57 -0400 < dpk> jcowan: you have to start it with a particular switch, iirc, or use DrRacket …
2023-08-16 11:05:01 -0400 < ecraven> so all the old code of the old implementations continues to work, you just can't write #!r6rs code and expect it to run on e.g. chicken
2023-08-16 11:05:10 -0400 < jcowan> Larceny takes the R6RS committee at its word: "larceny --r6rs" doesn't give you a REPL, you have to specify a program in a file.
2023-08-16 11:05:30 -0400 < dpk> i’ve never managed to get a Racket R6RS REPL in a terminal, although apparently DrRacket has one
2023-08-16 11:05:45 -0400 < ecraven> personally, I wish Scheme moved *more* towards CL in regards to introspection and "mutability" at runtime
2023-08-16 11:05:53 -0400 < mnieper`> ecraven: You wouldn't be able to write an R6RS-style program with the new features.
2023-08-16 11:06:31 -0400 < sham1> jcowan: of course Racket REPL doesn't allow for #!lang. Toplevel is hopeless, after all
2023-08-16 11:06:54 -0400 < jcowan> There is no such thing as R6RS-style.
2023-08-16 11:06:58 -0400 < mnieper`> Are you deliberately misinterpreting the Racket folks?
2023-08-16 11:07:12 -0400 < ecraven> mnieper`: well, why would you want to, if you have scheme202x which has all of the stuff anyway (though with slight changes in details)
2023-08-16 11:07:14 -0400 < mnieper`> jcowan: Like #vu8(...) for a quick example.
2023-08-16 11:08:10 -0400 < jcowan> Nothing stops an R7RS implementation from supporting that.  R6RS implemenations OTOH can't support #u8 unless you set a flag that says "This program is not R6RS".
2023-08-16 11:08:12 -0400 < mnieper`> Also, R6 doesn't say the REPL (= top level) is a mess; it just does not specify it.
2023-08-16 11:08:28 -0400 < jcowan> No, it was Racketeers who said that.
2023-08-16 11:08:28 -0400 < mnieper`> But if you read R7, it does not specify REPL semantics either.
2023-08-16 11:08:32 -0400 < dpk> mnieper`: nobody claimed it did, but that was the clear attitude of the R6RS editors
2023-08-16 11:08:45 -0400 < dpk> (mainly Matthew Flatt, who came up with the damned phrase)
2023-08-16 11:09:24 -0400 < mnieper`> It was certainly not the attitude of Dybvig, whose Chez has a top level.
2023-08-16 11:09:36 -0400 < mnieper`> And Flatt meant something different.
2023-08-16 11:09:50 -0400 < dpk> Racket has a top level too!
2023-08-16 11:09:55 -0400 < dpk> as did PLT Scheme
2023-08-16 11:10:01 -0400 < dpk> the point is not that it shouldn’t exist
2023-08-16 11:10:08 -0400 < mnieper`> The reason why it was not specified is that there was no consensus on the semantics.
2023-08-16 11:10:12 -0400 < dpk> (anyone who thinks that should not consider themselves a Lisp programmer)
2023-08-16 11:10:18 -0400 < mnieper`> And R7 has gotten exactly as far as R6.
2023-08-16 11:10:29 -0400 < dpk> the point is that they think the semantics are somehow inevitably terrible
2023-08-16 11:10:39 -0400 < mnieper`> No, they don't.
2023-08-16 11:11:15 -0400 < mnieper`> What they say is that macros do not behave as expected at the top-level.  Fexprs would.
2023-08-16 11:12:10 -0400 < jcowan> Yes, if you are reallly going to start from scratch, Kernel and Kraken have a lot of appeal
2023-08-16 11:13:47 -0400 < Zipheir> As ecraven says, R6RS was not the de facto standard at the beginnings of R7RS. It's hard to say it is now, with only two "full time" R6 implementations. (Add to that that Guile may be going in its own direction à la Racket.)
2023-08-16 11:14:32 -0400 < mnieper`> Zipheir: Chez, Loko, Racket, Guile
2023-08-16 11:14:40 -0400 < Zipheir> I forgot about Loko.
2023-08-16 11:14:49 -0400 < dpk> IronScheme
2023-08-16 11:14:59 -0400 < mnieper`> Sagittarius
2023-08-16 11:15:00 -0400 < mnieper`> Mosh
2023-08-16 11:15:04 -0400 < sham1> I feel everyone forgot about IronScheme
2023-08-16 11:15:41 -0400 < jcowan> At one point I was using Ypsilon as my "pure R6RS" implementation when developing SRFIs.
2023-08-16 11:15:59 -0400 < dpk> Guile isn’t about to drop R6RS support, even if it isn’t guaranteed it will adopt any future RnRS
2023-08-16 11:15:59 -0400 < mnieper`> It is a living (= de facto) Scheme standard. As is R7RS-small.
2023-08-16 11:16:40 -0400 < sham1> Guile doesn't need to drop it when it can just get more stuff added
2023-08-16 11:16:47 -0400 < jcowan> If you look at the tests from my mid-period SRFIs, they typically run on Chicken (R5RS+), Chibi (pure R7RS-small), Guile (R6RS+), and Ypsilon (pure R6RS)
2023-08-16 11:17:42 -0400 < jcowan> Oh, and fussily saying "de facto standard" is pointless.  We standardized R4RS+- so that people who needed an official standard for procurement purposes could specify it.
2023-08-16 11:17:52 -0400 < Zipheir> OK, it's got a lot more support than it did.
2023-08-16 11:18:34 -0400 < mnieper`> Zipheir: When did R7RS start? 2008? You can't expect that many implementations after 1 year.
2023-08-16 11:19:00 -0400 < Zipheir> I took "de facto standard" to mean the one that a majority of implementations were paying attention to, at the time. I take it it was R5RS back when R7 was started.
2023-08-16 11:19:28 -0400 < jcowan> I think that the clean Loko implementation and the dirty Guile implementation, both the work of individuals, are the evidence that R6RS still matters to implementers.
2023-08-16 11:19:31 -0400 < mnieper`> If the SC had wanted R6 to succeed, they would have waited with R7.
2023-08-16 11:19:40 -0400 < Zipheir> mnieper`: I agree, which is one reason why I wonder if that "no one's implementing R6RS" line in the introduction was injudicious.
2023-08-16 11:19:57 -0400 < jcowan> mnieper`: Exactly
2023-08-16 11:21:37 -0400 < jcowan> Standards are political, and expecting the post-R6RS committee to respect the work of the R6RS-era committee is like expecting the Biden Administration to accept everything the Trump Administration did.  That's not why Biden is there.
2023-08-16 11:21:56 -0400 < dpk> Zipheir: well, they weren’t just not implementing it, they were also saying they’re not going to implement it nowaynohow never nuh-uh
2023-08-16 11:22:16 -0400 < jcowan> Chicken in particular
2023-08-16 11:22:35 -0400 < Zipheir> Well, that hasn't changed, at least.
2023-08-16 11:22:52 -0400 < dpk> or – according to the ERR5RS rationale, at least – picking and choosing bits of it. (originally ERR5RS was going to just pick and choose a standard subset so at least you didn’t have n mutually incompatible subsets)
2023-08-16 11:23:01 -0400 < Zipheir> dpk: Predictably, it's gotten more acceptable over the years.
2023-08-16 11:23:39 -0400 < jcowan> What has?
2023-08-16 11:23:43 -0400 < Zipheir> R6
2023-08-16 11:24:04 -0400 < mnieper`> We can end all these discussions about `map' vs. `map' or `define-library' vs `library' by moving forward to a world in which we accept that there are two incompatible Scheme dialects that will eventually have their own history and their own names. But the differences between R6RS and R7RS-small are so small that it sounds like burying our heads in the sand.
2023-08-16 11:24:24 -0400 < jcowan> I don't know any existing players who have changed their minds, it's just that there are more players.
2023-08-16 11:24:31 -0400 < Zipheir> Yes.
2023-08-16 11:24:41 -0400 < jcowan> mnieper`: The differences I just listed are not ssmall at all: they are fundamental.
2023-08-16 11:25:13 -0400 < mnieper`> If ERR5RS had succeeded, it could have become R7RS-small, R6RS would have been R7RS-mid, and R7RS-large would have been long done.
2023-08-16 11:25:22 -0400 < jcowan> No.
2023-08-16 11:25:33 -0400 < Zipheir> Just two incompatible dialects?
2023-08-16 11:25:37 -0400 < mnieper`> jcowan: Why not?
2023-08-16 11:25:45 -0400 < jcowan> Two incompatible attitudes to standardization.
2023-08-16 11:26:00 -0400 < mnieper`> I think I am lost.
2023-08-16 11:26:56 -0400 < jcowan> You may not think the R6 MUSTard is preposterous (and there's less of it in the final draft), but there's no denying that there is a lot more of it.  R6RS has very few instances of UB; all other Scheme standarads have many.
2023-08-16 11:28:21 -0400 < jcowan> s/lot more of it/lot more of it than in R[23457]RS
2023-08-16 11:29:26 -0400 < jcowan> Larceny is a pretty good attempt to implement the R7-style parts of R6
2023-08-16 11:29:30 -0400 < Zipheir> Every standard is going to have some MUSTard. The differences must be more fundamental than just "more MUSTard" or "less".
2023-08-16 11:29:39 -0400 < mnieper`> ERR5RS would have left it out (as R7RS-small did).
2023-08-16 11:29:52 -0400 < acdw> i prefer MAYonnaise
2023-08-16 11:29:54 -0400 < jcowan> Zipheir: Sure.
2023-08-16 11:29:54 -0400 < dpk> Zipheir: yes! correct! absolutely! thank you!
2023-08-16 11:30:13 -0400 < sham1> Without MUSTard, you don't have a standard
2023-08-16 11:30:19 -0400 < dpk> mnieper`: however, even before it became R7RS small, ERR5RS had already given up on the R6RS record system and invented SRFI 99
2023-08-16 11:30:32 -0400 < dpk> i don’t know what else had been done
2023-08-16 11:30:45 -0400 < sham1> UUIDs for records sounds just wild
2023-08-16 11:31:02 -0400 < mnieper`> dpk: SRFI 99 is not incompatible with R6RS.
2023-08-16 11:31:03 -0400 < jcowan> I think the ERR6RS group considered records the most important thing to fix
2023-08-16 11:31:37 -0400 < mnieper`> It is debatable whether there was anything to fix. :)
2023-08-16 11:31:44 -0400 < jcowan> Of course standards have MUSTard.  I shouldn't have talked about that, I should have talked about UB
2023-08-16 11:31:44 -0400 < mnieper`> sham1: Why?
2023-08-16 11:31:58 -0400 < sham1> Well it's certainly unique
2023-08-16 11:32:10 -0400 < sham1> I don't think I've seen any other language do that.
2023-08-16 11:32:14 -0400 < mdhughes> People whining about "MUSTard" have never read an RFC. They need to get over it, specs say SHOULD, MUST, MAY, etc.
2023-08-16 11:32:21 -0400 < mnieper`> jcowan: An ERR5RS implementation wouldn't have been an R6RS implementation, but the other way round.
2023-08-16 11:32:29 -0400 < jcowan> mdhughes: Thtat's crap.
2023-08-16 11:32:49 -0400 < sham1> The closest I can see to this kind of use of UUIDs is with Microsoft's COM and that's very much an outlier
2023-08-16 11:32:51 -0400 < mdhughes> https://www.rfc-editor.org/rfc/rfc2119
2023-08-16 11:33:14 -0400 < mdhughes> This is not crap. This is the bare minimum necessary language to specify something.
2023-08-16 11:33:41 -0400 < mnieper`> sham1: You don't need to use UUIDs. It can be just a convention.
2023-08-16 11:33:43 -0400 < jcowan> Nobody is denying that standards are all about MUSTard.  Will Clinger was opposed to the pervaisveness in R6RS, where everything that is not explicitly permitted is forbidden.
2023-08-16 11:33:59 -0400 < Zipheir> That's more fundamental.
2023-08-16 11:34:00 -0400 < jcowan> whereas in R[57] everything that is not explicitly forbidden is permited.
2023-08-16 11:34:39 -0400 < mdhughes> There's five whole shades of grey in RFC2119.
2023-08-16 11:34:56 -0400 < mnieper`> sham1: But some kind of identifier for record types is needed if you want two different parts of the program (can be in different processes) to speak the same language.
2023-08-16 11:35:20 -0400 < jcowan> If you look at the text of R6, you'll find there is a lot more explicit and implicit MUST than there is MAY or SHOULD.
2023-08-16 11:35:26 -0400 < mnieper`> sham1: C solves this by not distinguishing struct typedefs of the same shape. 
2023-08-16 11:35:36 -0400 < mnieper`> But this is not what you want in general.
2023-08-16 11:35:49 -0400 < mnieper`> A point in the plane and a complex number should not be the same type.
2023-08-16 11:35:53 -0400 < mdhughes> They were definitely trying to nail down a loosey-goosey bunch of non-languages, and that's how you do it.
2023-08-16 11:35:54 -0400 < jcowan> Eh?  No.  C is nominally typed, not structurally typed.
2023-08-16 11:36:01 -0400 < sham1> Well, structs of the same shape and tag were only made compatible fully in C23
2023-08-16 11:36:06 -0400 < sham1> But sure
2023-08-16 11:36:21 -0400 < jcowan> Oh, my bad, I'm obsolete.  Structural typing comes to C!
2023-08-16 11:36:23 -0400 < sham1> I see your point
2023-08-16 11:36:41 -0400 < mnieper`> I think Marc Feeley has to say a lot more about this because of his work on serializing and communication between Scheme processes.
2023-08-16 11:37:28 -0400 < jcowan> But that's "shape and tag", so nominalism is still prevalent.  mnieper` said "shape" alone, which is structural typing.  There's not a lot of that left.
2023-08-16 11:37:40 -0400 < sham1> Yeah
2023-08-16 11:37:59 -0400 < jcowan> note that points and complex numbers is not an example of structural typing, because the component names differ.
2023-08-16 11:38:06 -0400 < jcowan> Go is structurally typed
2023-08-16 11:38:19 -0400 < sham1> Well Go does both
2023-08-16 11:38:20 -0400 < jcowan> s/points and/points =
2023-08-16 11:38:29 -0400 < jcowan> Yes.
2023-08-16 11:39:29 -0400 < jcowan> Anyway, Scheme is committed to nominal typing for records.
2023-08-16 11:39:32 -0400 < sham1> Yeah
2023-08-16 11:39:38 -0400 < sham1> Probably for the best
2023-08-16 11:40:08 -0400 < jcowan> I don't think anyone's experimented with structural types in Lisps, though I'm probably wrong about that.
2023-08-16 11:41:13 -0400 < mnieper`> jcowan: Yes, I got it wrong with C, mixing it up with what pointer conversions are allowed.
2023-08-16 11:41:39 -0400 < jcowan> Using alists as records would certainly be structurally typed.
2023-08-16 11:42:04 -0400 < mnieper`> Nongenerative record types with known uuids are an approximation to structural record types.
2023-08-16 11:42:49 -0400 < mnieper`> At least, the other party can reconstruct the type.
2023-08-16 11:43:11 -0400 < mnieper`> Which is probably all that's needed.
2023-08-16 11:43:24 -0400 < ecraven> is there a summary of the differences of record types in r6rs and r7rs anywhere?
2023-08-16 11:43:38 -0400 < ecraven> I know the surface differences, but apparently not enough about the semantic differences
2023-08-16 11:44:08 -0400 < mnieper`> ecraven: R7RS record types are opaque, sealed and generative in R6RS language.
2023-08-16 11:44:38 -0400 < ecraven> what does that mean?
2023-08-16 11:44:55 -0400 < mnieper`> Apart from syntactic differences, there are no semantic differences besides that the R7RS record system maps monomorphically into the R6RS system.
2023-08-16 11:45:30 -0400 < jcowan> where "sealed" means "no subtyping allowed", "opaque" means "no inspection", and "generative" means "every unique declaration is a unique type"
2023-08-16 11:45:41 -0400 < mnieper`> ecraven: opaque = cannot be inspected (no such lib in R7RS), sealed = cannot be inherited, generative = whenever a define-record-type is evaluated a new type is created.
2023-08-16 11:45:58 -0400 < mnieper`> lol
2023-08-16 11:46:37 -0400 < jcowan> Two minds with but a single thought
2023-08-16 11:47:06 -0400 < ecraven> so r6rs allows non-opaque and/or non-sealed records, that I understand. but non-generative? how does that work?
2023-08-16 11:47:50 -0400 < ecraven> (for the record, I believe *nothing* should be opaque, you should always be able to inspect things fully at the repl / debugger / listener)
2023-08-16 11:48:16 -0400 < mnieper`> jcowan: Do you see an important area outside of violation of procedure/syntax domains where R6RS contains a lot more MUSTs than R7RS?
2023-08-16 11:48:19 -0400 < mdhughes> In practice you can usually write a record, see that it's a vector with some awful UUID in slot 0, fields in others. Then replace field 0 and read it back in.
2023-08-16 11:48:47 -0400 < jcowan> ecraven: is it really important to inspect bignums?
2023-08-16 11:49:13 -0400 < ecraven> jcowan: when debugging, it might be :P but I'll rephrase my sentence as "for compound objects"
2023-08-16 11:49:16 -0400 < mnieper`> ecraven: Opacity can be important (at least that the language has a (non-debug) mode to enforce it). See LCF-style theorem provers.
2023-08-16 11:49:42 -0400 < mnieper`> You can guarantees about your code you otherwise do not have.  This is important for proving program correctness.
2023-08-16 11:49:44 -0400 < gwatt> ecraven: non-generative means that the record's definition can be stable across compilations.
2023-08-16 11:50:01 -0400 < mnieper`> gwatt: Simpler.
2023-08-16 11:50:07 -0400 < mnieper`> Stable across evaluations.
2023-08-16 11:50:07 -0400 < ecraven> but that introspectability (which I used extensively on MIT/GNU Scheme) is exactly one of the things that have drawn me to Scheme.
2023-08-16 11:50:31 -0400 < ecraven> how does that work? is that like CLOS's redefining a class, and then every existing object is updated to the new definition?
2023-08-16 11:51:24 -0400 < jcowan> (let ((x (lambda () ... (define-record-type foo ...) ...)) (y (lambda () ... (define-record-type foo ...) ...))) ...) is a clearcut example.
2023-08-16 11:51:26 -0400 < ecraven> mnieper`: so this is a trade-off between wanting introspection, and wanting theorem proving.. 
2023-08-16 11:51:38 -0400 < jcowan> Everything is
2023-08-16 11:51:58 -0400 < jcowan> Typically most of the theorems we try to prove are in our own heads.
2023-08-16 11:52:06 -0400 < ecraven> jcowan: what happens to existing objects on redefinition? or does r6rs just not allow redefinition of an existing record type?
2023-08-16 11:52:35 -0400 < ecraven> what happens if the two definitions use the same name, but different fields?
2023-08-16 11:53:07 -0400 < jcowan> In a generative world it doesn't matter because the two definitions of foo are distinct.  In a nongenerative world, bzzzzt.
2023-08-16 11:53:31 -0400 < ecraven> so in a non-generative world, if *anyone* *ever* creates a record type with the same name as I did, things go boink?
2023-08-16 11:53:43 -0400 < jcowan> Hence the use of UUIDs
2023-08-16 11:54:20 -0400 < jcowan> the UUID supersedes the name (which is still local) for identification purposes: two definitions must be compatible if they have the same UUID.
2023-08-16 11:54:23 -0400 < ecraven> thanks for the explanation. I'm happy that R7RS didn't take this port of R6RS :P
2023-08-16 11:54:35 -0400 < ecraven> s/port/part/
2023-08-16 11:54:49 -0400 < mnieper`> ecraven: jcowan: This is wrong.
2023-08-16 11:54:52 -0400 < jcowan> In SRFI 9, the generative/nongenerative distinction was fudged by limiting record types to the top level only
2023-08-16 11:54:57 -0400 < jcowan> mnieper`: What is wrong?
2023-08-16 11:55:14 -0400 < mnieper`> The uid does not supersede the record's name.
2023-08-16 11:56:00 -0400 < mnieper`> If you define two non-generative record types with the same name without an uid at two different places in your program, they are distinct. 
2023-08-16 11:56:00 -0400 < jcowan> For identification purposes.  Two record type definitions define the same record type if they have the same UUID.
2023-08-16 11:56:31 -0400 < jcowan> Yes, because it makes up a UUID for you.
2023-08-16 11:56:43 -0400 < jcowan> That's, as you would say, purely syntactic.
2023-08-16 11:57:18 -0400 < mnieper`> ecraven speaks about the name. But this totally separated from an uid, specified or not.
2023-08-16 11:57:20 -0400 < ecraven> mnieper`: so what happens if I chose a UID of "foo", distribute this as a library, and someone else uses that library and *also* defines some record type as uid "foo" (but in an entirely different library)
2023-08-16 11:57:48 -0400 < mnieper`> ecraven: You don't choose an UID of "foo". Most likely, you don't choose you any UID.
2023-08-16 11:57:49 -0400 < jcowan> Bad things.  The whole point of UUIDs is that they are extremely likely to be unique.
2023-08-16 11:58:12 -0400 < mnieper`> *drop last you
2023-08-16 11:58:25 -0400 < jcowan> Most likely, you use generative definitions anyway
2023-08-16 11:58:35 -0400 < ecraven> so there is a "global" registry of UIDs in a sense? across scheme systems, across time, across libraries?
2023-08-16 11:58:43 -0400 < jcowan> In a sense.
2023-08-16 11:59:09 -0400 < ecraven> what is the point of this? to have write/read'able records?
2023-08-16 11:59:41 -0400 < ecraven> is the UID-generation-algorithm specified? will different scheme implementations chose the same UID for "the same" record type definition?
2023-08-16 11:59:42 -0400 < jcowan> Well, they are certainly impossible without it (or rather, they may give results you don't expect)
2023-08-16 12:00:13 -0400 < jcowan> No, no algorithm is specified.  Using any of the standard UUID algorithms (which produce non-overlapping UUIDs) is extremely unlikely to fail.
2023-08-16 12:00:31 -0400 < ecraven> but then how does this *other* Scheme implementation read my records, if they were written with a different UID?
2023-08-16 12:00:45 -0400 < mnieper`> ecraven: Most of the time, you actually want the R6RS nongenerative way (but with autogenerated uid) instead of R7RS's generative record types.
2023-08-16 12:00:51 -0400 < jcowan> If it doesn't know the definition, it can't.
2023-08-16 12:00:55 -0400 < jcowan> mnieper`: I disagree
2023-08-16 12:00:59 -0400 < mnieper`> Where?
2023-08-16 12:01:20 -0400 < ecraven> but if you don't specify the UID directly, and there's no specified algorithm, how will they arrive at the same UID/
2023-08-16 12:01:41 -0400 < jcowan> ecraven: By putting it inn the record-type declaration.
2023-08-16 12:01:57 -0400 < mnieper`> ecraven: You have to agree with the other party.
2023-08-16 12:02:07 -0400 < ecraven> so you *have* to specify it to actually do what it's supposed to do (anything *except* read and write records inside the same process)?
2023-08-16 12:02:20 -0400 < mnieper`> No, you don't.
2023-08-16 12:02:38 -0400 < mnieper`> Only if you need to recreate it in a different process.
2023-08-16 12:03:08 -0400 < mnieper`> Or if you have two independent libraries but want them to both export a compatible record type but without the need of a third helper library.
2023-08-16 12:03:09 -0400 < ecraven> well, the obvious use of this is serialisation. and that doesn't actually work, because on the next run, the uid will be different. what am I missing here?
2023-08-16 12:03:19 -0400 < sham1> No it won't
2023-08-16 12:03:21 -0400 < jcowan> I disagree that nongenerative but autogenerated record types are better than generative record types.  However, in most cases, the distinction betweene generative and nongen-but-auto is irrelevant, because most record types are declared at the top level
2023-08-16 12:03:32 -0400 < sham1> The whole point is that the UID is part of the record definition
2023-08-16 12:03:42 -0400 < jcowan> YEs
2023-08-16 12:03:44 -0400 < sham1> You as the library author or whatever specify it
2023-08-16 12:03:56 -0400 < sham1> Just like any other identifier
2023-08-16 12:03:56 -0400 < mdhughes> If you use nongenerative, and pick your name, serialization works just fine. Without it, it's impossible, you're back to manual serialization code.
2023-08-16 12:04:04 -0400 < ecraven> but I thought you don't have to, and it'll be auto-generated ("randomly")
2023-08-16 12:04:05 -0400 < mnieper`> ecraven: See SRFI 237 for a proposal for serialization.
2023-08-16 12:04:24 -0400 < ecraven> thanks, I'll read that
2023-08-16 12:04:29 -0400 < jcowan> ecraven: Right.  So don't do that if you want interoperability with other instances
2023-08-16 12:04:36 -0400 < ecraven> this whole thing seems to mix serialisation with record types, imho
2023-08-16 12:04:40 -0400 < jcowan> (of Scheme processes, not of record types)
2023-08-16 12:04:46 -0400 < jcowan> That's just one application
2023-08-16 12:04:46 -0400 < mdhughes> And yes, don't pick something that'll conflict with anyone else. Good luck.
2023-08-16 12:05:00 -0400 < ecraven> mdhughes: so no personalised UUIDs :P
2023-08-16 12:05:19 -0400 < sham1> Well the point is that they're Universally Unique IDentifiers
2023-08-16 12:05:20 -0400 < mdhughes> Well, you can. Name your classes ecraven:Foo and you're fine.
2023-08-16 12:05:33 -0400 < jcowan> The luck is .999999999999... (about (1 - 1/2^56) likely to be good
2023-08-16 12:05:52 -0400 < mdhughes> Just like Java uses reverse DNS. It's not guaranteed, but it's usually fine.
2023-08-16 12:06:00 -0400 < mnieper`> jcowan: I didn't say that "nongenerative is better than autogenerated".  I said that most of the times (when it would matter) you likely want nongenerative ones.
2023-08-16 12:06:08 -0400 < mdhughes> Using a random UUID means you can't ever read it back in, which is silly.
2023-08-16 12:06:28 -0400 < mnieper`> There are only a few cases (like the impl of our SRFI 137) where you want a new type on each procedure invocation.
2023-08-16 12:06:31 -0400 < ecraven> so how do I later *change* that record type definition, add a field or something?
2023-08-16 12:06:51 -0400 < mnieper`> If you give your record a uid, you make a contract with yourself.
2023-08-16 12:06:52 -0400 < mdhughes> You can do that with the programmatic API in R6RS.
2023-08-16 12:07:00 -0400 < jcowan> mdhughes: What do you mean by "random UUID"?  A type 4 UUID has random bits when it's created, but that's irrelevant to its purpuse.
2023-08-16 12:07:23 -0400 < mdhughes> The actual symbol used in Schemes is rarely a real UUID4, it's gensym or something.
2023-08-16 12:07:26 -0400 < jcowan> Oh, s/56/61
2023-08-16 12:07:36 -0400 < ecraven> mnieper`: so I'd have to have my-record-type-v1, my-record-type-v2, and so on?
2023-08-16 12:07:43 -0400 < sham1> You'd want that anyway
2023-08-16 12:07:46 -0400 < sham1> Believe me
2023-08-16 12:08:01 -0400 < ecraven> well, you could do it the way CLOS does things.. (though I'm not saying you should :P)
2023-08-16 12:08:12 -0400 < jcowan> As long as they have distinct uuids, you can give them the same name in a given scope
2023-08-16 12:08:14 -0400 < mdhughes> Been a few years since I toured records in every Scheme I cared about, and they all do it differently.
2023-08-16 12:08:25 -0400 < ecraven> ok, thanks to all of you for bearing with me and explaining!
2023-08-16 12:08:33 -0400 < jcowan> mdhughes: That's nice
2023-08-16 12:08:54 -0400 < jcowan> ecraven: Sure
2023-08-16 12:09:01 -0400 < mdhughes> It's the opposite of nice. It is not precise, or accomodating.
2023-08-16 12:09:20 -0400 < mnieper`> ecraven: I wonder how you could be so quick and say that you like the way R7RS did it when you didn't understand the other system.  (Serious question, no offense meant.)
2023-08-16 12:09:47 -0400 < Zipheir> That could be a good reason in itself...
2023-08-16 12:10:05 -0400 < mdhughes> What would be ideal is the signature of the record somehow becomes the UUID symbol, so at least you could consistently write/read a record of the same structure.
2023-08-16 12:10:13 -0400 < ecraven> mnieper`: I haven't ever seen a use for non-generative record types (because I only use top-level rtds). Can you give me an example of when they would be needed?
2023-08-16 12:10:16 -0400 < jcowan> I don't speak for ecraven, but my answer would be that liking X is not a commitment to not liking every non-X (in the universe of discourse)
2023-08-16 12:10:51 -0400 < ecraven> mdhughes: that's what I assumed happened, when I asked whether there was a standard algorithm for deriving the UUID.
2023-08-16 12:10:57 -0400 < mnieper`> jcowan: In the context above, it was in comparison to R6RS.
2023-08-16 12:11:04 -0400 < mnieper`> Otherwise, I agree.
2023-08-16 12:11:14 -0400 < mdhughes> What does "liking" have to do with anything? This is technical suitability for the problem.
2023-08-16 12:11:16 -0400 < mnieper`> ecraven: Lexical scoping.
2023-08-16 12:11:18 -0400 < ecraven> what I run into often at the repl is the need to *redefine* an existing rtd, but that's a different problem
2023-08-16 12:11:31 -0400 < jcowan> Aha, the top level is hopeless!
2023-08-16 12:11:33 -0400 < ecraven> mnieper`: but what are use-cases for local rtds?
2023-08-16 12:11:45 -0400 < jcowan> Encapsulation generally
2023-08-16 12:12:08 -0400 < jcowan> Note that a record-type, like any other identifier, defined in a library is "local"
2023-08-16 12:12:47 -0400 < mnieper`> ecraven: I am sure you have algorithms in your code where pairs of values are worked on internally. 
2023-08-16 12:13:05 -0400 < mnieper`> You probably use `cons' and `car' and `cdr' for these pairs.
2023-08-16 12:13:25 -0400 < mnieper`> At some point, you may want to be more explicit (self-documenting code!).
2023-08-16 12:13:48 -0400 < ecraven> mnieper`: but the use-case here is very narrow, right? it's only useful for library-internal non-exported functions
2023-08-16 12:14:03 -0400 < jcowan> Record types with explicit UUIDs can be declared locally, but their definition has to be consistent everywhere; you don't have to import it from some library, you can justs copy the definition and all is well.
2023-08-16 12:14:14 -0400 < mnieper`> So you write (define-record-type either (fields left right)).
2023-08-16 12:14:45 -0400 < mnieper`> And replace cons by make-either, car by either-left, etc.
2023-08-16 12:15:00 -0400 < mnieper`> (-> see SRFI 189 for the names).
2023-08-16 12:15:11 -0400 < mnieper`> s/names/example names
2023-08-16 12:15:14 -0400 < ecraven> mnieper`: but if I return this from my library to your function in *another* library, you can't ever get at that record type, because you don't know my UUID, right?
2023-08-16 12:15:29 -0400 < dpk> mnieper`: how much effort would it be for you to add support for intermingling definitions and expressions in bodies as in https://codeberg.org/scheme/r7rs/issues/104 to Unsyntax? it would be a relatively simple SRFI to write, but would require some core hacking on one or another implementation to satisfy the need for a sample implementation, i think
2023-08-16 12:15:30 -0400 < mnieper`> You can return a record value.
2023-08-16 12:15:56 -0400 < mnieper`> But it would be opaque.
2023-08-16 12:16:13 -0400 < mnieper`> Because the client code has no accessors or mutators.
2023-08-16 12:16:52 -0400 < jcowan> ecraven: If the UUID is autogenerated, then you can only get at it by import.  I don't normally export record types, I just export a subset of their consturctors, accessors, and mutators.
2023-08-16 12:16:59 -0400 < mnieper`> dpk: This would not be hard because Unsyntax already supports this for program and library bodies.
2023-08-16 12:17:29 -0400 < mnieper`> Chibi had this.
2023-08-16 12:17:40 -0400 < ecraven> so I still don't see any actual (non-theoretical) use-case for this in code that *doesn't* just have very large functions (where it makes sense to define purely internal record types)
2023-08-16 12:17:40 -0400 < mnieper`> Support was removed at some point.
2023-08-16 12:18:14 -0400 < ecraven> jcowan: that's what I do too (but I only use R7RS record types)
2023-08-16 12:19:16 -0400 < mnieper`> ecraven: As R7RS record types are generative and as R7RS does not prescribe how often a library is evaluated, in fact it is allowed that two different libraries of your program importing from a third see incompatible record types.
2023-08-16 12:19:20 -0400 < jcowan> But it comes up on occasion.  If two SRFIs want to share the same data type, it has to be defined in another SRFI, for example.
2023-08-16 12:20:04 -0400 < mnieper`> ecraven: Technically, the comparator type of SRFI 128 is a different one for every import.
2023-08-16 12:20:18 -0400 < mnieper`> s/is/can be
2023-08-16 12:20:33 -0400 < jcowan> No, I don't think so.  
2023-08-16 12:20:52 -0400 < mnieper`> jcowan: It was the output of a discussion many years ago.
2023-08-16 12:21:01 -0400 < ecraven> couldn't this be solved by saying that identical record type definitions create the same record type?
2023-08-16 12:21:08 -0400 < mnieper`> Between Alex, you and me, I think.
2023-08-16 12:21:16 -0400 < jcowan> ecraven: That's precisely what "nongenerative" means.
2023-08-16 12:21:29 -0400 < mnieper`> lol... I was about to type exactly the same.
2023-08-16 12:21:43 -0400 < ecraven> jcowan: but then why not specify some algorithm that calculates a UUID based on the specification, not force the user to somehow invent and copy it around?
2023-08-16 12:21:56 -0400 < mnieper`> ecraven: The user is not forced to invent it.
2023-08-16 12:22:10 -0400 < mnieper`> You have to understand the difference between expansion and evaluation.
2023-08-16 12:22:20 -0400 < mnieper`> A form may be expanded only once, but evaluated many times.
2023-08-16 12:22:37 -0400 < mnieper`> A uid is generated once per expansion.
2023-08-16 12:23:00 -0400 < mnieper`> A generative record type behaves as if a new uid were generated per evaluation.
2023-08-16 12:23:06 -0400 < jcowan> I'm not sure whether single expansion is a consequence of R7RS or not.
2023-08-16 12:23:14 -0400 < ecraven> so r6rs specifies that define-record-type is a macro, and it specifies that macros are expanded only once per library?
2023-08-16 12:23:27 -0400 < sham1> But that only really works within the same environment. That doesn't work when you're trying to serialize and deserialize between Scheme processes,  in which case you'll have to invent one
2023-08-16 12:23:29 -0400 < mnieper`> define-record-type is a form
2023-08-16 12:23:32 -0400 < mnieper`> All forms are expanded.
2023-08-16 12:23:34 -0400 < mdhughes> nongenerative *can* be the same type, if they're compatible values when you write/read.
2023-08-16 12:23:48 -0400 < jcowan> Right, but inventing a uuid is easy type "uuid" into your development system.
2023-08-16 12:24:24 -0400 < jcowan> Then you have it and you can publish the definition.  The result is context-free.
2023-08-16 12:25:07 -0400 < jcowan> damned ; key is not working reliably
2023-08-16 12:25:16 -0400 < mnieper`> https://paste.debian.net/1289165/
2023-08-16 12:25:22 -0400 < mdhughes> But the UUIDs would be different every time you did (define-record-type, so it doesn't "create a type" that persists past one run.
2023-08-16 12:25:23 -0400 < mnieper`> (for Emacs ^^)
2023-08-16 12:25:57 -0400 < Zipheir> mdhughes: SRFI 224 is probably the first SRFI to explicitly state the UUID of the type it defines (fxmappings).
2023-08-16 12:26:03 -0400 < Zipheir> That's one way to use them.
2023-08-16 12:26:24 -0400 < ecraven> mnieper`: but now you have to copy (and keep in sync) that definition all over the place, wherever you want to use it, right?
2023-08-16 12:26:32 -0400 < mdhughes> fxmapping-7a1f4d5b-a540-462b-82b1-47283c935b85 ROFL
2023-08-16 12:26:35 -0400 < mnieper`> Zipheir: As far as I know this is the only way to make sense of the disjoint-type-problem of the SRFIs.
2023-08-16 12:26:40 -0400 < jcowan> mdhughes: That's true *unless* you specify an explicit UUID in the define-record-type.  
2023-08-16 12:27:00 -0400 < mdhughes> jcowan: Correct, I mean generative UUID.
2023-08-16 12:27:02 -0400 < jcowan> ecraven: The alternative is always importing it from the same library.
2023-08-16 12:27:08 -0400 < mnieper`> ecraven: Indeed.
2023-08-16 12:27:21 -0400 < mnieper`> Which is what most people would do, I think.
2023-08-16 12:27:29 -0400 < mdhughes> The fxmapping thing reminds me of The IT Crowd's new 911 number.
2023-08-16 12:27:39 -0400 < ecraven> this is all too complicated, let's just go back to lists and tagged vectors :P :D thanks for explaining *again* :D
2023-08-16 12:27:41 -0400 < jcowan> ... yeees?
2023-08-16 12:27:53 -0400 < jcowan> Sure, as long as the tags are UUIDs.
2023-08-16 12:28:11 -0400 < sham1> Well a symbol can be anything
2023-08-16 12:28:19 -0400 < mnieper`> We mix up UUID with uid here.
2023-08-16 12:28:22 -0400 < jcowan> I still like the idea that vectors are lists in which the cars are mutable and the cdrs are immutable, so they differ only at construction time.
2023-08-16 12:28:57 -0400 < sham1> CDR-coding isn't coming back
2023-08-16 12:29:03 -0400 < ecraven> cdr-code them, as zetalisp did, so you can access the same data as a vector *or* a list :D
2023-08-16 12:29:09 -0400 < jcowan> mnieper`: I'm assuming that you never want a uid that isn't *unjiversally* unique.  You are asking for trouble if you do that.
2023-08-16 12:29:10 -0400 < sham1> Unless we CoW everything
2023-08-16 12:29:13 -0400 < ecraven> (or rather *and* a list)
2023-08-16 12:30:00 -0400 < jcowan> CDR-coding is related but not the same.  The trickery in CDR-coding is to allow set-cdr! to stsill work.  But if vectors are lists with immutable cdrs, then set-cdr! doesn't work on them by deifnition.
2023-08-16 12:30:24 -0400 < ecraven> so instead of something like com.example.ecraven.Foo.V1 (to take java as an example), I'd call my record ecraven-332a6ff3-04d1-3e38-ca7b-d798ab367829?
2023-08-16 12:31:06 -0400 < mnieper`> No, you *call* your record "coloured-point".
2023-08-16 12:31:12 -0400 < mnieper`> ecraven-332a6ff3-04d1-3e38-ca7b-d798ab367829 would be the uid.
2023-08-16 12:31:12 -0400 < ecraven> sorry, use that as the UID
2023-08-16 12:31:16 -0400 < jcowan> Yes.
2023-08-16 12:31:31 -0400 < ecraven> hm.. so in fact nothing prevents me from using `foo' as the uid? it's just a symbol?
2023-08-16 12:31:35 -0400 < mnieper`> This uid will only appear in your program's documentation.
2023-08-16 12:31:59 -0400 < mdhughes> Or you can be sane and not do that, just as long as your nongenerative name is probably-distinct.
2023-08-16 12:32:38 -0400 < mnieper`> Back to the question of how often a record type definition is expanded:
2023-08-16 12:32:39 -0400 < ecraven> mdhughes: but if I *don't* specify the UID, why would I use a non-generative record type definition in the first place? that'd be rather dangerous
2023-08-16 12:32:53 -0400 < mnieper`> R6RS says: only once per library in phase 0 (during runtime).
2023-08-16 12:33:10 -0400 < mdhughes> I mostly nongenerative name my records mdh:whatever:version and I'd be very surprised if a library boned me on that.
2023-08-16 12:33:41 -0400 < mnieper`> This means that the macro transformers defined in different libraries may see incompatible record types imported from a third library when no uid is given.
2023-08-16 12:33:45 -0400 < ecraven> mdhughes: ah, sorry, I misread that, please ignore my comment
2023-08-16 12:33:48 -0400 < mdhughes> If you don't care about round-tripping it, generative is fine. That's most records that have ever been made!
2023-08-16 12:33:59 -0400 < mnieper`> For this to be a problem, the transformers would have to try to communicate.
2023-08-16 12:34:08 -0400 < jcowan> Nothing prevents you from using foo as the uid, any more than Java prevents you from writing "public class Foo".  You'll just suffer later on, or your users will.
2023-08-16 12:34:49 -0400 < jcowan> (without a package declaration, that is)
2023-08-16 12:35:21 -0400 < mnieper`> But Ghuloum and Dybvig make a point that it is unsound to expand a library more than once in a program, regardless of phase.
2023-08-16 12:36:08 -0400 < mnieper`> If an implementation follows their arguments, explicit uids are superfluous when one restricts to what R6RS has.
2023-08-16 12:38:14 -0400 < mnieper`> ecraven: Re opaqueness. For provability of program correctness it is enough if the implementation specifies a way where you cannot peek and poke everywhere.
2023-08-16 12:38:41 -0400 < mnieper`> It is not un-Lispy to have opaque record types.  Closures (= procedures) are likewise opaque in standard Scheme.
2023-08-16 12:39:07 -0400 < ecraven> mnieper`: I'm not saying it is, however for debugging it is very beneficial if you *can* introspect everything (including closures)
2023-08-16 12:39:08 -0400 < mnieper`> But implementations may offer modes or libraries that allow to take a look at the closed-over locations.
2023-08-16 12:39:46 -0400 < mnieper`> ecraven: This is certainly not in contrast to R6RS (or R7RS).
2023-08-16 12:39:46 -0400 < ecraven> regarding sealed-ness, I have wished for this a few times in R7RS, was this discussed but not deemed a good idea?
2023-08-16 12:40:29 -0400 < jcowan> ecraven: You mean R7RS-small?  Alll types are sealed, because there is no way to define subtypes.
2023-08-16 12:40:32 -0400 < mdhughes> Debuggers usually let you inspect a record, but not usually modify it as you'd like.
2023-08-16 12:40:32 -0400 < ecraven> (I've wanted it for things like e.g. condition hierarchies)
2023-08-16 12:40:48 -0400 < mnieper`> You mean you wanted inheritance?
2023-08-16 12:41:12 -0400 < ecraven> jcowan: but is there no way to define subtypes because it was deemed unwanted, or because srfi-9 just doesn't have that?
2023-08-16 12:41:20 -0400 < jcowan> IMO (and this is only MO) inheritance is only really useful if you want *other people* to inherit stuff from your record types.
2023-08-16 12:41:33 -0400 < ecraven> mnieper`: or some sort of polymorphism [which probably comes down to the same thing]
2023-08-16 12:41:42 -0400 < mnieper`> The problem with SRFI 9, the choice of R7RS, is that it is not obvious way how to extend it to inheritance.
2023-08-16 12:42:02 -0400 < mnieper`> That's why it spawned so many proposals (SRFI 99, SRFI 131, SRFI 136, SRFI 150).
2023-08-16 12:42:06 -0400 < ecraven> jcowan: so how do I write a hierarchy of condition records then? like error > file-error > some-specific-file-error
2023-08-16 12:42:07 -0400 < jcowan> There is no obvious way to *do* inheritance.  R6RS does it, but not in an obvious way.
2023-08-16 12:42:27 -0400 < jcowan> Expose an "error?" function that knows all about the others.
2023-08-16 12:42:29 -0400 < Zipheir> That's the challenge with subtype polymorphism.
2023-08-16 12:43:11 -0400 < mnieper`> Inheritance (when you need it) can be emulated with R7RS.
2023-08-16 12:43:36 -0400 < mnieper`> It will just be not as efficient as using a native system like R6RS.
2023-08-16 12:44:56 -0400 < jcowan> If you look inside the implementation of SRFI 113 (ssets and bags) everythign is done internally with a type named "sob" (set or bag).  There is a flag in sobs that say whether this sob is a set or a bag, and the set-* and bag-* functions check this flag before calling the sob-* function.  Only a few sob-* functions (sob-add, obvs) care about the state of this flag.
2023-08-16 12:45:26 -0400 < jcowan> This would be hopeless if I cared about people adding new kinds of sobs, but I don't.
2023-08-16 12:45:27 -0400 < mnieper`> I think the condition hierarchy you wrote down is a very good example where inheritance is useful.
2023-08-16 12:46:01 -0400 < mdhughes> I do a fair amount of record inheritance in R6RS, and it's useful, but annoying: It doesn't copy over accessors of the parent type, so you have to do (define Bar-x Foo-X) etc.
2023-08-16 12:46:19 -0400 < jcowan> Furthermore, I could have written some macros that given a sob-* function name would generate the set-* and bag-* functions.  I didn't because the problem wasn't big enough to justify it.
2023-08-16 12:46:27 -0400 < mnieper`> mdhughes: You would want to use Chez's `alias'.
2023-08-16 12:46:29 -0400 < jcowan> s/functions/function definitions
2023-08-16 12:46:33 -0400 < mdhughes> But sometimes I don't need a full object system, but do need refined details of a type.
2023-08-16 12:46:36 -0400 < mnieper`> mdhughes: Or rename on export.
2023-08-16 12:47:14 -0400 < mnieper`> mdhughes: The reason why parent accessor names are not duplicated is simple. It would break an abstraction barrier.
2023-08-16 12:48:09 -0400 < jcowan> The usual approach is that there is either no abstraction barrier between a class and its subclasses, or the barrier is tuneable on a per-identifier basis.
2023-08-16 12:48:38 -0400 < mdhughes> mnieper`: These are within the same library. Is alias any different from a define?
2023-08-16 12:49:14 -0400 < jcowan> (Smalltalk has no barriers between classes and subclasses for methods, but the barrier between instance variables is absolute: an instance variable of a given instance is not accessible from another instance even of the same class.
2023-08-16 12:49:17 -0400 < jcowan> )
2023-08-16 12:51:34 -0400 < jcowan> I almost never write Java methods that look inside the (private) instance variables of another instance, except for stereotyped cases like "if (this.class != that.class)", where that is some other instance.
2023-08-16 12:51:35 -0400 < mdhughes> I wrote a real Self-like OOP system for when I deal with "big objects all the time", but for many tasks that's overkill.
2023-08-16 12:51:51 -0400  * jcowan nods
2023-08-16 12:52:02 -0400 < mnieper`> mdhughes: alias does not create a new location.
2023-08-16 12:52:09 -0400 < jcowan> That's why R[45]RS has no record types: you are expected to roll your own.
2023-08-16 12:52:19 -0400 < mnieper`> It is just a second name for the same thing.
2023-08-16 12:52:40 -0400 < jcowan> At all phases?
2023-08-16 12:52:47 -0400 < mnieper`> jcowan: But you don't get type safety against procedures or vectors.
2023-08-16 12:53:12 -0400 < mnieper`> jcowan: It is like exporting an identifier twice. Once with rename, once without.
2023-08-16 12:53:24 -0400 < mnieper`> Which can be done in R7RS as well.
2023-08-16 12:53:25 -0400 < mdhughes> But both names point at the same function, so it's not saving memory, or any faster.
2023-08-16 12:53:49 -0400 < ecraven> so if I want a hierarchy of conditions, the r7rs way is to create the record types, then extend the predicates to answer true also for (conceptual, not actual) subtypes, and write the accessors so they also work on subtypes?
2023-08-16 12:54:05 -0400 < jcowan> Yes.  And use macros to help.
2023-08-16 12:54:08 -0400 < mnieper`> Because Chez Scheme has R7RS procedure equality, the function pointers must be different.
2023-08-16 12:54:16 -0400 < ecraven> jcowan: thanks
2023-08-16 12:54:34 -0400 < jcowan> Also mutators, if you have any (typically you don't want mutators for conditions)
2023-08-16 12:54:42 -0400 < Zipheir> The R7RS way is closer to predicate-based type families.
2023-08-16 12:54:43 -0400 < ecraven> yea, that's why I didn't add them ;)
2023-08-16 12:55:37 -0400 < jcowan> A little library to create this kind of subtyping would be a good SRFI (hint, hint)
2023-08-16 12:55:47 -0400 < mnieper`> The last was for mdhughes 
2023-08-16 12:56:15 -0400 < mnieper`> jcowan: SRFI 136, SRFI 150, SRFI 137... ?
2023-08-16 12:56:23 -0400 < jcowan> Of course, you'd have to define the record types through the library in the first place, in order to save the metadata somewhere.  And there would be issues around generativity.
2023-08-16 12:56:49 -0400 < jcowan> mnieper`: Those are all run-time discoverable and extensible.  This would not be, it would just help you write the definitions.
2023-08-16 12:57:05 -0400 < ecraven> (define-record-type-hierarchy ...)
2023-08-16 12:57:12 -0400 < jcowan> Yes.
2023-08-16 12:57:27 -0400 < mnieper`> Under a closed-world assumption, this works.
2023-08-16 12:57:28 -0400 < ecraven> I'll give it a go, if it ever goes anywhere, maybe it'll be useful for someone else too
2023-08-16 12:57:51 -0400 < jcowan> mnieper`: Right.  ecraven: Great!
2023-08-16 12:57:52 -0400 < mnieper`> But are you sure you don't want to add conditions somewhere else?
2023-08-16 12:58:16 -0400 < ecraven> mnieper`: yes, however the problem I see is that I may want to "inherit" from something outside the library
2023-08-16 12:58:33 -0400 < mnieper`> what do you mean exactly?
2023-08-16 12:58:35 -0400 < jcowan> Yes, it deliberately does not deal with that use case.
2023-08-16 12:58:42 -0400 < ecraven> say I'm wrapping socket, I'll create all my own condition types (and no-one should come along and create new sub-types anyway), but I may want to inherit from some default "error" record type
2023-08-16 12:58:47 -0400 < jcowan> (the open-world assumption)
2023-08-16 12:59:30 -0400 < ecraven> thanks for all the discussions, jcowan I'll let you know when I have anything.. this has been bugging me for some time in several libraries, this sounds like a good first step
2023-08-16 12:59:43 -0400  * jcowan nods
2023-08-16 13:00:55 -0400 < mnieper`> ecraven: I you want to inherit from some default "error" record type, you are back to the open-world assumption.
2023-08-16 13:01:12 -0400 < mnieper`> (As far as the perspective of the default "error" type is concerned.)
2023-08-16 13:01:29 -0400 < ecraven> mnieper`: this could be added to the macro though (as opposed to making it inheritable in other places)
2023-08-16 13:01:38 -0400 < mnieper`> This is a good point for why standardized record systems make sense.
2023-08-16 13:02:01 -0400 < mnieper`> ecraven: No, because you wouldn't be able to change the predicate error?.
2023-08-16 13:02:12 -0400 < ecraven> ah, indeed, very good point
2023-08-16 13:02:24 -0400 < mnieper`> Take a look at SRFI 136 or SRFI 150.
2023-08-16 13:02:33 -0400 < ecraven> mnieper`: well, the problem is that so many different things are bunched into the record type system
2023-08-16 13:02:49 -0400 < mnieper`> What do you mean?
2023-08-16 13:03:13 -0400 < mnieper`> SRFI 136 and SRFI 150 are both fairly conservative extensions of R7RS's version of SRFI 9.
2023-08-16 13:03:49 -0400 < ecraven> it would be easier if these things (like opaque/open, sealed/inheritable, generative/non-generative) were all orthogonal and solvable in different ways
2023-08-16 13:04:07 -0400 < mnieper`> These are not in SRFI 136/150.
2023-08-16 13:04:19 -0400 < mnieper`> And even in R6RS, they don't come into your way.
2023-08-16 13:04:30 -0400 < mnieper`> As much as call/cc doesn't if you don't need/understand it.
2023-08-16 13:04:50 -0400 < mnieper`> R6RS: (define-record-type file-error (parent error) (fields filename))
2023-08-16 13:04:57 -0400 < mnieper`> Can't be simpler.
2023-08-16 13:06:13 -0400 < mdhughes_> mnieper`: If I (define Bar-x Foo-x), then (Bar-x bar) works exactly the same as (Foo-x bar), because both names point to the same function.
2023-08-16 13:06:49 -0400 < ecraven> mnieper`: I prefer the r7rs variant, however as you've pointed out, those two srfis provide options there
2023-08-16 13:07:02 -0400 < mnieper`> Ah, sorry, yes, it doesn't have anything with procedure equivalence.
2023-08-16 13:07:12 -0400 < mnieper`> But define creates a location.
2023-08-16 13:07:32 -0400 < mnieper`> So your function pointer will be stored in two locations.
2023-08-16 13:07:33 -0400 < mdhughes_> alias would be useful if I wanted two names for the same integer location, say.
2023-08-16 13:07:44 -0400 < mnieper`> Unless the compiler is smart enough.
2023-08-16 13:08:10 -0400 < mnieper`> ecraven: Write a large program in R7RS and write the same large program in R6RS. And then tell which dialect you prefer.
2023-08-16 13:08:48 -0400 < mdhughes_> Or: R5RS+CHICKEN and then R6RS+Chez, and wow the latter's a lot nicer.
2023-08-16 13:09:59 -0400 < ecraven> mnieper`: (un)fortunately that question doesn't arise, because I won't ever use R6RS until all of the systems I'm interested in (which include MIT/GNU Scheme) implement R6RS
2023-08-16 13:10:23 -0400 < ecraven> and it's simpler to shim R7RS (at least "good enough" onto chez than r6rs onto mit)
2023-08-16 13:10:38 -0400 < ecraven> sorry, that closing parenthesis is wrong, should be earlier
2023-08-16 13:27:24 -0400 -!- mdhughes_ is now known as mdhughes
2023-08-16 13:29:57 -0400 < mnieper`> ecraven: Above you said you "prefer the r7rs variant", which was about the language as such, not about particular implementations.
2023-08-16 13:30:08 -0400 < mnieper`> That's why I gave you the task.
2023-08-16 13:36:17 -0400 < mnieper`> Re closed world: What we really want/need is a simple way (some macro) to define recursive inductive data types together with their constructors and pattern matchers (= destructors).
2023-08-16 13:47:50 -0400 < gwatt> so, "data List a = Cons a (List a) | Nil" ?
2023-08-16 13:49:56 -0400 < Zipheir> You could do that with sealed record types and predicates.
2023-08-16 13:51:59 -0400 < Zipheir> The macro layer might be somewhat complicated, but I bet there's some prior work here.
2023-08-16 13:53:03 -0400 < mnieper`> gwatt: Yes.
2023-08-16 13:57:45 -0400 < gwatt> The nanopass library's type definitions don't look too far off, though it's harder to use them in normal scheme
2023-08-16 14:04:25 -0400 < mnieper`> Yes, this is what I have in mind.
2023-08-16 14:04:32 -0400 < mnieper`> Without the baggage.
2023-08-16 14:07:16 -0400 < Zipheir> Yeah, the nanopass type form, that's what I was thinking of.
2023-08-16 14:23:23 -0400 < ecraven> ah, catamorphisms all the way!
2023-08-16 14:24:19 -0400 < ecraven> jcowan: regarding define-record-type-hierarchy, how would that deal with super-type accessors in subtypes? it would have to gensym the names, unless we want to specify *all* of them?
2023-08-16 14:27:12 -0400 < mnieper`> Zipheir: I wouldn't want to write such an extensive macro without s-c, though.
2023-08-16 14:28:04 -0400 < jcowan> ecraven: my view is htat you don't need them.  If you have type i/o-error and a subtype file-not-found and i/o-error has an accessor i/o-error-port, you would just call that accessor on file-not-found instances.  You do not need an accessor file-not-found-port.
2023-08-16 14:31:03 -0400 < ecraven> ok, so the only thing necessary is to extend the super-type predicates to the subtypes?
2023-08-16 14:46:35 -0400 < jcowan> No, you still need to make the supertype accessors *accept* the subtype instances, you just don't have to expose this.
2023-08-16 14:47:20 -0400 < ecraven> right.. not sure I can manage this in syntax-rules alone :-/
2023-08-16 14:47:32 -0400 < ecraven> (it should be possible, just that *I* can write hairy code like that)
2023-08-16 14:47:35 -0400 < jcowan> so i/o-error-port has to be able to treat file-not-found objects too
2023-08-16 14:55:25 -0400 < mnieper`> ecraven: Try SRFI 148.
2023-08-16 14:55:36 -0400 < mnieper`> s-r macros simpler
2023-08-16 15:28:01 -0400 < ecraven> mnieper`: yea, but the only guaranteed macro system at this point is syntax-rules :-/
2023-08-16 15:30:37 -0400 < dpk> ecraven: the SRFI 148 sample implementation is complete and compliant and runs on any R7RS small
2023-08-16 15:30:55 -0400 < dpk> with just syntax-rules as a base
2023-08-16 15:31:02 -0400 < ecraven> thanks, I'll look into that
2023-08-16 15:31:04 -0400 < dpk> i need to make a FAQ or something for this
2023-08-16 15:33:39 -0400 < dpk> this is the second time time this week someone has misunderstood that SRFI 148 isn’t a new macro system in the way syntax-case or explicit renaming is, but a way to write syntax-rules macros in pseudo-procedural style
2023-08-16 15:35:56 -0400 < dpk> the SRFI itself doesn’t explain that very well
2023-08-16 15:36:49 -0400 < ecraven> hm.. is it not legal to use (syntax-rules () ((_ name name) name) to find instances of (_ foo foo) or (_ bar bar)? chez doesn't like this...
2023-08-16 15:37:15 -0400 < dpk> no, that’s not possible
2023-08-16 15:37:32 -0400 < dpk> unless name is a literal
2023-08-16 15:37:46 -0400 < ecraven> I want to find out whether x occurs in a list, with syntax-rules
2023-08-16 15:38:33 -0400 < dpk> it’s not allowed to have multiple pattern variables with the same name in syntax-rules, in R6 or R7
2023-08-16 15:38:55 -0400 < ecraven> so there's no way to match something non-specific?
2023-08-16 15:39:23 -0400 < dpk> what do you mean by non-specific?
2023-08-16 15:39:59 -0400 < dpk> usually the problem with syntax-rules is you can’t be specific *enough* with the patterns, heh
2023-08-16 15:40:13 -0400 < ecraven> given something like this http://ix.io/4DGr I want to check for each sub-expression whether it contains an identifier (each in turn)
2023-08-16 15:40:42 -0400 < ecraven> so I want (subclasses-of error <entire-expression>) and (subclasses-of file-error <entire-expression>) and so on
2023-08-16 15:41:35 -0400 < ecraven> (where subclasses-of is another syntax-rules macro that does the matching)
2023-08-16 15:41:58 -0400 < ecraven> (subclasses-of error (foo bar error)) should return foo
2023-08-16 15:44:05 -0400 < ecraven> s/return/expand to/
2023-08-16 15:44:57 -0400 < mnieper`> Can't you expand this into a bunch of SRFI 136 record type definitions?
2023-08-16 15:45:12 -0400 < mnieper`> As SRFI 136 is solely syntax-rules and R7RS record type.
2023-08-16 15:45:26 -0400 < dpk> there is a trick in syntax-rules to test for whether something is an identifier. it was discovered by Oleg Kiselyov, which might give you an idea of how much dark magic it contains
2023-08-16 15:46:05 -0400 < dpk> the relevant trick is in SRFI 148 in much easier to use form and is called em-identifier?
2023-08-16 15:46:13 -0400 < dpk> you will have a much better time with that
2023-08-16 15:46:26 -0400 < dpk> or possibly with what mnieper` is suggesting
2023-08-16 15:47:18 -0400 < dpk> (correction: it’s called em-symbol?)
2023-08-16 15:50:55 -0400 < mnieper`> For demonstration, I wrote SRFI 150's sample impl with em-macros.
2023-08-16 15:53:22 -0400 < gwatt> ecraven: I suspect you can do what you want with only syntax-rules, but it will likely be hairy
2023-08-16 15:56:58 -0400 < gwatt> https://dpaste.com/EZ57MZL4Q 
2023-08-16 16:06:56 -0400 < ecraven> gwatt: thanks!
2023-08-16 16:29:36 -0400 < ecraven> mnieper`: http://ix.io/4DH6 is line 3 an error? the #f case, how can that expand to 'predicate-name?
2023-08-16 16:32:39 -0400 < mnieper`> Sorry, I have to check it tomorrow. Turning off the computer now.
2023-08-16 16:32:49 -0400 < ecraven> no problem, good night ;)
2023-08-16 18:04:00 -0400 < cow_2001> Should I learn how to use CLOS or whatever is popular in Scheme?
2023-08-16 18:04:33 -0400 < Zipheir> If you're interested in OOP.
2023-08-16 18:04:38 -0400 < cow_2001> Passing around the environment was a bit of a chore.
2023-08-16 18:04:54 -0400 < cow_2001> Not a huge chore.
2023-08-16 18:05:18 -0400 < Zipheir> State is usually a chore.
2023-08-16 18:05:33 -0400 < cow_2001> (loop (do-something env))
2023-08-16 18:05:50 -0400 < Zipheir> The environment monad from SRFI 165 is one option, if you don't like explicit passing.
2023-08-16 18:06:08 -0400 < cow_2001> (loop (take-env-and-return-an-env-slightly-changed env))
2023-08-16 18:06:12 -0400 < Zipheir> Boxes, also.
2023-08-16 18:06:24 -0400 < cow_2001> Hmm.
2023-08-16 18:06:35 -0400 < Zipheir> The 100% worst solution is to make the state global and mutable, of course.
2023-08-16 18:07:47 -0400 < Zipheir> Though I suppose there's no way around that, sometimes.
2023-08-16 18:07:56 -0400 < cow_2001> (take-global-state-and-change-it-slightly! global-state)
2023-08-16 18:08:11 -0400 < cow_2001> err
2023-08-16 18:08:50 -0400 < cow_2001> Wait, how do you even make library functions aware of globals without passing them around
2023-08-16 18:08:52 -0400 < cow_2001> ?
2023-08-16 18:09:01 -0400 < cow_2001> procedures………
2023-08-16 18:09:29 -0400 < cow_2001> That would be dynamic scoping.
2023-08-16 18:09:31 -0400 < Zipheir> Traditionally names of global, mutable variables have earmuffs. "Affix asterisks to the beginning and end of a globally mutable variable.  This allows the reader of the program to recognize very easily that it is badly written!" --Riastradh
2023-08-16 18:09:50 -0400 < cow_2001> Hah.
2023-08-16 18:09:54 -0400 < Zipheir> cow_2001: Parameters.
2023-08-16 18:10:09 -0400 < cow_2001> Parameters.  We've talked about those before.
2023-08-16 18:10:10 -0400 < Zipheir> By which I mean parameter objects, not plain old arguments.
2023-08-16 18:10:25 -0400 < cow_2001> dang ol' arguments
2023-08-16 18:10:49 -0400 < Zipheir> I'm dubious about parameters, but I don't think they're quite as bad as mutable globals.
2023-08-16 18:11:03 -0400 < cow_2001> They are quarantined.
2023-08-16 18:11:45 -0400 < Zipheir> Only as much as their dynamic scope is quarantined.
2023-08-16 18:14:33 -0400 < Zipheir> IME boxes can be a reasonably clean and very fast alternative to state-passing. Monadic state combinators are OK, but they sometimes require a ton of allocation.
2023-08-16 18:16:03 -0400 < Zipheir> (Make a state, extract the values, twiddle them, make a new state, extract the values, twiddle them, make a *new* state ...)
2023-08-16 18:36:02 -0400 < cow_2001> Zipheir: So what I did was a ton of allocation, if it was used anywhere in reality, that is?
2023-08-16 18:36:33 -0400 < cow_2001> No optimisations around this pattern?
2023-08-16 18:41:51 -0400 < Zipheir> cow_2001: Yeah, I think that's the problem. Scheme implementations probably don't do much optimizations for explicit state-passing. Especially if you don't have immutable records.
2023-08-16 18:42:44 -0400 < Zipheir> The environment monad is just *im*plicit state-passing, so you probably have to pay the same overhead if you use that.
2023-08-16 18:43:59 -0400 < Zipheir> But I haven't done any benchmarking of this except on CHICKEN, a few years back.
2023-08-16 18:51:41 -0400 < Zipheir> cow_2001: Also, you don't need to worry about any of this unless your program is too slow or too memory-hungry for your purposes.
2023-08-16 19:02:50 -0400 < cow_2001> Zipheir: It is an immutable record.
2023-08-16 19:04:55 -0400 < Zipheir> That's good.
2023-08-16 19:06:48 -0400 < cow_2001> "In category theory, a monad on a category C is nothing but a monoid in the monoidal category of endofunctors [C, C] over C."
2023-08-16 19:06:57 -0400 < cow_2001> Of course!
2023-08-16 19:10:04 -0400 < Zipheir> That's infamous.
2023-08-16 19:10:27 -0400 < cow_2001> (What is IME?)
2023-08-16 19:10:38 -0400 < cow_2001> Zipheir: ~_~……… I know………
2023-08-16 19:10:44 -0400 < Zipheir> In My Experience
2023-08-16 19:10:47 -0400 < cow_2001> OH!
2023-08-16 19:11:39 -0400 < cow_2001> Thank you.
2023-08-16 19:12:35 -0400 < cow_2001> Okay, I don't really understand how boxes are used in this case.
2023-08-16 19:13:08 -0400 < cow_2001> Aren't boxes cons with a car and no cdr?
2023-08-16 19:17:46 -0400 < aeth> Conceptually, boxes are just a layer of indirection, though I think there's box SRFIs, too.
2023-08-16 19:18:00 -0400 < cow_2001> Off topic: Isn't it a bit suspicious that Firefox is making us use its synchronisation service instead of having a nice data export option at the front of its menus?
2023-08-16 19:18:51 -0400 < cow_2001> An SRFI for boxes and a box for SRFIs.
2023-08-16 19:19:04 -0400 < aeth> a pair where the CDR is nil, or a 1-length vector, or a 0-dimensional CL-style array, etc., can all be boxes (and can all be a way you implement a box)
2023-08-16 19:19:22 -0400 < cow_2001> There is a multi value box SRFI that is separate to the single value one.
2023-08-16 19:19:32 -0400 < aeth> (looks like e.g. SRFI 231 does 0D arrays CL-style, just to pick one at random)
2023-08-16 19:20:21 -0400 < aeth> (0D kind of being like a discrete "point" just like 1D is a discrete "line" or 2D a discrete grid of sorts, etc... i.e. 0D having one elemnt)
2023-08-16 19:20:33 -0400 < aeth> s/elemnt/element/
2023-08-16 19:20:34 -0400 < jcowan> Yes, I twisted Marc's arm to make him support zero-dimensional aand degenerate arrays
2023-08-16 19:21:00 -0400 < jcowan> (ones whose lower bound is >= upper bound
2023-08-16 19:21:00 -0400 < jcowan> )
2023-08-16 19:22:30 -0400 < cow_2001> Okay, so I recognise jcowan in the SRFIs.  Who else here is in on the scheme?
2023-08-16 19:22:48 -0400 < jcowan> We all are!
2023-08-16 19:22:54 -0400 < cow_2001> O_o
2023-08-16 19:23:18 -0400 < jcowan> We are all Schemers.  Possibly some us were once Connivers or Planners,, but not likely.
2023-08-16 19:25:55 -0400 < aeth> 0D is nice to have for completeness, sort of like how (+) and (*) still work with 0 arguments
2023-08-16 19:26:13 -0400 < aeth> although it's almost entirely redundant with 1-length 1D
2023-08-16 19:26:32 -0400 < cow_2001> I should stop worrying and learn to love the (possible) bomb (in performance)………
2023-08-16 19:28:07 -0400 < cow_2001> flatwhatson: Are there any optimisations around passing immutable records as some sort of an environment state?
2023-08-16 19:29:34 -0400 < flatwhatson> i'm not sure what you mean exactly?  you're probably being overly concerned with performance
2023-08-16 19:30:29 -0400 < cow_2001> Really, I get hung up on something that is irrelevant to what I am really trying to do right now.  The normal name for those is "rabbit holes" but there is this computer game programmer that calls them "rat holes" because of how they can derail one
2023-08-16 19:30:31 -0400 < cow_2001> .
2023-08-16 19:30:52 -0400 < cow_2001> flatwhatson: Yes, and what I am doing right now is entirely didactic.
2023-08-16 19:31:02 -0400 < cow_2001> So performance does not matter.
2023-08-16 19:31:06 -0400 < flatwhatson> if you really don't want to cons unnecessarily, immutable structures are not for you
2023-08-16 19:34:14 -0400 < flatwhatson> if you have a good reason to keep previous states around, they're very convenient
2023-08-16 19:41:36 -0400 < Zipheir> cow_2001: A box is basically a 1-element vector.
2023-08-16 19:42:45 -0400 < Zipheir> cow_2001: You can avoid allocation by passing a boxed state around. The code is about the same as the "pure" version, but you mutate the box instead of allocating a new state record. Hopefully that makes sense.
2023-08-16 19:44:56 -0400 < cow_2001> flatwhatson: "Rat holes" is used by Jon Blow, who've made Braid, with its rewind mechanics………  What you've just said might somehow be linked to that?
2023-08-16 19:45:16 -0400 < Zipheir> Braid's a great game.
2023-08-16 19:46:26 -0400 < cow_2001> Zipheir: The record itself, if it is not immutable, will be the multi-value box, no?
2023-08-16 19:46:44 -0400 < Zipheir> I don't understand.
2023-08-16 19:47:04 -0400 < Zipheir> Oh, you mean could you use a mutable record like a box? Sure.
2023-08-16 19:47:44 -0400 < Zipheir> That's probably the most convenient way to do it, if your state is already a record.
2023-08-16 19:50:46 -0400 < cow_2001> The only difference is that SRFI-9 set-*! returns the new value of the field while the immutable set-* will return a new record.
2023-08-16 19:52:20 -0400 < Zipheir> SRFI 9 setters return an unspecified value.
2023-08-16 19:52:29 -0400 < cow_2001> If it had returned the existing record, I could have just added a bunch of bangs to those set procedures.
2023-08-16 19:52:33 -0400 < cow_2001> Oh.
2023-08-16 19:53:07 -0400 < flatwhatson> i think style-wise you should treat most set-foo! as not returning anything
2023-08-16 19:53:20 -0400 < Zipheir> Instead of something like (loop (make-state ...)) you get the (begin (set-state-foo! state) ... (loop state)) pattern.
2023-08-16 19:53:22 -0400 < cow_2001> Sorry.  Why did I pick that wrong bit of information?
2023-08-16 19:53:47 -0400 < Zipheir> Some implementations of SRFI 9 might have the setters return the new value.
2023-08-16 19:53:56 -0400 < Zipheir> (Which is fine, but not reliable.)
2023-08-16 19:54:48 -0400 < Zipheir> You can, of course, write a mutative state-update procedure which *does* return something.
2023-08-16 19:54:56 -0400 < flatwhatson> it's similar to a C thing: a = b = c = value;
2023-08-16 19:55:32 -0400 < flatwhatson> but obscuring mutation is a recipe for bugs & misunderstandings
2023-08-16 19:57:17 -0400 < cow_2001> Must be the Guile documentation?
2023-08-16 19:58:38 -0400 < cow_2001> flatwhatson: How does it obscure mutation?
2023-08-16 19:58:52 -0400 < jcowan> A use case for 0D is inner product on two 1D vectors.
2023-08-16 20:00:04 -0400 < jcowan> it preserves the invariant that the number of dimensions of an inner product is the sume of the num-of-dims of the two arrays minus 2.
2023-08-16 20:00:30 -0400 < jcowan> the sum, even
2023-08-16 20:01:10 -0400 < jcowan> aeth: ^^
2023-08-16 20:11:20 -0400 < Zipheir> cow_2001: As for SRFI authors in the channel, I think mnieper may have the record for number of SRFIs. Unless that award goes to jcowan.
2023-08-16 20:27:44 -0400 < jcowan> Zipheir: I have 55 SRFIs (many of them collaborative) and he has 34 (mostly alone)
2023-08-16 20:28:52 -0400 < Zipheir> Wow.
--- Day changed Thu Aug 17 2023
2023-08-17 00:51:12 -0400 < dpk> i’m wondering how long we should wait for steering committee action before giving up on them
2023-08-17 00:55:00 -0400 < mdhughes> Also Chez has boxes in (chezscheme); it really should be in R8RS-or-whatever.
2023-08-17 00:59:49 -0400 < mdhughes> Rathole was a common phrase back in the '90s when I started working in tech, ngram shows the dashed forms are similar frequency, undashed is all rathole all the time. https://books.google.com/ngrams/graph?content=rathole%2Crat-hole%2Crabbithole%2Crabbit-hole&year_start=1800&year_end=2000&corpus=en-2019&smoothing=3
2023-08-17 00:59:50 -0400 < rudybot> https://teensy.info/mOl3NWaoS0
2023-08-17 01:01:27 -0400 < Zipheir> dpk: Is there a list of their email addresses somewhere?
2023-08-17 01:02:43 -0400 < Zipheir> It's possible that none of them are checking the WG[12] mailing lists these days.
2023-08-17 01:03:26 -0400 < dpk> no public list, but their mail addresses are all public on their respective (personal/project/university) websites, i think
2023-08-17 01:04:09 -0400 < dpk> Zipheir: jcowan emailed them all directly separately from the mailing list posts (he cc’d the subcommittee chairs including me, which is how i know this)
2023-08-17 01:05:22 -0400 < dpk> however, mnieper said he was in contact with Jim Rees last year, who said the SC has become unresponsive to email in general. which isn’t exactly confidence-inspiring
2023-08-17 01:05:22 -0400 < jcowan> Indeed, sending the mail to the mailing lists was an afterthought on my part; I was going to wait for some acknowledgement from the Committee, but then I realized I might well wait forever.
2023-08-17 01:05:36 -0400 < Zipheir> OK, good. At least they should now be aware of the situation.
2023-08-17 01:08:22 -0400 < jcowan> Or if not, it's nobody's fault but their own.
2023-08-17 01:08:38 -0400 < Zipheir> What's a Steering Committee for if they can't steer?
2023-08-17 01:08:55 -0400 < dpk> an acknowledgement from the SC (‘thank you for your years of work, we’ll consider what to do next’) would at least rule out the possibility of de facto dissolution by non-action
2023-08-17 01:09:21 -0400 < Zipheir> Yes.
2023-08-17 01:11:45 -0400 < Zipheir> If they're scattered and unresponsive to email, though, they'll have to put themselves together again to consider anything or to take action.
2023-08-17 01:29:51 -0400 < mnieper`> Zipheir: cow_2001: There is also the "syntactic monad", which comes with zero overhead.
2023-08-17 01:31:21 -0400 < mnieper`> https://github.com/cisco/ChezScheme/blob/main/s/cmacros.ss#L1737
2023-08-17 01:32:11 -0400 < mnieper`> Basically, it adds implicit arguments to a lambda and a call as actual arguments.
2023-08-17 01:32:30 -0400 < mnieper`> Great for state machines, loops, interpreters, ...
2023-08-17 01:33:00 -0400 < Zipheir> I remember trying to find some documentation on define-syntactic-monad... RTFS, I guess.
2023-08-17 01:33:50 -0400 < Zipheir> mnieper`: Thanks.
2023-08-17 01:34:30 -0400 < flatwhatson> any good examples of use of this?
2023-08-17 01:38:22 -0400 < mnieper`> https://github.com/cisco/ChezScheme/blob/821879d0f0e9d50d2576d521e793dbe51462914f/s/format.ss#L107
2023-08-17 01:38:43 -0400 < mnieper`> BTW, this is also an example for locally defined (nongenerative) record types.
2023-08-17 01:38:47 -0400 < mnieper`> ecraven: ^^
2023-08-17 01:55:57 -0400 < mdhughes> I love *giant blob of macro*, no comments. Good luck, here's a shovel.
2023-08-17 01:56:21 -0400 < flatwhatson> so you get the efficiency of using bindings to pass state, without needing to spell them all out on each call
2023-08-17 01:56:43 -0400 < mnieper`> Right.
2023-08-17 01:57:30 -0400 < mnieper`> And you can easily add more state without changing your procedure calls everywhere.
2023-08-17 01:59:40 -0400 < sham1> Parameters?
2023-08-17 01:59:45 -0400 < flatwhatson> at the cost of some lexical clarity
2023-08-17 02:01:42 -0400 < mnieper`> sham1: Parameters have runtime overhead.
2023-08-17 02:02:22 -0400 < mnieper`> flatwhatson: Procedures and calls are all marked with your particular syntactic monad.
2023-08-17 02:02:31 -0400 < mnieper`> So you see where stuff is going on.
2023-08-17 02:02:38 -0400 < mnieper`> (which is not the case with parameters).
2023-08-17 02:02:48 -0400 < mnieper`> They are truly implicit.
2023-08-17 02:05:06 -0400 < flatwhatson> parameters are pretty easy to parse, they're just "getter"/"setter"
2023-08-17 02:06:16 -0400 < flatwhatson> i think you showed an effects system which had the same interface as parameters?
2023-08-17 02:09:47 -0400 < flatwhatson> this is a neat technique though
2023-08-17 02:11:10 -0400 < ecraven> mnieper`: is there a version for srfi 148 that works on chez?
2023-08-17 02:13:32 -0400 < mnieper`> ecraven: The problem is possible not SRFI 148 but SRFI 147, which redefines define-syntax and friends. Another difference is that R6RS's let(rec)-syntax is splicing.
2023-08-17 02:14:17 -0400 < mnieper`> (better choice, unfortunately not in R7RS-small)
2023-08-17 02:15:27 -0400 < mnieper`> s/possible/possibly
2023-08-17 02:16:36 -0400 < mnieper`> flatwhatson: In my effects system (where I coined the "parameters" "liquids"), you can not only dynamically rebind them but also `set!' them.
2023-08-17 02:17:37 -0400 < mnieper`> Their `set!' is pure in the sense that jumping around with continuations will undo settings.
2023-08-17 02:18:09 -0400 < mnieper`> Liquids model basically an environment monad but without any syntactic overhead.
2023-08-17 02:18:34 -0400 < mnieper`> You can just use the normal Scheme syntax and the normal Scheme procedures.
2023-08-17 02:20:00 -0400 < dpk> mnieper`: is this FAQ answer okay with you? https://codeberg.org/scheme/r7rs/wiki/FAQ
2023-08-17 02:20:05 -0400 < ecraven> I've tried changing srfi-148 and dependencies to work on chez, but hit ; Evaluation aborted on Exception: invalid syntax (syntax-rules :::1 () ((m %kt %kf) (begin (...) (...)))) near line 29, char 4 of chez/srfi/:148/148.identifier.scm.
2023-08-17 02:20:15 -0400 < dpk> (i ask purely because it could be interpreted as disparaging your SRFI, which is not the intent)
2023-08-17 02:20:41 -0400 < dpk> oh, i forgot to mention that SRFI 148 can still be used in the small language thanks to its sample implementation
2023-08-17 02:20:49 -0400 < ecraven> mnieper`: that's like chez's parameters, right?
2023-08-17 02:21:01 -0400 < mnieper`> Liquids? No.
2023-08-17 02:21:20 -0400 < mnieper`> R6RS syntax-rules don't have custom ellipses.
2023-08-17 02:21:29 -0400 < mnieper`> The :::1 above.
2023-08-17 02:22:25 -0400 < mnieper`> Not really needed there because any macro that may need them is so complex that you want to write it with syntax-case anyway.
2023-08-17 02:23:22 -0400 < dpk> okay, added a paragraph mentioning that
2023-08-17 02:24:56 -0400 < ecraven> ok, so I can't use srfi-148 to write a macro on chez that should work on r7rs schemes :D
2023-08-17 02:25:18 -0400 < mnieper`> ecraven: Well, you can write a SRFI 148 impl on R6RS.
2023-08-17 02:25:36 -0400 < ecraven> mnieper`: yes, or maybe I should just not write this on chez, but use some actual r7rs scheme
2023-08-17 02:25:55 -0400 < mnieper`> If you want to write R7RS scheme, don't use Chez.
2023-08-17 02:26:33 -0400 < ecraven> well, for a *lot* of code my simple shims are good enough.. and other people have probably written better ones
2023-08-17 02:27:54 -0400 < mnieper`> dpk: I am not so sure about exclusion of SRFI 148 in the Batteries anymore (but don't have a strong opinion).  The reason why it may make sense there is that it can be implemented much more efficiently with syntax-case. It is then helpful for programs intended to be compatible with R7RS-small that are also to be going run on a R7RS-large platform.
2023-08-17 02:28:39 -0400 < mnieper`> SRFI 147 may need some overhaul, though, because it changes the semantics of core forms, which may be incompatible with R7RS-large. 
2023-08-17 02:28:53 -0400 < mnieper`> The changes are not incompatible with R7RS-small, though.
2023-08-17 02:29:33 -0400 < mnieper`> So, my suggestion for the FAQ: s/No./Probably not.
2023-08-17 03:46:18 -0400 < dpk> mnieper`: https://codeberg.org/scheme/r7rs/wiki/commit/c745178b9c6eb688f55b1ab45ded33b734ad67d6
2023-08-17 03:46:40 -0400 < dpk> (Codeberg doesn’t like Unicode punctuation in wikis, it seems)
2023-08-17 03:53:05 -0400 < mnieper`> Because of the punctuation being spaces?
2023-08-17 03:53:40 -0400 < dpk> i have one non-breaking space which it has highlighted in red, and it has also put yellow boxes with warning signs around all my ‘s and ’s
2023-08-17 03:56:50 -0400 < mnieper`> Long lives "`ASCII"' and \LaTeX! 
2023-08-17 04:06:12 -0400 < lockywolf> 148 sounds like fun
2023-08-17 04:06:18 -0400 < lockywolf> why not include it into Batteries?
2023-08-17 05:53:56 -0400 -!- rgherdt_ is now known as rgherdt
2023-08-17 06:37:18 -0400 -!- stultulo is now known as f8l
2023-08-17 08:28:58 -0400 < mnieper`> How does ML conceptionally solve ad-hoc polymorphism for arithmetical operators within its HM type system?
2023-08-17 08:29:28 -0400 < mnieper`> (slightly off-topic, but I know that many smart people are lurking here)
2023-08-17 08:31:00 -0400 < dpk> that might be a question for the new https://langdev.stackexchange.com/
2023-08-17 08:47:47 -0400 < flatwhatson> mnieper`: it's static overloading: https://homepages.inf.ed.ac.uk/stg/NOTES/node44.html
2023-08-17 08:58:08 -0400 < mnieper`> Ah, thanks. 
2023-08-17 08:58:42 -0400 < mnieper`> So it looks to me that it would have been more in the spirit of ML if the real versions of the arithmetic operators were denoted by, say .+ .- or .<.
2023-08-17 09:06:27 -0400 < flatwhatson> in prescheme it's + (int), fl+ (float), un+ (unsigned int)
2023-08-17 09:13:16 -0400 < mnieper`> Prescheme has HM type inference?
2023-08-17 09:22:28 -0400 < flatwhatson> yep!
2023-08-17 09:26:51 -0400 < flatwhatson> https://gitlab.com/flatwhatson/scheme48/-/blob/main/ps-compiler/prescheme/infer-early.scm
2023-08-17 09:32:34 -0400 < jcowan> Not adopting splicing let-syntax was a WG1 error.  I argued against it because I misunderstood it, and that convinced WG1 to go along with me
2023-08-17 09:43:12 -0400 < mnieper`> flatwhatson: Thanks a lot!!
2023-08-17 10:00:13 -0400 < flatwhatson> mnieper`: are you exploring the idea of HM for scheme?
2023-08-17 10:09:22 -0400 < mnieper`> We did this long(TM) time ago.
2023-08-17 10:10:00 -0400 < mnieper`> In the context of Steme (https://github.com/pre-srfi/static-scheme).
2023-08-17 10:11:09 -0400 < mnieper`> Sometimes, I do think about things like type inference and the thought about type inference for +, *, ... in ML just surfaced today.
2023-08-17 10:12:20 -0400 < mnieper`> In the context of Scheme it shows that because Scheme is mostly monomorphic (we have all this vector-bla, string-bla, frob-bla), type inference could be made to work.
2023-08-17 10:12:34 -0400 < mnieper`> But it would restrict the number of possible Scheme programs.
2023-08-17 10:13:21 -0400 < mnieper`> Most likely, something like (lambda (x) (if (> x 0) "positive" -1)) would no longer be possible.
2023-08-17 10:14:04 -0400 < mnieper`> But I would already now call such a procedure ill-typed where "ill" is my subjective aesthetics.
2023-08-17 10:24:51 -0400 < mdhughes> But if you block that by typing, you also block all collections that aren't uni-typed.
2023-08-17 10:25:02 -0400 < sham1> Well the type is clearly number? -> (or string? number?)
2023-08-17 10:26:05 -0400 < sham1> It's a sum type
2023-08-17 10:26:22 -0400 < mdhughes> It's been, what, 8 years now?, and Swift can just about read a JSON object, if you're willing to write a lot of boilerplate around it. In a dynamic lang, it's trivial.
2023-08-17 10:28:16 -0400 < mnieper`> mdhughes: Such a "Steme" would not mean that you can expect every classical Scheme program to work.
2023-08-17 10:29:24 -0400 < mdhughes> Or: any of them.
2023-08-17 10:29:35 -0400 < mnieper`> sham1: An algebraic sum type is different from an ad-hoc sum of two existing types.
2023-08-17 10:29:39 -0400 < mdhughes> It'd be a new, less useful language.
2023-08-17 10:30:07 -0400 < mnieper`> Less useful for some cases, more useful for others.
2023-08-17 10:30:38 -0400 < sham1> Where does the difference come in? After all it just seems to me that ad-hoc or not, that's clearly a type you can infer
2023-08-17 10:31:25 -0400 < mnieper`> sham1: Any static type system defines a set of expressible types.
2023-08-17 10:31:58 -0400 < sham1> You can easily have that in a statically typed language. Whether or not it's useful is another question entirely
2023-08-17 10:32:05 -0400 < mnieper`> For a type system that is supposed to infer all types, not every set of types is possible.
2023-08-17 10:32:20 -0400 < mnieper`> For example, we have HM that doesn't cover such types.
2023-08-17 10:32:29 -0400 < sham1> Most of the time you want for both arms of an if-expression to be the same type of course
2023-08-17 10:33:20 -0400 < mdhughes> Plenty of times you don't, even aside from collections. (index) returns an integer or #f.
2023-08-17 10:33:41 -0400 < mnieper`> mdhughes: The obvious solution here is SRFI 189.
2023-08-17 10:33:54 -0400 < mdhughes> What's the result of a cdr? '(), atom, or list.
2023-08-17 10:34:08 -0400 < mdhughes> I'm not gonna ask Maybe please may I have my value.
2023-08-17 10:34:20 -0400 < mdhughes> INTERCAL is -> that way
2023-08-17 10:34:43 -0400 < sham1> Programmer is insufficiency polite
2023-08-17 10:34:52 -0400 < mnieper`> mdhughes: Lists are proper and homogeneous.
2023-08-17 10:34:56 -0400 < mdhughes> Best error message since "Printer is on fire"
2023-08-17 10:35:23 -0400 < mdhughes> How are lists homogenous? They contain *any* type, in sequence, only terminated by nil
2023-08-17 10:35:43 -0400 < mnieper`> "Steme" lists, not Scheme lists.
2023-08-17 10:35:45 -0400 < sham1> Obviously in this Steme subset of Scheme they'd be
2023-08-17 10:35:49 -0400 < mdhughes> You don't have (list<integer>)
2023-08-17 10:36:24 -0400 < mdhughes> Really, ML already does exist.
2023-08-17 10:36:25 -0400 < mnieper`> I was once convinced like mdhughes that having non-homogeneous collections is an important asset of dynamically typed or weakly typed languages.
2023-08-17 10:36:41 -0400 < sham1> Scheme is by no means weakly typed
2023-08-17 10:36:52 -0400 < mnieper`> sham1: OR. I wrote OR.
2023-08-17 10:36:53 -0400 < mdhughes> Ocaml is even somewhat useful, despite being BDSM
2023-08-17 10:36:54 -0400 < mnieper`> :)
2023-08-17 10:37:06 -0400 < sham1> fair enough
2023-08-17 10:37:10 -0400 < sham1> mnieper`: ada
2023-08-17 10:37:27 -0400 < mnieper`> Ada means what in this context?
2023-08-17 10:37:39 -0400 < mnieper`> (Don't know Ada.)
2023-08-17 10:37:51 -0400 < mdhughes> I interact with a lot of the real world, so yes, loose collections of stuff are important.
2023-08-17 10:38:29 -0400 < mdhughes> Ada's another useful BDSM language. Well, supposedly, I can't get a compiler to work on my system, and don't feel like trying it on the remote system I could run it on.
2023-08-17 10:38:47 -0400 < mnieper`> It is all about the universe of discourse.
2023-08-17 10:38:57 -0400 < mnieper`> About the difference between Tarski and Russell universes.
2023-08-17 10:39:06 -0400 < mnieper`> Scheme gives you a Russell universe.
2023-08-17 10:39:30 -0400 < mnieper`> With Steme/ML/Haskell/C++/... you can model a Tarski one.
2023-08-17 10:39:32 -0400 < mdhughes> (and I do apologize to people who like BDSM, it's an unfair comparison. But it's the closest analogy.)
2023-08-17 10:41:03 -0400 < mdhughes> Computers aren't math theory. They're barely-consistent masses of wiring that let you represent 0 and 1 as electrical charges.
2023-08-17 10:41:29 -0400 < mnieper`> Flowers aren't animals.
2023-08-17 10:41:36 -0400 < mdhughes> If you bang on them hard enough, you can just about get music, or text, or dirty pictures to print out.
2023-08-17 10:42:16 -0400 < mdhughes> And a language is a slightly less annoying way to wire them up.
2023-08-17 10:43:38 -0400 < mnieper`> I don't see a problem with JSON and a language with an ML or Haskell-like type system.
2023-08-17 10:44:48 -0400 < mdhughes> ["foo", 1, {"hey":1970-01-01}] is what type?
2023-08-17 10:44:50 -0400 < jcowan> The fallacy in that argument is the assumption that incomplete specifications are just useless.
2023-08-17 10:45:57 -0400 < dpk> mdhughes: it’s a Value from Data.Aeson.Types
2023-08-17 10:46:27 -0400 < mnieper`> mdhughes: JSON is defined inductively.
2023-08-17 10:46:38 -0400 < mnieper`> You can write down an algebraic data type for it.
2023-08-17 10:46:52 -0400 < mdhughes> You can't, because the next call might produce a radically different structure.
2023-08-17 10:47:07 -0400 < mnieper`> But structured the same.
2023-08-17 10:47:31 -0400 < mnieper`> You can suddenly have {"foo":"bar":"xx"} in your input.
2023-08-17 10:47:42 -0400 < mdhughes> No, because that's invalid text.
2023-08-17 10:47:57 -0400 < mnieper`> If you can parse JSON, you can turn JSON into an AST.
2023-08-17 10:47:58 -0400 < mdhughes> (actually, my example uses a cheaty extension for dates. But whatever.)
2023-08-17 10:48:17 -0400 < mnieper`> And this AST can be given a type.
2023-08-17 10:48:41 -0400 < mnieper`> Whenever JSON is extended, the parser has to be extended as has the type.
2023-08-17 10:48:45 -0400 < mdhughes> Which you'd have to run every single time you pull a value from some service. Meanwhile a dynamic lang says "Yeah, it's a bundle of stuff. That's what we do!"
2023-08-17 10:49:09 -0400 < mnieper`> How that? You write the parser once.
2023-08-17 10:49:50 -0400 < mdhughes> Next call returns {"error":404, "message":"service moved", data:[]}, what do you do?
2023-08-17 10:49:51 -0400 < mnieper`> jcowan: Can you give a good example for this fallacy/underspecification where it surfaces?
2023-08-17 10:50:23 -0400 < mnieper`> mdhughes: It is still a value of the same ADT.
2023-08-17 10:50:34 -0400 < jcowan> What is the appropriate static type for a JSON object if all you want to do is count how many you have received?
2023-08-17 10:51:22 -0400 < mnieper`> You mean something like (in ML notation)   json list -> int  ?
2023-08-17 10:54:17 -0400 < mnieper`> mdhughes: You don't have to rewrite a C compiler when it is given a new source file.
2023-08-17 10:55:14 -0400 < mdhughes> Yeah, but C's not BDSM. What is the type declaration of a JSON tree? It's not decidable in ML or Swift, without some really hairy <T> shit.
2023-08-17 10:55:56 -0400 < mnieper`> What is BDSM (in this context!)?
2023-08-17 10:56:01 -0400 < mdhughes> At least in Java, generics are just compile-time bullshit and you can do everything in loose objects if you want.
2023-08-17 10:56:21 -0400 < flatwhatson> something like JsonValue : JsonString|JsonNumber|JsonArray|JsonObject
2023-08-17 10:57:11 -0400 < dpk> i’m more interested by what mdhughes thinks ‘decidable’ means
2023-08-17 10:57:12 -0400 < mdhughes> Bondage Domination Sado-Masochism. https://www.catb.org/~esr/jargon/html/B/bondage-and-discipline-language.html
2023-08-17 10:57:14 -0400 < mnieper`> mdhughes: Yes, translate C's union and structs directly.
2023-08-17 10:57:45 -0400 < mdhughes> dpk: "Not Decidable" is one of Swift's many amusing errors at complex types.
2023-08-17 10:58:25 -0400 < dpk> doubly amusing, given that Swift’s type system was, iirc, actually found to be undecidable
2023-08-17 10:58:39 -0400 < dpk> in the actual sense of ‘undecidable’, not whatever you’re making up
2023-08-17 10:58:39 -0400 < mdhughes> So you do know what the word "decidable" means.
2023-08-17 10:59:19 -0400 < mnieper`> That's why we need (and luckily have) this strange "math theory" mdhughes mentioned.
2023-08-17 10:59:46 -0400 < mdhughes> All words are made up, those by theory wanks doubly so.
2023-08-17 11:00:27 -0400 < mdhughes> Dog's gotta go take a shit, which is more productive. Please go play with ML instead.
2023-08-17 11:00:35 -0400  * mdhughes goes outside
2023-08-17 11:01:34 -0400 < jobol> positive? + positive? -> positive?
2023-08-17 11:03:15 -0400 < mnieper`> jcowan: Did you see my query? (No hurry if you saw it.)
2023-08-17 11:10:07 -0400 < dpk> also, as a side note, for amusing errors in Apple compilers, the MPW C compiler will never be beaten (This struct already has a perfectly good definition)
2023-08-17 11:10:15 -0400 < dpk> especially since Apple no longer believes in fun
2023-08-17 11:10:16 -0400 < mnieper`> jobol: What's the intention?
2023-08-17 11:13:28 -0400 < jobol> mnieper`, being positive of course. But also, a type system could also track the used subset for type... 
2023-08-17 11:13:49 -0400 < mnieper``> If you use Agda, you can express all this.
2023-08-17 11:14:16 -0400 < mnieper``> But Agda won't be able to do automatic type inference.
2023-08-17 11:14:52 -0400 < mnieper``> dpk: MPW?
2023-08-17 11:15:40 -0400 < dpk> Macintosh Programmer’s Workshop, which was the IDE type thing they used to make Mac apps back in the dark ages
2023-08-17 11:36:26 -0400 < aeth> the problem with fun error messages in compilers is that compiler errors aren't fun when you're trying to compile
2023-08-17 11:36:30 -0400 < aeth> so it seems like the computer is mocking you
2023-08-17 11:37:40 -0400 < dpk> yes, i would much rather if a compiler tries to be friendly it does so like Elm, and tries to suggest things that might be wrong/how to correctly do what it thinks i might be trying to do
2023-08-17 11:38:21 -0400 < aeth> that seems to be the new trend
2023-08-17 11:38:26 -0400 < aeth> only downside is the verbosity
2023-08-17 11:39:31 -0400 < dpk> that said, TeX does explain what the problem is in its funnier error messages (at least the ones that are intentionally funny)
2023-08-17 11:39:43 -0400 < dpk> unintentionally funny: ‘I can only handle fonts at positive sizes that are less than 2048pt, so I've changed what you said to 10pt.’
2023-08-17 11:39:51 -0400 < dpk> you wanted: massive. i’ll give you: tiny
2023-08-17 11:40:15 -0400 < dpk> intentionally funny: ‘I dddon’t go any higher than filll.’
2023-08-17 11:42:28 -0400 < dpk> it will also refer you to the TeXbook to suggest solutions in a sort of proto-Elm-style, in some cases. of course, this is of limited usefulness these days because nearly nobody now who uses TeX has read the TeXbook
2023-08-17 11:42:49 -0400 < aeth> yes, but I don't think corporate things can be well received when they try to be fun anymore... probably why April Fools has kind of faded away
2023-08-17 11:43:24 -0400 < aeth> your Scheme (if you write one) is in the same box as TeX, anything by a trillion dollar company wouldn't be
2023-08-17 12:28:32 -0400 < X-Scale> Knuth also has some funny quotes on his TeX pascal source code as in page 16: "last <- first;  { cf. Matthew 19.30 }"
2023-08-17 12:28:37 -0400 < X-Scale> https://tug.org/texlive/Contents/live/texmf-dist/doc/generic/knuth-pdf/tex/tex.pdf
2023-08-17 12:44:34 -0400 < dpk> was Knuth the first person to use the convention that the keyword to close a block is the keyword that opened it, spelled backwards?
2023-08-17 12:45:01 -0400 < dpk> it feels like quite a Knuthian thing, even though i hadn’t seen it in his code before today
2023-08-17 12:55:37 -0400 < jcowan> Oh no, that comes from Algol 68
2023-08-17 12:55:45 -0400 < jcowan> if .. fi, do ... od, etc.
2023-08-17 12:56:06 -0400 < jcowan> Bliss took it even further: module ... eludom
2023-08-17 12:56:31 -0400 < jcowan> though comment ... tnemmoc is stretching it.
2023-08-17 12:57:05 -0400 < jcowan> Bash has it because A68 did
2023-08-17 13:20:35 -0400 < acdw> knuth, the text mf
2023-08-17 13:21:15 -0400 < acdw> I wanna know why anyone thought that was a good idea tbh
2023-08-17 13:24:01 -0400 < sham1> It's unambiguous 
2023-08-17 13:28:52 -0400 < cow_2001> There is a bit where he generates Java code by using a small language defining the AST syntax.
2023-08-17 13:29:09 -0400 < cow_2001> Must be a way to do the same with macros, right?
2023-08-17 13:30:10 -0400 < cow_2001> But how do you take a symbol or symbols, do some string manipulations, and then return the form?
2023-08-17 13:31:43 -0400 < sham1> You turn the symbols into strings, do the string manipulation and then turn the strings into symbols
2023-08-17 13:32:10 -0400 < cow_2001> :|  Inside a macro definition?
2023-08-17 13:32:12 -0400 < cow_2001> :|
2023-08-17 13:32:36 -0400 < sham1> Why not
2023-08-17 13:32:40 -0400 < mnieper`> jcowan: json-length : json list -> int ?
2023-08-17 13:32:44 -0400 < cow_2001> O_o
2023-08-17 13:32:53 -0400 < cow_2001> Huh!
2023-08-17 13:33:03 -0400 < cow_2001> OKAY!
2023-08-17 13:33:30 -0400 < cow_2001> So the definition will return a form that would do various string manipulations at run time!
2023-08-17 13:33:51 -0400 < Zipheir> It's unambiguous, but then so is 'end if', 'end do', etc.
2023-08-17 13:33:56 -0400 < Zipheir> s/is/are/
2023-08-17 13:34:02 -0400 < cow_2001> This is exciting!
2023-08-17 13:34:25 -0400 < sham1> Zipheir: yes, but I haven't really seen many languages doing the "end if" style
2023-08-17 13:34:35 -0400 < Zipheir> Is Ada the only one?
2023-08-17 13:34:45 -0400 < sham1> IIRC Scala 3 does that
2023-08-17 13:35:08 -0400 < sham1> It also uses an off-side rule IIRC
2023-08-17 13:35:14 -0400 < Zipheir> Ah.
2023-08-17 13:35:17 -0400 < cow_2001> Does POSIX Shell's fi count?
2023-08-17 13:35:49 -0400 < Zipheir> if ... fi is the kind of thing they were talking about.
2023-08-17 13:36:24 -0400 < cow_2001> Oh, oops.  That's why I get for butting in in the middle of a conversation.
2023-08-17 13:38:14 -0400 < Zipheir> Granted that in Ada 'end' is the counterpart to 'begin' and defines a block. The end "tag" just disambiguates the block being terminated.
2023-08-17 13:38:29 -0400 < cow_2001> I would say that ) terminating an (if looks like an ) terminating a (define or an (and or a (match…
2023-08-17 13:39:18 -0400 < sham1> That's one of the advantages of Lisps, but it also means that you need to indent stuff properly
2023-08-17 13:39:19 -0400 < Zipheir> Well, that's the trade-off with brackets or braces.
2023-08-17 13:39:19 -0400 < cow_2001> ))))) can lead to some confusion…
2023-08-17 13:39:31 -0400 < sham1> Since you're not supposed to spill the Pringles 
2023-08-17 13:39:49 -0400 < Zipheir> If you want minimum ambiguity, you could write Lisp like XSLT...
2023-08-17 13:40:00 -0400 < cow_2001> Then again, smart editors………
2023-08-17 13:40:06 -0400 < cow_2001> Blah.
2023-08-17 14:03:30 -0400 < acdw> Zipheir: I agree with the end if stuff ... or if it needs to be one token for some reason, endif. I think fi, od, etc are more confusing than anything else
2023-08-17 14:06:57 -0400 < Zipheir> Yes. 'od' is "octal dump" or one of those reviled two-letter Scrabble words, not programming language syntax. :)
2023-08-17 14:09:02 -0400 < mnieper`> wenn ... nnew
2023-08-17 14:13:04 -0400 < gwatt> lambda ... abdmal
2023-08-17 14:13:42 -0400 < Zipheir> letrec ... certel is almost pronounceable.
2023-08-17 14:13:43 -0400 < sham1> hotel ... trivago
2023-08-17 14:15:11 -0400 < Zipheir> trivago?
2023-08-17 14:15:32 -0400 < sham1> It's a corny joke about a travel agency
2023-08-17 14:15:39 -0400 < sham1> Whose ads are like that
2023-08-17 14:18:05 -0400 < mnieper`> What about abbreviating ))))) by )^5 ?
2023-08-17 14:18:47 -0400 < gwatt> why not bring back the super paren? "]" terminates all open ")", back to the last open "["
2023-08-17 14:18:59 -0400 < gwatt> erm, all open "("
2023-08-17 14:20:08 -0400 < Zipheir> I would be worried if I knew that macros could emit super parens.
2023-08-17 14:20:14 -0400 < dpk> i considered implementing a REPL with line-editing where typing ] outside of a string literal or similar would insert as many )s as needed to close all expressions
2023-08-17 14:21:02 -0400 < Zipheir> It does strike me as more of a REPL feature.
2023-08-17 14:22:32 -0400 < gwatt> Yeah, it would be a feature of (read).
2023-08-17 14:23:08 -0400 < dpk> the advantage of implementing it in line editing is that it can look ahead
2023-08-17 14:24:10 -0400 < dpk> if i have (let ((x 42*) where * is my cursor position, it can know i only want to insert two, because there’s one ahead of it
2023-08-17 14:24:33 -0400 < mnieper``> I would prefer a paredit-like REPL.
2023-08-17 14:24:47 -0400 < mnieper``> So that everything is well-structured by default.
2023-08-17 14:25:02 -0400 < dpk> is paredit compatible with comint-mode?
2023-08-17 14:25:58 -0400 < dpk> (i dislike things that automatically insert closing things, as anyone who’s ever looked at my HTML code can probably guess, so i’ve never used paredit)
2023-08-17 14:26:32 -0400 < mnieper``> For Scheme it works perfectly.
2023-08-17 14:26:50 -0400 < mnieper``> Because it also deletes the stuff in pairs.
2023-08-17 14:36:22 -0400 < jcowan> That's not always the wrong wthing.  "The shortest way from a WF document to another WF document is often through an ill-formed document."
2023-08-17 14:37:56 -0400 < jcowan> gwatt: It's actually reciprocal: ] closes )s back to the last [ or the beginning if there is none, and ) closes ]s back to the last ( or the beginning if there is none.
2023-08-17 14:39:32 -0400 < sham1> I'd like the super-parenthesis if it was just a keychord that just added the necessary amount of closing parentheses, but I've also head of the ones that are (like (this (this ...]
2023-08-17 14:44:14 -0400 < dpk> jcowan: we could have this and not break R6RS compatibility!
2023-08-17 14:44:17 -0400 < dpk> (not a serious proposal)
2023-08-17 14:48:31 -0400 < michal_atlas> I think parinfer works like that, where you only write the ( and necessary )s and at the end of the line it closes all of them plicitly
2023-08-17 15:17:50 -0400 < michal_atlas> Hello, out of curiosity, is there a canonical way to do a compile-time calculation in Scheme? I know one can use a macro, but unlike CL most implementations seem to limit that to only readable values.
2023-08-17 15:19:28 -0400 < Zipheir> michal_atlas: What macro system are you using? You'll need a procedural macro.
2023-08-17 15:19:29 -0400 < gwatt> michal_atlas: Which scheme are you using?
2023-08-17 15:19:43 -0400 < mnieper``> What kind of value?
2023-08-17 15:20:04 -0400 < mnieper``> You can calculate any value during compile-time; the question is what you want to do with it.
2023-08-17 15:22:36 -0400 < dpk> ask two rabbis, get three answers. ask one #scheme, get three answers
2023-08-17 15:23:42 -0400 < mnieper``> 126
2023-08-17 15:54:18 -0400 < ecraven> sham1: I like the ones where ] closes everything up to the preceding ] :D interlisp had that
2023-08-17 15:55:38 -0400 < sham1> I personally don't like it. It breaks things like paredit and the like
2023-08-17 15:56:10 -0400 < ecraven> sham1: only because they don't know about it.. they could ;)
2023-08-17 15:56:22 -0400 < ecraven> personally, I use only (), I even dislike r6rs []
2023-08-17 15:56:27 -0400 < ecraven> it's unSchemely :P
2023-08-17 15:56:29 -0400 < leah2> you dont need paredit then :^>
2023-08-17 15:56:30 -0400 < sham1> It also looks unbalanced
2023-08-17 16:00:44 -0400 < DeeEff> I've come to avoid [] because the community has more or less come to avoid []
2023-08-17 16:01:05 -0400 < DeeEff> but I don't hate it
2023-08-17 16:01:54 -0400 < sham1> I like [] as an alternative for ()
2023-08-17 16:03:08 -0400 < gwatt> I like it too. It's a nice visual distinction for when you're required to have immediately next to each other
2023-08-17 16:03:35 -0400 < sham1> (let ([foo (bar)] [baz (quux)]) ...)
2023-08-17 16:03:41 -0400 < DeeEff> my kingdom for a schemefmt akin to clang-format or rustfmt
2023-08-17 16:03:59 -0400 < sham1> Problem with a schemefmt would be that Scheme syntax is quite dynamic
2023-08-17 16:04:15 -0400 < gwatt> 1) open chez repl. 2) enter expression. 3) ^[q
2023-08-17 16:04:54 -0400 < dpk> sham1: Rust also has macros, even procedural ones … if they can do it
2023-08-17 16:05:05 -0400 < dpk> the problem would be more getting Schemers to agree on one style :P
2023-08-17 16:06:22 -0400 < Zipheir> Canonical style-enforcing programs are stupid. They're an invitation to their authors to come up with all sorts of cargo-cult rules.
2023-08-17 16:06:23 -0400 < DeeEff> rustfmt avoids any opinions in macros
2023-08-17 16:06:49 -0400 < DeeEff> but unlike scheme where s-expressions are the norm, Rust can let you do a lot of syntax / token mangling
2023-08-17 16:07:01 -0400 < Zipheir> If your particular group wants to write a schemefmt, fine, but don't expect others to agree with it.
2023-08-17 16:07:20 -0400 < DeeEff> in Scheme I guess you also can do that but then your code stops looking like scheme
2023-08-17 16:07:42 -0400 < sham1> dpk: this is going to sound stupid but in some ways Rust is more "regular" in terms of that. With Lisps the way macros are formatted can vary wildly based on just the macro in question. Also for example, if you have a procedure call, how do you break up the lines once your call would get too long
2023-08-17 16:08:02 -0400 < sham1> It's ironic because one of the advantages of s-expressions is that you're not really supposed to have syntax at all as such
2023-08-17 16:08:02 -0400 < DeeEff> Zipheir: respectfully disagree. The brutalist nature of the style-enforcement is to prevent any question regarding the nature of "how do I write this piece" and instead focus on the effects of the code itself
2023-08-17 16:08:39 -0400 < dpk> my last job (2016, since which i have been in blessed studentdom, where people take me seriously when i spend all day considering the development of ancient languages, rather than the development of new features on ancient web apps) had a bunch of arbitrary in-house rubocop configurations, so i agree with Zipheir
2023-08-17 16:08:51 -0400 < Zipheir> DeeEff: I do appreciate that argument, given the decades of flame-wars about C style.
2023-08-17 16:09:39 -0400 < sham1> An organisation or a codebase should agree on a style just for consistency
2023-08-17 16:10:02 -0400 < Zipheir> I'm just not a fan of anything which creates a body of Style Police.
2023-08-17 16:10:14 -0400 < Zipheir> (MLA and APA should also burn, e.g.)
2023-08-17 16:10:48 -0400 < Zipheir> sham1: Sure.
2023-08-17 16:11:01 -0400 < sham1> And just like with those, I like being able to automate the styles. So for citations you'd use bibtex to just use whatever style you're required to use and the same goes for programming style
2023-08-17 16:12:56 -0400 < gwatt> Much of the value of consistency is for an unfamiliar reader, not the writer.
2023-08-17 16:14:06 -0400 < DeeEff> Yeah, there's a net benefit to code all "looking the same way" in some sense. When it's across libraries, repos, and communities it is invaluable because it means that you don't have to learn style conventions on top of what is already an investigative puruit into the code itself.
2023-08-17 16:14:11 -0400 < Zipheir> Yes. But do you want to be one of the people who decides what the Scheme style is? I don't.
2023-08-17 16:14:44 -0400 < DeeEff> Seems easy enough. clang-format, python's black, etc range dramatically from "perfect standard" to "here's 50 knobs that produce mostly consistent rulesets"
2023-08-17 16:15:18 -0400 < sham1> This is why you should be able to customise the style for the Scheme formatter
2023-08-17 16:15:19 -0400 < DeeEff> so really it's about how opinionated you want to be, and I'd say usually you want to be more opinionated because it's just aligning brackets at the end of the day
2023-08-17 16:15:22 -0400 < DeeEff> but ¯\_(ツ)_/¯
2023-08-17 16:15:23 -0400 < sham1> Just like with clang-format and so on
2023-08-17 16:15:50 -0400 < sham1> gwatt: even as a familiar reader having a consistent style helps. For example code reviews
2023-08-17 16:16:05 -0400 < Zipheir> Consistency is the key.
2023-08-17 16:17:07 -0400 < mnieper`> DeeEff: There is more than one Scheme community.
2023-08-17 16:17:29 -0400 < sham1> There are N scheme communities, where N is the amount of Scheme implementations
2023-08-17 16:17:58 -0400 < Zipheir> Yes, and thankfully there is no group with the authority to mandate code style.
2023-08-17 16:18:38 -0400 < Zipheir> sham1: At the very least.
2023-08-17 16:20:34 -0400 < DeeEff> Zipheir: I'm not convinced that any existing tools for any existing languages are "authoritative" other than in the sense that users find them useful and are annoyed when projects decide to depart and do their own thing
2023-08-17 16:20:44 -0400 < DeeEff> which by the looks of most C/C++ projects, is most of them
2023-08-17 16:21:06 -0400 < DeeEff> Python is perhaps different in that they standardized PEP-8 but even that has evolved
2023-08-17 16:21:33 -0400 < sham1> Go enforces gofmt output, but that's about the only thing I can think that does this
2023-08-17 16:21:50 -0400 < Zipheir> DeeEff: OK. I guess there aren't that many languages with an official formatter.
2023-08-17 16:22:18 -0400 < aeth> today on HN: https://news.ycombinator.com/item?id=37164243
2023-08-17 16:22:39 -0400 < sham1> Well having an official formatter doesn't mean that you necessarily have an official format. And even if you do, it doesn't necessarily mean that you can't change what the formatter outputs
2023-08-17 16:22:55 -0400 < dpk> > Disappointed. Thought I was going to see a resignation letter shaped like a large chair.
2023-08-17 16:23:07 -0400 < Zipheir> A formatter for languages with macros is harder, since the indentation of specal forms can vary considerably.
2023-08-17 16:23:30 -0400 < aeth> dpk: yes, so many chair jokes... you wouldn't have seen that on HN a few years ago... lots of people left Reddit for vaguely comparable sites and that means a lot of Reddit culture is currently leaking all over the internet
2023-08-17 16:24:11 -0400 < dpk> yes, even on lobste.rs (which i read more) i’ve noticed an increase in bad jokes
2023-08-17 16:24:29 -0400 < aeth> but these jokes were always bad so it's clearly just an attempt at karma farming
2023-08-17 16:24:35 -0400 < aeth> even if just instinctual
2023-08-17 16:24:54 -0400 < Zipheir> What I associate with Reddit is not so much bad jokes as bad-joke feedback which takes over the entire thread.
2023-08-17 16:25:46 -0400 < Zipheir> It seems like a lot of people want to know what R7RS actually is.
2023-08-17 16:25:58 -0400 < sham1> Do *we* know?
2023-08-17 16:28:48 -0400 < Zipheir> sham1: Not at the moment.
2023-08-17 16:30:53 -0400 < Zipheir> sham1: It's the small language and ...?
2023-08-17 16:36:34 -0400 < aeth> Zipheir: what I see is some lost redditors trying to overtake a thread with puns and getting confused as to why they're losing, not gaining, karma
2023-08-17 16:37:04 -0400 < Zipheir> Haha.
2023-08-17 16:37:12 -0400 < aeth> e.g. https://news.ycombinator.com/item?id=37167318
2023-08-17 16:37:25 -0400 < aeth> The comments being very short is also a symptom of modern Reddit.
2023-08-17 16:37:36 -0400 < Zipheir> YES.
2023-08-17 16:37:47 -0400 < aeth> YouTube and Reddit traded places. Nowadays, YouTube often has long comments, at least if you watch decent channels.
2023-08-17 16:38:04 -0400 < aeth> (hidden behind a "Read more", though)
2023-08-17 16:38:15 -0400 < Zipheir> Ill-considered, single-sentence-fragment comments is one of the reasons I mostly stopped paying attention to Reddit.
2023-08-17 16:39:13 -0400 < aeth> the last remaining good subreddits fell apart this June with the mod/API drama, so the ~14 year chore of constantly removing old subreddits as they either died or grew too big and became r/all culture has finally ended.
2023-08-17 16:39:42 -0400 < aeth> the subs with any longevity had such a hard balancing act because if they stayed small they'd fade away but if they grew they'd become terrible
2023-08-17 16:40:06 -0400 < leah2> what does karma bring you, i just enjot bad puns
2023-08-17 16:40:09 -0400 < dpk> /r/de seems to be the only subreddit that has profited from the reddit calamity
2023-08-17 16:40:42 -0400 < dpk> it was very zany five years ago, but started to take itself too seriously
2023-08-17 16:41:15 -0400 < gwatt> leah2: idk, some people just enjoy increasing their number of fake internet points. Doesn't really make sense
2023-08-17 16:41:27 -0400 < sham1> I ended up just removing myself from Reddit entirely after the whole API fiasco, because being a mod in a relatively large sub without proper tools would have been terribad
2023-08-17 16:42:23 -0400 < aeth> I just don't care about Reddit anymore because I came there for the comment sections and the comment sections are basically dead now because comments from new.reddit and official app users suck because the UI deemphasizes comments
2023-08-17 16:42:44 -0400 < aeth> compared to HN, Tildes, Lobsters, etc., it's no contest. Too bad none of them is big enough to have e.g. r/scheme, r/lisp, etc.
2023-08-17 16:42:50 -0400 < aeth> Most don't even have subsections
2023-08-17 16:44:00 -0400 < aeth> the WSB/crypto wave in 2021 did Reddit comment quality no favors, either.
2023-08-17 16:44:48 -0400 < Zipheir> People who comment on Reddit inexorably begin to sound like stereotypical Redditors, because the system rewards them for it.
2023-08-17 16:45:40 -0400 < Zipheir> At least some subreddits had the sense to turn off comment karma.
2023-08-17 16:46:15 -0400 < aeth> At least old Reddit culture didn't reward emojis.
2023-08-17 16:46:23 -0400 < aeth> Generally would get you downvoted.
2023-08-17 16:46:34 -0400 < aeth> After 2021, with WSB/crypto, you could unironically post a comment like this and get rewarded: 📈🌝🚀💎🙏
2023-08-17 16:47:14 -0400 < aeth> That's the culture Reddit corp wants now. Entirely emoji comments.
2023-08-17 16:49:13 -0400 < aeth> I think you're supposed to read those emoji like "stonks moon rocket diamond hands" btw
2023-08-17 16:50:27 -0400 < dpk> you must hang out in very different subreddits to where i did
2023-08-17 16:50:48 -0400 < aeth> You must have ignored Reddit entirely in the middle of 2021 if you avoided seeing diamond hands
2023-08-17 16:51:00 -0400 < dpk> (i was mostly in ones related to where i live (/r/berlin and /r/de), hobby based ones, and a couple more esoteric ones)
2023-08-17 16:51:22 -0400 < aeth> WallStreetBets went from 1 million to 11 million people in like a week. And of course they joined other subs, not just one sub, when they joined Reddit.
2023-08-17 16:51:54 -0400 < aeth> Of course, ever-shrinking pockets of quality existed on Reddit until June 2023 when just about everyone seemed to quit.
2023-08-17 16:52:34 -0400 < dpk> the number of people investing in the US stock market in Germany is probably small enough to explain why that didn’t spill over into my local ones
2023-08-17 16:53:14 -0400 < aeth> well, the crypto communities were a carbon copy of the meme stock ones and they flooded Reddit, including lots of spam that your moderators probably caught
2023-08-17 16:55:01 -0400 < aeth> thankfully, the gaming and programming (and the intersection, gamedev) communities all over the internet both managed to see through NFTs as a solution in search of a problem.
2023-08-17 16:55:57 -0400 < aeth> but the slow decline of Reddit certainly accelerated over the past 5 years.
2023-08-17 16:56:27 -0400 < aeth> stuff like r/lisp and r/scheme just became quieter and quieter instead of dropping in quality, though
2023-08-17 16:58:28 -0400 < aeth> We need a new Lisp forum... Usenet's dead, the standalone forums died, most serious programming subreddits died...
2023-08-17 16:58:44 -0400 < dpk> where do you think you are right now
2023-08-17 16:59:05 -0400 < aeth> chat isn't a forum, as much as some Discord communities don't seem to understand the difference
2023-08-17 16:59:42 -0400 < aeth> nobody's going to come back to this chat unless they grep their logs for some tiny detail (so they're not going to come back to *this* chat)
2023-08-17 17:03:57 -0400 < Zipheir> aeth: I proposed Lemmy a while back. There's https://lemmy.ml/c/scheme
2023-08-17 17:04:13 -0400  * mnieper` agrees with aeth
2023-08-17 17:04:25 -0400 < aeth> I don't like Lemmy because it feels too much like New Reddit. It even has images in the comments, which is something Reddit didn't do until very recently!
2023-08-17 17:04:33 -0400 < Zipheir> I'd love to see a Scheme BBS, but only people like me and aeth would use it.
2023-08-17 17:04:52 -0400 < aeth> You can't just start at 2020 levels of Reddit quality, that's already bad. You have to go back to 2011 Reddit and slowly work your way to 2020 Reddit quality.
2023-08-17 17:05:38 -0400 < mnieper`> Scheme BBS sounds great.
2023-08-17 17:05:41 -0400 < Zipheir> I'd be glad to see a 2011 Reddit clone for Scheme.
2023-08-17 17:05:42 -0400 < diod> what's wrong with email?
2023-08-17 17:05:44 -0400 < mnieper`> So we are already 3
2023-08-17 17:06:13 -0400 < Zipheir> diod: There are a number of lists already, but no general Scheme ml that I know of.
2023-08-17 17:06:38 -0400 < diod> ok
2023-08-17 17:06:50 -0400 < Zipheir> Now, is there a BBS implementation in Scheme?
2023-08-17 17:06:52 -0400 < diod> a forum interface for email seems like that solves all the problems
2023-08-17 17:06:52 -0400 < Zipheir> :)
2023-08-17 17:07:08 -0400 < aeth> Scheme's too narrow
2023-08-17 17:07:33 -0400 < aeth> but if you make it usenet-style hierarchical you can have a programming.lisp.scheme.r7rs.chibi
2023-08-17 17:07:49 -0400 < aeth> Reddit lacked subforums, so it was already a downgrade over phpBB in that critical sense
2023-08-17 17:08:55 -0400 < aeth> If you permitted programming.lisp.scheme.homework and mods could move all homework questions there (instead of closing the thread and hoping they reposted the question in something like a r/scheme_homework after closing it in r/scheme, and they usually didn't), then you could have more focused forums without seeming like you close every topic for arbitrary rules
2023-08-17 17:09:11 -0400 < Zipheir> diod: Google Groups, basically.
2023-08-17 17:09:46 -0400 < aeth> ironically, Gmail *loves* sending mailing lists to spam.
2023-08-17 17:10:05 -0400 < aeth> So Google's email duopoly with Microsoft is probably the main reason why mailing lists aren't practical outside of the nichest of niches.
2023-08-17 17:10:28 -0400 < aeth> despite also having Google Groups and the Usnet archive/gateway in Google Groups
2023-08-17 17:10:31 -0400 < Zipheir> No two projects at Google talk to each other, I guess, so Gmail is killing off Google Groups.
2023-08-17 17:10:53 -0400 < aeth> well, maybe they treat Google Groups specially and just choose to spamlist all other mailing list software
2023-08-17 17:12:14 -0400 < Zipheir> Anyway, reddit.com/r/scheme is probably the most active "forum" at the moment, and that's not saying much. So maybe we don't need to multiply fora.
2023-08-17 17:12:57 -0400 < aeth> The technical side of Reddit hasn't been active in years, though, because Reddit has chosen to emphasize memes instead of forum features.
2023-08-17 17:13:16 -0400 < aeth> even stuff like r/programming aren't that active compared to what they used to be
2023-08-17 17:13:40 -0400 < aeth> no surprise r/scheme isn't that active if r/programming itself is barely hanging on
2023-08-17 17:13:41 -0400 < Zipheir> I'm talking about a place for a Scheme forum, since people seem to want that.
2023-08-17 17:13:53 -0400 < diod> Zipheir I thought that was for usenet?
2023-08-17 17:14:14 -0400 < Zipheir> diod: Google Groups? It handles mls.
2023-08-17 17:14:20 -0400 < diod> oh
2023-08-17 17:15:33 -0400 < gwatt> aeth: Companies that derive revenue from advertising are going to always prefer increasing "engagement" now to anything else. If the people want memes, that's what's going to get the focus
2023-08-17 17:17:32 -0400 < aeth> gwatt: yes, of course, I can't imagine old.reddit.com's version of r/scheme would ever drive many clicks on ads compared to meme subreddits in the app that can have meme-style ads almost indistinguishable from content
2023-08-17 17:18:00 -0400 < aeth> but it also means that using r/scheme in 2023 is fighting against what the site clearly wants for its content
2023-08-17 17:18:00 -0400 < gwatt> I worked at a company that shifted from a consumer subscription model to ad-based revenue, and it was interesting to see the complaints roll in
2023-08-17 17:18:06 -0400 < Zipheir> Wow. The current "new" reddit UI is ridiculous.
2023-08-17 17:18:34 -0400 < Zipheir> aeth: Good point.
2023-08-17 17:18:46 -0400 < aeth> Zipheir: the new design is primarily designed to make ads indistinguishable from (meme) content, which now autoexpands (so the ads are automatically there) as you infinite scroll (instead of being paginated)
2023-08-17 17:18:59 -0400 < aeth> and shows many, many fewer comments because it wants you to infinite scroll into the next meme
2023-08-17 17:19:02 -0400 < aeth> (or into the next ad)
2023-08-17 17:19:17 -0400 < Zipheir> Reddit is probably to, er, enshittified (Cory Doctorow's term) to use for a serious programming forum.
2023-08-17 17:19:34 -0400 < aeth> What Reddit needed was e.g. subforums
2023-08-17 17:19:36 -0400 < Zipheir> *sigh*
2023-08-17 17:19:45 -0400 < aeth> What it got was... basically becoming indistinguishable from Twitter, or, I'm sorry, X
2023-08-17 17:21:05 -0400 < Zipheir> Yes. All of these things are converging.
2023-08-17 17:21:13 -0400 < aeth> What we need is something more or less like Old Reddit in style, but with subforums, and just put Scheme in programming.lisp.scheme (as opposed to programming.lisp.common)
2023-08-17 17:21:32 -0400 < aeth> best as a standalone thing, since standalone Reddit clones are now en vogue
2023-08-17 17:22:52 -0400 < aeth> The thing that costs lots of money to host is the images and especially the videos, but if you're not chasing ad revenue or engagement, you never have to support videos and image support can come much, much later to discourage that sort of meme culture from forming
2023-08-17 17:23:08 -0400 < Zipheir> I'm sure there's forum software that still works if you really want something standalone.
2023-08-17 17:23:24 -0400 < Zipheir> Otherwise, Lemmy is really not that far from that idea.
2023-08-17 17:24:11 -0400 < gwatt> I was on a programming forum that closed down a couple years ago because it couldn't compete with reddit / stackoverflow. This was a site that had been operating since the early 2000s. The owner said it'd been losing money for a while at the time of shutting down.
2023-08-17 17:24:27 -0400 < aeth> Zipheir: No, Lemmy is kind of a Reddit 1.5, with half of its design cues taken from New Reddit, including in-image comments. But, more importantly, it already has that Reddit culture and its only complicated feature is to federate with other lemmies, where people will sound like stereotypical Redditors, as you talked about earlier.
2023-08-17 17:24:32 -0400 < gwatt> I suspect it would be even harder to start something like that now
2023-08-17 17:24:57 -0400 < aeth> Zipheir: Federation in this case is a bit of an anti-feature, since anyone from other "instances" would lower the quality of the discussion
2023-08-17 17:25:25 -0400 < aeth> Multiple clients is fine, multiple servers hosting user profiles will encourage one big community shared with the memes
2023-08-17 17:25:40 -0400 < Zipheir> aeth: Sure, but it doesn't cost anything and it's not running on J. Random Schemer's home server.
2023-08-17 17:26:08 -0400 < aeth> gwatt: A couple of years ago is quite unfortunate because now that interest rates are going up and all of these companies need to start profiting immediately instead of just having revenue...
2023-08-17 17:26:26 -0400 < aeth> gwatt: ...we're seeing all of these sites fall apart at once. StackOverflow had a moderator revolt around the same time as Reddit!
2023-08-17 17:27:46 -0400 < aeth> Zipheir: The way to go would probably be to have an optional subscription and if there's enough to break even, it'll always break even. Text doesn't cost that much to host.
2023-08-17 17:29:23 -0400 < Zipheir> I don't think anyone would want to pay to discuss Scheme on a new and probably quiet formu.
2023-08-17 17:29:25 -0400 < Zipheir> *forum
2023-08-17 17:32:10 -0400 < aeth> Zipheir: programming in general, and you could probably put some (mostly nerdy) culture stuff in there on other forums, such as various games. The lack of images/memes would attract a very different crowd so it could find a niche.
2023-08-17 17:32:49 -0400 < gwatt> aeth: RE: "Text doesn't cost that much to host". In the "shutting down" post for the forum I was talking about, the owner said hosting ran around $1500/mo, and that through much effort could maybe get that cost down to $600/mo
2023-08-17 17:33:24 -0400 < aeth> solely text?
2023-08-17 17:33:28 -0400 < aeth> must've been a lot of text
2023-08-17 17:33:47 -0400 < aeth> sounds 10x more expensive than I'd estimate
2023-08-17 17:34:14 -0400 < gwatt> I'm not sure how the image hosting worked, because there was a "memes" section as an outlet. But the site had been operating for about 20 years
2023-08-17 17:38:15 -0400 < Zipheir> aeth: What you're describing is still a pain for the lucky person who does it. They'd have to deal with legal issues, moderation, etc.
2023-08-17 17:38:38 -0400 < aeth> gwatt: most traditional forums just let people hotlink images from e.g. photobucket, tinypic, imgur, etc. So one by one they went down. Imgur might still let you do it, though
2023-08-17 17:39:03 -0400 < aeth> But imgur is going to start deleting old images (if they haven't already) so imgur is soon to be on that list of hosting dead images
2023-08-17 17:40:12 -0400 < gwatt> aeth: IIRC, the site would allow linking, but also had a limited store of images you could upload to the site itself. I think there was a subscription you could pay for that would increase your own storage
2023-08-17 17:42:17 -0400 < aeth> All of my largest code repo is < 15 MB, i.e. about 3 images. But without the git metadata, it's just under 5 MB, or about 1 image (but some images are < 1 MB). Text is so much smaller than images, and can compress well if needed.
2023-08-17 17:42:28 -0400 < aeth> Images are also where most legal issues would be
2023-08-17 17:43:57 -0400 < aeth> if I threw in free git hosting, then automated pulling of the git repos could cause a lot of traffic, though
2023-08-17 17:45:20 -0400 < aeth> hmm, images I've saved off from social media tend to be < 1 MB, though, because they tend to be very low quality images
2023-08-17 17:45:46 -0400 < aeth> Often < 0.1 MB
2023-08-17 17:46:03 -0400 < gwatt> I think most image hosting sites re-encode them at lower qualities
2023-08-17 17:46:50 -0400 < aeth> which saves space and bandwidth, but now requires a more powerful machine
2023-08-17 17:46:57 -0400 < aeth> to reencode
2023-08-17 17:48:16 -0400 < gwatt> images off my phone are usually 5-ish MB. The ones off my dive camera are usually 2+ MB 
2023-08-17 17:48:55 -0400 < gwatt> Though I guess some of those phone images are actually a brief time-lapse
2023-08-17 17:51:05 -0400 < cow_2001> How do you programatically list all the names you wish to export in a define-library?
2023-08-17 17:51:49 -0400 < cow_2001> (define-library (blah) (import (scheme base)) (export ???) (begin ???))
2023-08-17 17:55:50 -0400 < gwatt> cow_2001: You can do (include-library-declarations <filename>) to export all things defined in <filename>
2023-08-17 17:56:26 -0400 < cow_2001> What if I don't want all file declarations?
2023-08-17 17:57:00 -0400 < gwatt> well, how you would you like to programmatically (automatically?) export definitions from your library?
2023-08-17 17:58:24 -0400 < gwatt> You have to either explicitly list all identifiers you want exported, or use the include-library-declarations form
2023-08-17 18:52:02 -0400 < cow_2001> gwatt: I could include-library-declarations into a dummy library, and then export except!
2023-08-17 18:52:43 -0400 < cow_2001> except the declarations used to generate the stuff.
2023-08-17 19:01:17 -0400 < flatwhatson> explicitly listing exports isn't as bad as it sounds, and makes things more greppable
2023-08-17 19:02:38 -0400 < flatwhatson> especially when using non-hygienic macros, the exports might be the *only* place a name is mentioned aside from callsites
2023-08-17 23:50:57 -0400 < Zipheir> As for BBS software in Scheme, I almost forgot about https://textboard.org/  I wonder if it could be turned into a non-anonymous discussion board.
2023-08-17 23:55:30 -0400 < mdhughes> I have an ugly search that finds all my defined functions, but in practice I just copy a name and paste it in exports.
2023-08-17 23:56:59 -0400 < mdhughes> I use a mix of (define (foo)… (define foo (λ ()… (define foo (λ* ()… so life's hard.
2023-08-17 23:57:41 -0400 < mdhughes> And there's probably old code where I wrote out "lambda"
--- Day changed Fri Aug 18 2023
2023-08-18 00:00:14 -0400 < mdhughes> Last time I looked at a textboard, it was full of N-word spam.
2023-08-18 00:01:13 -0400 < mdhughes> Lemmy has the best longer-term appeal, since it can have moderation.
2023-08-18 00:04:51 -0400 < Zipheir> That's why I was trying to recommend it if people want a Scheme forum.
2023-08-18 00:07:29 -0400 < Zipheir> https://lemmy.ml/c/scheme has been slightly active.
2023-08-18 00:49:26 -0400 -!- pony is now known as testing_stuff
2023-08-18 00:49:35 -0400 -!- testing_stuff is now known as testing
2023-08-18 00:49:45 -0400 -!- testing is now known as pony
2023-08-18 01:37:07 -0400 < mnieper``> jcowan: More interesting than JSON (which, I think, works fine in a dynamic or a static type system) is the `eval' procedure, I think.
2023-08-18 01:47:05 -0400 < mnieper``> A first approximation would be that eval is polymorphic and its static type is eval : str -> 'a with a runtime error when the evaluation of the string does not produce the type to which 'a will be unified.
2023-08-18 01:47:31 -0400 < mnieper``> Problem with this is that the type variable is only in covariant, not in contravariant position.
2023-08-18 01:48:44 -0400 < mnieper``> A solution could be to introduce a dummy argument (only interesting because of its type) as in eval : 'a * str -> 'a.
2023-08-18 01:49:34 -0400 < mnieper``> That's not perfect because some value for the dummy argument would have to be constructed during runtime.
2023-08-18 01:50:29 -0400 < mnieper``> Another solution could be to make eval monomorphic by providing eval-str, eval-int, eval-int->int, or generally eval[type annotation].
2023-08-18 02:23:15 -0400 < flatwhatson> i wonder if passing in a type predicate / assertion could work
2023-08-18 02:24:33 -0400 < flatwhatson> the type checker would need to understand type assertions specially
2023-08-18 03:15:53 -0400 < mnieper`> You mean something like (eval boolean? '(if (> 1 0) #t #f)) ?
2023-08-18 03:17:46 -0400 < mnieper`> flatwhatson: ^^
2023-08-18 03:18:59 -0400 < flatwhatson> yeah, and we know the result of eval will be boolean or error
2023-08-18 03:37:22 -0400 < mnieper`> Now that I think about it: If the static type system does not have a runtime representation (say, because the type checker's state is ephemeral), we may restrict eval to the signature eval : datum -> environment -> datum -> datum.
2023-08-18 03:38:22 -0400 < mnieper`> Datum is the type of a serialized version of a serializable value (we already know datums from Scheme).
2023-08-18 03:38:48 -0400 < mnieper`> Environment is the type of an environment returned by, say, (environment '(scheme base)).
2023-08-18 03:39:11 -0400 < mnieper`> The first argument must then evaluated (through `eval') to a procedure taking a datum and yielding a datum.
2023-08-18 03:39:40 -0400 < mnieper`> This effectively makes `eval' monomorphic.
2023-08-18 04:11:19 -0400 < lockywolf> What are "assumptions" about variables available in, say, Maxima?
2023-08-18 04:17:45 -0400 < lockywolf> contracts?
2023-08-18 04:18:00 -0400 < lockywolf> they can be inconsistent though
2023-08-18 04:18:35 -0400 < mnieper`> You have to be able to write down a sound type theory that is decidable.
2023-08-18 04:19:00 -0400 < mnieper`> I would like even more, namely automatic type inference.
2023-08-18 05:06:49 -0400 < michal_atlas> Zipheir: I was asking in general, since even syntax-case and define-macro when I calculate and return something like a hashtable, many schemes just say, unreadable value / unhandled constant or some equivalent. So I mainly wanted to see any way of doing it in any scheme for curiosity's sake.
2023-08-18 05:12:39 -0400 < mnieper`> michal_atlas: A macro transformer must return a syntax object representing a datum value.
2023-08-18 05:12:49 -0400 < mnieper`> A hashtable is not a datum value.
2023-08-18 05:13:52 -0400 < mnieper`> You need to serialize your hashtable in a vector (using hashtable-entries) at expansion time and rebuild the hashtable at runtime from the vector constants.
2023-08-18 05:15:44 -0400 < mnieper`> A hashtable structure contains its hash function, but a Scheme procedure is not serializable, which means that a general hashtable is neither.
2023-08-18 05:16:46 -0400 < mnieper`> Note that, in general, a different process is run during expand-time than during run-time.  (Think of AOT expansion of libraries.)
2023-08-18 05:19:02 -0400 < michal_atlas> Okay, I just figured that there'd be another way that I was overlooking. thank you for the explanation.
2023-08-18 05:30:15 -0400 < mnieper`> In some situations, some Schemes may allow more general values, but this would not be covered by the standard.
2023-08-18 05:30:54 -0400 < michal_atlas> Makes sense, 
2023-08-18 05:33:20 -0400 < mdhughes> alists are a little easier to serialize to/from. If you know the hash/equality function names, you could serialize that, and use it to recreate the hashtable. In practice you usually know that in the code.
2023-08-18 05:35:05 -0400 < dpk> wrote this for the broader programming community http://dpk.io/r7rswtf
2023-08-18 06:05:23 -0400 < mnieper`> mdhughes: Pairs of vectors, not alists for huge tables.
2023-08-18 06:06:11 -0400 < mdhughes> I disagree, it's much easier to edit a data file stored as alists, than try to read two giant vectors and match up entries.
2023-08-18 06:06:42 -0400 < mdhughes> And for read/write, it's not any different (maybe 2 extra bytes per entry).
2023-08-18 06:06:43 -0400 < mnieper`> In the context of the question, you will never see the data as such.
2023-08-18 06:07:02 -0400 < mnieper`> Everything is inside the compiler.
2023-08-18 06:07:04 -0400 < mdhughes> You will in fact, if you ever want to debug your data, or edit it in a text editor.
2023-08-18 06:07:42 -0400 < mnieper`> Then you have to add debug code anyway and this debug code can output your transformer output as you wish.
2023-08-18 06:08:53 -0400 < mdhughes> You don't need to debug Lisp data formatters usually, because the output is sexprs. This isn't Java or some shit.
2023-08-18 06:09:46 -0400 < mnieper`> mdhughes: I am not sure you understand the context.  By the way, a transformer does not output sexprs.
2023-08-18 06:09:54 -0400 < mdhughes> Back to the JSON, ASN.1 kind of argument. Opaque data formats are a terrible idea, they were a massive historical mistake.
2023-08-18 06:18:51 -0400 < dpk> great, now my server is going to get battered by Hacker News readers
2023-08-18 06:19:01 -0400 < dpk> fortunately, static files save the day
2023-08-18 06:21:20 -0400 < mnieper`> dpk: Your description of the R6RS list library is possibly incomplete: it does not offer the same functionality as SRFI 1, only a small percentage; one should also add (which may not be clear to readers) that it is trivial to install SRFI 1 on every R6RS system. Also, the procedures of SRFI 1 were all considered, so existing practice was not ignored as some claimed.
2023-08-18 06:22:16 -0400 < mnieper`> I would also add something to the paragraph before "the current issues" which is, I think, the root cause of the necessity of the recent discussions.
2023-08-18 06:23:20 -0400 < mnieper`> The assumption that the split into a small and a large language will eventually suit the R5RS and the R6RS camp was probably wrong.
2023-08-18 06:24:01 -0400 < mnieper`> The R5RS camp (which exludes die-hard R4RS fans) enjoys R7RS-small.
2023-08-18 06:25:05 -0400 < mnieper`> The R6RS people, however, weren't and aren't looking just for a large language but for a programming language as precisely specified as R6RS.
2023-08-18 06:26:17 -0400 < mnieper`> So unless the R7RS-small core of the large language is replaced by something in the line of R6RS, the initial assumption was plainly wrong.
2023-08-18 06:26:50 -0400 < mnieper`> [of the Steering Committee]
2023-08-18 06:31:26 -0400 < dpk> this is true, if at all, only of a small subset of the ‘R6RS camp’
2023-08-18 06:31:38 -0400 < dpk> it doesn’t include Will Clinger or the Guile implementors, most obviously
2023-08-18 06:31:58 -0400 < dpk> besides which, i refer the right honourable gentleman to the third paragraph of my article, in particular the last sentence
2023-08-18 06:31:59 -0400 < mnieper`> Clinger is anti-R6RS.
2023-08-18 06:33:33 -0400 < mnieper`> dpk: I read this sentence, and I didn't say you have to change your text, just that I think it can be made a bit more precise.
2023-08-18 06:34:19 -0400 < mnieper`> Guile does not belong to any camp. Well, if to any, then to the "Scheme standardization has become hopeless"-camp.
2023-08-18 06:49:36 -0400 < leah2> i try to stay out of the discourse, but afaict no implementor wants to implement r7rs-large
2023-08-18 06:53:45 -0400 < mnieper`> The idea was to make the Foundations attractive enough to find implementers.  The rest would be a portable library.
2023-08-18 06:54:19 -0400 < leah2> imo this is the wrong way around
2023-08-18 06:54:30 -0400 < mnieper`> In what sense?
2023-08-18 06:55:04 -0400 < leah2> the implementors should find a consenus what belongs into the core
2023-08-18 06:55:16 -0400 < dpk> leah2: we don’t know this for certain. maintainers (Larceny, Gambit) are on the steering committee; maintainers (Gambit, Kawa, Sagittarius) have actively engaged in the votes
2023-08-18 06:55:35 -0400 < dpk> (+ Chibi and Gerbil for the latter, actually!)
2023-08-18 06:55:36 -0400 < mnieper`> dpk: Is Larceny still maintained?
2023-08-18 06:55:47 -0400 < leah2> chibi wont do large afaiu
2023-08-18 06:56:10 -0400 < leah2> and gambit barely does small
2023-08-18 06:57:16 -0400 < mnieper`> Kawa's maintainer has been quite sceptical about R7RS-large.
2023-08-18 06:57:16 -0400 < dpk> mnieper`: the only way you can define Will Clinger as ‘anti-R6RS’ is by (a) extending his antipathy for the record system to the entire rest of the language and (b) defining anyone as ‘anti-R6RS’ who doesn’t subscribe to the strict-definitions-or-nothing camp you describe, which would make your argument tautological
2023-08-18 06:57:40 -0400 < dpk> have you read http://andykeep.com/SchemeWorkshop2015/papers/sfpw1-2015-clinger.pdf ?
2023-08-18 06:59:17 -0400 < mnieper`> dpk: I have some insider information.  But there are also a number of public posts, which you can google.
2023-08-18 07:00:19 -0400 < dpk> leah2: in any case, i share your concern though i don’t put it in quite such strong terms. i want to find someone who will accept Large support into their implementation and work with them on the report. if that doesn’t pan out … well, maybe the implication of what you say is correct, that implementer interest is so low that we should in fact dissolve the working group
2023-08-18 07:00:54 -0400 < ecraven> the situation here is different than CL, when financial interests were also at play, I believe :-/
2023-08-18 07:01:10 -0400 < dpk> that would be the end of Scheme as a standard language, effectively. but all things must come to an end. maybe it is Scheme’s time. who knows
2023-08-18 07:03:08 -0400 < mnieper`> In some sense, the end had already come in 2007.
2023-08-18 07:04:38 -0400 < mnieper`> A standard only accepted by half of the community meant that there was no "standard Scheme" (whatever this means) anymore.
2023-08-18 07:05:15 -0400 < mnieper`> 2013 cemented this. 
2023-08-18 07:06:30 -0400 < mnieper`> Thus my lobbying for considering both current standards equally if we still want to call the resulting product a "standard Scheme".
2023-08-18 07:06:48 -0400 < leah2> dpk: indeed i hope you're more optimistic than me ;)
2023-08-18 07:07:19 -0400 < jobol> avoiding scheme death is a need IMHO
2023-08-18 07:07:37 -0400 < mnieper`> Another problem that remains to be solved is that R7RS-large will probably compete with Racket - especially if it will only have one implementer.
2023-08-18 07:08:04 -0400 < mnieper`> Why not use Racket then, which already is what R7RS-large wants to become.
2023-08-18 07:08:33 -0400 < mnieper`> (Apart from that Racket is not a standard.)
2023-08-18 07:08:39 -0400 < jobol> can't we say GUILE is the way? And say it because it is a defacto standard?
2023-08-18 07:08:49 -0400 < mnieper`> jobol: Scheme won't die if the RnRS process ends.
2023-08-18 07:08:56 -0400 < mnieper`> As you say, there is Guile, there is Racket, ...
2023-08-18 07:09:24 -0400 < mnieper`> These are implementations of *a* Scheme language.
2023-08-18 07:10:16 -0400 < mnieper`> They are no standards (and Guile is probably far away from being able to be standardised), but we have seen a lot of thriving languages without standards.
2023-08-18 07:10:26 -0400 < leah2> if we say that large implies s-c, then there are 4 realistic implementations? and chez doesnt wanna do r7rs?
2023-08-18 07:11:34 -0400 < dpk> Dybvig has expressed support for the idea of a standard to reunify R7RS small with R6RS
2023-08-18 07:12:13 -0400 < mnieper`> Suggesting the name R8RS and that is should be based on R6RS.
2023-08-18 07:12:31 -0400 < dTal> would we pronounce it "raters"
2023-08-18 07:12:47 -0400 < dTal> R8RS of the lost Arc
2023-08-18 07:13:45 -0400 < leah2> like php 5 -> 8 *duck*
2023-08-18 07:14:59 -0400 < dpk> there does seem to be a curse associated with programming languages and the version number 6
2023-08-18 07:15:20 -0400 < mnieper`> EcmaScript 4
2023-08-18 07:15:26 -0400 < dpk> possibly extending to 7 – we’ll see if the curse now afflicts Perl
2023-08-18 07:23:26 -0400 < dpk> someone comments on Hacker News: ‘It was refreshing to see that this appears to be about disagreement over the direction of the language as opposed to an identity politics hijacking which seems to be the usual cause for drama in projects these days.’
2023-08-18 07:24:24 -0400 < dpk> the temptation is strong to revive my (long-inactive) HN account to reply: ‘Don’t worry, if made chair I will ensure that the standard contains infinite genders and conforms to the woke leftist agenda’
2023-08-18 07:25:16 -0400  * mnieper` wonders whether unrelated drama is actually good so that no one has energy to argue about anything language-related.
2023-08-18 08:18:20 -0400 < flatwhatson> divide and conquer!
2023-08-18 08:26:05 -0400 < acdw> dpk: doooo eeeetttt
2023-08-18 08:26:42 -0400 < mnieper`> dpk: You mention in your blog post that Scheme "has so often pioneered features that later broke into the mainstream".  I totally agree with you, of course.  But this is about the past.  What about today and in the future?  Do you think Scheme plays or will play such a role again?
2023-08-18 09:03:23 -0400 -!- mirai_ is now known as mirai
2023-08-18 09:05:21 -0400 -!- rgherdt_ is now known as rgherdt
2023-08-18 09:08:54 -0400 < mnieper`> flatwhatson jcowan Zipheir and whoever might be interested in static typing: Another approach to `eval' might be to make the static typechecker "dynamic" in the sense that it exists at runtime. Whenever eval is evaluated at a site S and this evaluation yields a term of type T, a typing constraint is added, namely that the (dynamic) value of S is at least of type T. If this makes the program untypeable, an exception is raised.
2023-08-18 09:18:17 -0400 < lockywolf> let us just declare Scheme as done
2023-08-18 09:22:34 -0400 < mdhughes> Committee Scheme might be done. Eh. As long as I have Chez I'm fine.
2023-08-18 09:23:41 -0400 < mdhughes> I just don't want to have to use Common Lisp or Clojure or some such.
2023-08-18 09:24:06 -0400 < mnieper`> lockywolf: I think the core of Scheme to which everyone agrees was done.  It is probably R4RS (or IEEE Scheme).
2023-08-18 09:24:54 -0400 < lockywolf> I was being ironic, obviously.
2023-08-18 09:25:23 -0400 < mnieper`> Sure, but I think there is a bit of truth in your irony.
2023-08-18 09:25:48 -0400 < lockywolf> But anyway, the real driving factor behind Scheme, at least to me, seems to have been the teaching books using it. That is actually why I proposed those two SRFIs covering SICP.
2023-08-18 09:26:49 -0400 < lockywolf> Therefore the answer to the question, "is scheme still relevant", would, to me, be seen as "are there still textbooks which find Scheme the simplest language to represent the code in them".
2023-08-18 09:28:28 -0400 < lockywolf> Since both "Software Design for Flexibility" and "Little Learner" are with us, and are fairly recent, seemingly, Scheme is still alive.
2023-08-18 09:29:30 -0400 < dpk> mnieper`: i think there’s no reason it won’t be as long as (a) lambda calculus remains a standard vehicle for expressing new developments in PLT and (b) Scheme remains an ‘interpreter for extended lambda calculus’
2023-08-18 09:32:08 -0400 < mnieper`> So this idea is along the lines "R7RS-large will be an attractive language for many, thus bringing more programmers in contact with Scheme, implying that Scheme's appearances in papers increase"?
2023-08-18 09:33:50 -0400 < lockywolf> there haven't been a standard for Common Lisp for a while
2023-08-18 09:36:20 -0400 < lockywolf> I haven't actually grounded through all the "Little", and other scheme-involved books out there, and I am not sure whether a standard Scheme can support everything they need.
2023-08-18 09:37:38 -0400 < jobol> speaking for me, it was great to find scheme standards and SRFI process. That is very good for adoption.
2023-08-18 09:42:20 -0400 < lockywolf> maybe, again, the new chair could try to (more pro-actively) gather more feedback from (a) scheme implementers, (b) scheme book authors, to try and better understand which features are deemed necessary, and which are just icing on the cake?
2023-08-18 09:44:04 -0400 < lockywolf> Scheme has never followed the "worse is better" approach, but it did include a lot of legacy features, which later were found to  be impractical. So making mistakes in the reports is not a fatal error.
2023-08-18 09:44:42 -0400 < mnieper`> IMO it still includes such features.
2023-08-18 09:45:10 -0400 < sham1> The thing is that book writers probably don't need most of the things that are being thought of
2023-08-18 09:45:43 -0400 < mnieper`> They probably need/want less.
2023-08-18 09:46:02 -0400 < sham1> If anything, you might argue that they might even want an even smaller than R7-small 
2023-08-18 09:46:07 -0400 < sham1> Yeah
2023-08-18 09:46:45 -0400 < mnieper`> https://docs.racket-lang.org/htdp-langs/index.html
2023-08-18 09:49:17 -0400 < dpk> a Scheme book showing what one can do with delimited continuations would be a good idea
2023-08-18 09:49:32 -0400 < dpk> for someone other than me to write, that is
2023-08-18 09:50:28 -0400 < lockywolf> The Little Continuator
2023-08-18 09:50:34 -0400 < lockywolf> The Little Continuer
2023-08-18 09:53:17 -0400 < mnieper`> Such a book can be written with R6RS or R7RS-small; just assume there is a library (delimited-continuations) that can be imported.
2023-08-18 09:55:50 -0400 < mnieper`> A bigger problem is to find a standard-conforming Scheme that can implement such a library.
2023-08-18 09:59:22 -0400 < mnieper`> everyone: What do you think of developing the foundational part of the standard incrementally? E.g. specifying a minimal library for delimited continuations to R6RS & R7RS-small (can be done within the SRFI process) and then asking implementers of R6RS and R7RS-small to actually implement it. As soon as two implementations are ready, it gets into the incrementally growing standard.
2023-08-18 10:00:33 -0400 < jobol> mnieper`, I vote yes
2023-08-18 10:01:29 -0400 < mnieper`> The same can be done with the undisputed parts of the syntax system (syntax-case, SRFI 212, SRFI 213) where we just have to define library names (individually for R6RS and R7RS-small systems) and wait until implementers catch up.
2023-08-18 10:02:06 -0400 < mnieper`> Call the results R6RS 2023 and R7RS 2023 (or whatever).
2023-08-18 10:02:29 -0400 < mdhughes> Write a spec for R7RS to support Unicode.
2023-08-18 10:02:45 -0400 < mnieper`> Isn't it optional?
2023-08-18 10:02:55 -0400 < mnieper`> And when the option is used, Unicode is supported?
2023-08-18 10:07:06 -0400 < mnieper`> What I sketched above is not so far away from jcowan 's original approach to get the Red and Tangerine docket done and implemented first.  I see some subtle, yet important difference, though.  The Red and Tangerine dockets didn't need any commitment from implementers.  Because portable libraries were available, it was simple to add them.
2023-08-18 10:07:53 -0400 < jcowan> The reason for that was to build trust that would make implementers more willing to put in the investment.
2023-08-18 10:11:14 -0400 < mnieper`> And implementers showed interest!
2023-08-18 10:16:00 -0400 < jcowan> dpk: Great whitepaper
2023-08-18 10:16:35 -0400 < mnieper`> But we don't have yet an implementer saying the Yellow Docket would soon be implemented.
2023-08-18 10:18:04 -0400 < mnieper`> This would be easier for R6RS-supporting Schemes, but these are (yet?) left out because the Red and Tangerine Dockets formally only address R7RS-small Schemes.
2023-08-18 12:02:13 -0400 < Zipheir> dpk: Thanks for the write-up.
2023-08-18 12:48:47 -0400 < leah2> yep
2023-08-18 12:53:41 -0400 < dpk> i’m glad Schemers thought it was a good article. i was concerned when writing it that people would feel i had misrepresented things (or worse, misrepresented them personally)
2023-08-18 12:54:27 -0400 < lockywolf> mnieper`: the github page for r7rs is not saying that Yellow is finished
2023-08-18 12:56:19 -0400 < dpk> i wish it hadn’t caused such a pessimistic mood to come over #scheme, though …
2023-08-18 12:58:28 -0400 < Zipheir> I don't feel pessimistic about it. We'll find some way forward, with or without the old standardization framework.
2023-08-18 13:00:27 -0400 < dpk> Per is claiming we fell apart over whether we wanted to generalize the monomorphic list procedures to become polymorphic 🤨 i haven’t seen any discussion of that https://news.ycombinator.com/item?id=37178039
2023-08-18 13:01:24 -0400 < Zipheir> This is the "perfect" time for disaffected Schemers to air their grievances.
2023-08-18 13:01:36 -0400 < dpk> yes, possibly
2023-08-18 13:01:38 -0400 < Zipheir> "Everything was going fine until..."
2023-08-18 13:02:06 -0400 < Zipheir> (Until I found this hill to die on.)
2023-08-18 13:02:22 -0400 < sham1> Everything was going well until no unicode!
2023-08-18 13:07:39 -0400 < Zipheir> Sorry, that was a bit harsh. Most people have a few dear ideas about programming languages which they don't like compromising on. I get it.
2023-08-18 13:08:17 -0400 < mnieper`> lockywolf: I thought Yellow was essentially done after the vote.
2023-08-18 13:09:24 -0400 < lockywolf> https://github.com/johnwcowan/r7rs-work/blob/master/R7RSHomePage.md
2023-08-18 13:09:40 -0400 < lockywolf> The plans for future partial editions can be found at Color Dockets; Yellow (formerly Kronos) is the next docket to be voted on in 2021, soon to be followed by Orange. The rest may be voted on in any order, and proposals will move between dockets.
2023-08-18 13:10:02 -0400 < mnieper`> Per has always been expressing his distaste for Scheme's monomorphism, which has become apparent in R7RS-large.
2023-08-18 13:10:19 -0400 < mnieper`> lockywolf: We voted on Yellow in 2021/2022.
2023-08-18 13:10:38 -0400 < lockywolf> but the page is still saying "to be voted"
2023-08-18 13:13:43 -0400 < mnieper`> jcowan: ^^ ?
2023-08-18 13:15:17 -0400 < jobol> in eiffel SCOOP is old (1993, see https://se.inf.ethz.ch/~meyer/publications/cacm/scoop.pdf) but nothing like that for scheme (answering mnieper` question "Do you think Scheme plays or will play such a role again?")
2023-08-18 13:16:17 -0400 < mnieper`> dpk: I also don't think that your article had a pessimistic effect.  It has the effect of making us rethink where we are, but that is very good.
2023-08-18 13:49:38 -0400 < jobol> i have no idea why () must should be written '(). Do you write (let () ...) or (let '() ...) ?
2023-08-18 13:52:06 -0400 < mnieper`> In (let () ...), the () is no expression, but part of let's syntax.
2023-08-18 13:52:38 -0400 < jobol> well it is undecided if it is funny or not
2023-08-18 13:52:39 -0400 < mnieper`> By convention, () is not an expression (evaluating to the empty list), so one has to use the expression (quote ())
2023-08-18 13:53:03 -0400 < jobol> change the convention
2023-08-18 13:53:41 -0400 < mnieper`> I think I agree with you.
2023-08-18 13:53:57 -0400 < mnieper`> https://codeberg.org/scheme/r7rs/issues/128
2023-08-18 13:55:34 -0400 < mnieper`> There is no good theoretical reason (even taking Racket's dialect into account) that () needs to be quoted as an expression.
2023-08-18 13:56:12 -0400 < Zipheir> #() is self-quoting post-R5, right?
2023-08-18 13:56:22 -0400 < mnieper`> Post R6
2023-08-18 13:56:25 -0400 < Zipheir> Ah.
2023-08-18 13:56:38 -0400 < mnieper`> R7 removed the quote from vector constants.
2023-08-18 13:57:06 -0400 < mnieper`> It would have been consistent to remove it from the empty list as well.
2023-08-18 13:57:10 -0400 < Zipheir> I wonder why () didn't get similar treatment.
2023-08-18 13:57:51 -0400 < Zipheir> I suppose it's because all other list literal must be quoted.
2023-08-18 13:57:55 -0400 < Zipheir> *literals
2023-08-18 13:58:41 -0400 < Zipheir> (There's no way around having to quote '(1 2 3).)
2023-08-18 13:59:19 -0400 < mnieper`> Actually, pairs have to be quoted, not lists.
2023-08-18 13:59:35 -0400 < mnieper`> That's why the empty list is not a special case.
2023-08-18 14:00:00 -0400 < mnieper`> Pairs and symbols (identifiers) because these can be valid non-constant expressions.
2023-08-18 14:00:14 -0400 < Zipheir> I don't understand. What are lists in Scheme if not pairs?
2023-08-18 14:00:26 -0400 < mnieper`> The empty list is not a pair.
2023-08-18 14:00:29 -0400 < Zipheir> And that.
2023-08-18 14:00:40 -0400 < jobol> issue 128 is of interest thanks. i am sure that () can be self evaluating to the empty list
2023-08-18 14:01:06 -0400 < Zipheir> But we almost always use pairs and the empty list to construct lists, and that makes () a special case among "list" literals.
2023-08-18 14:01:33 -0400 < mnieper`> All non-constant expressions are of the form <identifier> and (<identifier> . <datum>) where <identifier> is a variable or a keyword.
2023-08-18 14:01:38 -0400 < Zipheir> You'd have to explain to the new Schemer that you always quote lists literals, except for the empty list.
2023-08-18 14:02:24 -0400 < Zipheir> jobol: But what's the benefit? Now you have to remember a special case.
2023-08-18 14:02:29 -0400 < mnieper`> The new Schemer has to understand that (1 2 3) is short for (((1 . 2) . 3) . ()) anyway.
2023-08-18 14:02:39 -0400 < mnieper`> Zipheir: No, you are making up a special case.
2023-08-18 14:02:59 -0400 < Zipheir> I think it's missing the forest for the trees to pretend that we don't think in terms of lists.
2023-08-18 14:03:22 -0400 < mnieper`> Because (foo . 3) can be a valid expression (guaranteed by R6RS).
2023-08-18 14:03:28 -0400 < Zipheir> Of course.
2023-08-18 14:03:48 -0400 < mnieper`> Which is not a list.
2023-08-18 14:04:28 -0400 < Zipheir> But people think of (), (1), and (1 2 3) as lists, and I think it may confuse them to learn that only the non-empty lists have to be quoted.
2023-08-18 14:04:30 -0400 < mnieper`> And <identifier> is also not a list, but a valid expression.
2023-08-18 14:05:09 -0400 < mnieper`> The beginner can safely quote ().
2023-08-18 14:05:37 -0400 < Zipheir> True, you can always quote it. This is a molehill issue.
2023-08-18 14:05:47 -0400 < sham1> Even from a non-beginner standpoint I'd worry that it'd feel inconsistent
2023-08-18 14:06:02 -0400 < mnieper`> Actually, I think that the quote is stripped by evaluation (sometimes!) is much harder to understand for beginners.
2023-08-18 14:06:21 -0400 < mnieper`> 1 => 1     '1 => 1   ''1 => '1
2023-08-18 14:07:00 -0400 < mnieper`> '(1 . 2)  =>  (1 . 2)   (1 . 2) => error   ''(1 . 2) => '(1 . 2)
2023-08-18 14:07:16 -0400 < mnieper`> (cons 1 2) => (1 . 2)      '(cons 1 2)   => (cons 1 2) 
2023-08-18 14:07:19 -0400 < sham1> Well that['s more the inconsistency of self-quoting data
2023-08-18 14:07:58 -0400 < mnieper`> In some sense yes (or the problem of the printer, which, maybe, should not print the value but an expression evaluating to the value).
2023-08-18 14:08:17 -0400 < Zipheir> Because 1 isn't syntactically equivalent to (quote (quote ... (quote 1) ...))
2023-08-18 14:08:49 -0400 < mnieper`> But nevertheless, I believe that this is much harder to understand than accepting that () evaluated to () because what else?
2023-08-18 14:08:56 -0400 < mnieper`> sham1: Why inconsistent?
2023-08-18 14:09:38 -0400 < sham1> Because () wouldn't need a quote but (1) and so forth would. And yeah, as said, beginners can add it, but it feels a tad inconsistent that empty lists would be special in this sense
2023-08-18 14:10:08 -0400 < Zipheir> Scheme has a folklore list type just as C has a folklore string type.
2023-08-18 14:10:23 -0400 < sham1> I don't really like vectors and bytevectors being excepted from quoting either
2023-08-18 14:10:47 -0400 < mnieper`> sham1: As I wrote to Zipheir, it may feel like this but () is no special case; R7RS currently special cases it.
2023-08-18 14:10:48 -0400 < sham1> Same with CL's NIL and T as well. I learnt lisp with Emacs and over there you do need many quotes
2023-08-18 14:11:20 -0400 < sham1> mnieper`: how is it not a special case? No other list is self-evaluating
2023-08-18 14:12:24 -0400 < sham1> Unless you're proposing that without being "special cased" an empty list would be self-evaluating by default
2023-08-18 14:12:34 -0400 < jobol> mnieper`, check: (1 2 3) is (1 . (2 . (3 . ())) not what you wrote
2023-08-18 14:12:43 -0400 < sham1> In which case I'd appreciate a quote (hah)
2023-08-18 14:13:29 -0400 < Zipheir> sham1: IIUC, mnieper` is pointing out that there are no lists, just pairs (which must be quoted) and ().
2023-08-18 14:13:55 -0400 < sham1> Okay, but lists have a special blessed syntax in the language
2023-08-18 14:13:57 -0400 < Zipheir> Which is true, but we still tend to think of lists.
2023-08-18 14:14:24 -0400 < sham1> While they're not really first-class objects in the language as-such, they're very much treated like such
2023-08-18 14:14:35 -0400 < Zipheir> I agree.
2023-08-18 14:14:44 -0400 < Zipheir> A little like strings in C.
2023-08-18 14:15:16 -0400 < sham1> Yeah, a block of non-zero chars followed by '\0' (mutatis mutandis for wchar_t)
2023-08-18 14:15:53 -0400 < sham1> Same with lists. Pairs where the cdr is a list or an empty list
2023-08-18 14:17:04 -0400 < sham1> If I wanted to go for the consistency gravy train I'd probably just write `(1 . (2 . (3 . ())))` but everyone can see that it's not exactly a fun way to write that, which is why we have the blessed syntax of `(1 2 3)`
2023-08-18 14:17:57 -0400 < jobol> and pairs have to be quoted but the empty list?
2023-08-18 14:18:17 -0400 < haugh> mnieper`: re make-hash-table, what do you mean by "procedure equality" not being "computable"? I'm just not familiar with this language.
2023-08-18 14:18:26 -0400 < sham1> Pairs have to be quoted as does the empty list. The argument being presented here is that the empty list wouldn't have to need it. I disagree but I see the point
2023-08-18 14:18:55 -0400 < sham1> haugh: how would you determine if two procedures are equalk
2023-08-18 14:18:59 -0400 < sham1> equal?
2023-08-18 14:19:05 -0400 < mnieper`> Zipheir: sham1: There are lists, but these are not special for expressions.
2023-08-18 14:19:09 -0400 < sham1> Like what would `equal?` for example have to do
2023-08-18 14:19:12 -0400 < haugh> Oh I see
2023-08-18 14:19:15 -0400 < Zipheir> As long as '() still works as expected I have only quibbles.
2023-08-18 14:19:45 -0400 < Zipheir> mnieper`: I'm not sure I understand.
2023-08-18 14:20:20 -0400 < Zipheir> "What does () evaluate to if not itself?" seems like a strong argument.
2023-08-18 14:20:20 -0400 < mnieper`> A list is () or (<val> . <list>).
2023-08-18 14:20:42 -0400 < mnieper`> But this concept is irrelevant for the evaluator/expander of Scheme.
2023-08-18 14:20:48 -0400 < Zipheir> Right.
2023-08-18 14:20:56 -0400 < mnieper`> The evaluator checks whether it sees an identifier.
2023-08-18 14:21:06 -0400 < mnieper`> Or whether it sees a pair.
2023-08-18 14:21:50 -0400 < mnieper`> These two cases have to be quoted.
2023-08-18 14:21:52 -0400 < sham1> But you can't have dotted lists as procedure applications
2023-08-18 14:22:09 -0400 < mnieper`> But as macros (guaranteed by R6RS).
2023-08-18 14:22:34 -0400 < mnieper`> In Racket you could via #%app
2023-08-18 14:22:45 -0400 < mnieper`> (dotted procedure apps)
2023-08-18 14:22:47 -0400 < sham1> Well after macro expansion I'd certainly hope that the evaluator wouldn't need to see quotes or anything like that anywhere
2023-08-18 14:23:03 -0400 < mnieper`> What do you mean?
2023-08-18 14:23:05 -0400 < gwatt> But racket's not scheme and is not likely to care about RNRS, outside of a #lang compatibility
2023-08-18 14:24:09 -0400 < sham1> I mean that when the expander expands the program into some implementation-specific ASTs and whatnot that explicit quote forms and such get eliminated during this process
2023-08-18 14:24:11 -0400 < mnieper`> For the argument, that's irrelevant, I think. (Especially, as this was just a hint where one could see dotted procedure applications)
2023-08-18 14:24:16 -0400 < mnieper`> gwatt: ^^
2023-08-18 14:24:41 -0400 < mnieper`> sham1: Yes because (quote bla) has to become some AST node.
2023-08-18 14:25:09 -0400 < sham1> And after expansion you wouldn't expect to see dotted lists at least in RnRS scheme
2023-08-18 14:25:34 -0400 < sham1> Well as calls
2023-08-18 14:25:41 -0400 < sham1> Just like how you wouldn't expect to see cyclic data
2023-08-18 14:26:47 -0400 < gwatt> why not?
2023-08-18 14:27:15 -0400 < sham1> Pop quiz, what would (+ . #0=(1 . #0#)) be
2023-08-18 14:27:49 -0400 < sham1> There's a reason why you can't have a call like this. You'd have to quote the cyclic data
2023-08-18 14:28:16 -0400 < gwatt> probably nothing as it would expand infinitely. But I didn't realize you meant absent a quoted form
2023-08-18 14:28:49 -0400 < dpk> sham1: you could write it as (1 . (2 . (3 . (] ! :D
2023-08-18 14:28:52 -0400 < sham1> Well, the implementation ought to report to the user that what they're doing is silly
2023-08-18 14:29:25 -0400 < sham1> dpk: it looks wrong!
2023-08-18 14:29:32 -0400 < sham1> It looks unbalanced
2023-08-18 14:30:21 -0400 < Zipheir> dpk: Can Superparen close off an infinite number of open parens?
2023-08-18 14:30:52 -0400 < Zipheir> Unless they're made of kryptonite, I guess.
2023-08-18 14:33:47 -0400 < sham1> Weird, radioactive parentheses. I'd stay away from those
2023-08-18 14:34:03 -0400 < mnieper`> (+ . #0 = (1 . #0#)) should be rejected by the expander.
2023-08-18 14:34:11 -0400 < mnieper`> There is no need for it to loop.
2023-08-18 14:35:29 -0400 < mnieper`> That cyclic structures made it into code for R7RS-small unfortunately complicates a lot in the expander because it always has to check for cyclicity.
2023-08-18 14:35:52 -0400 < mnieper`> Which includes the syntax-case and syntax-rules pattern matcher.
2023-08-18 14:36:38 -0400 < mnieper`> It also invalidates the inductive definition of syntax object (given in R6RS).
2023-08-18 14:37:31 -0400 < mnieper`> If a new charter for WG2 (if it comes) allows to polish R7RS-small, I am in favour of removing datum labels (at least from code).
2023-08-18 14:38:11 -0400 < sham1> Well they're already not allowed. Unless you also meant that something like (foo '#0=bar #0#) would also be disallowed
2023-08-18 14:38:12 -0400 < mnieper`> IIRC, some WG1 members said it was probably a mistake.
2023-08-18 14:38:29 -0400 < mnieper`> sham1: Yes, it would also be allowed.
2023-08-18 14:38:39 -0400 < mnieper`> The problem is that you don't know what ends up being quoted.
2023-08-18 14:38:48 -0400 < mnieper`> The expansion algorithm is Turing-complete.
2023-08-18 14:39:21 -0400 < mnieper`> s/allowed/disallowed
2023-08-18 14:41:21 -0400 < mnieper`> sham1: Sorry, I might have misunderstood your example. You didn't mean (foo '#0=(bar #0#))  ?
2023-08-18 14:42:10 -0400 < sham1> No
2023-08-18 14:42:29 -0400 < mnieper`> In that case, it is equivalent to (foo 
2023-08-18 14:42:40 -0400 < mnieper`> (foo 'bar bar), which is okay.
2023-08-18 14:42:45 -0400 < sham1> Well my example would just be (foo 'bar 'bar)
2023-08-18 14:43:04 -0400 < sham1> Or hm, yeah, the quote doesn't transfer does it
2023-08-18 14:43:04 -0400 < mnieper`> Just no cycles in code.
2023-08-18 14:43:16 -0400 < sham1> Well that's already not allowed
2023-08-18 14:43:17 -0400 < mnieper`> no
2023-08-18 14:43:27 -0400 < mnieper`> no to does not transfer
2023-08-18 14:44:01 -0400 < mnieper`> sham1: Why not allowed? 
2023-08-18 14:44:05 -0400 < mnieper`> foo can be a keyword.
2023-08-18 14:44:23 -0400 < sham1> You can't have cyclic applications
2023-08-18 14:44:35 -0400 < mnieper`> (foo 'bar bar) has no cycles.
2023-08-18 14:44:55 -0400 < sham1> Right, but that's in the context of you wanting to ban datum labels in general
2023-08-18 14:45:08 -0400 < sham1> From code
2023-08-18 14:45:54 -0400 < mnieper`> Datum labels that do not produce cyclic structures would pose no problem.
2023-08-18 14:46:00 -0400 < mnieper`> But they are useless for code.
2023-08-18 14:46:20 -0400 < mnieper`> In any case, the expander sees the datum that was read by the reader.
2023-08-18 14:46:37 -0400 < mnieper`> All labels are long gone.
2023-08-18 14:47:00 -0400 < mnieper`> The only thing the expander would check is if there are cycles in the code.
2023-08-18 14:47:33 -0400 < sham1> Yes, and again, cyclic code is already disallowed so why would we have to ban it again
2023-08-18 14:47:42 -0400 < mnieper`> sham1: It is not.
2023-08-18 14:48:12 -0400 < mnieper`> (foo #0=(bar . #0#)) can be a valid expression in R7RS-small.
2023-08-18 14:48:34 -0400 < sham1> It is an error for a 〈program〉 or 〈library〉 to include circular references except in literals. In particular, it is an error for quasiquote (section 4.2.8) to contain them.
2023-08-18 14:48:49 -0400 < dpk> sham1: what if foo is just an alias for quote
2023-08-18 14:48:52 -0400 < sham1> 2.4. Datum labels. Last paragraph of that section
2023-08-18 14:48:56 -0400 < mnieper`> Right, but you don't see this before the end of expansion.
2023-08-18 14:49:08 -0400 < mnieper`> "Literal" can only be detected after expansion.
2023-08-18 14:49:09 -0400 < dpk> or otherwise uses its argument as a quoted literal without needing it to be explicitly quoted
2023-08-18 14:49:39 -0400 < mnieper`> Fairly enough, one of the authors of R7RS-small didn't understand it as well.
2023-08-18 14:51:37 -0400 < mnieper`> dpk: You may want to note in your syntax fascicle that the definition of syntax objects may have to be revised/made complicated as long as we stick to cyclic structures in code.
2023-08-18 14:52:25 -0400 < sham1> Of course it helps that R7-small doesn't explicitly define how expansion and such work, but it seems to have considered this case
2023-08-18 14:52:43 -0400 < dpk> i recently edited the inductive definition you referred to. how, specifically, does it need to be changed?
2023-08-18 14:52:56 -0400 < dpk> it seems to me to hold up in the presence of cycles
2023-08-18 14:53:01 -0400 < mnieper`> It would be no longer an inductive type.
2023-08-18 14:53:16 -0400 < sham1> Heck, the standard text even gives an example: `#1=(begin (display #\x) #1#) ; => error`
2023-08-18 14:53:19 -0400 < mnieper`> You can no longer built a syntax object from its building blocks
2023-08-18 14:54:13 -0400 < dpk> we are talking about this definition, no? https://usercontent.irccloud-cdn.com/file/5QApcXJ0/1692384843.JPG
2023-08-18 14:54:16 -0400 < mnieper`> sham1: Yes, what else?
2023-08-18 14:54:29 -0400 < dpk> thanks for recompressing my screenshot in a lossy format, IRCCloud
2023-08-18 14:54:42 -0400 < mnieper`> dpk: Yes.
2023-08-18 14:54:48 -0400 < sham1> Well this doesn't need to be forbidden in the large standard
2023-08-18 14:54:59 -0400 < sham1> It's already forbidden
2023-08-18 14:55:22 -0400 < mnieper`> It is about forbidding any cycles in code, whether they eventually end up quoted or not.
2023-08-18 14:55:41 -0400 < sham1> But if they're quoted why does it matter
2023-08-18 14:56:07 -0400 < mnieper`> The point is that before they may end up quoted, all macro transformers (and the whole expander) have to deal with possible circular input.
2023-08-18 14:56:34 -0400 < sham1> How would you express this stuff then
2023-08-18 14:57:01 -0400 < mnieper`> That the datum making up the code for a library, a program or the argument to `eval' must not contain circular structure.
2023-08-18 14:57:59 -0400 < sham1> Okay? And that still doesn't answer how you'd express circular data
2023-08-18 14:58:18 -0400 < mnieper`> Not via quote.
2023-08-18 14:59:36 -0400 < mnieper`> For the 0.01% of the cases where embedding circular data literally (!) inside the code might be helpful, 99.99% of use cases have to pay for it.
2023-08-18 15:01:01 -0400 < mnieper`> And 99% of the cases where you see circular data in code are MWEs to demonstrate bugs in implementations.
2023-08-18 15:04:17 -0400 < dpk> R4RS allowed symbols to appear in syntax objects iff they were ultimately going to be part of quoted datums, do we want to allow that? (like the circular datum thing, this could only be detected at the end of expansion, which would make it harder to know which particular transformation procedure ballsed up and put a symbol in code. i’m guessing this is why R6RS forbade it)
2023-08-18 15:05:27 -0400 < sham1> How did R4RS in that case distinguish between symbols and identifiers
2023-08-18 15:05:39 -0400 < sham1> Because when read they of course look the same
2023-08-18 15:07:22 -0400 < dpk> R4RS already had the concept of a wrapped syntax object, although not under that name (‘syntactic representation of a <<datum>>’) and it was less clear to what extent lists and such were wrapped – R6RS defined that all much more clearly
2023-08-18 15:07:49 -0400 < dpk> but identifiers and symbols were already distinct (in the low level macro system) in the same way as in syntax-case
2023-08-18 15:08:17 -0400 < sham1> But wherein is the wrap applied to the identifier?
2023-08-18 15:08:54 -0400 < sham1> Obviously not when reading because it needs to leave the symbols alone
2023-08-18 15:09:38 -0400 < dpk> yes, like R6RS, it’s not defined what the relationship between read and the creation of a wrapped syntax object is, only that the compiler has to create a wrapped syntax object before performing macro expansion
2023-08-18 15:11:36 -0400 < sham1> okay, and is there any specification for what symbols are to be wrapped because they're identifiers and what to leave alone because they're symbols
2023-08-18 15:12:08 -0400 < mnieper``> dpk: I would be careful to allow symbols in the output of a macro.
2023-08-18 15:12:10 -0400 < dpk> all symbols become wrapped as identifiers before macro expansion. the (internal to the compiler) expansion of the ‘quote’ primitive unwraps them
2023-08-18 15:13:11 -0400 < sham1> That's what I was thinking about
2023-08-18 15:13:38 -0400 < dpk> (i’ve looked at the R6RS syntax-case chapter so much recently that my browser address bar now auto completes it when i type ‘r’)
2023-08-18 15:14:35 -0400 < mnieper``> In principle, the expander could map symbols in the output of a macro to identifiers with a special wrap.
2023-08-18 15:14:35 -0400 < sham1> If we were to disallow symbols in transformer output, you'd have to check for it just as much as you'd have to check that your transformer doesn't output cyclic syntax objects
2023-08-18 15:15:48 -0400 < mnieper``> sham1: Yes, the expander iterates through the macro output until it reaches wrapped objects.
2023-08-18 15:15:57 -0400 < mnieper``> The iteration needs to check for cycles.
2023-08-18 15:16:33 -0400 < mnieper``> It has to do this anyway, so it can check for symbols with zero cost.
2023-08-18 15:16:55 -0400 < sham1> Yeah, but that already requires for the expander to be able to cope with cyclic data
2023-08-18 15:17:05 -0400 < sham1> Just to check that there is no cyclic data
2023-08-18 15:18:12 -0400 < dpk> hmm, the R6RS datum->syntax procedure doesn’t specify where the wrapping is applied to the syntax object (possibly to accommodate expanders like van Tonder’s, since the committee didn’t realize they have incompatible semantics in general)
2023-08-18 15:18:15 -0400 < sham1> In the contrafactual where we wouldn't allow any cyclic data in any code to be expanded
2023-08-18 15:18:49 -0400 < mnieper``> sham1: This is done for the macro output and not for macro inputs and does not concern the semantics of syntax objects.
2023-08-18 15:19:13 -0400 < mnieper``> dpk: The committee knew the incompatibilites with SRFI 72.
2023-08-18 15:19:49 -0400 < mnieper``> dpk: What do you mean by "where applied"?
2023-08-18 15:20:07 -0400 < dpk> mnieper``: i have not seen any evidence that they knew of the one you found. they made changes to accommodate a later version of van Tonder’s expander which was intended to be compatible with R6RS, see the formal comments
2023-08-18 15:21:08 -0400 < dpk> mnieper``: it’s not specified if (datum->syntax #'some-id '(cons a b)) returns a wrapped syntax object, or an unwrapped list where the identifiers within are wrapped
2023-08-18 15:21:09 -0400 < mnieper``> SRFI 93 discusses SRFI 72 and the difference algorithm of applying marks/colors.
2023-08-18 15:21:36 -0400 < mnieper``> They couldn't know of Van Tonder's final algorithm.
2023-08-18 15:25:25 -0400 < sham1> Time to read the bc-syntax-case paper again
2023-08-18 15:25:28 -0400 < dpk> remind me, what implementations of an R6RS syntax-case expander are there besides psyntax?
2023-08-18 15:25:55 -0400 < dpk> (and how can i test them to see what they do in certain situations)
2023-08-18 15:26:06 -0400 < dpk> (i.e. what actual implementations are they in)
2023-08-18 15:27:12 -0400 < sham1> One thing that disturbs me about the syntax-case implementation as presented by Dybvig is that the marks and substitutions are mixed within the wrap list
2023-08-18 15:32:29 -0400 < mnieper``> <mnieper``> s/difference/different  [21:25]
2023-08-18 15:32:29 -0400 < mnieper``> <mnieper``> 12.3 says that a transformer procedure receives a wrapped syntax
2023-08-18 15:32:29 -0400 < mnieper``>             object.  [21:26]
2023-08-18 15:32:32 -0400 < mnieper``> <mnieper``> I think the point is that an implementation may divide out a
2023-08-18 15:32:35 -0400 < mnieper``>             relation in the definition of syntax objects, namely that a
2023-08-18 15:32:38 -0400 < mnieper``>             wrapped syntax object can also be a (partially) unwrapped one.
2023-08-18 15:32:41 -0400 < mnieper``>                                                                         [21:31]
2023-08-18 15:32:44 -0400 < mnieper``> <mnieper``> And this makes the observation about datum->syntax moot.
2023-08-18 15:32:48 -0400 < mnieper``>  
2023-08-18 15:33:45 -0400 < cow_2001> There is an IEEE standard.  Why isn't IEEE = RnRS?
2023-08-18 15:34:00 -0400 < sham1> IEEE = R4RS
2023-08-18 15:34:03 -0400 < sham1> Basically
2023-08-18 15:34:04 -0400 < cow_2001> Oh.
2023-08-18 15:34:22 -0400 < cow_2001> Okay, why not n = latest?
2023-08-18 15:34:31 -0400 < mnieper``> sham1: Is bc-syntax-case post-R6RS?
2023-08-18 15:34:37 -0400 < dpk> and i think the IEEE standard’s period of ‘validity’ has lapsed
2023-08-18 15:34:44 -0400 < cow_2001> Oh boy.
2023-08-18 15:34:45 -0400 < mnieper``> dpk: Unsyntax
2023-08-18 15:34:53 -0400 < mnieper``> dpk: And Chez's expander
2023-08-18 15:34:54 -0400 < dpk> mnieper``: oh, duh, thanks
2023-08-18 15:35:04 -0400 < sham1> mnieper``: bc-syntax-case is 2007, so probably not
2023-08-18 15:35:05 -0400 < dpk> Chez’s expander is psyntax in name only :D
2023-08-18 15:35:11 -0400 < dpk> err, except in name
2023-08-18 15:35:17 -0400 < mnieper``> No, it isn't.
2023-08-18 15:35:24 -0400 < mnieper``> psyntax was extracted from Chez code.
2023-08-18 15:35:35 -0400 < mnieper``> But is not quite correct.
2023-08-18 15:35:43 -0400 < mnieper``> While Chez's expander is correct (as far as I know).
2023-08-18 15:36:01 -0400 < mnieper``> psyntax has a problem with let-syntax in a corner case.
2023-08-18 15:36:27 -0400 < mnieper``> Check with Chez and Unsyntax. If Unsyntax has a bug, tell me. :)
2023-08-18 15:36:37 -0400 < dpk> (so in other words, it’s basically psyntax, like i said)
2023-08-18 15:36:47 -0400 < mnieper``> ?
2023-08-18 15:37:03 -0400 < dpk> one migth as well say Guile’s expander isn’t psyntax because they’ve also hacked on it and added stuff beyond what Dybvig wrote
2023-08-18 15:37:23 -0400  * dpk tries to remember how she got unsyntax running last time …
2023-08-18 15:37:35 -0400 < mnieper``> The relationship between psyntax and Guile's expander is clear.
2023-08-18 15:37:53 -0400 < dpk> ah, docker run -ti schemers/unsyntax
2023-08-18 15:38:05 -0400 < mnieper``> psyntax and Chez's have *something* in common.
2023-08-18 15:38:29 -0400 < acdw> well I missed the () Convo. wouldn't assigning it a variable like nil work too?
2023-08-18 15:38:44 -0400 < sham1> You could indeed do (define nil '())
2023-08-18 15:39:03 -0400 < mnieper``> But neither of them is a development out of the other one.
2023-08-18 15:39:21 -0400 < mnieper``> Even better (define-syntax nil (identifier-syntax '()))
2023-08-18 15:39:34 -0400 < mnieper``> sham1 acdw: ^^
2023-08-18 15:39:53 -0400 < mnieper``> So that no one can do (set! nil '(Hah!)).
2023-08-18 15:39:55 -0400 < acdw> uwu
2023-08-18 15:40:09 -0400 < acdw> maybe I'll just define that somewhere
2023-08-18 15:40:35 -0400 < sham1> Fine. (define-constant nil '()) We can add this, and it'd be useful even outside of this
2023-08-18 15:40:37 -0400 < mnieper``> dpk: So you have psyntax, chez, unsyntax. And testing Guile and Loko also makes sense because of the additions they made in their code.
2023-08-18 15:41:24 -0400 < sham1> Because sometimes you want to have constants instead of identifier syntax transforms
2023-08-18 15:41:45 -0400 < mnieper``> Ah, and you have PLT Scheme's (historic) impl.
2023-08-18 15:42:43 -0400 < mnieper``> sham1: You mean you want to define a macro (define-constant nil x) => (define-syntax nil (identifier-syntax 'x))?
2023-08-18 15:42:55 -0400 < mnieper``> (or without the quote)
2023-08-18 15:43:40 -0400 < sham1> Well no, because consider a more complicated computation in a library for example. You might want to precompute something, and doing identifier-syntax would basically just copy-paste the computation code to every use site, no?
2023-08-18 15:44:56 -0400 < sham1> So for `(define-constant expensive-constant (expensive-computation))`, I wouldn't want every use of `expensive-constant` to be made into `(expensive-computation)`
2023-08-18 15:45:11 -0400 < sham1> Because it is, well, expensive
2023-08-18 15:45:52 -0400 < sham1> While the transformation into `(define-syntax expensive-constant (identifier-syntax (expensive-computation)))` would do that
2023-08-18 15:45:54 -0400 < mnieper``> sham1: Understood
2023-08-18 15:46:31 -0400 < dpk> then transform it into (define generated-identifier (expensive-constant)) (define-syntax expensive-constant (identifier-syntax generated-identifier))
2023-08-18 15:46:45 -0400 < mnieper``> I was just writing the macro for that. :)
2023-08-18 15:46:48 -0400 < dpk> and don’t export the generated identifier (which you won’t if it’s actually generated)
2023-08-18 15:48:26 -0400 < sham1> Hmm. That really only works with exported identifiers, which, fair enough. In that use case one could probably then just have a separate library for constants and export from there
2023-08-18 15:48:35 -0400 < mnieper``> Why?
2023-08-18 15:48:40 -0400 < mnieper``> hygiene?
2023-08-18 15:48:56 -0400 < mnieper``> s/second ?/!
2023-08-18 15:50:01 -0400 < sham1> Because if `(define generated-identifier (expensive-constant)) (define-syntax expensive-constant (identifier-syntax generated-identifier))` and I tried to do `(set! expensive-constant "Hello")` by mistake, it'd still get set, no?
2023-08-18 15:50:06 -0400 < sham1> Unless I'm missing something
2023-08-18 15:50:15 -0400 < sham1> If we're within the same library of course
2023-08-18 15:50:16 -0400 < mnieper``> dpk: When there is no competitive implementation of syntax-case that does only know fully unwrapped syntax objects, we may actually enforce the wrapping.
2023-08-18 15:50:42 -0400 < mnieper``> sham1: A macro (that I stopped writing after dpk's answer) will generate the code for you.
2023-08-18 15:50:58 -0400 < mnieper``> Including generated-identifier.
2023-08-18 15:51:23 -0400 < mnieper``> #'(begin (define tmp <expr>) (define-syntax <id> (identifier-syntax tmp)))
2023-08-18 15:52:02 -0400 < sham1> Well the macro wouldn't prevent `set!` if we're in the same library. Of course if I'm trying to `set!` it from a separate library or even the <program> then that's of course disallowed
2023-08-18 15:52:25 -0400 < dpk> mnieper``: this is what i mean by cleaning up identifier properties, fwiw. (needs a bit of a copy edit, but all this information is just missing from SRFI 213) https://usercontent.irccloud-cdn.com/file/OqkLsNfp/1692388305.JPG
2023-08-18 15:52:46 -0400 < mnieper``> sham1: You can't set! the tmp identifier.
2023-08-18 15:53:02 -0400 < sham1> Even if I set! <id>?
2023-08-18 15:53:07 -0400 < sham1> How does that work
2023-08-18 15:53:39 -0400 < mnieper``> Because the basic form of identifier-syntax disallows set!
2023-08-18 15:53:53 -0400 < sham1> OH! Well that's a crucial detail
2023-08-18 15:54:10 -0400 < mnieper``> And you can't do (set! tmp ...) because you have no hold of tmp outside the macro.
2023-08-18 15:54:24 -0400 < sham1> Well true, because it gets renamed for hygiene
2023-08-18 15:54:29 -0400 < mnieper``> identifier-syntax wouldn't know what to do with set!
2023-08-18 15:54:30 -0400 < sham1> I see!
2023-08-18 15:54:32 -0400 < dpk> (copy edit e.g.: i forgot to end a sentence that should end ‘without those definitions or redefinitions being visible in the original library’)
2023-08-18 15:54:32 -0400 < sham1> That's neat
2023-08-18 15:54:46 -0400 < mnieper``> You have to tell it explicitly.
2023-08-18 15:54:55 -0400 < mnieper``> It is in the base library of R6RS.
2023-08-18 15:56:03 -0400 < sham1> I just read the documentation in the Chez docs
2023-08-18 15:56:10 -0400 < sham1> Interesting
2023-08-18 15:57:55 -0400 < mnieper``> R6RS is a great programming language... ;)
2023-08-18 15:58:27 -0400 < aeth> May I suggest an R13RS that combines R6RS with R7RS?
2023-08-18 15:59:17 -0400 < mnieper``> dpk: I will have to read it in more detail later (which, unfortunately, means in two weeks).
2023-08-18 15:59:24 -0400 < sham1> But wouldn't that be 2R13R2S
2023-08-18 15:59:49 -0400 < aeth> you're right
2023-08-18 15:59:52 -0400 < sham1> Well not even that, because you couldn't just sum them up
2023-08-18 16:00:00 -0400 < sham1> The number is an exponent
2023-08-18 16:00:01 -0400 < aeth> ah, multiplication, then?
2023-08-18 16:00:19 -0400 < sham1> R^{13}R^2S^2
2023-08-18 16:00:38 -0400 < mnieper``> dpk: You speak once about "identifier binding". It probably makes sense to stick to this language.
2023-08-18 16:01:11 -0400 < aeth> let's represent the second R as R-prime, i.e. R'
2023-08-18 16:01:12 -0400 < mnieper``> Properties are associated to identifier bindings, not identifiers.  The same holds for keys.  
2023-08-18 16:01:30 -0400 < aeth> sham1: you want (R⁶R'S)(R⁷R'S)
2023-08-18 16:01:37 -0400 < sham1> Yes
2023-08-18 16:01:41 -0400 < mnieper``> This simplifies the semantics a lot.
2023-08-18 16:01:59 -0400 < aeth> sham1: i.e. R⁶(R⁷R'S)R'(R⁷R'S)S(R⁷R'S)
2023-08-18 16:02:02 -0400 < Zipheir> If the SC doesn't say anything, my first suggestion will be that we dump the "RnRS" naming scheme.
2023-08-18 16:02:49 -0400 < aeth> sham1: or (R¹³R'S)(R⁷(R')²S)(R⁷R'S²)
2023-08-18 16:02:55 -0400 < sham1> Yeah
2023-08-18 16:03:04 -0400 < mnieper``> I wouldn't go too much into detail about libraries yet until it is decided whether we will have local modules because then we have to use "import" and not "library" in the language of your text.
2023-08-18 16:03:19 -0400 < sham1> Zipheir: we'd then have to come up with another way to name the standard
2023-08-18 16:03:23 -0400 < sham1> Years?
2023-08-18 16:03:28 -0400 < sham1> Scheme 2025?
2023-08-18 16:03:40 -0400 < sham1> (Quite optimistic, but w/e)
2023-08-18 16:03:51 -0400 < Zipheir> That's the (slightly boring, IMO) way that many languages do it.
2023-08-18 16:04:15 -0400 < aeth> or you could do it the Debian way or the old Android way and name it after something
2023-08-18 16:04:29 -0400 < aeth> e.g. https://en.wikipedia.org/wiki/List_of_Ponzi_schemes
2023-08-18 16:04:52 -0400 < aeth> amusingly one of the code names you could use is "Van Rossem". https://en.wikipedia.org/wiki/Jean-Pierre_Van_Rossem
2023-08-18 16:04:54 -0400 < Zipheir> But this is the ultimate Scheme bikeshed. :)
2023-08-18 16:05:03 -0400 < aeth> (-em, not -um, but almost perfect)
2023-08-18 16:05:19 -0400 < mnieper``> dpk: I think it should be an error if two conflicting property lists have to be unioned.
2023-08-18 16:06:17 -0400 < sham1> Scheme 2032: Copious Coup
2023-08-18 16:06:30 -0400 < acdw> aeth, sham1: no, I think r42rs
2023-08-18 16:08:20 -0400 < cow_2001> Oh no.
2023-08-18 16:08:50 -0400 < mnieper``> If the name RnRS is dropped, the R6RS/R7RS split may be solved in a radical new way, namely by giving each of this dialect an independent new name.
2023-08-18 16:09:12 -0400 < aeth> I recommend the name "aeth"
2023-08-18 16:09:44 -0400 < dpk> if i become chair, i will rename Scheme to ‘Daphne’s Programming Language’
2023-08-18 16:09:58 -0400 < sham1> DPL for short I hope
2023-08-18 16:10:05 -0400 < mnieper``> :)
2023-08-18 16:10:10 -0400 < Zipheir> Daphlisp
2023-08-18 16:10:23 -0400 < Zipheir> Sure, follow linus's example. :)
2023-08-18 16:10:23 -0400 < mnieper``> I thought about "Mustard Scheme" and "Ketchup Scheme". 
2023-08-18 16:11:04 -0400 < aeth> dpk: seems like a very astronomy way to name things, e.g. https://en.wikipedia.org/wiki/Tabby%27s_Star
2023-08-18 16:11:51 -0400 < sham1> IIRC a lot of those astronomical objects were named by others in honour of people
2023-08-18 16:12:05 -0400 < aeth> right, even e.g. craters
2023-08-18 16:12:23 -0400 < aeth> usually gods/mythology or people
2023-08-18 16:13:12 -0400 < aeth> a more academic way to name Scheme would be to use acronyms, though
2023-08-18 16:13:18 -0400 < mnieper``> Didn't know this: https://de.wikipedia.org/wiki/(71445)_Marc
2023-08-18 16:13:22 -0400 < acdw> food names are underrated
2023-08-18 16:13:41 -0400 < acdw> bread scheme
2023-08-18 16:13:42 -0400 < mnieper``> Ah, you support my Mustard Scheme proposal?
2023-08-18 16:13:56 -0400 < acdw> hell yeah
2023-08-18 16:14:09 -0400 < acdw> BLT Scheme
2023-08-18 16:14:13 -0400 < Zipheir> Part of the community seems to have a problem with mustard.
2023-08-18 16:14:15 -0400 < gwatt> MUSTard scheme surely won't cause any consternation
2023-08-18 16:14:21 -0400 < sham1> Scheme: Explicitly not vegan-friendly
2023-08-18 16:14:23 -0400 < acdw> lol oops
2023-08-18 16:14:56 -0400 < acdw> reader macros for 🍞set! foo 5🍞
2023-08-18 16:15:11 -0400 < sham1> Well that's why you'd call R6RS the MUSTard Scheme
2023-08-18 16:16:20 -0400 < gwatt> acdw: There's already emojicode if you want that
2023-08-18 16:16:34 -0400 < sham1> Also those breads are unbalanced
2023-08-18 16:17:08 -0400 < mnieper``> And R7RS becomes UBubese Scheme
2023-08-18 16:17:27 -0400 < mnieper``> (does anyone know a better food beginning with the letters UB?)
2023-08-18 16:18:11 -0400 < sham1> Seafood Scheme
2023-08-18 16:18:16 -0400 < sham1> Spelt as C-food Scheme
2023-08-18 16:18:18 -0400 < aeth> let's go back to dpk's astronomy stuff, in a more literal sense
2023-08-18 16:18:22 -0400 < aeth> ☾define ☾1+ x☽ ☾+ 1 x☽☽
2023-08-18 16:18:30 -0400 < Zipheir> This is all getting very silly.
2023-08-18 16:18:32 -0400 < leah2> my eyes
2023-08-18 16:18:33 -0400 < aeth> Just supporting () and [] aren't enough
2023-08-18 16:18:51 -0400 < acdw> aeth: beautiful
2023-08-18 16:19:00 -0400 < sham1> Well you want to support the whole Unicode gamut so might as well
2023-08-18 16:19:15 -0400 < acdw> sham1: there isn't a left bread and right bread 😔
2023-08-18 16:19:20 -0400 < sham1> Indeed
2023-08-18 16:19:26 -0400 < gwatt> I guess bread just has to be self-closing
2023-08-18 16:19:39 -0400 < acdw> it can be quite characters
2023-08-18 16:19:51 -0400 < acdw> quote
2023-08-18 16:19:53 -0400 < aeth> how hard can it be to get left bread and right bread added to Unicode?
2023-08-18 16:20:00 -0400 < acdw> ezpz
2023-08-18 16:20:04 -0400 < sham1> Top bun, bottom bun
2023-08-18 16:20:10 -0400 < aeth> Maybe there's some character we can use to generate it for Emoji fonts without adding it to Unicode
2023-08-18 16:20:14 -0400 < gwatt> There's probably going to be a left shark emoji before left bread
2023-08-18 16:20:47 -0400 < acdw> speaking of quotes, let's do a lua and make [[ ... ]] strings. so you don't have to escape " inside
2023-08-18 16:21:11 -0400 < sham1> Those are also how you do multiline comments in Lua
2023-08-18 16:21:15 -0400 < aeth> or 🧵
2023-08-18 16:21:31 -0400 < aeth> if you are OK with treating it like "..." and don't need the start and end to differ
2023-08-18 16:21:46 -0400 < aeth> 🧵This should be a thread.🧵
2023-08-18 16:21:51 -0400 < gwatt> top bun bottom bun would lend itself well to calling an implementation "sandwich scheme" and then getting sillier from there
2023-08-18 16:21:53 -0400 < aeth> Whichi s like a string.
2023-08-18 16:22:03 -0400 < acdw> sandwich scheme sounds delicious
2023-08-18 16:22:18 -0400 < sham1> Sandwich crimes
2023-08-18 16:22:20 -0400 < acdw> omg aeth 
2023-08-18 16:22:28 -0400 < Zipheir> acdw: ⟦ and ⟧ are used to denote catamorphisms in a few historically important functional programming books.
2023-08-18 16:22:49 -0400 < sham1> Are those books people still read
2023-08-18 16:23:09 -0400 < Zipheir> *Some* people.
2023-08-18 16:23:49 -0400 < Zipheir> Which reminds me that felix wincklemann never did send me his (hated) copy of _The Algebra of Programming_...
2023-08-18 16:24:21 -0400 < acdw> idk what catamorphism is. is it like a dogomorphism
2023-08-18 16:24:29 -0400 < Zipheir> acdw: fold
2023-08-18 16:24:41 -0400 < acdw> if [[ is in the string just have another: [[[
2023-08-18 16:24:44 -0400 < sham1> But since we're doing silly suggestions: wisp syntax as an alternative to s-expressions
2023-08-18 16:24:50 -0400 < acdw> bah
2023-08-18 16:24:55 -0400 < acdw> Zipheir: oh neat
2023-08-18 16:25:14 -0400 < acdw> I don't like off side rule syntax tbh
2023-08-18 16:25:14 -0400 < dpk> Zipheir: i think we need some silliness after a difficult week for the community!
2023-08-18 16:25:36 -0400 < Zipheir> dpk: True.
2023-08-18 16:26:28 -0400 < gwatt> sham1: we're doing silly suggestions not blasphemous ones!
2023-08-18 16:27:19 -0400 < sham1> That's why I said "alternative". If I wanted to go proper blasphemy I'd say to just replace s-expressions
2023-08-18 16:27:56 -0400 < acdw> lmao
2023-08-18 16:28:14 -0400 < acdw> t-expressions!
2023-08-18 16:28:22 -0400 < Zipheir> There are definitely times when it would be nice to have infix syntax. But I wonder how it would work with expansion.
2023-08-18 16:28:37 -0400 < Zipheir> M-expressions are the classical alternative.
2023-08-18 16:28:46 -0400 < sham1> Maybe we could look at how Elixir turns infix into something you can macroise
2023-08-18 16:28:55 -0400 < Zipheir> But then you're just programming in dynamic ML :)
2023-08-18 16:29:25 -0400 < aeth> the way I'd personally do infix is #I(...)
2023-08-18 16:29:42 -0400 < aeth> you don't need the whole language infix, just the potentially nested arithmetic
2023-08-18 16:29:53 -0400 < aeth> #I(x + (y * z))
2023-08-18 16:30:44 -0400 < aeth> #I(x define 42)
2023-08-18 16:31:01 -0400 < Zipheir> aeth: Isn't that just a differint syntax for curly-infix expressions (SRFI 105)?
2023-08-18 16:31:03 -0400 < sham1> It'd be easiest if we ignored mathematical precedence rules, but the precedence rules are one of the points
2023-08-18 16:31:51 -0400 < aeth> Zipheir: recursive, though?
2023-08-18 16:32:09 -0400 < aeth> Zipheir: so, yes, you can implement that on top of SRFI 105
2023-08-18 16:32:27 -0400 < aeth> #I(x + (y * z)) => {x + {y * z}}
2023-08-18 16:32:58 -0400 < sham1> Poor sharp-sign namespace 
2023-08-18 16:33:18 -0400 < Zipheir> aeth: You're right. I don't think SRFI 105 is recursive.
2023-08-18 16:34:02 -0400 < aeth> to be fair, it creates a mess, e.g. extend my define... #I(1+ define (lambda (x) (+ 1 x))) ... oh wait no, it would be (1 + x) ... oh no wait the lambda would also change...
2023-08-18 16:34:24 -0400 < aeth> so it's not a general solution, it only works well specifically for arithmetic
2023-08-18 16:35:17 -0400 < aeth> although I guess you could mix it with [] for s-expressions (-:
2023-08-18 16:35:21 -0400 < Zipheir> Arithmetic is mostly where infix expressions are missed.
2023-08-18 16:36:07 -0400 < aeth> but, yes, the easiest thing to do would be to recursively turn every seen ( into a {, if the particular implementation works like that since it's character-based syntax (a reader macro of sorts?)
2023-08-18 16:37:27 -0400 < gwatt> #i is also used to do inexact numbers, so might not be the best for infix
2023-08-18 16:37:58 -0400 < acdw> I dont know I don't miss infiz
2023-08-18 16:38:04 -0400 < acdw> I also don't do the most math ever
2023-08-18 16:39:18 -0400 < gwatt> A problem with infix is that you then get into PEMDAS territory.
2023-08-18 16:40:40 -0400 < leah2> every school kid can do that
2023-08-18 16:40:52 -0400 < dpk> i find it interesting that americans learn a different order of expressions than we britons do
2023-08-18 16:41:06 -0400 < dpk> britons learn divisions before multiplications
2023-08-18 16:41:34 -0400 < gwatt> leah2: Yes, but many people forget it and just want to go left to right
2023-08-18 16:41:47 -0400 < aeth> gwatt: the problem with a one letter namespace is trying to find no conflicts
2023-08-18 16:41:58 -0400 < aeth> although at least Scheme is case-sensitive so... in theory...
2023-08-18 16:42:12 -0400 < dpk> which makes no difference in practice in school mathematics, because the ÷ sign is already gone in favour of whatever you call it when you write the dividend over the divisor with a horizontal line between
2023-08-18 16:42:19 -0400 < dpk> by the time you get to order of operations
2023-08-18 16:42:28 -0400 < gwatt> dpk: multiplication and division are technically the same priority, and in that case left to right wins
2023-08-18 16:42:34 -0400 < sham1> In Finland we're taught that multiplication and division come at the same time, left to right
2023-08-18 16:42:35 -0400 < gwatt> (at least in the states)
2023-08-18 16:42:36 -0400 < dpk> ah!
2023-08-18 16:42:46 -0400 < Zipheir> sham1: Ah, sanity.
2023-08-18 16:42:49 -0400 < dpk> they might have taught us that and i just forgot it, then :D
2023-08-18 16:43:04 -0400 < sham1> Of course you then get multiplication by juxtaposition and division with the fraction line
2023-08-18 16:43:19 -0400 < aeth> in practice, math is like programming and you're writing for people to read, so if "PEMDAS" (or the other 10 acronyms that exist just in different English-speaking countries alone) ever comes into play, then you've already lost
2023-08-18 16:43:31 -0400 < aeth> though the internet likes to argue about it
2023-08-18 16:43:42 -0400 < sham1> PE(DM)(AS)
2023-08-18 16:43:51 -0400 < Zipheir> aeth: If only some C programmers could remember that.
2023-08-18 16:43:53 -0400 < aeth> Unfortunately, programming language compilers/interpreters aren't quite as smart as people, so PEMDAS kind of comes back into play there
2023-08-18 16:44:31 -0400 < aeth> The correct solution would be to require significant whitespace between things (as Schemes and Lisps do, but other languages, even Python, almost always don't)
2023-08-18 16:44:35 -0400 < sham1> Meh, C's only problem with this is the precedence of bitwise OR in relation with bitwise AND
2023-08-18 16:44:36 -0400 < aeth> and to require some "extra" parentheses
2023-08-18 16:44:39 -0400 < acdw> brackets around everything 
2023-08-18 16:44:58 -0400 < aeth> extra parentheses that aren't strictly necessary are fine, even in infix. Infix just removes one layer (the outer layer) over s-expression prefix notation
2023-08-18 16:45:40 -0400 < aeth> If parentheses were that bad we'd all use fixed-length prefix/postfix that removes the need for parentheses (Scheme uses arbitrary-length so you do need the parentheses, but that's useful to have)
2023-08-18 16:45:47 -0400 < sham1> Err, the precedence of bitwise AND and OR in relation with ==
2023-08-18 16:45:49 -0400 < Zipheir> Precedence isn't too hard to fix. Haskell's fixity declarations are fairly simple: https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-800004.4
2023-08-18 16:46:32 -0400 < Zipheir> e.g. infixl 4 foo
2023-08-18 16:47:04 -0400 < sham1> Also makes parsing Haskell interesting because you can't fully form the parse tree until you've read all the fixity declarations
2023-08-18 16:47:07 -0400 < gwatt> ah right, and exponentiation is sometimes right-associative as opposed to other operators. Another wrinkle for infix
2023-08-18 16:47:18 -0400 < Zipheir> Alternatively, you can explicitly reject precedence rules and require unambiguous bracketing.
2023-08-18 16:47:28 -0400 < aeth> right
2023-08-18 16:47:29 -0400 < Zipheir> sham1: Yeah, it can be awful.
2023-08-18 16:47:59 -0400 < sham1> gwatt: It's because (a^b)^c = a^(b+b+b+b+...+b c times) = a^(bc)
2023-08-18 16:48:03 -0400 < aeth> usually, when I implement infix macros for s-expressions I: (1) require spacing between everything just like in s-expressions, (2) require everything to either be the same level or have parenthesis to break ambiguity
2023-08-18 16:48:09 -0400 < aeth> x+y => fail.
2023-08-18 16:48:14 -0400 < aeth> x + y * z => fail.
2023-08-18 16:48:26 -0400 < Zipheir> sham1: In general, Haskell's situation with cryptic infix operators may be an argument against user-defined precedence rules.
2023-08-18 16:48:28 -0400 < sham1> You really couldn't justify exponents being left-associative
2023-08-18 16:48:31 -0400 < aeth> x + (y * z) => no issues.
2023-08-18 16:48:45 -0400 < aeth> exponentiation might still have issues, and using - for negation and subtraction might still have issues
2023-08-18 17:05:10 -0400 < dpk> Zipheir: some languages (Io? Self? can’t remember) with vaguely Smalltalk-like message-passing syntax (so receiver methodname argument, only spaces between each token) rejected special-casing the precedence of methods which are mathematical operators in favour of whatever the default associativity rule is for message passing, and i think that’s generally felt to be a mistake
2023-08-18 17:09:29 -0400 < aeth> well, if x + y * z is parsed as (x + y) * z, yes, that's counter-intuitive to most people and probably the source of many bugs
2023-08-18 17:09:41 -0400 < aeth> although it's really the fault of the user :-p
2023-08-18 17:13:44 -0400 -!- ben_ is now known as cornett
2023-08-18 17:21:32 -0400 < dpk> the right thing would be to do something like Haskell’s fixity and allow it to be customized for all method names in the language
2023-08-18 17:23:04 -0400 < dpk> of course, because the meaning of a message name depends on the object it is passed to, which is only known at runtime, this can’t be done ‘hygienically’ as we say in Scheme
2023-08-18 18:44:04 -0400 < leah2> dpk: smalltalk, apl
2023-08-18 22:10:40 -0400 < mdhughes> Just switch to RPN everywhere. x y + * is unambiguous.
2023-08-18 22:11:15 -0400 < mdhughes> Why yes, I did learn with an HP calculator, and worked for HP.
2023-08-18 22:45:23 -0400 < acdw> how about reverse reverse polish notation
2023-08-18 22:47:35 -0400 < Zipheir> We've already got that.
2023-08-18 22:49:35 -0400 < mdhughes> Too many parens, tho. RPN or FPN would be more readable.
2023-08-18 22:51:57 -0400 < Zipheir> If you want Joy, you might know where to find it.
2023-08-18 22:52:42 -0400 < Zipheir> https://en.wikipedia.org/wiki/Joy_(programming_language)
2023-08-18 23:11:21 -0400 < mdhughes> I've written a few forth-likes, and HP-35/48 simulators.
2023-08-18 23:11:52 -0400 < mdhughes> forth programming yoda talk like me makes.
2023-08-18 23:25:36 -0400 < quidnunc> What's the difference between (call/cc (lambda (cc) cc)) and (call/cc (lambda (cc) (cc cc)))
2023-08-18 23:25:47 -0400 < quidnunc> ?
2023-08-18 23:27:32 -0400 < Zipheir> I don't think there's any difference.
2023-08-18 23:28:49 -0400 < Zipheir> Replace the value 'cc' with 4 and it won't look so odd.
2023-08-18 23:33:46 -0400 < Zipheir> Since the continuation of the call/cc expression is bound to 'cc', returning a value at the end of the lambda is precisely equivalent to calling 'cc' on it.
2023-08-18 23:34:46 -0400 < Zipheir> The funkiness of returning the continuation itself is misleading.
2023-08-18 23:35:08 -0400 < Zipheir> quidnunc: ^
2023-08-18 23:37:53 -0400 < quidnunc> Zipheir: It must be done for a reason? It seems to be a convention
2023-08-18 23:38:02 -0400 < quidnunc> https://matt.might.net/articles/programming-with-continuations--exceptions-backtracking-search-threads-generators-coroutines/
2023-08-18 23:38:03 -0400 < rudybot> https://teensy.info/kv9b0fJg1b
2023-08-18 23:38:06 -0400 < quidnunc> ^ Here for example
2023-08-18 23:40:16 -0400 < Zipheir> I don't know why Matt Might wrote it that way. Maybe someone else will have an idea.
2023-08-18 23:41:35 -0400 < Zipheir> It seems like the most obvious way to write current-continuation is (call/cc values).
2023-08-18 23:42:15 -0400 < Zipheir> Which is just a shorter version of (call/cc (lambda (cc) cc)).
2023-08-18 23:45:14 -0400 < quidnunc> Zipheir: okay, thanks
--- Day changed Sat Aug 19 2023
2023-08-19 00:48:47 -0400 < cow_2001> Which Scheme object oriented system is……… uh……… most……… uh……… standard(?)
2023-08-19 00:50:59 -0400 < Zipheir> cow_2001: Take a guess.
2023-08-19 00:51:59 -0400 < Zipheir> Actually, is there any portable Scheme Object system? I don't know of one.
2023-08-19 00:52:02 -0400 < cow_2001> The home grown ad hoc system I will be developing myself without even noticing if I keep on doing what I do.
2023-08-19 00:52:59 -0400 < Zipheir> Depending on what you want, R6RS's single-inheritance records might qualify.
2023-08-19 00:53:16 -0400 < Zipheir> So many different ideas are lumped into OOP.
2023-08-19 00:53:29 -0400 < cow_2001> Yeah.
2023-08-19 00:59:16 -0400 < cow_2001> Seems like GOOPS is a sorta CLOS.
2023-08-19 01:01:55 -0400 < aeth> records are OOP if C++ is OOP
2023-08-19 01:02:06 -0400 < aeth> (but a lot of people wouldn't count it)
2023-08-19 01:06:12 -0400 < Zipheir> I think the three basic ideas are inheritance (subtype polymorphism), data hiding (especially of local state), and overloading. All of those can be implemented without OOP, of course.
2023-08-19 01:07:26 -0400 < aeth> "data hiding" is a very C++/Java thing
2023-08-19 01:07:54 -0400 < aeth> many OOP systems don't hide it at all except by convention, and many others let you get it if you really want to
2023-08-19 01:08:05 -0400 < daviid> indeed, encapsulation is the very reason clos was invented, to fight it :)
2023-08-19 01:08:23 -0400 < aeth> the only true encapsulation in Common Lisp isn't from CLOS, but from lexical closures
2023-08-19 01:08:33 -0400 < aeth> the poor person's object system
2023-08-19 01:09:12 -0400 < aeth> But at least it has ways to *basically* be private (not exporting the symbol for the slot name from the package), while some dynamic languages don't even have any way to stop you.
2023-08-19 01:10:12 -0400 < Zipheir> Module systems are another way to hide data.
2023-08-19 01:11:00 -0400 < Zipheir> I think encapsulation is a great idea, at least in the abstract. I haven't had to understand someone else's Java codebase, though.
2023-08-19 01:12:55 -0400 < Zipheir> In fact, one of the founding papers (supposedly) of OOP, by Cardelli & Wegner, proposed first-class modules as the main way to encapsulate types and data.
2023-08-19 01:16:15 -0400 < cow_2001> Records of Lodos War
2023-08-19 01:17:24 -0400 < aeth> Well, Common Lisp's modules (packages) don't really do full encapsulation, either, because you can just :: instead of :
2023-08-19 01:18:00 -0400 < Zipheir> aeth: Are there no export lists?
2023-08-19 01:18:12 -0400 < Zipheir> Sorry, I haven't used CL in years.
2023-08-19 01:18:35 -0400 < aeth> foo::bar lets you use a non-exported symbol... and you can also explicitly import a symbol in a DEFPACKAGE that's not exported from its package iirc
2023-08-19 01:18:49 -0400 < Zipheir> Yuck.
2023-08-19 01:18:49 -0400 < aeth> this is what I mean by the only true encapsulation being from lexical closures
2023-08-19 01:19:34 -0400 < aeth> although if you do (slot-value foo some-package::%dont-use-this) then it's very clearly on you if something breaks
2023-08-19 01:19:48 -0400 < aeth> considering that's not at all how you should be using CLOS
2023-08-19 01:19:56 -0400 < cow_2001> Zipheir: When you said "guess", was the answer that there is no answer?
2023-08-19 01:20:23 -0400 < Zipheir> cow_2001: I was going to say "none of them", which is not the same as "no answer" or "mu".
2023-08-19 01:20:48 -0400 < aeth> hmm, sorry, it would probably be (slot-value foo 'some-package::%don't-use-this)
2023-08-19 01:21:07 -0400 < aeth> ugh, sorry, 'some-package::%dont-use-this
2023-08-19 01:21:14 -0400 < Zipheir> cow_2001: I just don't think there's a portable system.
2023-08-19 01:21:16 -0400 < aeth> the name would be enough protection, I think :-p
2023-08-19 01:21:30 -0400 < Zipheir> Most Object systems seem to be modeled on CLOS.
2023-08-19 01:21:30 -0400 < aeth> as for portable object systems, you can have one, but it won't be as useful as a non-portable one
2023-08-19 01:21:51 -0400 < aeth> you kind of want implementation support for this sort of thing
2023-08-19 01:21:55 -0400 < Zipheir> aeth: It sort of makes export lists pointless.
2023-08-19 01:22:11 -0400 < cow_2001> Zipheir: Hmm.  Hmmmmm... Are you sure they are not used the same way?  無 and none, that is.
2023-08-19 01:22:25 -0400 < aeth> Zipheir: a 1980s Lisp hacker would probably say that if they can't do :: then they might as well just modify the exposed parts of the compiler to let them do :: anyway
2023-08-19 01:22:36 -0400 < Zipheir> cow_2001: I don't know. I'm not a Zen master. :-p
2023-08-19 01:23:34 -0400 < aeth> The "you can't do what you want on your own machine" is not a very Lispy way of thinking, although Microsoft, Google, and Apple have all embraced this to varying extents as well as various programming languages.
2023-08-19 01:23:50 -0400 < aeth> The :: means you're doing something bad in the first place.
2023-08-19 01:23:57 -0400 < Zipheir> I suppose so.
2023-08-19 01:24:04 -0400 < aeth> And would likely fail any code review unless you had a good reason
2023-08-19 01:24:12 -0400 < Zipheir> unsafePerform::
2023-08-19 01:24:26 -0400 < aeth> The explicitly importing a symbol in a DEFPACKAGE that's not exported sounds like something that an implementation should at least warn/style-warn for, though
2023-08-19 01:24:32 -0400 < cow_2001> Is CL more or less equivalent to rnrs + srfis?
2023-08-19 01:24:39 -0400 < aeth> and maybe they do this now since it's a rare thing
2023-08-19 01:25:01 -0400 < Zipheir> cow_2001: You mean in size and features, or as a language? It has very different semantics from Scheme.
2023-08-19 01:25:02 -0400 < aeth> cow_2001: there was a CL equivalent to SRFIs called... CDRs maybe? but they never took off.
2023-08-19 01:25:04 -0400 < cow_2001> I don't know anything about CL, except that it looks spooky.
2023-08-19 01:25:17 -0400 < aeth> cow_2001: the CL equivalent to SRFI is probably https://portability.cl/
2023-08-19 01:25:19 -0400 < cow_2001> Zipheir: Features.
2023-08-19 01:25:27 -0400 < aeth> as in a bunch of portability libraries over implementation-internal features
2023-08-19 01:25:28 -0400 < cow_2001> Zipheir: And size, yes.
2023-08-19 01:25:41 -0400 < cow_2001> aeth: Hmm.
2023-08-19 01:25:45 -0400 < aeth> solely feature SRFIs like JSON wouldn't really make sense in the CL world instead of just being a library
2023-08-19 01:25:50 -0400 < aeth> i.e. srfi 180
2023-08-19 01:25:53 -0400 < Zipheir> cow_2001: If R7RS-large were to be finished as intended, it would be a lot bigger than CL.
2023-08-19 01:26:16 -0400 < Zipheir> cow_2001: But CL is definitely bigger than R6RS, the biggest extant Scheme standard.
2023-08-19 01:26:39 -0400 < Zipheir> CL was considered *huge* when it came out, but it's small by current standards.
2023-08-19 01:27:11 -0400 < aeth> CL + the portability libraries may still beat the scope of R7RS-large, e.g. one of the very key ones is CFFI, which Schemers will never agree on
2023-08-19 01:27:22 -0400 < aeth> It's not part of CL, but it might as well be
2023-08-19 01:27:26 -0400 < Zipheir> Right.
2023-08-19 01:29:14 -0400 < Zipheir> cow_2001: Threads, FFI, and CLOS are things that will probably never be standardized in Scheme.
2023-08-19 01:29:27 -0400 < aeth> The CL approach is a lot easier than the SRFI approach, though. Rather than specifying something and coming up with a reference implementation, it's taking something that exists in several implementations, turning it into a portable library, and encouraging other implementations to expose similar functionality through the simple pressure of encouraging other libraries to use these portability libraries (so 
2023-08-19 01:29:27 -0400 < Zipheir> (By CLOS I mean some kind of Object system.)
2023-08-19 01:29:33 -0400 < aeth> implementing CL alone is insufficient if none of the libraries actually run on it)
2023-08-19 01:29:53 -0400 < Zipheir> (And by threads I mean some kind of concurrent programming model.)
2023-08-19 01:30:18 -0400 < Zipheir> aeth: That describes SRFI 1 and some others.
2023-08-19 01:30:45 -0400 < aeth> Yes... while threads, FFI, and the meta-object protocol are the three biggest parts of the CL portability libraries, the secret de facto shadow standard that you can never call a standard because Common Lispers think that The HyperSpec is delivered from the gods and written in stone
2023-08-19 01:31:00 -0400 < aeth> The others aren't that important
2023-08-19 01:31:24 -0400 < aeth> Maybe UIOP's random stuff, mostly filesystem stuff, to get ASDF (the package manager) to work
2023-08-19 01:31:59 -0400 < aeth> On the other hand, a lot of interesting FP stuff will never come to CL at the core (and thus compiler-optimized) level because good-enough libraries can exist for it
2023-08-19 01:32:07 -0400 < aeth> even e.g. immutable lists
2023-08-19 01:32:17 -0400 < Zipheir> Hmm.
2023-08-19 01:34:25 -0400 < aeth> So in effect, the state of things in CL encourages most functional programmers to use Scheme/Racket/Clojure/etc. rather than CL, for the most part, anyway.
2023-08-19 01:34:30 -0400 < aeth> While CLOS isn't particularly FP
2023-08-19 01:35:10 -0400 < daviid> clos is as fp as scheme
2023-08-19 01:36:33 -0400 < Zipheir> Whatever FP means, exactly.
2023-08-19 01:38:17 -0400 < shawnw> I think it's more that nobody has the time or energy to try updating the Common Lisp standard. Especially if they remember the first time around in the 90's.
2023-08-19 01:38:37 -0400 < aeth> I think the lack of widespread support for extensible-sequences (i.e. generic sequences) and the performance overhead you'd get if you used such a thing anyway is what makes FP not really take off in CL
2023-08-19 01:38:53 -0400 < aeth> CL has generic sequences... but only for the two built-in ones, vector and list.
2023-08-19 01:39:45 -0400 < aeth> You could use custom sequences Scheme-style with a bunch of explicit type prefixes like immutable-list, immutable-cons, immutable-cdr, immutable-car, etc., but that's not very idiomatic in CL
2023-08-19 01:39:50 -0400 < Zipheir> Haskell doesn't have generic sequences, and that's one of the most committed FP languages in common use.
2023-08-19 01:40:18 -0400 < Zipheir> OK, it's got the indexable, traversable, foldable, etc. typeclasses.
2023-08-19 01:40:40 -0400 < aeth> well, if you wanted to fold on custom sequences, you'd have to write your own in CL
2023-08-19 01:40:59 -0400 < aeth> and you'd normally traverse with LOOP, which also wouldn't treat your sequence as first class
2023-08-19 01:41:30 -0400 < aeth> shawnw: Sadly, Scheme's probably going to go the same way as CL as far as standardization efforts go
2023-08-19 01:41:45 -0400 < Zipheir> Right. I think it's more about the idioms of CL, which I'd call "hybrid functional"--aggressively so.
2023-08-19 01:41:50 -0400 < aeth> 10 years ago, I would've thought there'd be a chance of an r8rs by now, or at least the chance of starting an r8rs by now
2023-08-19 01:42:26 -0400 < aeth> But with how long r7rs-large has taken, then if there's an r8rs-small, it'll just be a small "bugfix" of r7rs-small to make it more compatible with r7rs-large and to merge in the errata (unless new versions of the PDF already merge in the errata, idk)
2023-08-19 01:42:40 -0400 < aeth> at the very end of the r7rs-large effort and with no further changes anytime soon
2023-08-19 01:43:39 -0400 < aeth> Zipheir: What's interesting, though, is that Common Lisp is very heavily an expression language. Even more so than Scheme in places (since Scheme has that dreaded #<undefined> in a lot of places, making some expressions effectively statements instead)
2023-08-19 01:44:01 -0400 < aeth> Zipheir: So idiomatic modern Common Lisp isn't functional at all, but it still uses way less mutation than most languages because you can simply return a value from e.g. a COND
2023-08-19 01:44:34 -0400 < Zipheir> aeth: Yes, that's what I thought.
2023-08-19 01:46:32 -0400 < aeth> But between LOOP, SETF, and CLOS, I think Common Lisp usually mutates more than Scheme.
2023-08-19 01:46:44 -0400 < aeth> SETF is very convenient, as is LOOP
2023-08-19 01:46:46 -0400 < Zipheir> Some of the functional-oriented computer scientists of the late 80s (e.g. D. A. Turner) claimed that Lisp wasn't making much progress toward "true" applicative programming, because the core of the usual Lisp program was heavily imperative.
2023-08-19 01:47:27 -0400 < Zipheir> D. A. Turner went so far as to say that Lisp wasn't a functional language. (I can't remember where; Phil Wadler was arguing against him.)
2023-08-19 01:48:08 -0400 < aeth> "functional core, imperative shell" is a very FP/Haskell thing, while Common Lisp is definitely the opposite (imperative core, functional shell), e.g. everything expanding to a GO in a TAGBODY instead of to tail recursion like in Scheme (though you really, really, really have to try hard to find a place where this changes things when using e.g. DO)
2023-08-19 01:49:06 -0400 < aeth> and the core of a Common Lisp program's control flow is probably a LOOP, or maybe a DO/DOTIMES/DOLIST, while the core of a Scheme program might be a tail recursive loop
2023-08-19 01:49:14 -0400 < Zipheir> Yes.
2023-08-19 01:49:25 -0400 < aeth> where, again, that Common Lisp program is using gotos even if the programmer never sees them
2023-08-19 01:49:43 -0400 < Zipheir> Well, the same should be true for your Scheme tail-loop.
2023-08-19 01:50:21 -0400 < aeth> the distinction, though, is that the tail recursion's done by the compiler in Scheme
2023-08-19 01:50:33 -0400 < cow_2001> I will just read GOOPS like a normal person and see what's what.
2023-08-19 01:50:33 -0400 < aeth> while the GOTO stuff is done by the macroexapnder in Common Lisp
2023-08-19 01:51:29 -0400 < Zipheir> But I think Scheme demonstrated that you can express loops recursively and still have them executed efficiently.
2023-08-19 01:51:44 -0400 < Zipheir> Most languages haven't caught up.
2023-08-19 01:55:17 -0400 < cow_2001> I haven't had any sleep for too long and I don't feel real anymore, so it would have to wait until yet another terrible period of sleep.
2023-08-19 01:56:02 -0400 < Zipheir> That sounds unpleasant.
2023-08-19 01:59:42 -0400 < cow_2001> Taking care of a cat after an operation.
2023-08-19 02:00:24 -0400 < cow_2001> Ambiguous sentence.  Embrace the mystery!
2023-08-19 02:00:40 -0400 < Zipheir> Indeed.
2023-08-19 02:17:57 -0400 < shawnw> I've been implementing a bunch of CL looping constructs in Racket, using recursion and delimited continuations to handle return and return-from. Haven't gotten tagbodies and go working yet though.
2023-08-19 02:23:54 -0400 < aeth> Zipheir: I think the issue with recursion is usually claimed to be debugging
2023-08-19 02:25:16 -0400 < Zipheir> aeth: It would help if CS education were a little better and programmers were actually comfortable with recursion.
2023-08-19 02:26:03 -0400 < Zipheir> I mean, programmers outside of our oddball corner.
2023-08-19 02:28:35 -0400 < aeth> Scheme recursion is a bit different from "regular" recursion
2023-08-19 02:29:21 -0400 < aeth> A very specific type of optimized recursion (which you can easily mess up with some small changes that break the tail recursion)
2023-08-19 02:29:41 -0400 < aeth> I think most programmers would probably prefer a language where compilation failed entirely if somehow tail recursion wasn't present
2023-08-19 02:29:54 -0400 < Zipheir> That's a good point. "Tail position" is not very intuitive to newcomers.
2023-08-19 02:30:51 -0400 < Zipheir> I'd argue that this is why higher-order functions are important in functional programming. You can't (as easily) screw up the tail recursion in 'fold-left' or 'for-each'.
2023-08-19 02:30:54 -0400 < shawnw> Maybe a warning, but not failing. Non-tail recursion is sometimes useful. Often easier to write.
2023-08-19 02:31:17 -0400 < Zipheir> Of course.
2023-08-19 02:31:46 -0400 < aeth> warning and letting you do it anyway is still very Lispy... or C-like, too, actually.
2023-08-19 02:32:46 -0400 < Zipheir> You want to abstract these details, rather than hand-writing all these loops. "From a certain perspective, recursive equations are the assembly language of functional programming" --Jeremy Gibbons
2023-08-19 02:33:08 -0400 < lockywolf> What was the name of that book, designed as a "prequel to SICP"?
2023-08-19 02:34:36 -0400 < Franciman> hi, is there any tutorial about implementing a logic programming language in scheme?
2023-08-19 02:35:11 -0400 < Zipheir> Franciman: The Reasoned Schemer, or any of the related papers on miniKanren.
2023-08-19 02:35:29 -0400 < Zipheir> Franciman: SICP also has a chapter on it. The implementation is similar to miniKanren.
2023-08-19 02:36:25 -0400 < Franciman> Zipheir: thanks! As far as you know, does miniKanren use resolution internally?
2023-08-19 02:37:10 -0400 < Zipheir> Franciman: Here's the paper that got Kanren down to 40 lines. http://webyrd.net/scheme-2013/papers/HemannMuKanren2013.pdf
2023-08-19 02:37:18 -0400 < Zipheir> Franciman: Yes, of course.
2023-08-19 02:37:53 -0400 < Franciman> wow nice!
2023-08-19 02:37:53 -0400 < Zipheir> It implements resolution a bit differently than the Prologs I've looked at. It's done through list-monad-style stream processing.
2023-08-19 02:38:10 -0400 < Franciman> i am reading robinson's original paper on resolution. I find it a bit confusing
2023-08-19 02:38:31 -0400 < Franciman> so i wanted to compare with actual implementations 
2023-08-19 02:38:33 -0400 < Zipheir> Is it dense?
2023-08-19 02:38:46 -0400 < Franciman> hm it's more the unusual nomenclature
2023-08-19 02:39:02 -0400 < Franciman> today I'm giving it a try again
2023-08-19 02:39:10 -0400 < Zipheir> I also highly recommend Mike Spivey's book, which is $0. https://spivey.oriel.ox.ac.uk/wiki/files/logprog/logic.pdf
2023-08-19 02:39:53 -0400 < Zipheir> It has a very good presentation of SLD resolution.
2023-08-19 02:40:11 -0400 < Franciman> thhanks
2023-08-19 02:40:39 -0400 < Franciman> having a solid logic language is my first step towards having a logic language using linear logic
2023-08-19 02:41:10 -0400 < Zipheir> That would be cool.
2023-08-19 02:41:20 -0400 < Franciman> there are some papers i think you know them
2023-08-19 02:41:23 -0400 < Franciman> like andreoli's one
2023-08-19 02:41:39 -0400 < Franciman> https://www.cs.cmu.edu/~fp/courses/15816-s12/misc/andreoli92jlc.pdf
2023-08-19 02:43:09 -0400 < Zipheir> Looks good, and fairly readable. Thanks.
2023-08-19 02:44:42 -0400 < Franciman> honestly i'm a bit bewildered by logic programming
2023-08-19 02:44:52 -0400 < Franciman> sounds even more alien than functional programming to me
2023-08-19 02:44:58 -0400 < Franciman> but i won't give up
2023-08-19 02:45:15 -0400 < Zipheir> It's really beautiful, but it is aliean.
2023-08-19 02:45:18 -0400 < Zipheir> *alien
2023-08-19 02:46:24 -0400 < Zipheir> Franciman: Have you seen any of Will Byrd's talks on logic programming? His dissertation is also worth reading.
2023-08-19 02:47:02 -0400 < Franciman> yes
2023-08-19 02:47:47 -0400 < Zipheir> Great.
2023-08-19 02:58:33 -0400 < Franciman> sorry here i am, Zipheir i find it a bit confusing for now
2023-08-19 02:58:53 -0400 < Franciman> i am also reading Lloyd's Foundations of Logic Programming
2023-08-19 04:14:53 -0400 < dpk> hmm, the lexical scoping of identifier properties is quite weird
2023-08-19 04:16:14 -0400 < dpk> what i wrote in the spec i sent to Marc yesterday, that the properties on an identifier become effectively inaccessible if that identifier’s binding is shadowed, is only, like, 99% true
2023-08-19 04:17:58 -0400 < dpk> it’s still possible (i’m pretty sure) for a macro transformer within the shadowing lexical context to access the shadowed identifier properties (or the shadowed binding) if it somehow has hold of a reference to the identifier which was created outside of the shadowing scope
2023-08-19 04:18:27 -0400 < dpk> however, i don’t think any such way out of lexical scoping exists for identifier properties which shadow other identifier properties!
2023-08-19 04:24:36 -0400 < dpk> hmm, or maybe i’m just being silly
2023-08-19 04:25:22 -0400 < dpk> i think the same applies: you need a reference to the identifier which was created outside of the place where the shadowing property was created
2023-08-19 04:25:28 -0400  * dpk tests it in Chez
2023-08-19 04:28:22 -0400 < dpk> yes, duh
2023-08-19 05:49:28 -0400 -!- rgherdt_ is now known as rgherdt
2023-08-19 05:51:41 -0400 < mnieper> dpk: When identifiers are accessed through macros, the nearest lexical binding is used to look up properties.
2023-08-19 05:52:31 -0400 < mnieper> An identifier as a syntax object knows its nearest lexical binding.
2023-08-19 05:53:12 -0400 < dpk> yes, i was not sufficiently awake yet at 10am to know what i was talking about
2023-08-19 06:05:57 -0400 < dpk> mnieper: your PFN to SRFI 213 states ‘It is an error if two properties with the same key but that were defined by different expansions of the define-property definition would be merged.’ – i propose to replace this with saying it’s only an error if the values aren’t eqv? to one another
2023-08-19 06:06:10 -0400 < dpk> damn, he’s gone. good job he checks the logs
2023-08-19 07:59:11 -0400 < lockywolf> why don't unbound symbols evaluate to themselves?
2023-08-19 07:59:50 -0400 < LeoNerd> It'd be too easy for typoes to turn into silent unreported errors
2023-08-19 08:00:52 -0400 < LeoNerd> (e.g. compare with Perl's `use strict`, shell's `set -x` or even Visual Basic's `Option Explicit`)
2023-08-19 08:01:08 -0400 < lockywolf> not even close
2023-08-19 08:01:28 -0400 < lockywolf> set -x is very musleading
2023-08-19 08:02:25 -0400 < lockywolf> I don't remember how unbound variables behave in perl
2023-08-19 08:02:38 -0400 < lockywolf> in bash they are just empty
2023-08-19 08:03:00 -0400 < lockywolf> but evaluating to themselves makes sense
2023-08-19 08:03:57 -0400 < lockywolf> 1 + x is 2 if x==1, and can be left as a 1-argument function if x is unbound
2023-08-19 08:04:22 -0400 < mdhughes> They evaluate to themselves (as uppercase words) in REXX, which is fine for doing reporting where it's immediately obvious "I didn't set TOTAL", it's less fun in database type programs.
2023-08-19 08:05:38 -0400 < mdhughes> Same in JS, where the undefined value is "undefined". Frustrating when you're looking up database[fob] instead of [foo]
2023-08-19 08:22:07 -0400 < DKordic> lockywolf: Interesting.  Some examples?  
2023-08-19 08:33:17 -0400 < dpk> Marc Feeley has appeared to confirm that the R7RS process will continue in some form despite jcowan’s resignation
2023-08-19 08:34:10 -0400 < dpk> the steering committee has acknowledged and accepted his resignation, which is a relief
2023-08-19 08:37:52 -0400 < dpk> i’m going to take a long bath and not try to think too hard about the possibility that i might actually become responsible for fixing this mess
2023-08-19 08:39:05 -0400 < dpk> lockywolf: there was an informal proposal for the large language Foundations which would have allowed you to get what you want, based on a similar feature in Racket
2023-08-19 08:39:45 -0400 < dpk> an unbound identifier foo would have been replaced with something like (#%unbound . foo), and the #%unbound macro transformer would be able to decide what to do with it
2023-08-19 08:40:27 -0400 < dpk> i think that’s unlikely to make it in now, but if someone were to write a SRFI for it, it’ll probably have to be considered
2023-08-19 08:50:37 -0400 < jcowan> yeesh, what an explosion
2023-08-19 08:51:10 -0400 < jcowan> I've always thought we should reserve "X Scheme" for implementors and not mix up named versions with implementations
2023-08-19 08:51:35 -0400 < jcowan> I agree that MUSTard Scheme and Ketchup Scheme are funny, though I myself personally hate both of them
2023-08-19 08:51:43 -0400 < jcowan> (the foods, not their names)
2023-08-19 08:52:37 -0400 < jcowan> As I've said before, the good part of OOP is generic functions: classes are just a confusion
2023-08-19 08:53:46 -0400 < jcowan> That's separate from the question of whether OOP is good at all.  I think it is.  And the GF space has to be global in order to capture the whole idea of predicate subsumption (the predicate version of subclassing), which is not so bad because whether one predicate subsumes another is a global fact
2023-08-19 08:55:50 -0400 < jcowan> we have to declare subsumption because the compiler can't figure it out for arbitrary predicates; however, it *can* figure it out for record predicates, and that would give R6RS-equivalent records + GFs pretty much everything people want from CLOS
2023-08-19 08:56:02 -0400 < jcowan> where by GFs I mean predicate GFs
2023-08-19 08:59:56 -0400 < jcowan> Ceterum censeo integers in fixity declarations are gross, if you're going to have precedence numbers they need to be exact rationals (which we have already)
2023-08-19 09:00:23 -0400 < jcowan> thus allowing operators between + and * in precedence
2023-08-19 09:00:49 -0400 < jcowan> s;precedence;precedence/priority;g
2023-08-19 09:02:56 -0400 < jcowan> gmail gives me three options in response to Marc Feeley's note:  "Great!", "Many thanks", and "Sigh".  All three would be appropriate, so I'll have to write something myself
2023-08-19 09:03:43 -0400 < dpk> hehe
2023-08-19 09:09:59 -0400 < sham1> MUSTard Scheme would be a fun name for a strict R6RS or R7RS-large implementation
2023-08-19 09:10:24 -0400 < sham1> Reference some of the controversy
2023-08-19 09:27:34 -0400 < sham1> RE: fixing this mess: I'm sure that others also feel this way, but it bears saying that I don't think this mess is being caused consciously. Now of course basically no one is claiming that it's going on, but I would imagine that basically everyone in the process wants to have things work out properly 
2023-08-19 09:28:33 -0400 < jcowan> sham1: For some sense of "properly".  The problem is that we don't agree on what's proper, and what's more, we don't agree on how to resolve what's proper
2023-08-19 09:30:03 -0400 < jcowan> First we had the consensus method, which boiled down to "No change except at the margins".  Then we had a democratic process for R7-small, but for R7-large that broke down too in favor of the Sitzfleisch process we have right now
2023-08-19 09:30:34 -0400 < jcowan> This is not uncommon in standards committees
2023-08-19 09:31:51 -0400 < dpk> i think i know what you mean by Sitzfleisch process, but can you explain?
2023-08-19 09:32:07 -0400 < jcowan> whoever stays in their seat arguing long enough, wins
2023-08-19 09:32:15 -0400 < dpk> right, that’s what i thought
2023-08-19 12:19:44 -0400 < cow_2001> > <@falconstinker:matrix.org> I was reading about GOOPS.
2023-08-19 12:19:46 -0400 < cow_2001> "To start using GOOPS you first need to import the (oop goops) module."
2023-08-19 12:19:48 -0400 < cow_2001> oop goops hehehehehehehehehehehehe
2023-08-19 12:27:51 -0400 -!- mirai_ is now known as mirai
2023-08-19 12:55:30 -0400 < Zipheir> I wonder what else is in the (oop ...) namespace.
2023-08-19 13:02:55 -0400 < sham1> Probably not as much stuff as in ice-9
2023-08-19 13:57:58 -0400 < dpk> could we accommodate explicit renaming better by defining eqv? to be bound-identifier=? when both arguments are identifiers? (we can’t fix uses of eq? in er macros, but if a macro wants to run on both a native er implementation and one that sits on top of syntax-case, changing eq? to eqv? is a lot less precarious a change than changing it to an identifier=? procedure which would have to cond-expand in eqv? vs bound-identifier=? depending what 
2023-08-19 13:57:58 -0400 < dpk> implementation it thinks it’s on)
2023-08-19 13:59:41 -0400 < dpk> it’s not the most satisfactory solution in general, though, because two identifiers which are merely bound-identifier=? to each other are not in any sense replaceable by one another in the sense that two values that are eqv? usually are
2023-08-19 14:06:44 -0400 < Zipheir> That seems like a dubious extension of eqv?, since one operand can't be substituted for the other.
2023-08-19 14:06:54 -0400 < Zipheir> (In general.)
2023-08-19 14:12:34 -0400 < Zipheir> A shorter name than bound-identifier=? might be nice, though.
2023-08-19 14:20:35 -0400 < sham1> bound/id=?
2023-08-19 14:23:45 -0400 < Zipheir> Isn't / usually pronounced as "with" in Scheme?
2023-08-19 14:24:51 -0400 < dpk> … we could also hack the same functionality into symbol=? [extremely cringey face]
2023-08-19 14:26:23 -0400 < Zipheir> Something about the '=' symbol strikes me as a little misleading when we're checking whether identifiers collide.
2023-08-19 14:26:55 -0400 < Zipheir> But it's intuitively clear what it means.
2023-08-19 14:27:34 -0400 < Zipheir> Yeah, extending symbol=? would be even more confusing.
2023-08-19 14:27:57 -0400 < Zipheir> Some people still have a hard time keeping identifiers and symbols straight.
2023-08-19 14:30:14 -0400  * dpk sighs, writes ‘A small number of explicit renaming macros may require adjustment to work correctly under this version of ~er-macro-transformer~ …’ and a long explanation, and a promise to provide a robust implementation of identifier=? which cond-expands to the right form just as soon as we know how the libraries in the Foundations report are going to be organized
2023-08-19 14:47:20 -0400 < Zipheir> dpk: Are you and Marc adding ER to Batteries?
2023-08-19 14:48:02 -0400 < dpk> the syntax fascicle, as i’m currently planning it, will include a non-normative appendix showing how to get CL-style unhygienic macros, ER and IR macros back out of the syntax-case system
2023-08-19 14:48:25 -0400 < dpk> actually including explicit renaming in R7RS was rejected narrowly by Yellow Ballot voters (before Foundations/Batteries were split)
2023-08-19 14:50:41 -0400 < Zipheir> Yes, I remember that.
2023-08-19 14:52:50 -0400 < jcowan> I thought syncase and sc/er/ir were proven to be inwardly incompatible. Has that been refuted now?  (I know there is an er that sort of works on syncase, but then SRFI 78 is a syncase that sort of works on er.
2023-08-19 14:52:51 -0400 < jcowan> )
2023-08-19 14:54:15 -0400 < dpk> jcowan: they are compatible, but if you want explicit-renaming to compile in linear time you can’t also have syntax-case. it’s explained (not very well, imo) in SRFI 211. these implementations will have to unwrap the whole syntax tree, meaning quadratic time
2023-08-19 14:54:26 -0400 < dpk> in the case of ir-macro-transformer, this is actually no worse than any implementation had anyway
2023-08-19 14:54:38 -0400 < dpk> but er-macro-transformer users will have to just put up with potentially slow expansion
2023-08-19 14:54:48 -0400 < dpk> (hey, we have fast computers now, it’s probably not a big deal)
2023-08-19 14:55:25 -0400 < jcowan> That's what I think, esp. for something that happens at compile time, but if you implement a whole Cobol compiler in macrology, you may care more than I would
2023-08-19 14:58:55 -0400 < haugh> Is it possible to match the concept of "any literal" using one syntax-case clause?
2023-08-19 14:59:30 -0400 < dpk> i don’t think so
2023-08-19 14:59:34 -0400 < haugh> I think I understand why there's no `literal?', because that type information isn't available at expansion time?
2023-08-19 14:59:48 -0400 < dpk> well, it depends what you mean by literal
2023-08-19 15:00:07 -0400 < dpk> you can detect whether something is a self-evaluating datum like a boolean, number, or string at eval time
2023-08-19 15:00:36 -0400 < Zipheir> And then a pair/vector of literals is a literal?
2023-08-19 15:00:37 -0400 < dpk> you can’t, in the general case, find out if something that isn’t self-quoting is quoted
2023-08-19 15:00:58 -0400 < dpk> err, at expansion time (above)
2023-08-19 15:00:59 -0400 < haugh> I've got three syntax literals and I have one clause where any of them could appear in the same position
2023-08-19 15:01:05 -0400 < Zipheir> Er, (LIT1 . LIT2) and #(LIT0 ... LITN) are literals.
2023-08-19 15:01:35 -0400 < dpk> no, wait
2023-08-19 15:01:37 -0400 < Zipheir> No, sorry, only the #(...) is a literal.
2023-08-19 15:01:50 -0400 < dpk> you mean literal in the sense of literal identifier in the pattern matcher. SORRY
2023-08-19 15:01:58 -0400 < haugh> Yessir, I should have been more clear there
2023-08-19 15:02:10 -0400 < dpk> you can use a fender to do that!
2023-08-19 15:02:33 -0400 < haugh> Should I just memq a quoted list of the symbols?
2023-08-19 15:04:13 -0400 < dpk> memq won't work, but member will if it's the version that supports a custom predicate: ((_ maybe-literal rest-of-your-pattern …) (member #'maybe-literal (list #'literal-one #'literal-two #'literal-three) free-identifier=?) and-then-your-expansion-goes-here)
2023-08-19 15:04:39 -0400 < haugh> AHA, now I understand free-identifier=? !
2023-08-19 15:04:48 -0400 < haugh> excellent
2023-08-19 15:05:32 -0400  * dpk checks if R6RS’s member is the version with a custom compare procedure … nope, sigh
2023-08-19 15:05:42 -0400 < haugh> hehe
2023-08-19 15:06:41 -0400 < dpk> so that was a nice idea, but you can do the somewhat arduous (or (free-identifier=? #'maybe-literal #'literal-one) (free-identifier=? #’maybe-literal #'literal-two) etc)
2023-08-19 15:06:55 -0400 < haugh> yeah I have an or* macro for these :)
2023-08-19 15:07:57 -0400 < Zipheir> I'd like to do more syntax-case programming. Some of this is new to me.
2023-08-19 15:08:52 -0400 < jcowan> dpk: that's memp, which is called find-tail in SRFI 1.  Unfortunately (perhaps), R6RS's assp ("Are you an ass?") has no SRFI 1 equivalent.
2023-08-19 15:10:11 -0400 < jcowan> It troubles me that what you get out of syncase transformers is so vaguely defined: is the syntax object corresponding to (a b c) a wrapper around a list or a list containing three wrapped symbols (= identifiers)?
2023-08-19 15:10:26 -0400 < jcowan> Should/can this be pinned down?
2023-08-19 15:13:57 -0400 < cow_2001> Aaaaa.  As expected, a lot of reference documentation but very few code examples in the GOOPS section.
2023-08-19 15:21:55 -0400 < dpk> jcowan: R6RS pins this down very precisely. your example isn’t precisely specified enough to say which of the two it is ;-)
2023-08-19 15:23:08 -0400 < mnieper``> dpk: Don't change the semantics of eqv?
2023-08-19 15:23:37 -0400 < mnieper``> Because, as others said, it would make eqv? identifiers not equivalent (wrt free-identifier=?, for example).
2023-08-19 15:24:24 -0400 < mnieper``> Also, don't change symbol=? because it is part of its contract that it may enforce that its arguments are symbols.
2023-08-19 15:24:58 -0400 < mnieper``> A problem with an ER implementation on top of R6RS is also the rename procedure.
2023-08-19 15:25:27 -0400 < mnieper``> It is easy to shim it for the case of a symbol argument, but not in the case of an identifier argument.
2023-08-19 15:26:30 -0400 < dpk> jcowan: if (a b c) is a form from source code, it is fully wrapped. if (a b c) came out of the syntax special form, it’s unwrapped as far as the rightmost one in the list which was a pattern variable, beyond which it’s fully wrapped (according to my understanding of the spec, which i’m still in the middle of freshening up before it goes in the potential draft syntax fascicle). i think that handles the two cases you mean
2023-08-19 15:28:54 -0400 < jcowan> cow_2001: That tends to be (not always, but often) a symptom of over-engineering.  "This is how you use feature F.  *Why* you want to use feature F is left to your imagination."
2023-08-19 15:29:20 -0400 < cow_2001> jcowan: Siiiiighhhhhhhhhhh………
2023-08-19 15:29:37 -0400 < Zipheir> Good point.
2023-08-19 15:30:24 -0400 < cow_2001> I bet there are good reasons for it being there, but I want to read some example code benefiting from it, showing how to colloquially(?) use it.
2023-08-19 15:30:53 -0400 < Zipheir> Object systems usually have the standard not-so-useful example suite involving barking dogs, mooing cows, and "speak"ing "animal"s.
2023-08-19 15:31:07 -0400 < cow_2001> There is another word used instead of "colloquial".
2023-08-19 15:31:10 -0400 < sham1> port goes "read"
2023-08-19 15:31:39 -0400  * cow_2001 goes 無.
2023-08-19 15:32:55 -0400 < dpk> Zipheir: very useful if you’re programming a See 'n Say toy!
2023-08-19 15:32:57 -0400 < cow_2001> I've heard somewhere that GUI is where OOP shines.
2023-08-19 15:33:04 -0400 < Zipheir> "One day Zarathud took his students to a pleasant pasture and there he confronted the Sacred Chao while She was contently grazing. "Tell me, you dumb beast," demanded the Priest in his commanding voice, "why don't you do something worthwhile. What is your Purpose in life, anyway?" Munching the tasty grass, the Sacred Chao replied "MU". Upon hearing this, absolutely nobody was enlightened. Primarily 
2023-08-19 15:33:04 -0400 < Zipheir> because no one could understand Chinese."
2023-08-19 15:33:10 -0400 < cow_2001> dpk: I giggled.
2023-08-19 15:33:29 -0400 < cow_2001> Zipheir: Page 23?
2023-08-19 15:33:56 -0400 < sham1> The problem is that the kinds of examples you'd have to use to have meaningful examples would be way too complex
2023-08-19 15:34:28 -0400 < Zipheir> I don't remember. A friend of mine used his remaining college printing budget to print me a copy of the Principia Discordia right before he graduated. I don't know where it is at the moment, sadly.
2023-08-19 15:34:37 -0400 < cow_2001> No, that's another page.
2023-08-19 15:35:08 -0400 < cow_2001> Zipheir: You've actually had a samizdat Principia Discordia!
2023-08-19 15:35:49 -0400 < Zipheir> cow_2001: Yes, but I'm not sure it's actually samizdat if the book was released as "all rites reversed".
2023-08-19 15:35:51 -0400 < cow_2001> sham1: Yeah.  Need a repository of examples.
2023-08-19 15:37:58 -0400 < dpk> there are presumably books on practical uses of CLOS, which would not be too hard to adapt to GOOPS
2023-08-19 15:38:09 -0400 < dpk> mnie<tab><tab><tab>
2023-08-19 15:39:11 -0400 < dpk> mnieper (when he gets back): yes, see later in the logs where i gave in and adopted your solution. (i’m also trying to survey macros in Chibi and Chicken to see just how often eqv? is used for this)
2023-08-19 15:39:25 -0400 < dpk> mnieper: what are the semantics in explicit renaming when rename is called on an identifier?
2023-08-19 15:41:15 -0400 < sham1> Of course, one use for an OO system is to do the kind of dependency injection you might want to do, for example when you are trying to test an application which needs a database connection
2023-08-19 15:41:19 -0400 < sham1> You can mock out the database connection
2023-08-19 15:41:27 -0400 < dpk> it’s already promising that out of 164 files in the entire set of Chicken 5 eggs which use er-macro-transformer or ir-macro-transformer, only 21 of them mention eq?, eqv?, or symbol=? in the same file
2023-08-19 15:41:40 -0400 < haugh> cow_2001, I must have read the Guile and TSPL definitions of free-identifier=? a dozen times each, but I didn't really understand it until today, when I needed the functionality. If you see what I mean. 
2023-08-19 15:44:35 -0400 < haugh> I've always thought of OOP as a set of tools for very granular access control, which may be essential in repos managed by multiple teams. This is guaranteed to be naive since I've never worked on one of those teams.
2023-08-19 15:45:08 -0400 < haugh> I don't mean to be dramatic but I may prefer death
2023-08-19 15:46:09 -0400 < dpk> argh, bollocks, here’s a case i hadn’t considered: there’s an ir-macro-transformer here in one egg which uses symbol? to check if something is an identifier
2023-08-19 15:46:49 -0400 < dpk> that puts the potential number of files containing macros that won’t Just Work up to 63 out of 164
2023-08-19 15:48:22 -0400 < cow_2001> haugh: Hmm.
2023-08-19 15:48:50 -0400  * dpk takes vague comfort from the fact that such macros will not work in e.g. Chibi or MIT Scheme anyway, because there an identifier might be a syntactic closure
2023-08-19 15:49:15 -0400 < cow_2001> I've never gotten this whole OOP thing.
2023-08-19 15:49:36 -0400 < dpk> the thing about OOP is that it means something different to everyone
2023-08-19 15:50:06 -0400 < dpk> Jonathan Rees listed a bunch of such definitions here http://mumble.net/~jar/articles/oo.html
2023-08-19 15:50:28 -0400 < sham1> We could ask the person who came up with the noun phrase "object oriented programming"
2023-08-19 15:50:42 -0400 < Zipheir> Alan Kay, right?
2023-08-19 15:50:49 -0400 < sham1> Yes
2023-08-19 15:51:09 -0400 < sham1> > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.
2023-08-19 15:51:16 -0400 < dpk> he stated sometime, essentially, that what he meant was nr 6 in Rees’s list
2023-08-19 15:51:20 -0400 < Zipheir> I just remember him saying "I came up with OOP, and C++ wasn't what I had in mind" :)
2023-08-19 15:51:26 -0400 < cow_2001> Terrible terrible audio. https://youtu.be/IrmHp1rRQ68
2023-08-19 15:52:49 -0400 < cow_2001> Message passing like Erlang?
2023-08-19 15:52:53 -0400 < sham1> Still not as bad as the audio in "Erlang: The Movie"
2023-08-19 15:52:55 -0400 < dpk> Zipheir: i think it’s actually the same quote that continues something like: i wish i hadn’t called it OOP and had made it about message passing instead, because that’s the important concept
2023-08-19 15:52:55 -0400 < Zipheir> Those three things can entail a lot of others.
2023-08-19 15:53:12 -0400 < Zipheir> Right, "message passing" was the big thing for him.
2023-08-19 15:53:43 -0400 < Zipheir> But you can see message passing as a way of implementing overloaded procedures, among other things.
2023-08-19 15:53:52 -0400 < Zipheir> So these ideas are a bit fluid.
2023-08-19 15:55:15 -0400 < Zipheir> Hey, computation is a young discipline. We're still poking around in the dark.
2023-08-19 16:04:10 -0400 < dpk> of 21 files included in Chibi which mention er-macro-transformer (excluding meta-7.scm which is hardly relevant to a survey of userland code), only two of them appear to contain macros which use eq?/eqv? to mean bound-identifier=?. one of them is (chibi match), which has meta-macros literally called match-bound-identifier=? and match-bound-identifier-memv, and the other is init-7.scm’s implementations of cond-expand and syntax-rules
2023-08-19 16:05:52 -0400 < dpk> not a single one of init-7’s implementations of core Scheme forms does it, admittedly probably mostly because e.g. let relies on the underlying lambda in order to catch attempts to bind the same variable twice in one let
2023-08-19 16:11:46 -0400 < dpk> (of *other* core Scheme forms, i should say)
2023-08-19 16:15:01 -0400 < daviid> sham1: "The Common Lisp Object System is based on generic functions rather than on message-passing. This choice is made for two reasons: 1) there are some problems with message-passing in operations of more than one argument; 2) the concept of generic func- tions is a generalization of the concept of ordinary Lisp functions."
2023-08-19 16:15:36 -0400 < daviid> sham1: and "What the Common Lisp Object System Is Not: The Object System does not attempt to solve problems of encapsulation or protection. ..."
2023-08-19 16:15:59 -0400 < sham1> yes
2023-08-19 16:16:33 -0400 < sham1> I'd say that the generic functions & multimethods generalise the method passing
2023-08-19 16:16:40 -0400 < sham1> Err, message passing
2023-08-19 16:19:15 -0400 < daviid> sham1: well it's not :) - or everything is everything ... i just wanted to point to some reading - https://www.dreamsongs.com/Files/ECOOP.pdf
2023-08-19 16:23:51 -0400 < mnieper``> dpk: Re merging properties.
2023-08-19 16:24:29 -0400 < mnieper``> It would hide programming errors if properties with by-chance equal values are silently merged.
2023-08-19 16:25:16 -0400 < mnieper``> Moreover, the value is only known late (when the imported library is visited).
2023-08-19 16:25:27 -0400 < dpk> can you suggest a real-world case where that might happen?
2023-08-19 16:26:01 -0400 < dpk> i mean, if the values are eqv? i can’t see how they could be equal by chance
2023-08-19 16:26:25 -0400 < mnieper``> Two libraries may mean different things by the same value.
2023-08-19 16:26:44 -0400 < dpk> realistically it would have to be a symbol, character, number, boolean, or empty list
2023-08-19 16:26:59 -0400 < dpk> surely that’s already protected against by using bindings as the keys rather than anything else
2023-08-19 16:27:04 -0400 < mnieper``> The value is any value that can exist at expansion time.
2023-08-19 16:27:15 -0400 < mnieper``> It is calculated when a library is visited.
2023-08-19 16:27:34 -0400 < mnieper``> Often it is an identifier, but can also be a procedure or a port or whatever.
2023-08-19 16:28:57 -0400 < mnieper``> Stick to the semantics in SRFI 213, otherwise the compatibility of libraries can depend on on non-determinacy of their visit code.
2023-08-19 16:29:32 -0400 < mnieper``> dpk: Where later do you want to see me in the logs?
2023-08-19 16:30:11 -0400 < mnieper``> dpk: Third point (before I have to go offline again): (rename identifier) returns a fresh identifier but with the lexical context of identifier (and with the same name).
2023-08-19 16:30:29 -0400 < mnieper``> (In R6RS language: it attaches a fresh mark).
2023-08-19 16:31:02 -0400 < dpk> mnieper``: it’s not important, i just added in your identifier=? to my er-macro-transformer and gave up on the bad idea of trying to make other accommodations
2023-08-19 16:31:33 -0400 < daviid> and for those who interested "CLOS: Integrating Object-Oriented and Functional Programming" - https://www.dreamsongs.com/Files/clos-cacm.pdf
2023-08-19 16:31:50 -0400 < dpk> mnieper``: aha, i can do this with R4RS generate-identifier, i’m fairly sure (if i’ve understood what you’re saying correctly)
2023-08-19 16:34:09 -0400 < mnieper``> The result of generate-identifier has no lexical context.
2023-08-19 16:35:33 -0400 < dpk> in an admittedly inaccurate regular expression search over the Chicken eggs (i can only guess that people probably called their rename procedures ‘r’ or ‘rename’), then a look over the results, i find only one er macro which appears to be using this feature of rename. and even then i’m not sure
2023-08-19 16:37:32 -0400 < dpk> i’m also going to have to ask you to explain the problem with my eqv? proposal again at some point
2023-08-19 16:37:37 -0400 < dpk> because i don’t understand your explanation
2023-08-19 16:37:44 -0400 < dpk> but it’s about time for me to go, as well
2023-08-19 16:42:41 -0400 < aeth> In case anyone here missed it, https://news.ycombinator.com/item?id=37164243
2023-08-19 16:42:42 -0400 < aeth> https://news.ycombinator.com/item?id=37173231
2023-08-19 16:43:55 -0400 < dpk> bah, Per’s comment containing information that he made up out of thin air is still at the top
2023-08-19 16:44:16 -0400 < dpk> fake news, fake news
2023-08-19 16:44:49 -0400 < Zipheir> There's a funny comment from someone saying, in essence, "I don't want to start a flamewar, but, who actually cares about Scheme?"
2023-08-19 16:45:06 -0400 < dpk> yes, there’s always the ‘why does anyone care about this in $current-year??’ guy
2023-08-19 16:45:15 -0400 < dpk> i’m surprised he took so long to turn up this time
2023-08-19 16:45:30 -0400 < aeth> Zipheir: idk, by IRC channel activity, #scheme is incredibly popular
2023-08-19 16:45:40 -0400 < aeth> maybe even top 10
2023-08-19 16:45:53 -0400 < aeth> quick, add it to the weighting algorithm of TIOBE, which people take seriously in 2023 for some reason
2023-08-19 16:46:22 -0400 < dpk> i’m still not sure what to make of someone complementing me on my use of literary allusion and saying ‘This seems especially apt for a young person with ambitions to chair a committee for standardizing such an old language.’
2023-08-19 16:46:27 -0400 < aeth> ime, these "language popularity" things used to be more accurate when Google exposed more of its inner workings to the world, e.g. by giving an honest account of how many search results there were for a given query
2023-08-19 16:46:31 -0400 < Zipheir> aeth: You can't be serious. #scheme is probably more popular than it was 5 years ago, but #haskell and #lisp must be bigger.
2023-08-19 16:46:39 -0400 < Zipheir> Er, whatever the CL channel is now.
2023-08-19 16:46:47 -0400 < sham1> #common_lisp IIRC
2023-08-19 16:46:55 -0400 < aeth> #lisp and #commonlisp aren't that active at the moment
2023-08-19 16:46:57 -0400 < sham1> #commonlisp
2023-08-19 16:47:05 -0400 < aeth> because #commonlisp moved a lot of its activity to #lispcafe and #clschool
2023-08-19 16:47:12 -0400 < aeth> which gives the impression that Common Lisp isn't active anymore
2023-08-19 16:47:16 -0400 < Zipheir> Ah.
2023-08-19 16:47:19 -0400 < aeth> sometimes, strictly enforcing the topic can be a bad thing
2023-08-19 16:47:43 -0400 < aeth> strangely, #lispcafe is very much *on* topic so idk where to go for off-topic anymore
2023-08-19 16:47:44 -0400 < sham1> Yeah, #scheme doesn't really enforce the scheme-ness of the topic and it helps keep threads of chatting alive
2023-08-19 16:47:47 -0400 < dpk> nor the number of people commenting on my knowledge of church history
2023-08-19 16:48:24 -0400 < Dooshki> Heh, I remember this one guy who always kept looking down upon whatever I did and telling me "Imagine doing <xyz> in 2015"...  yeah, it's been a while since I've been around them :P
2023-08-19 16:49:03 -0400 < Dooshki> trends != progress
2023-08-19 16:49:06 -0400 < sham1> Imagine reminiscing about trolls in 2023
2023-08-19 16:49:13 -0400 < aeth> dpk: can you confirm or deny that "so it goes" is a Vonnegut reference?
2023-08-19 16:49:20 -0400 < dpk> oh, and also the guy claiming that nobody does compilation by converting to CPS, or uses tail calls or hygienic macros, or is interested in delimited control operators, therefore Scheme is irrelevant after all, QED
2023-08-19 16:49:29 -0400 < aeth> because, to me, I didn't use the phrase "so it goes" at all until I read Vonnegut in high school
2023-08-19 16:49:36 -0400 < aeth> but it's a good phrase
2023-08-19 16:49:40 -0400 < Zipheir> "Dude, why are you learning BlooP? That's so 2012." https://abstrusegoose.com/503
2023-08-19 16:50:17 -0400 < dpk> oooh, we eventually got someone making a parentheses joke as well! i’ve never seen one of those before!
2023-08-19 16:51:19 -0400 < dpk> i have actually never read anything by Vonnegut to my knowledge, so if it’s an allusion it’s one i picked up from someone without realizing where they got it from
2023-08-19 16:51:31 -0400 < dpk> s/to my knowledge/as far as i can recall/
2023-08-19 16:52:11 -0400 < aeth> https://en.wikipedia.org/wiki/Slaughterhouse-Five
2023-08-19 16:52:12 -0400 < dpk> anyway, one thing in both the HN thread and the one on lobsters, bizarrely, gives me hope
2023-08-19 16:52:23 -0400 < aeth> > Characteristically, Vonnegut makes heavy use of repetition, frequently using the phrase, "So it goes". He uses it as a refrain when events of death, dying, and mortality occur or are mentioned; as a narrative transition to another subject; as a memento mori; as comic relief; and to explain the unexplained. The phrase appears 106 times.[9]
2023-08-19 16:53:46 -0400 < dpk> a number of people who were apparently not Schemers were asking ‘why do you need to add all these weird language features? i see why you’d want a large standard library, but …’ and others were asking ‘why do you want to bother having such a big standard library? i see why you’d want some of those advanced core features, but …’
2023-08-19 16:54:20 -0400 < dpk> which implies to me that the Foundations/Batteries split is something that’s sort of instinctual in how people think about what they want from a programming language
2023-08-19 16:54:22 -0400 < Zipheir> Others propose switching to the single-implementation-de-facto-standard model, which is flat out impossible.
2023-08-19 16:54:47 -0400 < aeth> right, it's flat out impossible because I never got around to finishing Airship Scheme
2023-08-19 16:54:56 -0400 < dpk> but: even if so, programming languages exist and successfully serve their communities
2023-08-19 16:55:01 -0400 < dpk> so R7RS can also find its community
2023-08-19 16:55:03 -0400 < Zipheir> Unless Guy Steele descends from on high and blesses his favorite implementation.
2023-08-19 16:55:20 -0400 < Dooshki> As someone who's mostly an outsider, R7RS-small is very useful to me!
2023-08-19 16:55:25 -0400 < Dooshki> (re: serving a community)
2023-08-19 16:55:44 -0400 < dpk> Zipheir: more likely, if RnRS Scheme were to die out, that would happen de facto by Racket becoming the single implementation that’s a de facto standard
2023-08-19 16:55:49 -0400 < Zipheir> Dooshki: That's good to hear.
2023-08-19 16:55:59 -0400 < sham1> dpk: or guile
2023-08-19 16:56:13 -0400 < Zipheir> Actually, there might be a Guile/Racket split, then.
2023-08-19 16:56:22 -0400 < sham1> GNU has a lot of weight behind it, after all
2023-08-19 16:56:30 -0400 < aeth> well, R7RS already accomplished a lot in that there's http://snow-fort.org/
2023-08-19 16:56:35 -0400 < aeth> in 2010, portable Scheme was a joke
2023-08-19 16:56:49 -0400 < aeth> some comments in HN are still in that mindset
2023-08-19 16:57:33 -0400 < Dooshki> Yeah, I'll admit that I've learned of Scheme via GNU and Guix back in 2015 or so, but didn't really have much of an intereste in it back than, other than knowing that it exists and that there's Guile
2023-08-19 16:57:36 -0400 < Zipheir> sham1: GNU's weight comes from all that spaghetti code. :)
2023-08-19 16:58:05 -0400 < Dooshki> And yeah, after getting interested again and looking at the API...  I decided to look for better options :P
2023-08-19 16:58:15 -0400 < sham1> Zipheir: I mean, you're not wrong...
2023-08-19 17:01:02 -0400 < Dooshki> GNU, and following the GNU Programming Style document (I was a bit invested in them back then), has somewhat ironically made me fall in love with the KISS principle as I was like, "why do we have to do things this way?  Why can't things be simple, beautiful and elegant?"
2023-08-19 17:01:46 -0400 < Dooshki> Embracing hacks and bloat doesn't sound like a great strategy for a software ecosystem
2023-08-19 17:02:53 -0400 < dpk> a couple of comments on Reddit too, nothing too insightful (doom and gloom in /r/lisp, mockery in a circlejerk subreddit, nothing elsewhere) https://groups.google.com/g/scheme-reports-wg2/c/xGd0_eeKmGI/m/q-xM5fbuAQAJ https://www.reddit.com/search/?q=url%3Ahttp%3A%2F%2Fdpk.io%2Fr7rswtf&type=link
2023-08-19 17:02:54 -0400 < Dooshki> *healthy software ecosystem
2023-08-19 17:03:16 -0400 < dpk> and on John’s original letter, just some comments saying thanks, Scheme is good in /r/lisp, then thanks, Scheme is bad is /r/scheme https://www.reddit.com/search/?q=url%3Ahttps%3A%2F%2Fgroups.google.com%2Fg%2Fscheme-reports-wg2%2Fc%2FxGd0_eeKmGI%2Fm%2Fq-xM5fbuAQAJ
2023-08-19 17:03:17 -0400 < rudybot> https://teensy.info/3o0bqfMbRd
2023-08-19 17:03:23 -0400 < dpk> a normal day on Reddit
2023-08-19 17:03:34 -0400 < Zipheir> dpk: Thanks for the aggregation. :)
2023-08-19 17:05:43 -0400 < aeth> oh, yeah, Reddit comments have been dead for a while
2023-08-19 17:05:50 -0400 < dpk> the mockery remind me, what language features did Scheme originate, beyond the four i listed?
2023-08-19 17:06:03 -0400 < aeth> Reddit comment quality being down so much is why HN comments aren't as good as they were even last year... that seems to be where the programming people went
2023-08-19 17:06:19 -0400 < aeth> some Reddit-tier comments in the threads, mostly the first one, not the second
2023-08-19 17:06:28 -0400 < dpk> ‘lexical scope in a dynamic language’ feels somewhat unfair considering ML had worked this out earlier
2023-08-19 17:07:17 -0400 < sham1> Well ML isn't dynamic ofc
2023-08-19 17:09:14 -0400 < dpk> it has first-class functions with upwards and downwards funargs, which is the thing that was actually considered tricky (although, did it already have those in 1973? that i’m not sure about)
2023-08-19 17:20:27 -0400 < aeth> hmm, the r/lisp reddit comments weren't that low quality... archived the old.reddit.com version so they're still readable when Reddit closes down old reddit (and thus effectively closes itself down)
2023-08-19 17:20:40 -0400 < aeth> (i.e. forced a crawl on archive.org)
2023-08-19 17:27:02 -0400 < haugh> By far my least favorite thing about Scheme is arguing about it with people who don't use Scheme.
2023-08-19 17:27:38 -0400 < aeth> haugh: but have you considered using the most popular modern descendent of Scheme? By that I mean JavaScript, of course.
2023-08-19 17:29:44 -0400 < sham1> Augh
2023-08-19 17:30:48 -0400 < haugh> I have no professional response to this
2023-08-19 17:31:21 -0400 < Dooshki> JavaScript is a descendant of Scheme?
2023-08-19 17:31:53 -0400 < haugh> I suspect the sick perverted joke may be that anything based on eval is a scheme descendant
2023-08-19 17:32:37 -0400 < sham1> Brendan Eich, the person who created JavaScript for Netscape famously in 14 days, was influenced by Scheme
2023-08-19 17:33:53 -0400 < haugh> TIL
2023-08-19 17:34:51 -0400 < aeth> JavaScript was supposed to be a Scheme dialect
2023-08-19 17:34:59 -0400 < aeth> but the suits at Netscape told him to make it look like Java
2023-08-19 17:35:14 -0400 < aeth> at which point it is definitely no longer a Scheme, but some people (who have never used Scheme?) still call it one
2023-08-19 17:35:27 -0400 < dpk> indeed, he originally wanted to put Scheme itself in the browser, allegedly, but Netscape higher-ups thought it wouldn’t fly and wanted something that looked like C and where they could ask Sun if they could jump on the Java marketing bandwagon, also allowing Sun to jump on the world wide web marketing bandwagon
2023-08-19 17:35:32 -0400 < dpk> aeth is faster at typing than i am
2023-08-19 17:35:33 -0400 < aeth> lacks the syntax, lacks the linked lists, lacks the macros, etc., etc.
2023-08-19 17:36:05 -0400 < haugh> Wow.
2023-08-19 17:36:16 -0400 < dpk> it’s actually only the better known of the two times we nearly got Scheme in the browser, the other one being DSSSL Lite. instead of that one, we got CSS, which if anything is the more galling one of the two
2023-08-19 17:36:17 -0400 < haugh> That is... the worst thing I've learned this week.
2023-08-19 17:36:35 -0400 < aeth> Also, CSS replaces DSSSL. https://en.wikipedia.org/wiki/Document_Style_Semantics_and_Specification_Language
2023-08-19 17:36:40 -0400 < aeth> this time, dpk beat me
2023-08-19 17:36:48 -0400 < aeth> so, yes, we could have had 2/3 of the web being Scheme, but instead 0/3 are
2023-08-19 17:37:20 -0400 < aeth> and Lisps are still probably the best language for handling XML/SGML/HTML in
2023-08-19 17:37:59 -0400 < haugh> SXML completely changed my perspective on XML
2023-08-19 17:38:18 -0400 < dpk> the main issue was that DSSSL (a) didn’t conform to TimBL’s (very bad) idea of the ‘principle of least power’, which was a no-go for a project originated inside the W3C instead of at one of the browser makers (who have never since about 1992 really cared what TimBL has to say)
2023-08-19 17:38:34 -0400 < dpk> and (b) is too oriented for an output medium divided into pages
2023-08-19 17:39:13 -0400 < dpk> in reality, it would have been close to a full redesign of DSSSL to adopt something like it on the web
2023-08-19 17:39:38 -0400 < aeth> by 90s web browser makers, so it almost certainly would have ruined Scheme
2023-08-19 17:39:55 -0400 < aeth> just like the web is now a mess
2023-08-19 17:44:34 -0400 < cow_2001> wasm now replaces most of javascript, and soon Guile'll be in the browser!
2023-08-19 17:47:46 -0400 < sham1> I doubt that wasm can replace JS
2023-08-19 17:49:17 -0400 < sham1> Anyway, Brendan Eich is an odd person in more ways than just creating JS. He's the mind behind the Brave browser, which got created after he was thrown out of Mozilla for his… interesting viewa
2023-08-19 17:49:20 -0400 < sham1> Views 
2023-08-19 17:50:11 -0400 < dpk> Brave also the browser which blocks ads while showing you them
2023-08-19 17:51:34 -0400 < sham1> It also does some odd cryptocurrency stuff
2023-08-19 17:52:18 -0400 < aeth> I thank them for doing that because it makes it easy to never consider using Brave
2023-08-19 17:52:46 -0400 < dpk> tbf, browsers still have no business model than ‘please Mr Google, can we have some money when people use our browser to search?’
2023-08-19 17:53:21 -0400 < aeth> And then Google's going to kill half of the browsers by DRMing the web.
2023-08-19 17:53:25 -0400 < dpk> which is not great in an age when Google itself has a browser with such ridiculous market share
2023-08-19 17:53:58 -0400 < dpk> every time that contract’s up for renewal with Mozilla, they turn the thumbscrews a bit tighter
2023-08-19 17:54:52 -0400 < dpk> just staying short of a situation where a court would rule they deliberately killed a competitor using monopolistic practices
2023-08-19 17:55:30 -0400 < sham1> Then again, a browser needing a business model is already absurd on the face of it. A browser is supposed to be a document viewer but the web has gone way past that. I don't think this was what Sir Tim Berners-Lee had in mind when working in CERN
2023-08-19 17:55:50 -0400 < dpk> sham1: gotta pay the developers somehow
2023-08-19 17:56:17 -0400 < dpk> (Mozilla is a non-profit, so ‘business model’ is perhaps the wrong term)
2023-08-19 17:56:42 -0400 < sham1> Sure. Developers need to be paid, but the web is quite complex 
2023-08-19 17:56:59 -0400 < sham1> And I don't think it needs to be that
2023-08-19 17:58:58 -0400 < aeth> browsers should just be tied to appropriate software suites
2023-08-19 17:59:13 -0400 < aeth> like when Gnome and KDE had their own browsers... KDE's eventually serving as the basis for Safari and Chrome
2023-08-19 17:59:35 -0400 < aeth> KDE still has its own PDF reader, etc.
2023-08-19 17:59:59 -0400 < sham1> Yeah. The lineage from KHTML to WebKit to eventually Blink
2023-08-19 18:01:15 -0400 < sham1> And most browsers nowadays are Blink. Really the only rebels in this sense are Firefox and Safari, but even Safari in some sense helps Google's hegemony since unlike gecko, WebKit is of course the direct descendant of Blink 
2023-08-19 18:01:33 -0400 < sham1> Err, ancestor
2023-08-19 18:02:32 -0400 < aeth> It's just not a good situation all the way around. The only thing stopping everything from being Chrome or a reskinned Chromium is Apple's iOS policy to not allow any other real web browser on its platform, which is intended to encourage native apps over web apps so it can take a 30% monopolist rentseeking tax on everything
2023-08-19 18:02:37 -0400 < aeth> So it's just monopolist vs monopolist
2023-08-19 18:03:39 -0400 < aeth> Or, OK, quite a lot of the big tech monopolies are actually duopolies. Sort of like a lot of the time (but not all of the time) you can choose between two bad broadband monopolist ISPs in the US (the phone company and the cable company) instead of just one.
2023-08-19 18:40:39 -0400 < dpk> great, now the internet commenters are sending me email
2023-08-19 18:41:25 -0400 < dpk> aeth: someone is asking why we don’t use Common Lisp as a platform to create the reference implementation of R7RS Large
2023-08-19 18:42:47 -0400 < aeth> dpk: the problem is just how portable do you want to be
2023-08-19 18:43:00 -0400 < aeth> you don't even get tail recursion for free in CL even though most implementations give you it
2023-08-19 22:04:06 -0400 < acdw> we'll use the lisp to build the lisp
--- Day changed Sun Aug 20 2023
2023-08-20 01:55:08 -0400 < sham1> Well you could always do the thing that Kawa does on the JVM when you insist on it to use real tail calls (at the cost of performance), you just make it use a driver loop
2023-08-20 01:55:51 -0400 < sham1> Compile into CPS except that in this case every "call" actually returns a thunk that will actually perform the call
2023-08-20 01:56:26 -0400 < aeth> yes, I did go with thunks
2023-08-20 04:06:58 -0400 < mdhughes> > Additional background would be nice. I clicked the link out of curiosity to see what it meant for a piece of furniture to resign from something. After clicking the link, I was no better informed.
2023-08-20 04:07:15 -0400 < mdhughes> Yes, that's the h4xx0r n00z reaction I was looking for.
2023-08-20 04:23:32 -0400 < dpk> so, i’ve spent quite a lot of time on Scheme this week, and am pretty sure that if we were to apply the 40h/month (≈ 10h/week) guideline i’ve suggested committing myself to as chair, i’ve already long blown through 10 hours this week. i need to spend the coming week polishing up my Lithuanian and probably writing a short paper on speech errors (not a topic an historical linguist usually deals with, it was part of my grounding in broader 
2023-08-20 04:23:32 -0400 < dpk> linguistics this semester)
2023-08-20 04:26:08 -0400 < dpk> i’ve noticed that even while the idea that we’re going to focus on polishing up the syntax expansion spec for the next while is still only provisional on the assumption the SC broadly accepts my plan, already this approach has drawn attention away from arguments which were spiralling out of control and into calm focus on the actual issues: cleaning up identifier properties, accommodating er macros, etc.
2023-08-20 04:26:35 -0400 < dpk> i hope my focussing on something else for a while doesn’t cause the situation to go nuts again
2023-08-20 04:26:50 -0400 < dpk> (i’ll still be here to talk about Scheme, ofc)
2023-08-20 04:40:04 -0400 < aeth> mdhughes: Reddit chased a bunch of users away a few months ago so Reddit comments are leaking everywhere
2023-08-20 04:41:35 -0400 < aeth> they're probably going to do it another 3 or so times because the IPO is still coming up
2023-08-20 04:43:48 -0400 < mdhughes> No, this has been going on for a decade+, there's a reason I block news.yc… in /etc/hosts (I had to read it with !wayback) and miss n-gate so much.
2023-08-20 04:44:46 -0400 < mdhughes> 2016-2021 RIP http://n-gate.com/hackernews/2016/
2023-08-20 04:45:37 -0400 < aeth> all of these sites/communities generally either get quieter or lower quality over time
2023-08-20 04:46:40 -0400 < mdhughes> Not slashdot, it started terrible and it's still terrible! It's maybe quieter since "nobody goes there anymore".
2023-08-20 04:47:10 -0400 < mdhughes> What was the /. that doesn't suck? Kuroshin with some dumb digits? I liked it for a year or so.
2023-08-20 04:48:44 -0400 < aeth> doesn't ring a bell
2023-08-20 04:50:49 -0400 < mdhughes> https://en.wikipedia.org/wiki/Kuro5hin
2023-08-20 04:55:03 -0400 < aeth> hmm... https://web.archive.org/web/20050822090244/http://www.kuro5hin.org/
2023-08-20 04:55:12 -0400 < aeth> nice early web 2.0 site design
2023-08-20 04:56:10 -0400 < aeth> tiny font and no maximum width (because why would everyone switch to widescreens?), but it definitely feels like a lot was lost from that era
2023-08-20 04:58:05 -0400 < aeth> I guess the comments were threaded so it technically counts. https://web.archive.org/web/20051212044042/http://www.kuro5hin.org/story/2005/8/15/65325/3931
2023-08-20 04:58:43 -0400 < aeth> heh, and it was from the days before Google SEO encouraged people to put the title of the article in the name of the URL
2023-08-20 04:59:03 -0400 < sham1> I like how this looks
2023-08-20 04:59:21 -0400 < aeth> the threaded comments don't look particularly well done, though
2023-08-20 05:00:49 -0400 < aeth> looks like everything beyond the top level was a separate link, which didn't get archived so only the titles are kept
2023-08-20 05:15:34 -0400 < lockywolf> what is a "name of the URL"?
2023-08-20 05:19:45 -0400 < flatwhatson> they're talking about sluggification
2023-08-20 05:29:44 -0400 < aeth> my bad
2023-08-20 05:29:51 -0400 < aeth> the title/name of the article in the URL
2023-08-20 05:30:48 -0400 < aeth> example.com/story/2005/8/15/65325/now-heres-a-completely-unnecessary-part-that-you-can-often-just-remove
2023-08-20 05:41:12 -0400 < sham1> TBF, I do like having at least an abbreviated title in the URI
2023-08-20 05:41:21 -0400 < sham1> Lets me know what I'm clicking
2023-08-20 07:49:41 -0400 < jcowan> sham1: That's how the Rabbit compiler worked; compile Scheme into Maclisp with a driver loop.
2023-08-20 07:53:40 -0400 < mnieper> dpk: What do want to clean up for identifier properties (ignoring the wording for the moment)?
2023-08-20 07:53:41 -0400 < jcowan> and I agree about sluggification
2023-08-20 07:55:09 -0400 < mnieper> And I would like to add that we have been discussing a lot of concrete stuff all the time on the issue tracker while John was chair.
2023-08-20 07:55:46 -0400 < jcowan> I have been asked if I am interested in a paid gig editing the forthcoming Rust "standard"
2023-08-20 07:56:23 -0400 < jcowan> I use horror quotes because it will actually be an English-language description of what rustc does, rather than a spec for Rust compilers in general
2023-08-20 07:56:47 -0400 < jcowan> I said yes (of course), so we'll see what happens
2023-08-20 07:58:44 -0400 < mnieper> jcowan: Great, that great news. 
2023-08-20 07:58:58 -0400 < jcowan> If it amounts to anything
2023-08-20 07:59:49 -0400 < mnieper> We need alternative implementations of Rust and without a standard it is hard for other vendors to compete.
2023-08-20 08:00:28 -0400 < sham1> Yes we do. But Rust, like most other "modern" languages, do the whole "the specification is just what the reference implementation does"
2023-08-20 08:00:46 -0400 < sham1> TBF that also happened with C back in the day
2023-08-20 08:00:50 -0400 < jcowan> Exactly; the only difference is that they will write down what rustc does
2023-08-20 08:01:12 -0400 < jcowan> but it is intended for new rustc maintainers
2023-08-20 08:01:56 -0400 < dpk> jcowan: who would be paying you (if you can say)? Mozilla?
2023-08-20 08:01:58 -0400 < jcowan> so the spec will be of the form "Rust will" rather than "Rust compilers must"
2023-08-20 08:02:06 -0400 < jcowan> The Rust Foundation, I suppose
2023-08-20 08:02:20 -0400 < dpk> oh, that’s a separate thing from Mozilla now? interesting
2023-08-20 08:02:21 -0400 < dpk> nice!
2023-08-20 08:02:32 -0400 < dpk> i wish you the best. don’t forget about us Schemers ;-)
2023-08-20 08:02:37 -0400 < jcowan> I will never forget you
2023-08-20 08:03:02 -0400 < jcowan> unless I get Alzheimer's
2023-08-20 08:03:33 -0400 < sham1> You could always put in a sneaky "Rust MUST optimise tail calls"
2023-08-20 08:03:35 -0400 < sham1> ;)
2023-08-20 08:03:54 -0400 < dpk> sometimes i think you’re even gloomier about your health than my father, although you’re 12 years younger than he is
2023-08-20 08:04:22 -0400 < sham1> Anyway, on completely unrelated news, my build has gotten stuck somehow
2023-08-20 08:05:33 -0400 < sham1> Oh it just went though
2023-08-20 08:05:50 -0400 < dpk> mnieper: the problem with SRFI 213 is that there was nothing in the spec language which suggested that an implementation such as the one i made for Chibi, where properties were attached to bindings in the sense of free-identifier=?, was wrong, because SRFI 213 lacks any operational description at all beyond a pile of examples
2023-08-20 08:06:24 -0400 < dpk> that’s why the spec language (now basically finished in my local draft) which i sent you recently
2023-08-20 08:09:21 -0400 < dpk> and, fwiw, you might be about to win another argument ;-) since i have looked again at the problem with ambiguous scopes in the sets-of-scopes models and concluded the model does not satisfy the two hygiene conditions set out by R[4-6]RS and R7RS small. i want to ask Matthew Flatt and the Racket people in general if they’ve made any progress into resolving this problem, but if not (and i expect not), we will have to go back to finding a way 
2023-08-20 08:09:22 -0400 < dpk> to formulate a description of the marks and substitutions algorithm which doesn’t rankle the people who thought it was too complicated in R6RS
2023-08-20 08:24:59 -0400 < dpk> an operational semantics of marks and subsitutions, comparable to the operational semantics of sets of scopes in the ‘Model’ chapter of Flatt’s paper, might be one way to do that
2023-08-20 08:52:53 -0400 < jcowan> dpk: the reference to old-timers disease was intended as black humor, not seriously
2023-08-20 08:56:23 -0400 < mdhughes> Will the Rust spec specify how many times a day a Rustacean must tell someone else to use Rust instead of C, or is that undefined behavior?
2023-08-20 09:03:09 -0400 < jcowan> The rustc compiler is innocent
2023-08-20 09:23:38 -0400 < jcowan> I just sent a response to Feeley at all, strongly recommending dpk as my successor:  Money quote:  "I believe she has the energy, focus, and strength of will to carry at least the Foundations part of R7RS-large through to completion in a reasonable time."
2023-08-20 09:23:50 -0400 < jcowan> s/at all/et al/ (curious sort of typo)
2023-08-20 09:28:57 -0400 < lockywolf> I like that part
2023-08-20 09:30:50 -0400 < dpk> thank you, i am honoured, and hope your trust in my having the qualities needed for the task turns out to be well-founded!
2023-08-20 09:32:53 -0400 < dpk> and also, setting aside what is mentioned above about the possibility of working on Rust, i would like to pass on a paraphrase of another part of jcowan’s recommendation mail: if anyone in this channel knows any opportunities for gainful employment (remote or in New York City) which might suit our illustrious former chair, he would be very grateful to hear about them
2023-08-20 09:33:20 -0400 < jcowan> I am very flexible, as a poor man should be
2023-08-20 09:33:48 -0400 < jcowan> should or must, wevs.  MUSTard, but not preposterous.
2023-08-20 09:39:36 -0400 < lockywolf> hehe, my company is hiring :) c++ programmers and physicists
2023-08-20 09:40:07 -0400 < lockywolf> we're pretty far from NYC though
2023-08-20 12:43:10 -0400 < Zipheir> aeth: Google should have encouraged people to learn about RDF instead. That "title in the URL" business has made for some ridiculous URLS.
2023-08-20 13:07:21 -0400 < Zipheir> jcowan: I hope you get the Rust thing.
2023-08-20 13:08:04 -0400 < jcowan> lockywolf: How about remote work?
2023-08-20 14:13:38 -0400 < Franciman> Zipheir: please RDF? :O
2023-08-20 14:13:44 -0400 < Franciman> what next, OWL 2 ?
2023-08-20 14:15:56 -0400 < dpk> Google does use RDFa if you want to use it, iirc. it’s one of the ways it can populate individual search results with extra information
2023-08-20 14:16:20 -0400 < Franciman> do you like OWL 2?
2023-08-20 14:16:57 -0400 < dpk> i don’t know about OWL 2, nor indeed that much about OWL in general. a friend of mine did her PhD thesis on it
2023-08-20 14:17:24 -0400 < Franciman> oh nice
2023-08-20 14:38:09 -0400 < Zipheir> That's the first I've heard of OWL.
2023-08-20 14:38:28 -0400 < Zipheir> It's a good name, though.
2023-08-20 15:54:56 -0400 -!- cedb is now known as yeet
2023-08-20 15:55:01 -0400 -!- yeet is now known as cedb
2023-08-20 15:58:22 -0400 < jcowan> I'm an OWL fan
2023-08-20 15:59:11 -0400 < jcowan> likewise of the Protege OWL editor and of Gist, a simple upper ontology
2023-08-20 16:08:38 -0400 < aeth> Zipheir: Title in the URL usually leads to three different titles for any given article: the URL one that never changes, the <title> one that should always update but somehow gets stale anyway, and then the heading title that's usually the thing that people sees and that always, always changes several times for some reason.
2023-08-20 16:08:52 -0400 < aeth> Although it is kind of cool to see what the original title was, via the URL
2023-08-20 16:25:09 -0400 < klovett> if the gist i'm thinking of it has the virtue of consulting use over some years & slimmed by the rigor ;-)
2023-08-20 16:27:49 -0400 < Zipheir> aeth: Yes. That's another reason why Google's advice is silly.
2023-08-20 16:34:43 -0400 < jcowan> I think it's a Good Thing for humans that the emojipedia URL for CHAIR is https://emojipedia.com/chair and not https://emojipedia.com/b9d2f221-2e4e-4a2e-a7cc-1e172ea1dbe0 or even https://emojipedia.com/1fa91.
2023-08-20 16:43:18 -0400 < sham1> I honestly thought that those were real links at first
2023-08-20 16:44:15 -0400 < dpk> one of them is
2023-08-20 16:45:25 -0400 < sham1> Yeah
2023-08-20 16:48:11 -0400 < jcowan> ditto with https://github.com/johnwcowan/r7rs-work/blob/master/CommitteeBDockets.md
2023-08-20 16:48:25 -0400 < jcowan> That is systematic and I can reconstruct it by hand
2023-08-20 16:49:07 -0400 < sham1> I'm actually writing a pre-SRFI for a low-level process management thing and I like to be able to name the file accordingly
2023-08-20 16:57:25 -0400 < Zipheir> Descriptive URLs are good, but page titles change.
2023-08-20 16:59:15 -0400 < Zipheir> If ephemeral (or maybe even legally dubious--think of tabloid headlines) content goes into the URL, then the URL will end up confusing people and robots. Or, more likely, it will end up dead.
2023-08-20 16:59:46 -0400 < Zipheir> ("We changed the title, so, for SEO reasons, we moved the page. Sorry.")
2023-08-20 17:04:23 -0400 < Zipheir> sham1: Do you have a draft yet?
2023-08-20 17:09:31 -0400 < sham1> I'm typing it up
2023-08-20 17:11:30 -0400 < Zipheir> Cool.
2023-08-20 17:14:25 -0400 < sham1> I'm debating whether the actual "spawn" procedure should have a `!` or not
2023-08-20 17:15:09 -0400 < sham1> Most other procedures that affect stuff outside of the current Scheme environment such as `display` and such don't have one, but I'm wondering whether this one should
2023-08-20 17:16:31 -0400 < sham1> Like it'll also return a meaningful value, that being the process handler, but in some sense it's quite side-effecty
2023-08-20 17:20:54 -0400 < Zipheir> If it returns a meaningful value, I'd avoid the !.
2023-08-20 17:21:18 -0400 < sham1> Hm, fair
2023-08-20 17:21:25 -0400 < Zipheir> Many Scheme things without the bang have side-effects, but none of the ! forms return "real" values.
2023-08-20 17:21:33 -0400 < Zipheir> AFAIR
2023-08-20 17:24:59 -0400 < Zipheir> sham1: You might want to take a look at the names in SRFI 170, if only for ideas. https://srfi.schemers.org/srfi-170/srfi-170.html
2023-08-20 17:26:00 -0400 < sham1> Well I think you'll probably like what I've cooked up
2023-08-20 17:31:42 -0400 < sham1> <https://codeberg.org/sham1/pre-srfi/src/branch/main/low-level-process-manipulation.md>
2023-08-20 17:32:32 -0400 < sham1> And as the name suggests, this is a low-level interface on purpose to allow for better things to be built on-top of it, although I did try to make it at least somewhat ergonomic
2023-08-20 17:36:23 -0400 < X-Scale> this concept of process is aligned with the idea of a UNIX process, or it's a more abstract kind of process ?
2023-08-20 17:38:28 -0400 < Zipheir> sham1: Great. I'll read it shortly.
2023-08-20 17:43:36 -0400 < sham1> I tried to make it abstract enough to at least work on more traditional OSes so both UNIX and Windows stuff. Couldn't probably use this for Erlang processes although that would probably already be a stretch
2023-08-20 17:44:05 -0400 < sham1> And any Scheme on such an environment would be probably using bespoke interfaces for this stuff anyway
2023-08-20 17:44:37 -0400 < sham1> So this also wouldn't work on the web either, although I don't know if that was really expected
2023-08-20 17:47:56 -0400 < Zipheir> sham1: What do you mean process-data being a "functional" type?
2023-08-20 17:48:19 -0400 < sham1> I suppose immutable would have been a better word for it
2023-08-20 17:48:25 -0400 < Zipheir> OK.
2023-08-20 17:48:50 -0400 < sham1> But if you look at the way process-data is used, you don't actually mutate it, you just get new copies
2023-08-20 17:49:01 -0400 < sham1> With the appropriate changes
2023-08-20 17:49:31 -0400 < Zipheir> Right.
2023-08-20 17:52:16 -0400 < Zipheir> I think I prefer something like update-process-data-name over process-data-with-program-name (etc.). There's a slight ambiguity in the current names.
2023-08-20 17:52:46 -0400 < Zipheir> ("Process some data with this program name"; not that that makes much sense.)
2023-08-20 17:53:44 -0400 < sham1> It follows the common practice of putting the relevant type name at the head of the procedure name 
2023-08-20 17:53:48 -0400 < Zipheir> The accessor should just be process-data-name, IMO.
2023-08-20 17:53:56 -0400 < sham1> True
2023-08-20 17:54:21 -0400 < Zipheir> process-data-set-program-name, maybe
2023-08-20 17:55:05 -0400 < Zipheir> s/set/update/
2023-08-20 17:59:12 -0400 < Zipheir> At the risk of more complexity, you could have another opaque type executable-identifier which generalizes paths and names.
2023-08-20 17:59:35 -0400 < Zipheir> Re: the TODO in process-data-create.
2023-08-20 19:31:40 -0400 < lockywolf> jcowan: l'll ask my boss, but "remote only" is unlikely. The boss wants to be good friends with provincial government, and they need "highly skilled migrant workers". It might be part-time on-site, though, I guess. say, 6 months shifts
2023-08-20 20:58:40 -0400 < aeth> jcowan: but wait... SRFIs don't have descriptive names, e.g. https://srfi.schemers.org/srfi-180/
2023-08-20 20:58:49 -0400 < aeth> instead of srfi-180-json or something
2023-08-20 21:00:08 -0400 < aeth> probably a legacy of the SRFI site itself being from the '00s era we're talking about, e.g. https://web.archive.org/web/20000310232526/http://srfi.schemers.org/final-srfis.html
2023-08-20 21:00:13 -0400 < aeth> Although it has had a few redesigns since then
2023-08-20 21:00:48 -0400 < aeth> however http://srfi.schemers.org/final-srfis.html still works as a URL, correctly redirecting to https://srfi.schemers.org/?statuses=final
2023-08-20 21:00:58 -0400 < aeth> so points for that, whoever runs the site
2023-08-20 21:01:24 -0400 < aeth> 23.5 years of archived URLs and the old links still work
2023-08-20 21:02:09 -0400 < Zipheir> "Cool URIs don't change", as Tim Berners-Lee says.
2023-08-20 21:16:25 -0400 < aeth> The problem is that there's a lot of bad legacy, such as .htm (because Windows couldn't handle .html at the time)
2023-08-20 21:17:05 -0400 < aeth> Or, worse, stuff like .aspx or .php that are probably lying because the site probably migrated twice since then, but the old extension is kept for compatibility
2023-08-20 21:59:06 -0400 < jcowan> I think the SRFI numbers reflect the RFC numbers
--- Day changed Mon Aug 21 2023
2023-08-21 02:35:00 -0400 < mdhughes> Zipheir: sham1: A lot of ! procedures like in SRFI-1 return an updated value, but also mutate the original. (set! ls (reverse! ls)) or you'll have a bad day!
2023-08-21 02:35:26 -0400 < mdhughes> Not every ! function follows that protocol, tho, many mutate and don't return anything.
2023-08-21 03:13:48 -0400 < lockywolf> us it a good practice to both mutate a value, and return it?
2023-08-21 03:14:09 -0400 < lockywolf> I am more used to functions that either mutate, or return.
2023-08-21 03:14:40 -0400 < lockywolf> although sometimes I see functions which mutate, but return true or false, depending on whether mutation succeeded or failed
2023-08-21 03:21:09 -0400 < mdhughes> I prefer to do pure functions without mutating, except things that entirely mutate state, and then they might return newvalue/#f. But there's no clear rule.
2023-08-21 03:33:09 -0400 < sham1> Well with the SRFI 1 operations, the `!` of course signifies that they *can* be destructive but that they don't need to be, which is why they return the value
2023-08-21 03:33:55 -0400 < sham1> Whereas I'm not sure if process spawning qualifies for `!` as far as Scheme is concerned. After all, display also doesn't have `!` even though it's side-effectful
2023-08-21 03:45:38 -0400 < dpk> hey, what do you know, i was just talking with jcowan about things like this last night, trying to get an overview (which i previously completely lacked) of what needs to go in the Environments report
2023-08-21 03:46:06 -0400 < dpk> (although i don’t expect to start serious work on that until around 2025)
2023-08-21 03:46:43 -0400 < dpk> http://dpk.io/temp/ENVIRONMENTS
2023-08-21 03:47:25 -0400 < dpk> if anyone can think of anything else the Environments would need, do chime in
2023-08-21 03:47:28 -0400 < mdhughes> I probably wouldn't mark file or thread functions !, because that's the side-effect, not internal state.
2023-08-21 03:48:08 -0400 < mdhughes> dpk: Don't "boo" bidirectional files. That's an essential tool, we use rw mode files in C all the time.
2023-08-21 03:49:58 -0400 < mdhughes> SRFI-181 is in the list, that's good.
2023-08-21 03:57:13 -0400 < dpk> mdhughes: can you make a concrete case for when opening files read-write is needed compared to two independent read and write ports?
2023-08-21 03:57:34 -0400 < mdhughes> Databases, obviously.
2023-08-21 03:57:51 -0400 < mdhughes> How would having two read/write ports synchronize?
2023-08-21 03:59:25 -0400 < dpk> what do you mean by ‘synchronize’?
2023-08-21 03:59:37 -0400 < mdhughes> Normally when you write a byte-layout database, you seek to some point, read what's there, write over it. If your ports are anything but a thin FFI over C functions, you'll have to copy position and buffers between them.
2023-08-21 03:59:54 -0400 < dpk> hmm, i see
2023-08-21 04:01:48 -0400 < dpk> well, fine. in practice it’ll be hard to make the case to drop R6RS I/O features, probably, for various reasons, although it depends on a few decisions we need to make for the Foundations
2023-08-21 04:03:12 -0400 < dpk> and, as i say, according to my rough plans, this part of Large will probably be started in 2025 at the earliest, and finished 2026 at the very earliest depending on what the ultimate scope is
2023-08-21 04:14:57 -0400 < sham1> I have some reservations about the FFI idea
2023-08-21 04:17:01 -0400 < mdhughes> FFI would have to be optional, since some Schemes aren't on C, some have very different working environments than C.
2023-08-21 04:17:18 -0400 < sham1> The problem is that you really can't have a general FFI without it being overly general to the point of uselessness.
2023-08-21 04:17:29 -0400 < mdhughes> But "if you can FFI, do it like this" would be nice
2023-08-21 04:17:49 -0400 < sham1> And yeah, a C FFI wouldn't work for Kawa for example. Or a Web based Scheme
2023-08-21 04:18:41 -0400 < sham1> A lot of the FFI library would have to be implementation-specific anyway
2023-08-21 04:19:24 -0400 < dpk> mdhughes: even most Schemes which aren’t on C should have some way of accessing libraries written with the C ABI. the two big ones: the JVM has one, the CLR has one
2023-08-21 04:19:40 -0400 < mdhughes> Javascript won't.
2023-08-21 04:19:55 -0400 < dpk> sure it will, if you’ve compiled the library to WASM
2023-08-21 04:20:00 -0400 < aeth> yeah, WASM
2023-08-21 04:20:09 -0400 < dpk> in any case, yes it would be optional
2023-08-21 04:20:24 -0400 < aeth> and in more extreme environments, there's probably a way to compile C to that
2023-08-21 04:20:29 -0400 < aeth> probably, not certainly
2023-08-21 04:20:30 -0400 < mdhughes> Python probably could, but it'd be going thru 2 layers which I think is improbable. It'd mess up the Python objects unless you knew you were doing a FFI-Python-C transition.
2023-08-21 04:20:57 -0400 < mdhughes> WASM isn't very C-like. You won't be calling POSIX etc. from it.
2023-08-21 04:21:44 -0400 < dpk> i’m not concerned at all about platforms like Python where it’s very unlikely someone will implement the large language on top of them
2023-08-21 04:22:30 -0400 < dpk> if Guido comes out tomorrow with a ‘Python Virtual Machine’ platform explicitly advertised as supposed to be a good basis for implementing other languages, then i’ll start thinking about Python ;-)
2023-08-21 04:23:12 -0400 < msavoritias> you can use posix from webasm with wasi https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-overview.md
2023-08-21 04:26:37 -0400 < jcowan> This is the can of worms I didn't want to open: keeping FFI out of the standard keeps the can closed
2023-08-21 04:26:50 -0400 < sham1> Agreed
2023-08-21 04:27:18 -0400 < sham1> I feel that a non-normative appendix would probably be better
2023-08-21 04:28:08 -0400 < sham1> And then you could create libraries that can cover up the differences at least for some implementations
2023-08-21 04:28:21 -0400 < msavoritias> (im not proposing to add wasi/wasm as ffi btw. I dont care much for FFI)
2023-08-21 04:28:53 -0400 < sham1> For a point of comparison, this is how CL does it, with CFFI being but a wrapper library around each implementation's native FFI
2023-08-21 04:29:10 -0400 < sham1> For the CLs that don't compile against the JVM, that is
2023-08-21 04:29:15 -0400 < sham1> For example 
2023-08-21 04:39:17 -0400 < aeth> someone is writing a Scheme on top of Python?
2023-08-21 05:01:34 -0400 < mdhughes> There's at least one, I think Nordvig wrote it?
2023-08-21 05:01:46 -0400 < mdhughes> http://www.norvig.com/lispy.html
2023-08-21 05:02:13 -0400 < mdhughes> And so from his shouty platform, I'm sure a thousand mutant copies of it exist.
2023-08-21 05:08:10 -0400 < aeth> I'm only aware of this, which isn't a Scheme afaik. https://en.wikipedia.org/wiki/Hy
2023-08-21 05:08:30 -0400 < aeth> looks more clojurey with [] in the very, very, very brief example code
2023-08-21 05:08:45 -0400 < Franciman> do you favour [] in scheme code?
2023-08-21 05:09:24 -0400 < sham1> I like them for some stuff
2023-08-21 05:09:26 -0400 < aeth> looks like a Racketism to me.
2023-08-21 05:09:35 -0400 < aeth> since Racket fully embraced [] that is not the same as Clojure's []
2023-08-21 05:09:52 -0400 < sham1> Helps with visual distinctiveness. Although yeah, it's probably from racket and also r6rs
2023-08-21 05:12:04 -0400 < lockywolf> ]
2023-08-21 05:12:07 -0400 < lockywolf> [] are evil
2023-08-21 05:12:39 -0400 < lockywolf> python does not have tail recursion, as far as I remember
2023-08-21 05:12:54 -0400 < Franciman> you'se right, lockywolf. It does not
2023-08-21 05:13:27 -0400 < lockywolf> Kawa has tail recursion, even though Java does not, but Kawa has some fun machinery behind that.
2023-08-21 05:13:42 -0400 < sham1> Yeah, you can use a driver loop
2023-08-21 05:13:54 -0400 < lockywolf> I actually learned Scheme by mistake, I intended to learn that Hy
2023-08-21 05:14:01 -0400 < sham1> IIRC Kawa doesn't use that by default though because it's very detrimental to the performance 
2023-08-21 05:15:10 -0400 < mdhughes> [] is great, it's visually distinct.
2023-08-21 05:15:38 -0400 < mdhughes> Alas, most non-R6RS "Schemes" if I can even call them that, are annoying about it.
2023-08-21 05:15:43 -0400 < lockywolf> I have just written an infinite recursion in Kawa, and it doesn't seem to blow the stack
2023-08-21 05:17:32 -0400 < sham1> Well in many instances your tail call will be to your current procedure so it can be optimised into a loop
2023-08-21 05:18:04 -0400 < sham1> IIRC the driver loop only comes into play with interprocedure tail calls
2023-08-21 05:18:15 -0400 < lockywolf> that I didn't check
2023-08-21 05:18:27 -0400 < sham1> At least that's how I would do it
2023-08-21 05:19:21 -0400 < lockywolf> sham1: yeah, blew up
2023-08-21 05:19:40 -0400 < sham1> Yeah, you'd have to enable the proper tail calls
2023-08-21 05:19:43 -0400 < lockywolf> I am not amused.
2023-08-21 05:19:44 -0400 < sham1> Like with a flag
2023-08-21 05:21:13 -0400 < lockywolf> Which flag do I need?
2023-08-21 05:22:41 -0400 < sham1> --full-tailcalls
2023-08-21 05:23:29 -0400 < sham1> And from the documentation of the opposite flag "--no-full-tailcalls":
2023-08-21 05:23:31 -0400 < sham1> > Self-tail-recursion (i.e. a recursive call to the current function) is still implemented correctly, assuming that the called function is known at compile time. 
2023-08-21 05:24:13 -0400 < sham1> TIL that Kawa also has a partial implementation of both elisp and CL
2023-08-21 05:24:32 -0400 < sham1> Very partial, especially the CL one. Still interesting 
2023-08-21 05:24:56 -0400 < aeth> since when?
2023-08-21 05:25:57 -0400 < sham1> I dunno, I just read it in the docs
2023-08-21 05:26:38 -0400 < sham1> https://www.gnu.org/software/kawa/Options.html#Options-for-language-selection
2023-08-21 05:32:09 -0400 < aeth> huh, very incomplete
2023-08-21 05:33:10 -0400 < aeth> I wonder if they are doing it from scratch or if they're waiting on Airship Scheme's r7rs-small in which case that's kind of my fault
2023-08-21 05:33:31 -0400 < dpk> i think making Emacs run on the JVM is one of the FSF’s previous ideas to try to solve the software engineering disaster rms’s iron-age ideas of good engineering practice has inflicted on Elisp
2023-08-21 05:33:58 -0400 < dpk> then there was guilemacs, which was also probably never going to happen, and now probably definitely never going to happen because gccemacs
2023-08-21 05:34:10 -0400 < dpk> people do love to be trying to reach the moon by piling up chairs
2023-08-21 05:41:46 -0400 < lockywolf> yeah, seems to work
2023-08-21 05:42:34 -0400 < lockywolf> by gccemacs you mean native-compile, dpk?
2023-08-21 05:42:43 -0400 < Franciman> yes
2023-08-21 05:43:24 -0400 < lockywolf> I don't know. Since emacs lisp has lexical scoping, I am fine with it. I suspect that eventually they will add tail call elimination to Emacs Lisp as well.
2023-08-21 10:32:23 -0400 -!- mirai_ is now known as mirai
2023-08-21 12:15:58 -0400 < leah2> is it called scheme because there are so many cons?
2023-08-21 12:16:25 -0400 < acdw> lmao
2023-08-21 12:16:30 -0400 < sham1> *rimshot*
2023-08-21 12:16:48 -0400 < leah2> i mean there are many implementations named after criminal activities
2023-08-21 12:17:31 -0400 < Zipheir> mdhughes: I now think that "linear update" in Scheme was a mistake. It was another mistake to re-use ! for naming them.
2023-08-21 12:17:56 -0400 < jcowan> leah2: earlier languages in the tradition were Planner (sort of a Prolog), Conniver, and Scheme should have been Schemer but 6 character limitations FTL.
2023-08-21 12:18:23 -0400 < leah2> that sounds more reasonable yes :)
2023-08-21 12:18:38 -0400 < jcowan> in the UK "scheme" means "plan" rather than "plot"; "government schemes" are not illegal
2023-08-21 12:18:57 -0400 < leah2> "pyramid schemes" are ;)
2023-08-21 12:19:17 -0400 < sham1> Pyramid plot
2023-08-21 12:19:51 -0400 < sham1> Zipheir: I like having the linear updates. For example if I'm reversing a list I'm returning, I don't want to cons a new list up again necessarily 
2023-08-21 12:20:03 -0400 < leah2> sham1: https://3.bp.blogspot.com/-ARXyhZq4laI/VIModMn_EuI/AAAAAAACDP0/bEooaC4-HyQ/s1600/Pie-Pyramid.png
2023-08-21 12:20:24 -0400 < sham1> Pffr
2023-08-21 12:21:32 -0400 < Zipheir> sham1: Oh, I don't have a problem with operations that are defined to be destructive. It's the "it might be destructive" ones I don't like.
2023-08-21 12:27:49 -0400 < Zipheir> I mention those procedures because mdhughes noted that they're the (possible) exceptions to the !-procedures-return-nothing-meaningful naming rule.
2023-08-21 12:28:18 -0400 < jcowan> The choice of ! was perhaps bad, but I don't see us changing it now, at least for SRFI 1 procedures.
2023-08-21 12:28:47 -0400 < jcowan> I sketched a version of SRFI 1 with guaranteed mutation using !!
2023-08-21 12:29:00 -0400 < Zipheir> Yeah, SRFI 1 is pretty much set in stone.
2023-08-21 12:29:05 -0400 < mdhughes> I generally think "am I wrong, or was Olin wrong?" and then I know I should do what Olin did.
2023-08-21 12:29:36 -0400 < Zipheir> There are also some minor incompatibilities between SRFI 1 and R6RS, but that's the way it goes.
2023-08-21 12:29:47 -0400 < mdhughes> Once in a while that's not ideal, and like I say, I try for pure functional.
2023-08-21 12:31:02 -0400 < Zipheir> Shiro Kawai had some good points about "linear update": https://srfi-email.schemers.org/srfi-discuss/msg/16764346/
2023-08-21 12:32:06 -0400 < Zipheir> I'll add that, without a linear usage checker, it's a dangerous way to live.
2023-08-21 12:34:39 -0400 < Zipheir> There's nothing stopping you from doing something with foo-list after, say, (reverse! foo-list). It may work, too, if reverse! isn't actually destructive.
2023-08-21 12:35:07 -0400  * dpk notices from the 404 page that r6rs.org is now hosted on Codeberg, wonders who managed to arrange that
2023-08-21 12:37:06 -0400 < sham1> Zipheir: well the whole point with reverse! is that you don't care about what happens with foo-list afterw4
2023-08-21 12:37:17 -0400 < sham1> Oh nice
2023-08-21 12:37:35 -0400 < Zipheir> sham1: I know, but there's no way you're going to get a warning if you try to use it.
2023-08-21 12:38:19 -0400 < sham1> Yeah 
2023-08-21 12:38:23 -0400 < Zipheir> Whereas if reverse! is defined to reverse a list in place (and return nothing meaningful), there's no problem.
2023-08-21 12:38:41 -0400 < sham1> Anyway, I've also noticed that R6RS.org has gained a TLS cert. Probably related to the move 
2023-08-21 12:38:54 -0400 < Zipheir> Really. Who's doing all of this work?
2023-08-21 12:39:30 -0400 < Zipheir> The R6 gnomes.
2023-08-21 12:41:14 -0400 < mdhughes> Sweet. 21st C site for the 21st C language.
2023-08-21 12:42:06 -0400 < mdhughes> As long as it doesn't get fancied up. Design from 1994 Netscape is the only way to go.
2023-08-21 12:42:44 -0400 < sham1> As long as I can read it from eww, I'm fine
2023-08-21 12:45:03 -0400 < Zipheir> Yeah, it's quite usable, aside from the index. I'm not sure what happened there.
2023-08-21 12:45:08 -0400 < mdhughes> I've always been a Lynx guy.
2023-08-21 12:45:46 -0400 < Zipheir> mdhughes: Does Lynx have Unicode support these days?
2023-08-21 12:46:56 -0400 < mdhughes> It's platform-specific, I think, but it works great in Mac Terminal (or iTerm2)
2023-08-21 12:48:21 -0400 < sham1> Fairly sure Lynx just displays whatever it gets
2023-08-21 12:49:00 -0400 < Dooshki> Yeah, but unicode requires special handling on the CLI to use the correct amount of screen columns ber byte sequence
2023-08-21 12:49:20 -0400 < Dooshki> s/on the CLI/of the screen/
2023-08-21 12:49:35 -0400 < Zipheir> Right.
2023-08-21 12:50:04 -0400 < Zipheir> Many otherwise-usable TUI programs from the 90s can't display anything beyond Latin-1.
2023-08-21 12:50:08 -0400  * Dooshki unfortunately has more experience with that than he'd like >.>
2023-08-21 12:50:32 -0400 < mdhughes> Layout's completely unimportant in Lynx, it's just line-based.
2023-08-21 12:50:44 -0400 < mdhughes> w3m might be less nice.
2023-08-21 12:51:00 -0400 < Dooshki> mdhughes: Yeah, but how many screen rows should the line take up?
2023-08-21 12:51:15 -0400 < Zipheir> mdhughes: Let's see how Lynx handles zh.wikipedia.org :)
2023-08-21 12:51:18 -0400 < mdhughes> 1? Emoji are line height.
2023-08-21 12:51:34 -0400 < sham1> Isn't it usually just that you either take one or two columns
2023-08-21 12:51:41 -0400 < Dooshki> mdhughes: But a line can span several rows, depending on its column count
2023-08-21 12:51:48 -0400 < mdhughes> I see a bunch of Chinese.
2023-08-21 12:52:03 -0400 < Zipheir> Apparently not at all, at list in urxvt.
2023-08-21 12:52:32 -0400 < Zipheir> *least
2023-08-21 12:55:56 -0400 < Dooshki> (and even the column count for a line can vary, depending on where the line gets folded - e.g. you only have 1 column free at the end of the row, but your next glyph is two columns wide, now it effectively takes up 3 columns)
2023-08-21 12:57:12 -0400 < Zipheir> There are certainly levels of Unicode support.
2023-08-21 13:03:55 -0400 < gwatt> Zipheir: what's your locale settings? terminals themselves tend to be touchy if you have LC_LANG set to something other than UTF-8
2023-08-21 13:26:24 -0400 < Zipheir> gwatt: Yeah, the locale is UTF-8. I think it's just lynx.
2023-08-21 15:05:17 -0400  * dpk started to write the part of the syntax fascicle on phasing today, then realized after starting that she doesn’t understand well enough how phasing *formally* works, sigh
2023-08-21 15:08:25 -0400 < mnieper`> SRFI 1 is indeed set in stone, but I still believe that (scheme list) needn't be an exact copy.
2023-08-21 15:09:06 -0400 < mnieper`> Enforcing mutation of the argument won't be possible in all cases (I think this was also observed during development of SRFI 225).
2023-08-21 15:09:07 -0400 < dpk> it will not be an exact copy
2023-08-21 15:09:24 -0400 < mnieper`> dpk: So can we remove the linear update procedures?
2023-08-21 15:09:38 -0400 < dpk> we need to fix the fold procedures, at the very least
2023-08-21 15:10:00 -0400 < mnieper`> Can you remind me of the fix for SRFI 1?
2023-08-21 15:10:27 -0400 < mnieper`> Why we cannot enforce mutation is that we cannot alter a list head.
2023-08-21 15:10:33 -0400 < dpk> i would say something like that would need to be put to a vote, for such a large change to SRFI 1 which went in by a vote
2023-08-21 15:10:47 -0400 < mnieper`> dpk: Sure.
2023-08-21 15:11:01 -0400 < dpk> the fix for fold procedures will probably be that the accumulator argument to the kons procedure will come first, not last
2023-08-21 15:11:03 -0400 < mnieper`> It is not a change to SRFI 1, though, but just to (scheme list).
2023-08-21 15:11:22 -0400 < dpk> however, we might also have to rename the fold procedures so that existing code ‘breaks in the right way’
2023-08-21 15:11:31 -0400 < mnieper`> Exactly.
2023-08-21 15:11:48 -0400 < mnieper`> Otherwise, users will get errors hard to understand.
2023-08-21 15:12:04 -0400 < mnieper`> R6RS already gives us fold-left (which is fold with the "correct" order).
2023-08-21 15:12:07 -0400 < dpk> in which case we might have to do some sad things like foldl and foldr, even though nothing else in Scheme uses that convention for left and right
2023-08-21 15:12:19 -0400 < mnieper`> fold-right-"correct" needs a new name
2023-08-21 15:12:32 -0400 < dpk> or maybe left-fold and right-fold
2023-08-21 15:13:00 -0400 < mnieper`> fold-left, we already have.
2023-08-21 15:13:19 -0400 < mnieper`> We have a procedure called xcons.
2023-08-21 15:13:36 -0400 < mnieper`> It makes sense to reuse x instead of importing Haskell naming.
2023-08-21 15:13:40 -0400 < dpk> then again, maybe we can keep the names: if (srfi 1) keeps the Olin order and (scheme list) switches to the Riastradh order, fixing the problem just means changing which library you import. people just have to be aware of the issue
2023-08-21 15:15:06 -0400 < dpk> the same problem applies to a bunch of libraries which copied the SRFI 1 convention
2023-08-21 15:16:34 -0400 < dpk> i collected a list here https://wiki.dpk.io/r7rs-ultraviolet-issues.html#org64793c3
2023-08-21 15:18:35 -0400 < mnieper`> Another reason why I would like to see the linear update procedures in SRFI 1 gone is that I believe in, as you know, that Scheme should deprecate mutable pairs rather sooner than later.  In a world of immutable pairs, linear update procedures for lists are superfluous.
2023-08-21 15:20:03 -0400 < mnieper`> Along that, circular-list should also be dropped from (scheme list).
2023-08-21 15:20:11 -0400 < dpk> (scheme list) probably won’t even get the biggest changes to a library already voted in. if i can persuade the electorate to allow us to require enforcing the immutability of literals, it becomes significantly more practical to do something like say ‘mutable pairs are a subtype of immutable pairs’, and all of the procedures in (scheme ilist) which deal only with accessing or iterating over an immutable list without consing up a new one 
2023-08-21 15:20:11 -0400 < dpk> will disappear, because you can use the ones in (scheme list) instead
2023-08-21 15:20:30 -0400 < dpk> you also said you want to re-do (scheme show) in terms of delimited continuations, iirc
2023-08-21 15:21:44 -0400 < mnieper`> dpk: This is yet only a crazy idea.
2023-08-21 15:22:25 -0400 < mnieper`> Does it make sense that mutable pairs form a subtype of an immutable pairs?
2023-08-21 15:22:27 -0400 < dpk> oh, and (scheme hash-table) will probably have all the compatibility-with-SRFI-69 stuff dropped, especially the requirement that hash functions take an extra argument for a seed value
2023-08-21 15:23:02 -0400 < dpk> mnieper`: probably not in a formal sense, but what i mean is that the standard accessors car and cdr will work on them – there won’t need to be separate icar and icdr accessors
2023-08-21 15:23:46 -0400 < dpk> they’ll answer #t to pair? and to a new predicate immutable?, making ipair? technically unnecessary but probably worth keeping around for a similar reason to exact-integer?
2023-08-21 15:24:30 -0400 < sham1> All immutable pairs would be pair? but not all pairs would be immutable?
2023-08-21 15:24:46 -0400 < sham1> And the question mark isn't a question ofc
2023-08-21 15:24:56 -0400 < dpk> yes, the same situation as with all things that can be literal
2023-08-21 15:24:59 -0400 < mnieper`> It remains the problem that rest arg lists are not immutable.
2023-08-21 15:25:11 -0400 < mnieper`> In the long run, we should follow Racket.
2023-08-21 15:25:12 -0400 < dpk> we’re stuck with that
2023-08-21 15:25:25 -0400 < sham1> Aren't rest arg lists also mutable in R6?
2023-08-21 15:25:31 -0400 < mnieper`> So whatever we do now, we shouldn't make the switch in the future harder.
2023-08-21 15:25:43 -0400 < mnieper`> sham1: As soon as you import (rnrs mutable-pairs), yes.
2023-08-21 15:26:07 -0400 < sham1> Wait, it depends on importing a library?
2023-08-21 15:26:10 -0400 < dpk> circular-list will not be dropped, in fact i might add a circular-ilist ;-)
2023-08-21 15:26:38 -0400 < mnieper`> dpk: That makes things worse... :-(
2023-08-21 15:26:47 -0400 < mnieper`> sham1: Conceptually, yes.
2023-08-21 15:26:54 -0400 < sham1> That's... horrible
2023-08-21 15:27:02 -0400 < mnieper`> sham1: What?
2023-08-21 15:27:06 -0400 < mnieper`> Think about it.
2023-08-21 15:27:21 -0400 < mnieper`> If you don't have set-cXr!, pairs are obviously immutable. :)
2023-08-21 15:27:22 -0400 < sham1> I don't like language semantics that depend on including libraries
2023-08-21 15:27:34 -0400 < mnieper`> sham1: Then you don't like any language.
2023-08-21 15:27:41 -0400 < sham1> More or less
2023-08-21 15:27:51 -0400 < mnieper`> Every new primitive procedure changes semantics.
2023-08-21 15:27:58 -0400 < mnieper`> Have to be afk for a while.
2023-08-21 15:28:00 -0400 < dpk> i have been considering how we can support datum labels without requiring that syntax objects be circular, and in the process noticed that it’s amusingly easy to send Chez’s syntax primitives into infinite loops with things that have datum labels in them
2023-08-21 15:28:05 -0400 < gwatt> It's not a "semantics" issue. The set-c[ad]r! procedures don't exist outside of (mutable pairs)
2023-08-21 15:28:22 -0400 < Zipheir> Presumably, you still pay the overhead of the rest-args list being fresh even without (rnrs mutable-paris).
2023-08-21 15:28:32 -0400 < sham1> But I was more thinking that the rest args list's pairs are still "mutable" assuming you get your set-cXr! procedures from somewhere
2023-08-21 15:28:39 -0400 < mnieper`> Zipheir: Right, that has to be fixed as well.
2023-08-21 15:29:11 -0400 < sham1> That the compiler doesn't just suddenly decide that just because you don't have (rnrs mutable-pairs) imported that it can use immutable pairs
2023-08-21 15:30:13 -0400 < Zipheir> gwatt: I think it is a semantics issue in the sense that so many lists are described as "newly allocated" in the reports.
2023-08-21 15:30:25 -0400 < dpk> sham1: if you get an args list, save it somewhere, then import the mutable-pairs library, the args list made before is mutable with the newly imported library
2023-08-21 15:30:36 -0400 < sham1> Okay, that's what I thought
2023-08-21 15:30:37 -0400 < Zipheir> gwatt: Which is pointless if lists can't be mutated.
2023-08-21 15:30:45 -0400 < dpk> mnieper` is just being too clever ;-)
2023-08-21 15:30:58 -0400 < sham1> So the semantics don't just change by importing it
2023-08-21 15:31:03 -0400 < sham1> Good
2023-08-21 15:31:50 -0400 < dpk> mnieper`: at the very least a circular-ilist? predicate is missing from (scheme ilist) if literal pairs are immutable pairs, because the reader is then a way to create such lists
2023-08-21 15:32:06 -0400 < sham1> Anyway, Zipheir gave me some nice feedback on my process pre-srfi. Does anyone else have any reckons. Naming is of course something I'm thinking of, `process-data` is probably not a good type name
2023-08-21 15:35:30 -0400 < dpk> according to my rough timetable, the immutability of literals will probably be decided in late 2024 or early 2025. (of course, all this is provisional on the SC actually accepting my plan – Marc Feeley said they’re meeting this week or next to discuss)
2023-08-21 15:37:26 -0400 < Zipheir> sham1: What did you think of making the executable-locator an opaque type?
2023-08-21 15:37:51 -0400 < dpk> process-spec?
2023-08-21 15:38:44 -0400 < Zipheir> sham1: Otherwise, what other kinds of things than strings do you need process-data-create to support?
2023-08-21 15:42:07 -0400 < sham1> Well you'd probably need to support bytestrings unless we get some kind of consensus on representing "non-Unicode" bytes in strings
2023-08-21 15:42:13 -0400 < sham1> For path purposes
2023-08-21 15:42:29 -0400 < sham1> That'd also fix that issue for environment variables
2023-08-21 15:43:07 -0400 < sham1> So bytevectors
2023-08-21 15:45:11 -0400 < Zipheir> That's not too much to support. process-data-create could just take a string-or-bytevector argument.
2023-08-21 15:45:28 -0400 < sham1> Yeah
2023-08-21 15:48:38 -0400 < Zipheir> I like dpk's "process-spec".
2023-08-21 15:48:45 -0400 < sham1> I like it too
2023-08-21 15:49:17 -0400 < sham1> I'll also have to change some of the words, like to call it an "immutable" type instead of "functional" type. I don't know what I was thinking last night honestly
2023-08-21 15:51:44 -0400 < dpk> ah, what the heck. i don’t see much reason not to put this out there already. this is my rough plan for getting the Foundations done if selected as chair: http://dpk.io/temp/FASCICLES
2023-08-21 15:52:40 -0400 < dpk> i expect to have the first fascicle done by the end of this year, and i believe the whole Foundations report can be done in time for Scheme’s 50th birthday in 2025
2023-08-21 15:53:37 -0400 < dpk> (the first report was, blessedly, dated 22 December 1975, giving us nearly all year to try to have it ready, but i’m also conscious that engineering projects rushed for artificial anniversary-based deadlines often turn out poorly)
2023-08-21 15:55:39 -0400 < haugh> > I don't know what I was thinking last night honestly
2023-08-21 15:55:44 -0400 < haugh> I should put this in my email sig
2023-08-21 16:07:34 -0400 < mnieper> (In principle, a compiler can statically detect whether mutable-pairs and/or eval is imported, so it can statically decide to use simpler code.)
2023-08-21 16:13:33 -0400 < mnieper>  (In principle, a compiler can statically detect whether
2023-08-21 16:13:33 -0400 < mnieper>           mutable-pairs and/or eval is imported, so it can statically decide
2023-08-21 16:13:33 -0400 < mnieper>           to use simpler code.)
2023-08-21 16:14:01 -0400 < sham1> It *can*
2023-08-21 16:16:26 -0400 < mnieper> For R6RS, I don't know of any implementation that chooses this freedom.
2023-08-21 16:17:12 -0400 < mnieper> Future versions of R6RS, however, can easily deprecate mutability of pairs and later remove them because they are not integral part of the language and the libraries.
2023-08-21 16:17:52 -0400 < dpk> that’s a bold statement about any version of Scheme, which has never been a pure functional language nor really aspired to be one
2023-08-21 16:18:23 -0400 < mnieper> I think you misunderstood.
2023-08-21 16:18:41 -0400 < mnieper> This has nothing to do with purity of the language.
2023-08-21 16:18:51 -0400 < sham1> This seems like an attempt to "racketify" Scheme
2023-08-21 16:19:21 -0400 < mnieper> Only that the builtin pair type (which is special because it is used in argument lists and wherever standard procedures expect lists of objects) becomes immutable.
2023-08-21 16:19:46 -0400 < mnieper> sham1: Racket just took this step, which R6RS couldn't because of R5RS-compatibility.
2023-08-21 16:19:52 -0400 < mnieper> But R6RS paved the way.
2023-08-21 16:20:51 -0400 < aeth> set-cdr! vs reverse
2023-08-21 16:20:58 -0400 < aeth> the list-builder debate
2023-08-21 16:21:24 -0400 < mnieper> We had this; an this should be part of the system-specific implementation of (scheme list).
2023-08-21 16:21:27 -0400 < aeth> if you don't care about RAM I guess you could just use doubly linked lists. car, cdr, and... cpr? cir? Then you wouldn't have the whole issue where 99% of the time you're building lists in reverse
2023-08-21 16:22:43 -0400 < mnieper> Using set-cdr! in code meant to run on multiple implementations for efficiency is a bad idea. set-cdr! can actually be slow because of interference with the garbage collector.
2023-08-21 16:23:27 -0400 < mnieper> So put a way to build lists in some standard library and let the impl choose how to implement it efficiently.
2023-08-21 16:23:42 -0400 < mnieper> Internally, it can mutate as much memory as it wishes.
2023-08-21 16:24:37 -0400 < aeth> yeah, this is what Common Lisp has that (small) Scheme doesn't... CL:LOOP's COLLECT and APPEND clauses
2023-08-21 16:24:43 -0400 < aeth> very useful
2023-08-21 16:24:56 -0400 < aeth> the problem is that every Schemer has a different idea on what to do with a LOOP
2023-08-21 16:26:35 -0400 < mnieper> I very much like Olin Shiver's loop amended with iteration and not only recursion (for which I wrote SRFI 242 to support the actual loop library).
2023-08-21 16:26:45 -0400 < dpk> Olin Shivers will release his definitive loop macro any decade now
2023-08-21 16:26:49 -0400 < aeth> so now a problem with three possibilities (though the doubly linked (imutable) list one is rarely considered) becomes how do you do loops (which has like 20 possibilities)
2023-08-21 16:26:51 -0400 < mnieper> I have a partially written SRFI on my hard disk for the actual loop.
2023-08-21 16:27:02 -0400 < mnieper> ?
2023-08-21 16:27:06 -0400 < dpk> or mnieper will finish it for him
2023-08-21 16:27:25 -0400 < mnieper> SRFI 242 is at least 50%.
2023-08-21 16:27:41 -0400 < mnieper> It is all the dirty compiler work.
2023-08-21 16:27:48 -0400 < mnieper> What's missing is syntax on top. :)
2023-08-21 16:27:58 -0400 < aeth> personally, I'd just lift CL:LOOP, parenthesize it so it's not "ugly" to a Lisper and so it auto-indents well, and remove a few ugly things that don't make much sense like "nconc", or the alternative forms like "ing", i.e. "nconcing"
2023-08-21 16:28:27 -0400 < aeth> with any space-separated multi-word forms replaced by "proper" hyphenated ones
2023-08-21 16:28:33 -0400 < mnieper> aeth: Have you read Olin's paper? His points about scoping are fundamental for a language like Scheme IMO.
2023-08-21 16:30:52 -0400 < aeth> maybe... it's been long enough that all such things are gone from my browsing history and never were bookmarked
2023-08-21 16:31:32 -0400 < aeth> the first result appears to be https://www.ccs.neu.edu/home/shivers/papers/loop.pdf
2023-08-21 16:33:19 -0400 < aeth> subloop? seems overengineered to me
2023-08-21 16:34:04 -0400 < sham1> I know that it's obviously a legacy name, but NCONC is a weird identifier
2023-08-21 16:34:56 -0400 < Zipheir> mnieper: Which paper?
2023-08-21 16:35:05 -0400 < aeth> sham1: more importantly, it's almost entirely redundant to APPEND in CL:LOOP
2023-08-21 16:35:32 -0400 < aeth> and the -ing stuff is entirely redundant to the non-ing forms
2023-08-21 16:35:37 -0400 < sham1> Well yeah. It's just a linear updating append innit
2023-08-21 16:36:38 -0400 < Zipheir> olin-loop is the Flying Dutchman of Scheme. Someone on an email thread claimed to have a copy of the full(!) source code back in 2015 or so, IIRC.
2023-08-21 16:36:58 -0400 < sham1> Might also be someone's white whale
2023-08-21 16:38:14 -0400 < aeth> CL:LOOP isn't small or entirely trivial to implement, but I'd bet a CL-LOOP would win in a worse-is-better kind of way. Or, rather, the hypothetical variation I call DO-LOOP, which adds parentheses around the clauses for Lispiness reasons (and then adds DO- in front so it blends in with the other DO macros).
2023-08-21 16:38:43 -0400 < aeth> More importantly, we know that it works well because Common Lispers heavily rely on it.
2023-08-21 16:38:45 -0400 < Zipheir> aeth: Have you forgotten about foof-loop and loopy-loop?
2023-08-21 16:38:49 -0400 < sham1> Translating one of the existing CL:LOOP implementations would still be a bit rough
2023-08-21 16:39:06 -0400 < Zipheir> I think foof-loop would win for existing implementations in Scheme.
2023-08-21 16:39:41 -0400 < shawnw> Chicken has an implementation of CL loop in an egg: https://wiki.call-cc.org/eggref/5/loop
2023-08-21 16:40:07 -0400 < Zipheir> The big problem with CL-LOOP is, as Shivers pointed out, the complete lack of scoping rules.
2023-08-21 16:40:30 -0400 < Zipheir> At the very least, that would have to be fixed.
2023-08-21 16:40:48 -0400 < aeth> what is going on with foof loop on DDG? It appears like it's one of those search results that might be heavily botted by SEO spam without an authoritative result near the top. https://duckduckgo.com/?q=foof+loop+scheme&ia=web
2023-08-21 16:40:53 -0400 < shawnw> Says it implements most features, but unfortunately doesn't include what isn't.
2023-08-21 16:41:13 -0400 < aeth> I have no clue which one of those foof-loop links is authoritative, if any
2023-08-21 16:41:31 -0400 < shawnw> https://mumble.net/~campbell/scheme/foof-loop.txt
2023-08-21 16:41:45 -0400 < aeth> so the answer is, page 2
2023-08-21 16:41:57 -0400 < aeth> probably because the authoritative link is a text file instead of HTML
2023-08-21 16:42:40 -0400 < Zipheir> Most likely.
2023-08-21 16:42:40 -0400 < aeth> foof loof to me seems too parenthesized
2023-08-21 16:42:48 -0400 < aeth> e.g. the example unzip5
2023-08-21 16:42:49 -0400 < Zipheir> foop-loof
2023-08-21 16:43:05 -0400 < aeth> oh, yeah, not being easy to write when distracted doesn't help either :-p
2023-08-21 16:43:24 -0400 < Zipheir> Also not being by foof. :)
2023-08-21 16:43:38 -0400 < sham1> woot-loop
2023-08-21 16:43:51 -0400 < Zipheir> Confusingly, loopy-loop is by foof; foof-loop is by Riastradh.
2023-08-21 16:43:57 -0400 < aeth> my proposed do-loop has the advantage of having a lispy name, as long as no one takes it first and puts something way easier to implement under that name
2023-08-21 16:44:47 -0400 < Zipheir> I suspect no loop macro will ever be standardized because everyone likes their own.
2023-08-21 16:45:01 -0400 < aeth> right
2023-08-21 16:45:15 -0400 < sham1> (let loop (...) ...)
2023-08-21 16:45:20 -0400 < Zipheir> Which is fine, since there's nothing you really need them for.
2023-08-21 16:45:33 -0400 < aeth> my personal design goal is least surprise when seen by Common Lispers, which only really affects my (eventual) Scheme
2023-08-21 16:45:38 -0400 < Zipheir> And we have 'do' and named-let, of course.
2023-08-21 16:45:54 -0400 < sham1> Does anyone *actually* use `do` over named lets
2023-08-21 16:45:58 -0400 < aeth> the various CL:LOOP competitors in Common Lisp itself (e.g. ITERATE) don't even aim at my goal
2023-08-21 16:46:18 -0400 < aeth> sham1: I went through a DO phase, but nobody reads or writes it so it becomes almost write-only
2023-08-21 16:46:30 -0400 < sham1> ITERATE is nice although it does tree walking and is a bit fragile because of it
2023-08-21 16:46:33 -0400 < aeth> quite elegant when you have a zero-body DO, though
2023-08-21 16:46:40 -0400 < Zipheir> Scheme's 'do' is a little odd.
2023-08-21 16:46:50 -0400 < aeth> (the body of DO is only really needed for side effects)
2023-08-21 16:47:17 -0400 < aeth> Zipheir: as for the need of a loop like this, the initial subject was alternatives to the whole set-cdr! vs reverse list-building controversy that will never be settled
2023-08-21 16:47:23 -0400 < sham1> Well Scheme's `do` is a tiny shim over named `let` while I'd imagine in CL it'd probably be implemented in terms of `LOOP` or even just a raw `TAGBODY` or whatever
2023-08-21 16:47:43 -0400 < aeth> Zipheir: on the other hand, CL:LOOP gives collect/append and they're very convenient list-builders (even for people who otherwise avoid CL:LOOP in their CL code)
2023-08-21 16:47:59 -0400 < aeth> the problem is, nobody wants or needs the entirety of CL:LOOP in Scheme
2023-08-21 16:48:18 -0400 < sham1> List building and then maybe finding minima and maxima from the items
2023-08-21 16:48:26 -0400 < sham1> That'd be what I'd probably use it for
2023-08-21 16:48:28 -0400 < Zipheir> Sure. If we had a syntax-case implementation of LOOP, though, the problem would be settled. (If you like LOOP, use it.)
2023-08-21 16:49:11 -0400 < aeth> except LOOP breaks indentation, and fancy usage of LOOP doesn't even indent right inside of CL when you use the modified Emacs+SLIME environment with special support for LOOP... so proper indentation everywhere else is hopeless
2023-08-21 16:49:25 -0400 < Zipheir> How big are the lists you're building? It seems to me that, if they're big enough that you can't build them with 'unfold', you might want a different structure.
2023-08-21 16:49:40 -0400 < Zipheir> ('unfold' being vanilla-recursive.)
2023-08-21 16:54:12 -0400 < aeth> usually map is good enough
2023-08-21 16:54:31 -0400 < aeth> but CL:LOOP reads better for list-building, whether trivial or quite complicated
2023-08-21 16:54:47 -0400 < aeth> it's the only part of CL:LOOP that isn't completely redundant with other parts of the language
2023-08-21 16:55:13 -0400 < aeth> might just be that most people are trained on Python/C/C++/Java/JavaScript/etc. so CL:LOOP reads more "naturally"
2023-08-21 16:56:10 -0400 < sham1> Yeah, most of the time having an "internal iterator" might be better but for developers from those languages CL:LOOP might be more natural. If you'd be from Ruby for example, you'd probably be more comfortable with the internal iteration
2023-08-21 16:56:19 -0400 < Zipheir> I can see that, although I prefer the higher-order constructors.
2023-08-21 16:56:45 -0400 < Zipheir> 'unfold' is unfamiliar to many *functional* programmers.
2023-08-21 16:56:46 -0400 < aeth> CL:LOOP does have some key flaws, such as not being multiple-value-aware (which is generally handled by needlessly consing up multiple-value-list or by introducing some otherwise unnecessary SETFs)
2023-08-21 16:57:44 -0400 < aeth> in fact, that's probably the main flaw other than the syntax since usually the flaws are things you can ignore
2023-08-21 16:57:59 -0400 < Zipheir> No scope rules is a big flaw.
2023-08-21 16:58:40 -0400 < aeth> is that a flaw in practice or a flaw in the specification where every concrete implementation converged on a certain compatible way of doing things?
2023-08-21 16:59:18 -0400 < Zipheir> I don't know enough about CL implementations to say. I know that the CLHS says, effectively, that the scope of bindings in a LOOP form is unspecified.
2023-08-21 16:59:40 -0400 < Zipheir> I'm guessing the implementations have figured out something that works.
2023-08-21 17:00:19 -0400 < aeth> I think what might be more problematic is the boundary mixed with the CL type system
2023-08-21 17:00:28 -0400 < aeth> as in, the end condition mixed with the type system
2023-08-21 17:01:28 -0400 < sham1> At least aesthetically a problem I have with `CL:LOOP` (and tbf with most other "explicit" iteration structures like a named `let`) is that you really cannot use it as a part of a bigger expression. It either has to be in the tail position or be refactored into its own procedure to look nice
2023-08-21 17:01:34 -0400 < aeth> i.e. will this fail even though all of the collected items stay in the range? (loop for i of-type (integer 0 9) below 10 collect i)
2023-08-21 17:02:12 -0400 < aeth> in which case you'd have to actually do (integer 0 10)
2023-08-21 17:03:05 -0400 < aeth> a much better syntax, btw, would be (do-loop (for i of-type (integer 0 10) below 10) (collect i))
2023-08-21 17:03:29 -0400 < aeth> or, in Common Lisp where plists are more common because there's a consensus on keyword syntax, perhaps something like (do-loop (:for i :of-type (integer 0 10) :below 10) (:collect i))
2023-08-21 17:05:01 -0400 < Zipheir> aeth: I don't understand why loop macros so often use infix.
2023-08-21 17:06:04 -0400 < aeth> this isn't infix if that's what you mean, this is a plist that might be disguised as superficially looking like CL:LOOP
2023-08-21 17:06:07 -0400 < Zipheir> foof-loop expressions at least look like Lisp.
2023-08-21 17:06:20 -0400 < acdw> what's wrong with named let
2023-08-21 17:06:28 -0400 < aeth> although in the Scheme world, plists aren't particularly common (but if you do it alist style now you get a lot of extra parentheses like foof-loop)
2023-08-21 17:06:34 -0400 < acdw> I find myself wishing for a named let*
2023-08-21 17:06:38 -0400 < aeth> acdw: for list-building?
2023-08-21 17:06:40 -0400 < sham1> A named let is a tad too low level
2023-08-21 17:06:49 -0400 < Zipheir> Named-let is basically GOTO.
2023-08-21 17:06:54 -0400 < Zipheir> Er, a GOTO loop.
2023-08-21 17:06:55 -0400 < sham1> Not just basically
2023-08-21 17:07:04 -0400 < aeth> do you still build things in reverse with a named let?
2023-08-21 17:07:05 -0400 < sham1> What is a tail-call if not a GOTO with arguments
2023-08-21 17:07:10 -0400 < acdw> huh I never thought about it. just (if (null? xs) (reverse acc) ...)
2023-08-21 17:07:21 -0400 < acdw> aeth: I don't know any other way really haha
2023-08-21 17:07:36 -0400 < Zipheir> unfold...
2023-08-21 17:07:46 -0400 < acdw> uuu
2023-08-21 17:07:51 -0400 < aeth> the main use for CL:LOOP in CL, even for people otherwise opposed to its unlispiness in its syntax, is basic in-order list-building
2023-08-21 17:07:52 -0400  * acdw looks up unfold
2023-08-21 17:07:54 -0400 < sham1> Technically you can build lists "in the correct order" with a named let, but it's clunky. And yeah, you'd most likely want to actually use unfold
2023-08-21 17:07:56 -0400 < aeth> (i.e. collect/append)
2023-08-21 17:07:56 -0400 < Zipheir> It's in SRFI 1.
2023-08-21 17:08:16 -0400 < acdw> I should... probably read thru srfi 1
2023-08-21 17:08:25 -0400 < Zipheir> It's worth the time.
2023-08-21 17:08:32 -0400 < sham1> SRFI 1 is a wonderful library
2023-08-21 17:08:57 -0400 < acdw> ty!
2023-08-21 17:09:13 -0400 < Zipheir> Just ignore the linear-update procedures!
2023-08-21 17:09:18 -0400 < sham1> It does also concern me sometimes wrt. the way it recurses. Like yeah, don't recurse on your head, but you can still tail-recurse while doing things in "the correct order". Might not be as pretty, but w/e
2023-08-21 17:09:20 -0400 < acdw> I can never remember which fold is the one you want to use (from Haskell)
2023-08-21 17:09:22 -0400 < acdw> Zipheir: lol
2023-08-21 17:09:32 -0400 < sham1> In Haskell you'd use foldl' and foldr
2023-08-21 17:09:53 -0400 < Zipheir> Yes. foldl (no apostrophe) in Haskell is a trap.
2023-08-21 17:09:57 -0400 < sham1> In Scheme, because Scheme is not lazily evaluated, you'd most likely want to use a left fold. It's tail-recursive
2023-08-21 17:10:03 -0400 < acdw> ohhhhhhg
2023-08-21 17:11:02 -0400 < aeth> iirc the problem ime with using higher order function stuff (besides that you're mostly doing it on unnamed lambdas to the point where you might want to make it into macros to make it look better and hide the lambda...)
2023-08-21 17:11:05 -0400 < Zipheir> In some cases you want a right fold. In particular, 'concatenate' is inefficiently implemented as (fold-left append '() ...)
2023-08-21 17:11:12 -0400 < aeth> the problem is that there's like 5 choices you might want
2023-08-21 17:11:16 -0400 < aeth> so good reminder :-)
2023-08-21 17:11:37 -0400 < aeth> with CL:LOOP, you can basically build any list you want, in order, just by mixing the different basic collect/append list-builder stuff
2023-08-21 17:11:42 -0400 < sham1> Something something Lisp curse
2023-08-21 17:11:47 -0400 < Zipheir> Just read Jeremy Gibbons's Origami Programming and you'll always remember what you want. :)
2023-08-21 17:11:49 -0400 < aeth> the burden is on the macro implementation for CL:LOOP
2023-08-21 17:12:31 -0400 < Zipheir> Here's the power of higher-order thinking: a compiler is a fold after an unfold.
2023-08-21 17:12:50 -0400 < sham1> A compiler is a monad
2023-08-21 17:12:55 -0400 < sham1> A tree-walking monad
2023-08-21 17:13:12 -0400 < Zipheir> Some compilers are. But in general the idea is much simpler.
2023-08-21 17:13:21 -0400 < sham1> And of course a compiler is just an interpreter which "executes" the code it sees by emitting code
2023-08-21 17:14:16 -0400 < Zipheir> Not at all.
2023-08-21 17:14:25 -0400 < Zipheir> That is 100% wrong, in fact.
2023-08-21 17:14:27 -0400 < Zipheir> Sorry.
2023-08-21 17:14:32 -0400 < sham1> Oh?
2023-08-21 17:14:48 -0400 < sham1> You need to walk your AST to emit your code
2023-08-21 17:15:22 -0400 < Zipheir> A compiler is a translation function. An interpreter is an operational semantics.
2023-08-21 17:15:42 -0400 < Zipheir> Maybe rudybot has that Riastradh definition.
2023-08-21 17:15:45 -0400 < Zipheir> rudybot: diverging or yielding a final answer
2023-08-21 17:15:45 -0400 < rudybot> 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-08-21 17:16:39 -0400 < Zipheir> Whereas a compiler is a total function from programs in language L to programs in language M.
2023-08-21 17:17:20 -0400 < aeth> is it a total function, though?
2023-08-21 17:17:22 -0400 < Zipheir> (There is no notion of "execution".)
2023-08-21 17:17:26 -0400 < sham1> Well a compiler also needs to implement the operational semantics, otherwise it wouldn't compile the program to language M properly
2023-08-21 17:17:39 -0400 < aeth> because it looks like based on Wikipedia, a total function needs to be provably terminating?
2023-08-21 17:17:46 -0400 < aeth> and I think some compilers don't have that
2023-08-21 17:18:04 -0400 < sham1> And yeah, compilers aren't necessarily total. Most often it's enforced though by just adding an iteration limit
2023-08-21 17:18:09 -0400 < aeth> some let you run anything at compile time and you might even want that
2023-08-21 17:18:26 -0400 < sham1> C++ templates are undecidable
2023-08-21 17:18:28 -0400 < Zipheir> Yes, in practice they may not be total.
2023-08-21 17:18:50 -0400 < aeth> if you can run anything that the language can run at compile time, you probably don't even get an iteration limit available to you, just a time limit (i.e. timeout if it hangs)
2023-08-21 17:18:59 -0400 < Zipheir> But the important point is how interpreters and compilers differ as functions.
2023-08-21 17:19:20 -0400 < sham1> (Parsing the grammar of the language is also undecidable for different reasons, but syntax is of course a great point for Lisps)
2023-08-21 17:19:49 -0400 < sham1> Vs. more "traditionally" syntaxed languages
2023-08-21 17:20:38 -0400 < aeth> a lot of "compiler" talk is syntax talk
2023-08-21 17:20:45 -0400 < aeth> so, yeah, eliminating an entire category of work is great
2023-08-21 17:21:16 -0400 < Zipheir> You can specify a language semantics with only syntax and reduction rules, so that's a distinction without meaning.
2023-08-21 17:21:49 -0400 < sham1> TBF, I know exactly why that is. Syntax is of course the surface of the language, the thing you interact with in the most visceral way, and deciding on a great grammar of course feels important. And then being able to parse it well is also important
2023-08-21 17:22:00 -0400 < aeth> the problem is the mountain of complexity infix adds, as well as things like a statement/expression distinction, etc. etc.
2023-08-21 17:22:14 -0400 < aeth> by contrast, 90% of the Scheme syntax is the number syntax, in particular complex
2023-08-21 17:22:41 -0400 < aeth> it also means you don't need keywords in the traditional sense of the term "keyword"
2023-08-21 17:23:00 -0400 < sham1> Well having something like pratt parsing makes infix a bit more tolerable to parse, but yeah
2023-08-21 17:23:22 -0400 < sham1> And yeah, the only "complex" part of parsing Scheme is, incidentally, complex numbers
2023-08-21 17:23:41 -0400 < Zipheir> S-expressions make it a little easier, but it's not all that important. Languages should be easy to parse, though, for the sake of our built-in parsers.
2023-08-21 17:24:05 -0400 < sham1> Yeah. Programming languages are human languages which just happen to also be read by computers
2023-08-21 17:24:25 -0400 < aeth> there are lots of things you can do that don't involve s-expressions that languages happen to *not* do
2023-08-21 17:24:42 -0400 < aeth> for instance, requiring space between things (rather than whitespace significance generally focusing on *indentation*)
2023-08-21 17:24:52 -0400 < aeth> i.e. x+y is a symbol and x + y is addition
2023-08-21 17:25:29 -0400 < aeth> Also, not having to deal with infix precedence at all, requiring parens (which still uses one fewer level of parens than s-expressions, i.e. (+ x (* y z)) vs x + (y * z) as arithmetic)
2023-08-21 17:25:43 -0400 < aeth> And not reserving keywords and not having statements, etc.
2023-08-21 17:26:06 -0400 < sham1> I've actually toyed around with making a language where spaces around binary operators are significant
2023-08-21 17:27:22 -0400 < aeth> anyway, Lisps tend to have simple syntax, but non-Lisps tend to not even come close in simplicity even when they can
2023-08-21 17:27:59 -0400 < aeth> I'd also say only using ()s is pretty big, too, because other languages might mix {}s and []s and even "... end"s, etc.
2023-08-21 17:28:25 -0400 < aeth> But... it's a popular Racketism to use []s, and Clojure even assigns a special meaning to []s
2023-08-21 17:41:11 -0400 < r0tty> in an improper list, how is the non-null "tail" element commonly referred to?
2023-08-21 17:41:22 -0400 < Zipheir> The cdr.
2023-08-21 17:42:04 -0400 < Zipheir> "Final" cdr, I guess.
2023-08-21 17:42:21 -0400 < aeth> no consensus
2023-08-21 17:42:28 -0400 < aeth> it's a dotted list so you could even call it the post-dot
2023-08-21 17:42:45 -0400 < r0tty> Zipheir: well, its not really necessary the `cdr` relative to the whole list; e.g. given (1 2 3 . what-am-i-called)
2023-08-21 17:43:19 -0400 < sham1> But it is the *final* cdr
2023-08-21 17:43:31 -0400 < dpk> final cdr is used in the syntax-rules spec
2023-08-21 17:43:58 -0400 < aeth> the final cdr, the final element (but that's ambiguous)... or more creatively post-dot (sounds like "post-doc"), the impropriety (since it's the thing that makes it improper), etc.
2023-08-21 17:44:18 -0400 < Zipheir> r0tty: Sorry, I was typing more quickly than I was thinking. Damn coffee.
2023-08-21 17:45:12 -0400 < r0tty> Zipheir: no problemo
2023-08-21 17:45:50 -0400 < r0tty> I think I'll go with `final`; thanks folks
2023-08-21 18:08:29 -0400 < jcowan> dpk et al: Mpairs cannot be a subtype of ipairs, because Liskov
2023-08-21 18:09:19 -0400 < jcowan> "A violation of this constraint can be exemplified by defining a mutable point as a subtype of an immutable point. This is a violation of the history constraint, because in the history of the immutable point, the state is always the same after creation, so it cannot include the history of a mutable point in general."  —WP
2023-08-21 18:11:18 -0400 < jcowan> More precisely, "Let phi(x) be a property provable about objects x of type T. Then phi(y) should be true for objects y of type S, where S is a subtype of T."
2023-08-21 18:11:47 -0400 < jcowan> What *can* and should be done is to make car, cdr, etc. equally applicable ad hoc to both ipairs and mpairs.
2023-08-21 18:12:54 -0400 < aeth> the only problem is that that doesn't seem very Scheme-like
2023-08-21 18:13:16 -0400 < aeth> Scheme is a language where +, *, etc., being generic seem like the odd ones out
2023-08-21 18:13:47 -0400 < jcowan> I think it is.  We don't have a problem with both (car '(a . b)) and (car (cons 'a 'b)) both working.
2023-08-21 18:14:12 -0400 < jcowan> assuming that the first one makes an ipair, as in Chibi
2023-08-21 18:14:53 -0400 < aeth> what happens with (append (list 1 2 3) '(4 5 6)) though?
2023-08-21 18:15:24 -0400 < jcowan> we have to define if append delivers ipairs or mpairs, and then have another procedure that delivers the other type.
2023-08-21 18:16:55 -0400 < jcowan> If you wanted to use mpairs in racket seriously, you'd need to write an mpair version of SRFI 1, since in Racket pairs are ipairs.
2023-08-21 18:17:56 -0400 < jcowan> I think we have several possibilities: pairs are mpairs, pairs are ipairs, or pairs are mpairs except for "rest" arg lists.
2023-08-21 18:18:53 -0400 < jcowan> everything that delivers a pair would have to be doubled up: we need either cons/icons or mcons/cons
2023-08-21 18:20:28 -0400 < jcowan> the same is potentially needed for everything that has a datum syntax: pairs, strings, vectors (hetero and homo), arrays, (some cases of) records.
2023-08-21 18:21:48 -0400 < jcowan> A fourth possibility is "everything with an mpair argument delivers mpairs, everything with all ipair arguments delivers ipairs", in which case we don't need to double up.
2023-08-21 18:23:33 -0400 < jcowan> so (append '(1 2) '(3 4)) delivers an ilist, whereas (append (list 1 2) (list 3 4)), (append (list 1 2) '(3 4)), and (append '(1 2) (list 3 4)) all deliver mlists.
2023-08-21 18:24:04 -0400 < jcowan> Then we only have to double up things like cons, where there are no mpair or ipair arguments to start from
2023-08-21 18:24:46 -0400 < jcowan> (we need a name for procedures that accept one or more foos and deliver one or more foos; they are neither accessors, constructors, nor mutators)
2023-08-21 18:27:27 -0400 < gwatt> what happens if you have something like (cons 1 '(2 3)) ? is only the outer shell considered in this world of (i|m)pairs?
2023-08-21 18:27:28 -0400 < aeth> functions?
2023-08-21 18:28:39 -0400 < dpk> gwatt: the outermost pair is mutable, its tail immutable
2023-08-21 18:28:55 -0400 < dpk> this is already the case since at least R5RS
2023-08-21 18:29:08 -0400 < dpk> implementations have often just not enforced it
2023-08-21 18:30:16 -0400 < dpk> https://docs.scheme.org/surveys/immutable-literals/
2023-08-21 18:31:31 -0400 < gwatt> I wasn't clear. I'm asking how the world of polymorphic pair procedures will handle it.
2023-08-21 18:32:23 -0400 < dpk> oh, sorry. i probably would have grasped that if i’d read the backscroll
2023-08-21 18:35:06 -0400 < haugh> Woah I had no clue about this Scheme Surveys thing. This is enlightening.
2023-08-21 18:36:51 -0400 < haugh> Who maintains this? Is there a public test suite?
2023-08-21 18:36:56 -0400 < jcowan> haugh: Thank you
2023-08-21 18:37:25 -0400 < jcowan> No, there isn't.  I just had a script that ran All Known Schemes interactively, and then pasted the test case into each
2023-08-21 18:38:46 -0400 < jcowan> better wording: "if any arg is mutable, so is the result, otherwise the result is immutable.
2023-08-21 18:38:50 -0400 < jcowan> "
2023-08-21 18:39:34 -0400 < jcowan> Of course all these things are incompatible with R7-small except "pairs = mpairs".
2023-08-21 18:39:42 -0400 < jcowan> which is why there is an ipair SRFI.
2023-08-21 18:40:46 -0400 < jcowan> Cons is actually confusing, depending on if you think of it as "make-pair" or "grow-list"
2023-08-21 18:41:21 -0400 < jcowan> in the former case it is a constructor that needs to be doubled up, in the latter it can be treated as a non-constructor.
2023-08-21 18:41:34 -0400 < jcowan> ("transformer"?)
2023-08-21 18:43:31 -0400 < jcowan> I forgot to add that if we instantiate phi as "is mutable" in the Liskov definition, we get the equivalent of the claim about points.
2023-08-21 20:05:06 -0400 < shawnw> I actually have a halfway done implementation of SRFI-1 functions for Racket mpairs.
2023-08-21 20:08:55 -0400 < shawnw> Really should finish it one of these months.
2023-08-21 21:04:12 -0400 < mdhughes> I don't want to have to scan en entire list to test mutability, before returning one or the other.
2023-08-21 21:08:46 -0400 < mdhughes> Many of the problems with lists would go away if we had inout parameters. (probably not a serious thought, I'm just drinking my first caffeine of the day)
--- Day changed Tue Aug 22 2023
2023-08-22 01:28:39 -0400 < cow_2001> Hmm……… How much do CL people and Scheme people talk and work on the same things?
2023-08-22 01:28:58 -0400 < cow_2001> What is the intersection?
2023-08-22 01:29:35 -0400 < cow_2001> Practical stuff, not theoretical.
2023-08-22 01:47:53 -0400 < mnieper> jcowan gwatt dpk aeth: For a future Scheme - as far as I see it - all pairs would be immutable, and there would not necessarily be an mpair type. If it will, it will be unrelated to the immutable pairs. The reason why there need not be such a type is that one can always define two-field records.
2023-08-22 01:48:25 -0400 < mnieper> The reason why (immutable) pairs must be predefined and have a special status is that they appear in what the reader reads (and we need lists for rest arguments).
2023-08-22 01:54:06 -0400 < aeth> you mean two-length vectors, right?
2023-08-22 01:57:06 -0400 < aeth> (define (kar pair) (vector-ref pair 0)) (define (kdr pair) (vector-ref pair 1)) (define (kons x y) (vector x y))
2023-08-22 02:01:48 -0400 < aeth> then obviously set-kar! and set-kdr! from vector-set! etc. etc. Although I guess it should be mpair, not pair
2023-08-22 02:09:48 -0400 < mnieper`> aeth: I meant something like (define-record-type binary-tree-node (fields (mutable left) (mutable right))) [in R6RS notation].
2023-08-22 02:10:35 -0400 < mnieper`> So, whenever you need a mutable "pair", define a custom record type modelling it (as you would define a struct in C, etc.).
2023-08-22 03:09:17 -0400 < jcowan> mnieper`: your argument proves too much.  Given an abstract type of rest arguments (which is probably a good idea anyway), all you need is immutable vectors, immutable records, and boxes.  If you want immutable pairs and/or lists, just construct them.
2023-08-22 03:09:50 -0400 < jcowan> In short, forget Scheme altogether and stick to either ML or C.
2023-08-22 03:11:07 -0400 < sham1> I'd personally like that the rest arguments were a vector instead of a list. Oh well, can't really change that for now
2023-08-22 03:15:49 -0400 < jcowan> mnieper takes the view that we can change anything for the better, and that backward compat is basically worthless
2023-08-22 03:16:40 -0400 < jcowan> I'm just pointing out that on his principles Scheme shouldn't exist at all.
2023-08-22 03:17:09 -0400 < jcowan> (as ML is slightly older)
2023-08-22 03:27:13 -0400 < aeth> doing things the record way is very C-like
2023-08-22 03:27:21 -0400 < aeth> I have written my custom variant conses before, though
2023-08-22 03:27:34 -0400 < aeth> and no, not with vectors
2023-08-22 03:29:17 -0400 < aeth> various issues, such as performance loss and nobody quite supporting the data structure except for you and your own code
2023-08-22 03:29:36 -0400 < dpk> this one surprises me https://docs.scheme.org/surveys/define-syntax-defines/
2023-08-22 03:30:17 -0400 < dpk> all of those in the latter category do not satisfy the hygiene condition for Scheme (described by all RnRSes in more or less identical language)
2023-08-22 03:30:27 -0400 < dpk> though Chibi seems to have fixed this since
2023-08-22 03:33:02 -0400 < dpk> oh, actually, on second thoughts they might satisfy the hygiene condition but have REPLs where all free bindings are ‘bound’. did you test in a REPL or with a compiled program, jcowan?
2023-08-22 03:33:46 -0400 < dpk> Guile has also fixed this since, which also doesn’t surprise me
2023-08-22 03:45:17 -0400 < jcowan> dpk: In the REPL
2023-08-22 03:50:51 -0400 < dpk> okay, Chicken is definitely non-hygienic in this regard. a compiled program has the same behaviour
2023-08-22 04:33:35 -0400 < Riastradh> aeth: if foof-loop is too parenthesized you might like nested-foof-loop
2023-08-22 04:33:58 -0400 < Riastradh> aeth: https://mumble.net/~campbell/tmp/nested-foof-loop.txt
2023-08-22 04:34:22 -0400 < Riastradh> aeth: https://mumble.net/~campbell/tmp/nested-foof-loop.scm
2023-08-22 04:34:40 -0400 < Riastradh> aeth: https://mumble.net/~campbell/tmp/loop-comparison.scm
2023-08-22 04:38:47 -0400 < aeth> is it going to be a srfi?
2023-08-22 04:40:17 -0400 < Riastradh> ecraven, sham1: Intel and Arm CPUs do have the same register set for integer and floating-point data, but there's a hefty performance penalty if you mix integer and floating-point operations in the same data flow path.
2023-08-22 04:40:54 -0400 < sham1> I'd think that there would be a different register file for SSA and later
2023-08-22 04:40:59 -0400 < Riastradh> for FP/SIMD instructions, I mean -- the xmm/ymm/zmm registers on Intel, the s/d/q/v registers on Arm
2023-08-22 04:41:24 -0400 < ecraven> Riastradh: did you ever finish the nan-boxing work on MIT/GNU Scheme?
2023-08-22 04:41:44 -0400 < Riastradh> ecraven: nope
2023-08-22 04:43:02 -0400 < Riastradh> aeth: nope (not by me, anyway)
2023-08-22 04:44:08 -0400 < ecraven> I had *assumed* that nan-boxing is a performance win, but maybe it actually isn't :-/
2023-08-22 04:44:35 -0400 < ecraven> let's go back to actual RISC :P :D
2023-08-22 04:44:42 -0400 < Riastradh> probably is, modern JavaScript engines have been doing it for ages
2023-08-22 04:45:13 -0400 < Riastradh> The big win is avoiding heap allocation for floating-point operations.
2023-08-22 04:45:51 -0400 < sham1> V8 meanwhile seems to do just fine while heap allocating the floating point numbers
2023-08-22 04:45:56 -0400 < sham1> So it depends
2023-08-22 04:46:17 -0400 < Riastradh> Does v8 not use NaN-boxing?  I forgot which ones do and don't.
2023-08-22 04:46:27 -0400 < sham1> V8 doesn't nan-box
2023-08-22 04:46:32 -0400 < sham1> Spidermonkey does
2023-08-22 04:47:02 -0400 < Riastradh> But anyway, a much bigger win is vectorization; a clever tagging scheme doesn't help with that.
2023-08-22 04:47:13 -0400 < sham1> I think JavaScriptCore (the one by Apple) also nan-boxes 
2023-08-22 04:47:42 -0400 < sham1> I don't know about ChakraCore and frankly I don't care
2023-08-22 04:48:03 -0400 < ecraven> well, I like nan-boxing conceptually, because you can have more immediate types
2023-08-22 04:48:44 -0400 < Riastradh> Now, NaN-boxing doesn't imply anything about which registers you use to pass around the data or what operations you do on them.
2023-08-22 04:49:39 -0400 < Riastradh> For pointers you need to have them in the `general-purpose registers', i.e., rax/rdx/rdi/... on x86, or xN on Arm.  Moving between the GPRs and the FP/SIMD registers _also_ carries a hefty penalty.
2023-08-22 04:50:21 -0400 < ecraven> hm.. so actually you want to do type inference and just keep the floating point numbers in the fp registers without any tagging?
2023-08-22 04:51:23 -0400 < sham1> Yeah, you mostly want to unbox your arithmetic if at all possible.
2023-08-22 04:51:25 -0400 < Riastradh> Well sure.  Really you want to do operations in bulk, vectorized, too.
2023-08-22 04:51:31 -0400 < sham1> Or that
2023-08-22 04:51:56 -0400 < ecraven> well, to do that, you need to understand (at "compile-time") what type your data is, right?
2023-08-22 04:51:59 -0400 < Riastradh> In most Scheme systems, there's two costs involved:
2023-08-22 04:52:01 -0400 < sham1> Autovectorisation is a hard problem but it can be done
2023-08-22 04:52:43 -0400 < Riastradh> 1. type checks and detagging/retagging, which sometimes means transferring data between register sets
2023-08-22 04:53:28 -0400 < Riastradh> (type checks can be predicted-not-taken branches which are almost free on their own, but you also need a bunch of other code around which has to have compatible register assignments, which can incur more detagging/retagging)
2023-08-22 04:53:57 -0400 < Riastradh> 2. heap allocation for storing floating-point results, which triggers more garbage collection
2023-08-22 04:54:10 -0400 < Riastradh> NaN-boxing helps with (2), but not with (1).
2023-08-22 04:54:35 -0400 < ecraven> but at least it doesn't exacerbate (1), right?
2023-08-22 04:54:39 -0400 < ecraven> so it's at least a bit of a win?
2023-08-22 04:55:00 -0400 < ecraven> it should at least be faster than entirely boxed floats, I think?
2023-08-22 04:55:01 -0400 < Riastradh> probably yes
2023-08-22 04:55:36 -0400 < ecraven> did you consciously abandon the nan-boxing stuff in MIT for reasons (e.g. it's just not a good idea), or did life just interfere? 
2023-08-22 04:55:43 -0400 < Riastradh> lotta work
2023-08-22 04:55:57 -0400 < ecraven> so it's not that it isn't a good idea, it just hasn't been done yet ;)
2023-08-22 04:56:16 -0400 < Riastradh> Next priority is teaching the MIT Scheme GC to handle W^X.
2023-08-22 04:56:29 -0400 < ecraven> for Mx Macs?
2023-08-22 04:56:44 -0400 < Riastradh> that, and really any modern OS even on x86.
2023-08-22 04:56:50 -0400 < dpk> and OpenBSD, and Linux (iirc) when that protection is turned on …
2023-08-22 04:57:07 -0400 < Riastradh> https://lists.gnu.org/archive/html/mit-scheme-devel/2022-12/msg00001.html
2023-08-22 04:57:23 -0400 < dpk> or is it FreeBSD where you can enable W^X protection as an option? not sure
2023-08-22 04:57:24 -0400 < Riastradh> It's just that macOS doesn't have a way to selectively disable W^X requirements on individual programs.
2023-08-22 04:57:26 -0400 < ecraven> Riastradh: thanks for doing all that work on MIT.. I love that implementation ;)
2023-08-22 04:57:46 -0400 < Riastradh> But I don't know when I'll next take a whack at it.
2023-08-22 05:00:30 -0400 < Riastradh> (volunteers welcome to beat me to it -- all my draft work is in the wx branch)
2023-08-22 06:59:46 -0400 < mnieper> jcowan: That's an unfair exaggeration of what I wrote.
2023-08-22 07:00:06 -0400 < mnieper> I didn't mean to turn the rest arguments into a vector.
2023-08-22 07:00:54 -0400 < mnieper> What I propose is (for some future Scheme) a minor (IMO) change.
2023-08-22 07:01:30 -0400 < mnieper> During R2RS < R3RS < R4RS < R5RS < R[67]RS, there have always been small incompatibilities.
2023-08-22 07:02:47 -0400 < mnieper> Actually, what I propose for the time being is to make such a future change not more difficult than it currently is.
2023-08-22 07:10:46 -0400 < dpk> mnieper: i just filed an issue about the resumability of continuations in SRFI 226. i realize now after writing it that i read, correctly, that the procedure in Guile takes a tag, then started to write the issue as if it were about a predicate on an already-captured continuation. so it’s a bit muddled, but do let me know if you think there could be an issue there (because of FFIs that can’t restore continuations containing foreign frame 
2023-08-22 07:10:46 -0400 < dpk> stacks, or because of call-with-continuation-barrier, or similar)
2023-08-22 07:11:11 -0400 < dpk> stack frames! not frame stacks
2023-08-22 07:11:19 -0400 < dpk> i am not on the ball today
2023-08-22 07:11:50 -0400 < mnieper> aeth: Do you have a concrete example about "nobody quite supporting
2023-08-22 07:11:55 -0400 < mnieper> " your data structures?
2023-08-22 07:19:58 -0400 < mnieper> dpk: Answered on Codeberg.
2023-08-22 07:30:04 -0400 < mdhughes> While the immutable pairs are not a workable idea, because we have existing code we want to keep running. An immutable tuple as a separate type would be really valuable. (values) is kinda that, but isn't convenient to pass around, take parts of.
2023-08-22 07:32:01 -0400 < mdhughes> Racket does break old code, and it's "not a Scheme" now, a lot of code doesn't work in it, for that and many other reasons.
2023-08-22 07:33:18 -0400 < mdhughes> In practice I use vectors for tuples and comment "don't mutate this!", but that's a shitty hack. Could put them in a record, but eh.
2023-08-22 07:35:04 -0400 < mdhughes> Argh, Riastradh left before I could 👍 getting W^x done sometime, I'd love to run MIT again.
2023-08-22 07:38:56 -0400 < mdhughes> If there was a (lock x) function for all the mutable types, to set an immutable flag for runtime checks, that'd be useful, too.
2023-08-22 07:39:50 -0400 < mdhughes> Then rest args could be locked, vectors you don't want people screwing with, etc.
2023-08-22 07:45:45 -0400 < sham1> make-immutable!
2023-08-22 07:45:59 -0400 < sham1> Maybe with some more bangs to make it more emphatic
2023-08-22 07:46:04 -0400 < sham1> make-immutable!!!
2023-08-22 07:56:18 -0400 < mdhughes> Presumably the real name would be (pair-make-immutable! x) etc., Scheme is like Scheme style.
2023-08-22 07:57:01 -0400 < mdhughes> And a convenience (list-make-immutable! x) that fixes all the pairs in a list.
2023-08-22 07:59:38 -0400 < dpk> one apparent source of my confusion over the phormalities of phasing: some sources use a model of phasing progressing from more positive phase numbers towards zero for the ultimate run time (including R6RS); others (like Gerbil) use more negative phase numbers for successive expansions, progressing towards zero from the other direction
2023-08-22 08:00:08 -0400 < dpk> furthermore, Gerbil users crack their eggs open at the little ends, while the R6RS spec authors crack them open at the big ends
2023-08-22 09:24:59 -0400 < mdhughes> Oh, and notably Chez's (chezscheme) library has (vector->immutable-vector), but that kinda sucks; as long as it's local it won't cost much in GC, but you're still alloc/copying twice. There's no immutable-vector constructor.
2023-08-22 09:28:38 -0400 < dpk> are you sure it copies directly, and doesn’t just mark the underlying vector for copy-on-write?
2023-08-22 09:29:28 -0400 < dpk> i.e. no extra cost at all if you never actually mutate the original mutable vector you called it on
2023-08-22 09:32:00 -0400 < mdhughes> Yes: https://paste.debian.net/1289679/
2023-08-22 09:32:35 -0400 < mdhughes> I mean, I can't prove it's not copy-on-write, would have to turn on more debugging.
2023-08-22 09:40:41 -0400 < mdhughes> So, yes. It's 32 bytes for v, another 32 for v2.
2023-08-22 09:41:57 -0400 < mdhughes> Chez optimization was screwing with me for a moment, where I had 0 bytes allocated, because nothing used v.
2023-08-22 10:04:33 -0400 < mnieper`> mdhughes: Racket is a Scheme; mutability of pairs is IMO hardly a defining characteristic of Scheme.  Adapting R6RS programs to Racket is also not that hard because pair mutation in R6RS is very explicit (you have to import a certain library).
2023-08-22 10:05:15 -0400 < mnieper`> A procedure that makes a list immutable is not a solution to the underlying problem that mutability destroys Scheme's "list" type to be actually a list type.
2023-08-22 10:05:21 -0400 < mdhughes> Or you can just (import (chezscheme)) or equivalent get-everything library.
2023-08-22 10:05:51 -0400 < mdhughes> Racket explicitly says they are not Scheme anymore.
2023-08-22 10:06:09 -0400 < mdhughes> And how does mutating a list make it not a list?
2023-08-22 10:06:55 -0400 < mdhughes> (define ls (list 1 2 3)) (set-car! ls 'foo) (list? ls) => #t
2023-08-22 10:07:01 -0400 < mnieper`> mdhughes: Not RnRS Scheme anymore (and they don't feel bound to a standard anymore).
2023-08-22 10:07:16 -0400 < mnieper`> mdhughes: You can turn a list into a circular list.
2023-08-22 10:07:23 -0400 < mdhughes> Quite often lists are built by mutating existing lists.
2023-08-22 10:07:28 -0400 < mnieper`> See John's comment about Liskov.
2023-08-22 10:07:41 -0400 < mdhughes> OK? I don't really use circular lists, but they work fine if you're careful.
2023-08-22 10:08:00 -0400 < mnieper`> dpk: Thank you for sharing http://dpk.io/temp/FASCICLES.
2023-08-22 10:09:01 -0400 < mdhughes> Writing sorts and reverse without mutation isn't fun. Mutable alists are not that unusual.
2023-08-22 10:11:16 -0400 < mdhughes> As for subtypes, Cocoa (Objective-C's library) makes all types immutable by default, then mutable subclasses. It works reasonably well. The reverse is dangerous, since it's hard to hide the mutable methods.
2023-08-22 10:12:58 -0400 < mdhughes> But since Scheme doesn't have reflection on types, locking an object would have to be done at runtime, since you *can* call the mutator on any object.
2023-08-22 10:13:37 -0400 < mnieper`> I should add that I have been reevaluating my own commitment since John's resign from the chair position.  As my initial hope that at least the Foundations will treat R6RS and R7RS-small on the same footing reconcile the two camps seems to be farer away than ever and as my ideas to modernize the language in the long run (post R7RS) are seemingly in conflict with the conservative view here, I may direct my energy elsewhere.
2023-08-22 10:15:31 -0400 < mnieper`> It will also mean one set of opinions less with which the WG has to deal.
2023-08-22 10:16:16 -0400 < mdhughes> "Modernize" is one of those words that means whatever the speaker intends, like Humpty-Dumpty.
2023-08-22 10:17:28 -0400 < mdhughes> Your macro work is interesting, it's just the ML/Haskell-isms that don't jive with existing Scheme code.
2023-08-22 10:23:35 -0400 < gwatt> mdhughes: In chez there are hidden "make this thing immutable" procedures. #%$<type>-set-immutable!, where <type> is string, vector, bytevector.
2023-08-22 10:24:43 -0400 < mdhughes> Neat!
2023-08-22 10:25:09 -0400 < mdhughes> And I love cartoon swearing in a function.
2023-08-22 10:43:29 -0400 -!- mirai_ is now known as mirai
2023-08-22 12:00:45 -0400 < mnieper`> mdhughes: I know only little about ML and Haskell. From what I know, I am not even sure that what I proposed has much to do with ML and/or Haskell.
2023-08-22 12:03:06 -0400 < mnieper`> You don't need to know other languages. Just allow yourself to take a long and deep look at Scheme and think of where its semantics are complicated and then think of whether each bit of complexity is necessary and which comes because of questionable design decisions (often coming from an ancient time where Scheme was/had to be implemented in terms of a Lisp).
2023-08-22 12:03:49 -0400 < mdhughes> I know enough Haskell to be dangerous to myself in it, and it's very much up your alley. ML I mainly know from Ocaml, but original ML & Standard ML are much more directly ancestral to Haskell.
2023-08-22 12:05:02 -0400 < mdhughes> But the Scheme semantics I like are the dynamic nature. The ability to just code something up in REPL, copy it into your editor or save the whole world image. That amazing power is compromised by safety and efficiency concerns.
2023-08-22 12:08:39 -0400 < Zipheir> Of course, world images have never been an "official" Scheme feature.
2023-08-22 12:08:44 -0400 < mdhughes> One long-term goal is to have an environment as good as Interlisp was; but with a more pleasant language. I can kinda do that now with LispPad or Wraith Scheme, but as a practical language Chez still beats them.
2023-08-22 12:11:27 -0400 < mdhughes> I'm not sure images can ever be really standardized, since each environment that has them has so many weird bits. LispPad is full of native Cocoa integrations. Wraith has its awesome Kitten Graphics and the little control panels.
2023-08-22 12:12:09 -0400 < mdhughes> http://jayreynoldsfreeman.com/Aux/WraithScheme.64/Wraith%20Scheme%20Help.2.27.html#Kitten%20Graphics
2023-08-22 12:24:34 -0400 < Zipheir> mnieper: I'm sorry to hear that you may not continue working on R7RS. Are you concerned about the lack of agreement, or the (growing) scale of the Foundations/Batteries languages?
2023-08-22 12:25:02 -0400 < msavoritias> for what its worth scheme is more conservative than i expected it to be going in. (this from a new person)
2023-08-22 12:25:40 -0400 < msavoritias> in my view scheme was one of the languages capable of self reflecting with a small core that evolves. but it seems its much more conservative than that
2023-08-22 12:26:22 -0400 < Zipheir> msavoritias: How so? Also, welcome.
2023-08-22 12:26:25 -0400 < msavoritias> and i do think the r6rs and r7rs focus on the the large is weird imo. since it sould be r7rs 
2023-08-22 12:26:50 -0400 < mdhughes> If it's already perfect, why evolve? Just make more libraries.
2023-08-22 12:27:18 -0400 < Zipheir> mdhughes: Reminds me of Guy Steele's "How to Grow a Language"
2023-08-22 12:27:22 -0400 < msavoritias> Zipheir: having lurked here for a few months now i do see a lot of we can change this because compatibility or this is set in stone. which is weird imo
2023-08-22 12:28:00 -0400 < mdhughes> But if you break compatibility, you lose those existing libraries.
2023-08-22 12:28:02 -0400 < msavoritias> is it though perfect? i mean thats one of the things thats weird about cl imo
2023-08-22 12:28:43 -0400 < msavoritias> mdhughes: do you? they can use the previous version. i mean obviously you dont break every 10-20 years everything
2023-08-22 12:28:49 -0400 < mdhughes> CL made some really unfortunate compromises to get their standard, but they have done well at adding libraries.
2023-08-22 12:29:09 -0400 < msavoritias> but if you stay static you end up with C/C++ which is a nightmare to work with
2023-08-22 12:29:21 -0400 < Zipheir> msavoritias: One reason for that is that the incompatibility between Scheme dialects has been the single biggest complaint about the language for two decades now.
2023-08-22 12:29:52 -0400 < msavoritias> mdhughes: the libraries are well yes. but to me as a newcomer its not clear what i throw out from the standard so to speak that is obsolete now
2023-08-22 12:30:43 -0400 < msavoritias> Zipheir: i saw yeah. but for such a small language that you can extend isnt that understandable? also from my understanding libraries werent specified until very recently for some reason
2023-08-22 12:30:48 -0400 < mdhughes> You can't always use the previous version. R5RS doesn't even have a standard library form; R6 & R7 disagree on how they work.
2023-08-22 12:30:57 -0400 < sham1> > C/C++
2023-08-22 12:31:05 -0400 < msavoritias> yep. i agree thats a problem
2023-08-22 12:31:17 -0400 < Zipheir> There's so little in the pre-R6RS standards that I don't think there's much to throw out. transcript-on/-off ...
2023-08-22 12:31:51 -0400 < Zipheir> Most everything else in R5RS is still relevant for normal programming.
2023-08-22 12:32:33 -0400 < msavoritias> yeah. obviously you dont throw everything out. but we shouldnt be afraid to throw out what doesnt work imo
2023-08-22 12:32:34 -0400 < mdhughes> In practice if you're careful, you can use .sld/.sls libraries to wrap your portable code. And it'd be nice if at least that much continued on.
2023-08-22 12:33:09 -0400 < acdw> is there any ... "best practices" document or article anywhere for portable r7rs code?
2023-08-22 12:33:12 -0400 < msavoritias> i know of gnunet-scheme that tries to do a portable scheme implementation of gnunet
2023-08-22 12:33:27 -0400 < acdw> i'm kind of muddling thru but it'd be nice to have a few tips
2023-08-22 12:33:31 -0400 < Zipheir> msavoritias: If I understand correctly, I agree that we don't want Total Conformance! in Scheme. There's nothing wrong with multiple libraries handling the same topic.
2023-08-22 12:33:54 -0400 < msavoritias> i agree yeah
2023-08-22 12:35:36 -0400 < Zipheir> We also get so much more power from the module system (libraries) and procedural macros that I sometimes wonder if R7RS-small-plus-syntax-case isn't the perfect Scheme. (semi-serious there) 
2023-08-22 12:36:31 -0400 < msavoritias> i do agree that the R7large is weird. in the sense that i would much rather make portable scheme as easy as possible and slap a search engine like rust has crates
2023-08-22 12:36:45 -0400 < Zipheir> acdw: Not that I know of. Look at the SRFI implementations; that's how I learned portable Scheme.
2023-08-22 12:37:07 -0400 < msavoritias> my point was about not being afraid to throw out part of the standards that dont work in a hypothetical r8rs
2023-08-22 12:37:14 -0400 < acdw> yeah that's kind of where i'm headed with it. thanks Zipheir !
2023-08-22 12:37:24 -0400 < sham1> Problem with the crates model: we don't want to "bless" a given distribution model/implementation/ecosystem over others
2023-08-22 12:37:27 -0400 < Zipheir> acdw: yw!
2023-08-22 12:37:49 -0400 < Zipheir> msavoritias: I agree.
2023-08-22 12:37:53 -0400 < sham1> (Also personally I don't like the crates model, but that's not neither here nor there)
2023-08-22 12:37:58 -0400 < acdw> for what it's worth i agree with Zipheir and msavoritias re R7large ... from what i can see it seems like r7rs is just about there ---- now if srfis just had a better naming convention ;)
2023-08-22 12:38:04 -0400 < msavoritias> and have some self reflection when stuff doesnt work we should rework them even if it breaks compatibility
2023-08-22 12:38:26 -0400 < msavoritias> because scheme is about minimalism and elegance and correctness anyway imo
2023-08-22 12:38:43 -0400 < Zipheir> msavoritias: I wouldn't go as far as some languages and arbitrarily break stuff every six months, of course.
2023-08-22 12:38:52 -0400 < msavoritias> sham1: yeah i definetily dont want to have a single search engine for everything.
2023-08-22 12:39:18 -0400 < Zipheir> (GHC Haskell did that at some point with Monad becoming a sub-typeclass of Applicative--that was fun.)
2023-08-22 12:39:21 -0400 < msavoritias> Zipheir: for sure. as i said it should be gradual, careful and over long time periods. 
2023-08-22 12:39:37 -0400 < sham1> The problem would go beyond just a "search engine" in terms of having to standardise a single repository for code, the way the code is packaged and how it's retrieved and submitted.
2023-08-22 12:39:38 -0400 < Zipheir> Well, we've got the "long time periods" part *down*. :)
2023-08-22 12:39:43 -0400 < mdhughes> I've had to use Swift off and on since it was released. Not a single file from 9 years ago still works. Often not from 2 years ago. They just screw up the language harder every version.
2023-08-22 12:39:56 -0400 < msavoritias> i wouldnt be comfortable imposing a you need to adopt something that is less than 10 years time imo
2023-08-22 12:40:19 -0400 < msavoritias> sham1: we dont have to do it like that though
2023-08-22 12:40:21 -0400 < mdhughes> I have a small amount of old Scheme code that's worked for ~30 years, and much more that's worked for 5-10. I'd like that to continue.
2023-08-22 12:40:52 -0400 < Zipheir> For instance, I agree with mnieper about immutable pairs in the core language. (I'll go further and say get rid of mutable strings.)
2023-08-22 12:41:04 -0400 < mdhughes> There's no reason to break stuff that works.
2023-08-22 12:41:45 -0400 < Zipheir> Mutable strings barely work, these days. And immutable pairs prevent a lot of optimization.
2023-08-22 12:41:51 -0400 < Zipheir> Sorry, *mutable pairs.
2023-08-22 12:41:55 -0400 < mdhughes> Immutable-by-default might've been a good idea for R5RS. It'd be a catastrophe on a lot of working code now.
2023-08-22 12:42:17 -0400 < msavoritias> yeah. guix does good work there of allowing old software to be easily installable. with software heritage
2023-08-22 12:42:39 -0400 < mdhughes> A rotten, buggy old runtime is not a solution to keeping code working.
2023-08-22 12:43:08 -0400 < msavoritias> mdhughes: why is it bad to fix a problem we see now?
2023-08-22 12:43:28 -0400 < msavoritias> nobody has to adopt the new standard immediately and old stuff will keep working
2023-08-22 12:43:29 -0400 < Zipheir> mdhughes: What's changed since R5? Have mutable pairs come back into style? AFAIK they've been used less and less.
2023-08-22 12:44:48 -0400 < mdhughes> Mutable pairs are still very handy for building tree structures and mini-databases.
2023-08-22 12:44:50 -0400 < Zipheir> They were nearly eliminated by R6RS.
2023-08-22 12:45:04 -0400 < Zipheir> Records do all of that just as well.
2023-08-22 12:45:10 -0400 < mdhughes> But they *weren't*. Which is the right decision, to leave working things alone.
2023-08-22 12:45:34 -0400 < msavoritias> sham1: coming back to the libraries thing. what would be needed imo is: portable libraries (probably a guide), a way to add portable libraries to your own scheme (another guide) and thats it pretty much. i think
2023-08-22 12:45:45 -0400 < msavoritias> everything else can be done per implementation
2023-08-22 12:46:02 -0400 < mdhughes> An immutable flag is a good forward-compatible change, because you can mark constant strings, constant lists, rest args, etc. immutable, without breaking anyone's working code.
2023-08-22 12:46:34 -0400 < msavoritias> but you dont break them even if you remove them do you? because you can put r6rs or something as your standard
2023-08-22 12:46:41 -0400 < msavoritias> or pull them as a library
2023-08-22 12:47:07 -0400 < msavoritias> put r6rs in the cli that is. at least in guile that is how its done and i pick r7rs
2023-08-22 12:47:25 -0400 < Zipheir> mdhughes: An example of how you pay for mutable pairs is the "variadic recursion" problem. If you have a recursive rest-args procedure 'foo', you don't want to define it this way: (define (foo . args) ... (apply foo (cdr args)))  You have to use a loop instead, because you can't re-use argument lists--someone might mutate them!
2023-08-22 12:47:54 -0400 < Zipheir> (By which I mean they must be newly-allocated per the Reports.)
2023-08-22 12:48:23 -0400 < mdhughes> How would that work? R8RS has immutable pairs. Suddenly everything breaks. Importing a library's not going to change what cons does.
2023-08-22 12:49:11 -0400 < mdhughes> Now everyplace I assume a mutable list, I have to rebuild it with kons?
2023-08-22 12:49:33 -0400 < sham1> Well we can always have an alternative cons that gives you mutable pairs
2023-08-22 12:49:37 -0400 < Zipheir> No, you could import it as 'cons'.
2023-08-22 12:49:44 -0400 < sham1> Yeah, basically that
2023-08-22 12:49:46 -0400 < mdhughes> Zipheir: Like I said, marking rest args immutable would be fine, since it's *probably* rare to mutate those.
2023-08-22 12:50:02 -0400 < Zipheir> It's just that the "built-in" lists like argument lists are immutable, which is what you want for efficiency.
2023-08-22 12:50:10 -0400 < Zipheir> Right.
2023-08-22 12:50:23 -0400 < msavoritias> im all for making more stuff immutable too btw
2023-08-22 12:52:18 -0400 < Zipheir> msavoritias: A way to install portable libraries would be very nice. I'm not sure how Snow or Akku are doing on that front. Lassi has make a CLI tool to install SRFIs (https://github.com/scheme-requests-for-implementation/srfi-common/tree/master/srfi-tools)
2023-08-22 12:52:19 -0400 < mnieper`> mdhughes: Old standards don't go away.  If a hypothetical R8RS removes mutable pairs, you can still run your old code in R<=7RS.
2023-08-22 12:52:23 -0400 < mdhughes> Also you probably shouldn't have a recursive rest-args function anyway, you normally build a HOF with source and collection list specified.
2023-08-22 12:52:52 -0400 < mnieper`> Zipheir: If you think R7RS+syntax-case would make a good basis for the Foundations, then I can only say that we already have R6RS.
2023-08-22 12:53:43 -0400 < mdhughes> mnieper`: If someone's on flavor-of-the-week compiler like guile, then you can't really run your code in R5RS. How maintained is that old branch?
2023-08-22 12:53:54 -0400 < Zipheir> mnieper`: I agree, but not everyone likes R6RS.
2023-08-22 12:54:24 -0400 < mdhughes> Chez probably won't change significantly, except to support what Racket's doing. Which is a little concerning sometimes, but the backports seem sane so far.
2023-08-22 12:54:24 -0400 < msavoritias> mdhughes: you can have it with inferiors or software heritage easily so it shouldnt matter
2023-08-22 12:54:42 -0400 < mdhughes> "heritage" means it's broken and unmaintained.
2023-08-22 12:54:54 -0400 < mnieper`> Zipheir: But they will get R6RS modulo renaming when served R7RS+syntax-case.
2023-08-22 12:55:01 -0400 < msavoritias> Zipheir: that looks like a nice source
2023-08-22 12:55:13 -0400 < Zipheir> That's another thing. No-one is talking about running a damnatio memoriae campaign on the older standards.
2023-08-22 12:55:28 -0400 < msavoritias> mdhughes: the last part yes. its unmaintained. not broken though necesserily.
2023-08-22 12:55:47 -0400 < msavoritias> plus every maintainer can maintain what they want right? open source and stuff
2023-08-22 12:56:02 -0400 < sham1> Zipheir: I hope anyway
2023-08-22 12:56:11 -0400 < mdhughes> All code bitrots, especially when on modern "change for change sake, push a broken version every year" publishing schedule.
2023-08-22 12:56:35 -0400 < msavoritias> but we are not that are we? scheme moves slower
2023-08-22 12:56:53 -0400 < msavoritias> r7rs is still not fully adopted and it has been 10 years
2023-08-22 12:56:55 -0400 < mdhughes> Not slow enough, according to some.
2023-08-22 12:57:02 -0400 < msavoritias> things moves slow and thats okay
2023-08-22 12:57:04 -0400 < mdhughes> That's because R7RS was a mistake.
2023-08-22 12:57:19 -0400 < Zipheir> Here we go again...
2023-08-22 12:57:20 -0400 < msavoritias> ah okay so you are from that crowd :P
2023-08-22 12:57:21 -0400 < mnieper`> Programming languages that want to do it right and want to stay beautiful have to move.
2023-08-22 12:57:37 -0400 < mnieper`> Otherwise, they will be overtaken by programming languages that do it better.
2023-08-22 12:57:47 -0400 < mdhughes> R6RS might've been a shocking change, but it was *forwards* compatible. Your old code just worked. 
2023-08-22 12:58:09 -0400 < mnieper`> R7RS was insofar a mistake as we are now at a point where we would like to get back things from R6RS, which was from 16 years ago.
2023-08-22 12:58:25 -0400 < mdhughes> And the stuff it added wasn't that weird. Fix Unicode. Use the good macro system to make records useful. Fix IO so it's usable in real-world problems.
2023-08-22 12:58:26 -0400 < mnieper`> Move back these 16 years and we would be farther ahead.
2023-08-22 12:59:37 -0400 < mnieper`> I would like to point out one big misconception that can be heard here as well: In fact, the library systems of R6RS and R7RS don't do much to make interchange of code easier compared to R5RS.
2023-08-22 13:00:09 -0400 < mnieper`> Already in R5RS you had "load", etc. and the same limits applied, namely the few portable procedures to do stuff outside the Scheme core.
2023-08-22 13:00:26 -0400 < mnieper`> What library/define-library guarantee you is some control about your top-level namespace.
2023-08-22 13:00:31 -0400 < mdhughes> I like data hiding in libraries. Doing (load) meant the library had to do private stuff inside a self-eval lambda.
2023-08-22 13:00:48 -0400 < mnieper`> Right. But it is not impossible.
2023-08-22 13:00:56 -0400 < mdhughes> And you couldn't easily rename things from an R5 library.
2023-08-22 13:01:06 -0400 < mnieper`> and you can wrap it into syntax, which you call "module"
2023-08-22 13:02:08 -0400 < mnieper`> What I want to get it is that we already had exchange of code during R5RS, e.g. SLIB and SRFI sample implementations, and that the situation has not fundamentally improved. 
2023-08-22 13:02:36 -0400 < msavoritias> then we need to ask why
2023-08-22 13:02:48 -0400 < Zipheir> msavoritias: A few implementations (Guile and CHICKEN, at least) moved to support R7RS early on. Guile's effort bogged down, it seems. CHICKEN's support is nearly ful.
2023-08-22 13:02:56 -0400 < Zipheir> *full
2023-08-22 13:02:59 -0400 < sham1> "why" what
2023-08-22 13:03:15 -0400 < mnieper`> msavoritias: In the C world, we have a well-defined ABI on each platform.
2023-08-22 13:03:29 -0400 < mnieper`> So C libraries work with any compiler on such a platform.
2023-08-22 13:03:47 -0400 < mdhughes> My three main systems have been MIT, CHICKEN, and Chez. MIT has nothing, it's a mess. CHICKEN has eggs, totally nonstandard and they break across versions. Chez has nice libraries, I've been using Thunderchez and a bunch of other libs quite safely in it.
2023-08-22 13:03:56 -0400 < mnieper`> Contrary to it, a portable Scheme library/file-to-be-loaded can only access portable procedures.
2023-08-22 13:04:30 -0400 < mnieper`> So people quickly have to use specific implementations, producing code that cannot be shared.
2023-08-22 13:04:38 -0400 < msavoritias> yeah im learning c to hopefully contribute to guile directly 
2023-08-22 13:04:45 -0400 < mdhughes> But now they break on R7RS, unless the library author includes both R6 and R7 forms.
2023-08-22 13:04:50 -0400 < mnieper`> define-library/library is not the cure. (But it has other merits.)
2023-08-22 13:04:56 -0400 < sham1> cond-expand?
2023-08-22 13:04:59 -0400  * sham1 runs
2023-08-22 13:05:11 -0400 < msavoritias> sham1: why the libraries situation hasnt fundamentally improved
2023-08-22 13:06:13 -0400 < mdhughes> I think it's in decent shape. Akku works.
2023-08-22 13:07:13 -0400 < msavoritias> mnieper`: afaik thats not in the real world though. were libraries and programs may compile on gcc but not clang. or compile on both of them but not cproc
2023-08-22 13:08:20 -0400 < mnieper`> msavoritias: But you are able to write most libraries you want portibly between gcc/clang/...
2023-08-22 13:08:52 -0400 < mnieper`> Of course, the ABI/environment has to be fixed (e.g. when you need to access the environment).
2023-08-22 13:09:24 -0400 < jobol> POSIX came here in the middle otherwise nothing had be possible
2023-08-22 13:09:27 -0400 < mnieper`> The point is that the system header files (outside the Scheme standard) are accessible from any conforming compiler on that platform.
2023-08-22 13:09:39 -0400 < msavoritias> mnieper`: so who are we blaming here? the implementations? that we dont have abi? posix but scheme?
2023-08-22 13:09:46 -0400 < Zipheir> I know very little about specifying ABIs, but it seems like having a standard Scheme ABI might be a burden to compiler authors.
2023-08-22 13:10:05 -0400 < mnieper`> The C people think otherwise.
2023-08-22 13:10:29 -0400 < mnieper`> I don't want to judge, but I think it becomes clear why we have a lot of Scheme islands. 
2023-08-22 13:10:54 -0400 < gwatt> The C people typically have much fewer compilation targets, and all those targets exist at the same abstraction level
2023-08-22 13:10:57 -0400 < jobol> Internally (for "static" C functions) ABI does not care 
2023-08-22 13:11:48 -0400 < mnieper`> Standardizing an FFI for Scheme would help a lot, but this would place quite a burdon on Scheme compiler/interpreter writers.
2023-08-22 13:12:00 -0400 < Zipheir> If there were a standard Scheme ABI, would it be possible for a Scheme-to-C compiler, say, to support it?
2023-08-22 13:12:36 -0400 < sham1> How would you standardise an FFI that works on native platforms with C, the JVM, CLR, the Web and whatever other platforms we might come up with in the future
2023-08-22 13:12:42 -0400 < sham1> Answer: no
2023-08-22 13:12:45 -0400 < Zipheir> (I suppose anything's possible in C with enough weird compiler flags.)
2023-08-22 13:13:10 -0400 < jobol> Zipheir, it would mean a scheme C-ABI, I mean it is not more a Binary interface
2023-08-22 13:13:14 -0400 < msavoritias> heh
2023-08-22 13:13:25 -0400 < mdhughes> I don't really want most libraries to be binary blobs, which is what an ABI would encourage. Source is nice.
2023-08-22 13:14:09 -0400 < mdhughes> And the compilers eventually have to produce C ABI to talk to dylib/so/dll, so that's fine for talking to native stuff.
2023-08-22 13:16:27 -0400 < sham1> Hell, an even more "mundane" scenario can be thought of with something like Airship Scheme. How does one interface CL and Scheme
2023-08-22 13:18:38 -0400 < sham1> Do macros work cross-language? How does one deal with the difference in namespaces? Or even the fact that CL is case insensitive while Scheme is case sensitive. Or the interaction between CL conditions and the Scheme exceptions? First-class continuations?
2023-08-22 13:19:36 -0400 < mdhughes> Wouldn't the Airship macros affect the Scheme level only? And then the functions called descend into CL.
2023-08-22 13:19:37 -0400 < sham1> FFI is complex and needing to deal with a wide variety of targets certainly doesn't make it easier
2023-08-22 13:20:16 -0400 < msavoritias> the problem with scheme is not that it doesnt have ffi. but that it doesnt have a good library ecosystem i can pull from
2023-08-22 13:20:33 -0400 < msavoritias> like i see a scheme library and i can pull it in guile easily and use it
2023-08-22 13:20:34 -0400 < sham1> Thunderchez, Snow, Guix
2023-08-22 13:20:48 -0400 < sham1> Also Nixpkg I suppose
2023-08-22 13:20:48 -0400 < mdhughes> And Akku.
2023-08-22 13:20:56 -0400 < sham1> Yeah
2023-08-22 13:21:25 -0400 < mdhughes> I dunno what guile does much, I don't touch GNU things if I can help it, but really it's worth checking out the library ecosystems.
2023-08-22 13:22:02 -0400 < mdhughes> `chicken-install -s foo` is pretty great. It's just the long compiles that suck ass.
2023-08-22 13:22:40 -0400 < gwatt> guile seems to be pickin up some steam. It's used to implement gnu shepherd, which is yet another init system
2023-08-22 13:22:51 -0400 < gwatt> and guix, of course
2023-08-22 13:23:16 -0400 < sham1> Yea. Guix System has many nice things done with Guile. My personal problem comes from how Guix System works, but oh well, GNU's gonna GNU
2023-08-22 13:23:40 -0400 < Zipheir> jobol: Thanks.
2023-08-22 13:26:32 -0400 < Franciman> sham1: do you have any specific example of things you dislike?
2023-08-22 13:26:50 -0400 < sham1> Not really anything specific or really anything technical
2023-08-22 13:27:05 -0400 < Franciman> the vibe?
2023-08-22 13:27:33 -0400 < sham1> I guess. As I said, GNU's gonna GNU and because of that the philosophy behind the system and the way it's presented is, well... yeah
2023-08-22 13:27:55 -0400 < mnieper``> Can you do SDL game programming, can you access the microphone, can you use libblas to do linear algebra, can you access the internet, ... with a portable library published in some Scheme repo?
2023-08-22 13:27:57 -0400 < sham1> I personally like the more pragmatic view for free software by Debian and Fedora and such
2023-08-22 13:29:11 -0400 < gwatt> One thing to keep in mind is that not everyone who works on GNU projects has the same ideals as RMS.
2023-08-22 13:29:53 -0400 < mdhughes> Not everyone in [terrible organization] shares the ideals of [terrible leader], but…
2023-08-22 13:30:12 -0400 < mnieper``> "Real world Scheme programs that are not compilers" tend to depend on a particular implementation.
2023-08-22 13:30:52 -0400 < mdhughes> mnieper``: Not *really*, but almost. 80% of my graphics/sound library ported from CHICKEN's sdl2 to Thunderchez's.
2023-08-22 13:30:52 -0400 < Zipheir> Yes.
2023-08-22 13:32:12 -0400 < sham1> TBF similar stuff applies in other languages as well. For example many C programs rely on many GCC-isms in their code (including for example the Linux kernel) which is also why clang has to also implement those extensions
2023-08-22 13:32:17 -0400 < mdhughes> I've done a lot of rewriting over time, and ultimately I may dump the Scheme sdl2 library and put it all in my FFI'd C code, but a simple use of the libraries is pretty portable.
2023-08-22 13:32:45 -0400 < sham1> Since C was brought up as something that tends to be "portable"
2023-08-22 13:32:48 -0400 < gwatt> mdhughes: I tend to dislike the "100% for or 100% against" kinds of arguments. I know that a bunch of people who work on GNU projects were never particularly enthused by RMS, and don't really consider him an authority figure over what they work on
2023-08-22 13:33:24 -0400 < mdhughes> gwatt: Unfortunately, he's shown that he'll take over projects that do rebel against him. It happened with gcc, glibc, and more.
2023-08-22 13:34:04 -0400 < sham1> At least on my part I tend to agree with the GNU project on things such as the value of software freedom and such. The real disagreement is in defining what "freedom" means, which is a big differentiator
2023-08-22 13:34:16 -0400 < mnieper``> Besides, a lot of things RMS has said are not nonsense. 
2023-08-22 13:34:19 -0400 < mdhughes> So if I want nothing to do with him, I avoid. I also don't want to touch even LGPL, let alone GPL, code if I can avoid it.
2023-08-22 13:34:47 -0400 < mdhughes> I believe in Freedom 0: The right to license your own code how you like.
2023-08-22 13:34:50 -0400 < mnieper``> GPL is just the best in a copyright system as we have it (my opinion).
2023-08-22 13:35:00 -0400 < mnieper``> mdhughes: No one takes away that right from you.
2023-08-22 13:35:03 -0400 < Zipheir> Let's not get into a GPL debate, please.
2023-08-22 13:35:14 -0400 < msavoritias> the thing with guix is that no other scheme offers that currently
2023-08-22 13:35:19 -0400 < sham1> Well I for one don't really accept intellectual property (aside from trademarks, but those are actually useful). But yeah, let's not get into this
2023-08-22 13:35:20 -0400 < mdhughes> Yeah, that's an incorrect but irrelevant opinion.
2023-08-22 13:35:28 -0400 < msavoritias> except maybe chicken a bit. but i am all in on wasm
2023-08-22 13:35:32 -0400 < msavoritias> with hoot
2023-08-22 13:36:34 -0400 < sham1> To close my argument on this, RMS has good thoughts and good ideas. He also has (or at least has had) some... weird ideas which I for one don't really jive with. Mostly stuff he has (had) up on his own personal website as opposed to on the GNU website
2023-08-22 13:37:21 -0400 < dpk> mnieper``: i have written you an email (too long, too long, i’m sorry) replying to your concerns
2023-08-22 13:37:36 -0400 < dpk> (not about the GPL, but about R7RS and John’s resignation)
2023-08-22 13:38:49 -0400 < duncanm> Riastradh hasn’t been around recently, has he?
2023-08-22 13:38:56 -0400 < dpk> he was here this morning
2023-08-22 13:38:57 -0400 < sham1> He was today
2023-08-22 13:38:58 -0400 < mdhughes> Just yesterday!
2023-08-22 13:39:03 -0400 < sham1> Timezones!
2023-08-22 13:39:28 -0400 < mdhughes> https://www.youtube.com/watch?v=QDmWYVdN8ug
2023-08-22 13:39:34 -0400 < mnieper``> dpk: Thanks!
2023-08-22 13:39:48 -0400 < dpk> he watches the logs for things of interest to him and joins when he wants to reply to something, usually
2023-08-22 13:40:09 -0400 < mdhughes> Kibo but fewer stories about stupid puppies.
2023-08-22 13:45:31 -0400 < sham1> mdhughes: what did I just watch
2023-08-22 13:45:42 -0400 < msavoritias> to be more concrete with the R7RS-Large thing
2023-08-22 13:46:00 -0400 < mdhughes> One of my favorite bands. Their albums are all amazing.
2023-08-22 13:46:07 -0400 < msavoritias> from my understanding it seems it wants to unify?? R6RS and R7RS for some reason
2023-08-22 13:46:16 -0400 < msavoritias> which seems weird imo
2023-08-22 13:46:19 -0400 < sham1> Yes. It was to heal the rift
2023-08-22 13:46:35 -0400 < sham1> That was caused by some of the controversy around the MUSTard and such
2023-08-22 13:47:08 -0400 < msavoritias> thats another one of the reasons i dont get large really
2023-08-22 13:47:58 -0400 < msavoritias> sham1: from my understanding a almost all the big implementations support r7rs though
2023-08-22 13:48:39 -0400 < msavoritias> and even if there are objections wont this be incompatible with everything? and make r7rs basically obsolete and fracture stuff even more?
2023-08-22 13:48:49 -0400 < msavoritias> i even saw a r8rs somewhere in there as a new name
2023-08-22 13:49:02 -0400 < gwatt> define "big". also, there's a world of difference between r7rs-small and a full r7rs-large (all dockets)
2023-08-22 13:52:28 -0400 < dpk> msavoritias: what do you mean by ‘incompatible with everything’?
2023-08-22 13:52:50 -0400 < mnieper``> msavoritias: Chez (which is one of the most important impls) doesn't support R7RS.
2023-08-22 13:53:19 -0400 < mnieper``> It does support the part that is similar enough to R6RS.
2023-08-22 13:55:22 -0400 < msavoritias> dpk: if it basically tries to combine r7rs and r6rs into some sort of combined thing that is not compatible with either of them independently no?
2023-08-22 13:55:52 -0400 < msavoritias> like a r7rs only mode with the large specification or a r6rs only mode with the large specification
2023-08-22 13:55:58 -0400 < dpk> the incompatibilities between R7RS small and R6RS are not that many
2023-08-22 13:56:23 -0400 < dpk> an implementation can support both R7 small and R6 at the same time quite sensibly
2023-08-22 13:56:32 -0400 < gwatt>  of the incompatibilities are in the library/define-library forms
2023-08-22 13:56:42 -0400 < dpk> well, an implementation can just support both
2023-08-22 13:56:47 -0400 < gwatt> s/^/Much/
2023-08-22 13:57:12 -0400 < gwatt> Yes, if I hadn't hit enter too early I would have included that point too. :)
2023-08-22 13:57:16 -0400 < dpk> that’s in fact why WG1, though i still think it was a mistake for them to define their own form instead of just subsetting R6’s library, at least had the common sense to give theirs a different name
2023-08-22 13:58:40 -0400 < dpk> there are lexical syntax differences, but again R6RS anticipated this with the #!r6rs reader directive
2023-08-22 14:16:07 -0400 < msavoritias> fair. i will wait and see then
2023-08-22 14:35:16 -0400 < klovett> oh no, i forgot fluorinated-time
2023-08-22 14:37:58 -0400 < Zipheir> ... a sinister Commie plot to sap and impurify our timestamps.
2023-08-22 14:40:03 -0400 < klovett> i'm thinking of adding as an "easter egg" to the CHICKEN srfi-19-time module. just need to understand time-utc/time-monotonic/... <=> time-fluorinated.
2023-08-22 14:40:03 -0400 < gwatt> If the commies can get everyone to use YYYY-MM-DD time format, better red than dead
2023-08-22 14:45:57 -0400 < Zipheir> Amen.
2023-08-22 14:56:13 -0400 < jcowan> msavoritias: It's important to realize that whereas Perl has a monopoly implementation, and most "modern" languages have a Maximum Leader implementation and all the others must pant to keep up with it, Scheme has a *lot* of implementations and no clear Maximum Leader.  "Let a hundred flowers bloom" is literally true: that's about the number of implementations.
2023-08-22 14:56:29 -0400 < jcowan> So standardization is an inherently different process here.
2023-08-22 14:57:03 -0400 < msavoritias> i understand. i am involved with xmpp which brings some perspectives for sure :D
2023-08-22 14:58:34 -0400 < jcowan> Of course, there are plenty of people who think the new name of the R7RS library form is the worst thing about it.  "Infinite are the arguments of mages."
2023-08-22 14:58:49 -0400 < jcowan> hmm, lessee, from scrool:
2023-08-22 14:58:54 -0400 < jcowan> where is dpk's process spec?
2023-08-22 14:59:03 -0400 < msavoritias> heh. yeah its always disagreeing :P
2023-08-22 14:59:26 -0400 < Zipheir> jcowan: It's sham1's process library, currently. That was dpk's suggested name for the type.
2023-08-22 14:59:46 -0400 < jcowan> Oh.  Okay, URL?
2023-08-22 14:59:53 -0400 < Zipheir> https://codeberg.org/sham1/pre-srfi/src/branch/main/low-level-process-manipulation.md
2023-08-22 15:00:17 -0400 < jcowan> Ta.
2023-08-22 15:03:24 -0400 < sham1> If you have any complaints (aside from nomenclature, I just haven't gotten to fixing it), I'd be happy to hear them
2023-08-22 15:03:54 -0400 < jcowan> Dammit, I wrote out the "noncharacters" approach to OS strings, but it didn't get saved in the wiki somehow
2023-08-22 15:05:04 -0400 < jcowan> Oh, I found it, it's just not linked into the root
2023-08-22 15:05:07 -0400 < jcowan> sham1: https://codeberg.org/scheme/r7rs/wiki/Noncharacter-error-handling
2023-08-22 15:05:26 -0400 < jcowan> how to get rid of the "string-or-bytevector" horror
2023-08-22 15:10:13 -0400 < sham1> I like the use of the replacement character as an escape, so you could still get your surrogate pairs for UTF-16 and not confuse them for this
2023-08-22 15:14:29 -0400 < jcowan> no, the replacement char is U+FFFD (which is not a noncharacter), the escape is U+FFFE
2023-08-22 15:15:18 -0400 < jcowan> If you are using a 16-bit encoding, you use the same principles, so a u16 value that is an unpaired surrogate is encoded as 4 noncharacters.
2023-08-22 15:15:22 -0400 < sham1> Oh I misread
2023-08-22 15:15:31 -0400 < sham1> Oh
2023-08-22 15:15:33 -0400 < sham1> oh
2023-08-22 15:15:41 -0400 < sham1> That'll be interesting
2023-08-22 15:16:28 -0400 < sham1> Would there be a way for us to specify these "non-characters" in string literals?
2023-08-22 15:17:10 -0400 < sham1> Ideally such that I as the user don't need to know about them being these non-characters
2023-08-22 15:17:16 -0400 < sham1> Like those specifically
2023-08-22 15:23:44 -0400 < mnieper``> dpk: Thank you once more for your long email; I am currently away from home for some days so please don't worry when a proper response takes time.
2023-08-22 15:24:27 -0400 < jcowan> A literal is a sequence of characters, so you'd use \u escapes to get the noncharacters in.  A procedure that appends strings and exact integers together would be useful for specifying the appropriate nonchar, although they are meant to be easy to figure out: if you want the internal representation of byte xy, type "\uFDDx;\uFDEy;"
2023-08-22 15:28:20 -0400 < sham1> I like this schema. I'm just curious about how it's gonna work, but it seems to be quite nice
2023-08-22 15:28:29 -0400 < jcowan> Thank you
2023-08-22 15:29:20 -0400 < dpk> sham1: i don’t know if nomenclature includes this, but process-data-create should be called make-process-spec
2023-08-22 15:29:39 -0400 < dpk> (assuming you go through with my rename of the whole thing)
2023-08-22 15:30:08 -0400 < sham1> The wiki article states that for getting path names on POSIX this schema is used with the utf-8 transcoder. Any opinion on whether this should also apply to the std{in,out,err} ports?
2023-08-22 15:30:35 -0400 < sham1> And how about when opening new files using the R7RS-small procedures which seem to be textual by default 
2023-08-22 15:30:35 -0400 < jcowan> I'm not clear if your low-level-process-manipulation stuff is informed by my https://github.com/johnwcowan/r7rs-work/blob/master/ProcessesCowan.md or not.  Did you develop yours independently?
2023-08-22 15:30:44 -0400 < sham1> I developed it independently 
2023-08-22 15:31:08 -0400 < jcowan> There are separate open procedures for textual and binary in R7RS
2023-08-22 15:31:52 -0400 < jcowan> however, whether the *file* is textual or binary is independent of its *name*, which is always quasi textual, except that it can contain garbage.
2023-08-22 15:32:12 -0400 < jcowan> I'd be glad to hear what you think of ProcessesCowan
2023-08-22 15:33:05 -0400 < jcowan> I'd be willing to switch from a setup dictionary to an opaque object
2023-08-22 15:33:21 -0400 < jcowan> the nice thing about a dictionary is that it's extensible
2023-08-22 15:35:46 -0400 < sham1> I should probably write into my spec that implementations should feel free to extend the type with platform-specific things
2023-08-22 15:36:30 -0400 < jcowan> That works too
2023-08-22 15:37:02 -0400 < jcowan> I also like the idea of process runners (analogous to Python's Trio, but simpler)
2023-08-22 15:37:14 -0400 < sham1> As long as those extensions are documented, it should be fine. You can always cond-expand them away
2023-08-22 15:37:44 -0400 < sham1> And because of how the spec is designed, an identity function would be a valid implementation 
2023-08-22 15:37:53 -0400 < jcowan> Oh, sorry, you specified stdin/out/err in particular.
2023-08-22 15:38:41 -0400 < jcowan> I assume that in R6 terms they would use the (native-transcoder), the value of which is system-dependent.  So it's a QoI issue.
2023-08-22 15:38:47 -0400 < sham1> Ah, alright
2023-08-22 15:39:21 -0400 < sham1> Anyway, my idea is that my library would and could be used to implement at least parts of ProcessesCowan and things like scsh
2023-08-22 15:39:43 -0400  * jcowan nods
2023-08-22 15:41:45 -0400 < sham1> So the library wouldn't provide pipes, that'd be the implementation's job, but it can then also provide a thing for `process-spec` such that you can essentially just `dup2` a file descripto
2023-08-22 15:45:27 -0400 < jcowan> I don't see the difference between creating pipes and creating processes.  Make-pipe is fundamentally a variant of open-binary-file
2023-08-22 16:59:00 -0400 -!- decfed is now known as sam-d
--- Day changed Wed Aug 23 2023
2023-08-23 00:49:57 -0400 < dpk> my main issue with the noncharacter encoding is that it requires treating even correctly-encoded streams specially
2023-08-23 00:50:37 -0400 < dpk> unlike, say, using made-up codepoints U+110000 through U+1100FF
2023-08-23 00:51:22 -0400 < dpk> but if we’re unwilling to make chars in any way not represent valid Unicode codepoints, and want strings to conceptually be vectors of chars, i guess any solution along these lines will have the same issue
2023-08-23 00:52:04 -0400 < dpk> (Python 3 uses unpaired surrogates in its strings for this, but that would either mean chars are not codepoints (since a single surrogate is not a codepoint), or that strings are not vectors of chars)
2023-08-23 01:24:11 -0400  * dpk finds an erratum in R6RS …
2023-08-23 01:28:53 -0400 < sham1> Within the constraints we have, I find that the non-character encoding is probably the best choice we have. I'd also ideally do U+110000 to U+1100FF but that would pretty much limit the character representation to either full codepoints or UTF-8
2023-08-23 01:29:04 -0400 < sham1> You can't represent those with UTF-16.
2023-08-23 01:30:06 -0400 < sham1> That in turn would harm implementations on the JVM like Kawa, .NET CLR based things like IronScheme and JS-based Schemes such as Lips
2023-08-23 01:30:34 -0400 < sham1> All of these things have their own funky UTF-16 stuff to allow for shenanigans 
2023-08-23 01:31:55 -0400 < dpk> aside from the actual error i just found (second example of the integer->char procedure), it also seems philosophically wrong that R6RS justifies the existence of the character type by saying ‘most things that a literate human would call a “character” can be represented by a single Unicode scalar value […] For example, Roman letters, Cyrillic letters, Hebrew consonants, and most Chinese characters fall into this category.’
2023-08-23 01:33:06 -0400 < dpk> in R7RS i intend to make the exact opposite case, that ‘Unicode scalar values’ are a shitty compromise that represent nothing in particular that is meaningful to a human but are nonetheless the best we can offer without introducing behaviour which is specific to whichever Unicode version an implementation happens to support
2023-08-23 01:34:24 -0400 < dave0> you can stuff three 21 bit unicode code points into a 64 bit register with 1 bit left over for parity
2023-08-23 01:37:10 -0400 < mdhughes> https://home.unicode.org/about-unicode/
2023-08-23 01:37:18 -0400 < mdhughes> Just quote them, keep your ideology out of it.
2023-08-23 01:38:41 -0400 < dpk> i’m not sure how that page resolves the issue i refer to (it doesn’t mention anything relevant to it) nor what is especially ideological in what i said
2023-08-23 01:39:48 -0400 < mdhughes> universal, uniform, unique address exactly that issue.
2023-08-23 01:40:29 -0400 < mdhughes> Obviously they *are* meaningful to most people, because WE ARE TYPING CHARACTERS NOW.
2023-08-23 01:41:28 -0400 < dpk> no, i think you are misunderstanding the issue. i am not saying that Unicode is not those things, but that it is not true that a single Unicode scalar value can represent ‘most things that a literate human would call a “character”’. to claim so is to ignore the very large number of languages in which a ‘character’ is something which requires a sequence of multiple scalar values to be represented in Unicode
2023-08-23 01:41:48 -0400 < mdhughes> It's unfortunate that I can't cleanly represent tlhIngan Hol in its natural alphabet, but eventually they'll address that.
2023-08-23 01:42:22 -0400 < mdhughes> Almost all modern languages *are* represented in Unicode.
2023-08-23 01:43:05 -0400 < mdhughes> A character isn't entirely isolated in Unicode, but a sequence of them does represent characters.
2023-08-23 01:43:33 -0400 < dpk> right. now compare that with the quote from R6RS above
2023-08-23 01:44:09 -0400 < mdhughes> And *MOST THINGS* can.
2023-08-23 01:44:42 -0400 < mdhughes> Emoji and some of the less popular Chinese characters are exceptions to MOST.
2023-08-23 01:45:23 -0400 < dpk> entire writing systems depend on it (Hangul most notably, and any abugida)
2023-08-23 01:45:25 -0400 < mdhughes> Maybe they didn't show you the Venn diagram (all (most))
2023-08-23 02:08:41 -0400 < sham1> IJ in Dutch could easily be argued to be a singular character, yet it usually takes the use of two codepoints. And that's even without leaving Europe. And yeah, the ligature exists as a singular codepoint, but it's not exactly easy to write
2023-08-23 02:08:58 -0400 < sham1> Especially given that Dutch people use the American English keyboard layout 
2023-08-23 02:11:55 -0400 < dpk> another reason i should have chosen the Netherlands instead of Germany!
2023-08-23 02:13:25 -0400 < dpk> fortunately this is an all-QWERTY household (well, my fiancé usually types on Neo2, but his keyboard is physically QWERTY and he switches it back if i have to use his computer), but i still have to type on QWERTZ occasionally and it’s maddening
2023-08-23 02:16:09 -0400 < dpk> also, try selling a second-hand laptop in Germany that has a QWERTY keyboard. nobody will have it
2023-08-23 02:16:19 -0400 < dpk> /rant
2023-08-23 02:39:21 -0400 -!- Netsplit *.net <-> *.split quits: enzuru, kjak, pyro, xelxebar, dstein64, aeth, r0tty, hernan, gnomon
2023-08-23 02:39:21 -0400 -!- dstein64- is now known as dstein64
2023-08-23 03:19:15 -0400 -!- aeth_ is now known as aeth
2023-08-23 03:21:01 -0400 -!- xelxebar_ is now known as xelxebar
2023-08-23 04:10:58 -0400 < lockywolf> Abelson and Sussman reference Spivak's Calculus on Manifolds in SICP. Is there some nice Scheme code to work that book through?
2023-08-23 05:41:38 -0400 < mnieper``> dpk: I bought a QWERTY keyboard for my laptop in Germany. :)
2023-08-23 06:27:44 -0400 < lockywolf> perhaps, misleadingly, AZERTY keyboard is not used in Azerbaijan 
2023-08-23 07:08:45 -0400 < qkote> hi I'm trying to write a version of define that works with strings for example (define "a" 10)  a -> 10
2023-08-23 07:08:46 -0400 < qkote> so far I wrote this but I don't know what is my problem, I'm pretty new to syntax-case macros.
2023-08-23 07:08:46 -0400 < qkote> I get "encountered raw symbol in macro output in subform hello of (test "hello" 10)" http://ix.io/4EiD
2023-08-23 07:17:37 -0400 < dpk> qkote: you need to convert the symbol to an identifier using datum->syntax
2023-08-23 07:20:06 -0400 < qkote> what is the difference between an identifier and a symbol aren't they the same thing and where should I do this conversion?
2023-08-23 07:20:49 -0400 < lockywolf> in normal lisps, symbols are identifiers :D
2023-08-23 07:21:12 -0400 < qkote> :)
2023-08-23 07:21:46 -0400 < sham1> s/normal/non-hygienic/
2023-08-23 07:22:13 -0400 < qkote> my impression so far is that identifiers can be symbols that don't point have any values yet 
2023-08-23 07:23:17 -0400 < qkote> this seems to work but I can't understand why http://ix.io/4EiI
2023-08-23 07:23:22 -0400 < lockywolf> does r7rs even have "symbols"?
2023-08-23 07:23:45 -0400 < dpk> an identifier is a kind of wrapper around a symbol that preserves the lexical scope of the place it was created. in your case, you want to pretend it has the lexical scope of the place your macro is used
2023-08-23 07:24:28 -0400 < dpk> qkote: are you using Racket? that shouldn’t work in ‘standard’ Scheme (but Racket is somewhat different here)
2023-08-23 07:24:37 -0400 < qkote> no i'm on guile
2023-08-23 07:24:42 -0400 < dpk> oh, weird
2023-08-23 07:25:00 -0400 < qkote> so an identifier is the same thing as a wrapped syntax object if the syntax object is a symbol right?
2023-08-23 07:26:03 -0400 < dpk> if the datum underlying the syntax object is a symbol, yes. a symbol cannot be (or be part of) a syntax object itself, which is why your original macro failed
2023-08-23 07:27:08 -0400 < sham1> lockywolf: yes. For example the thing that the form 'foo evaluates to is a symbol even in r7rs
2023-08-23 07:27:33 -0400 < sham1> `(symbol? 'foo) => #t`
2023-08-23 07:27:34 -0400 < dpk> a macro transformer must return a syntax object, and all ‘symbols’ in a syntax object must in fact be identifiers, which are wrapped syntax objects
2023-08-23 07:29:02 -0400 < qkote> do you guys have any tips for learning syntax-case macros I've tried many different sources but they all seem to be the same text from r6rs-lib with some minor changes or they are outdated now 
2023-08-23 07:31:26 -0400 < dpk> do you already know syntax-rules macros?
2023-08-23 07:31:42 -0400 < qkote> yes 
2023-08-23 07:32:05 -0400 < qkote> at least i think i know them there are always surprises 
2023-08-23 07:34:26 -0400 < qkote> I understand the pattern matching fenders and the literals part, what confuses me is the quasisyntax, with-syntax, datum->syntax and syntax->datum
2023-08-23 07:37:34 -0400 < qkote> for example in the last link that I sent how can I do the same thing the function s2s does within my quasisyntax expression
2023-08-23 07:39:29 -0400 < dpk> you can do #`(datum->syntax x (string->symbol (syntax->datum #'name)))
2023-08-23 07:39:40 -0400 < dpk> err, #, i mean at the start
2023-08-23 07:40:18 -0400 < qkote> you mean like this right?
2023-08-23 07:40:19 -0400 < qkote>        #`(define
2023-08-23 07:40:19 -0400 < qkote> 	   #,#`(datum->syntax x (string->symbol (syntax->datum #'name)))
2023-08-23 07:40:20 -0400 < qkote> 	   value)
2023-08-23 07:40:25 -0400 < qkote> sry
2023-08-23 07:40:40 -0400 < dpk> no, i mean only #, and not #,#`
2023-08-23 07:40:43 -0400 < qkote> #`(define #,#`(datum->syntax x (string->symbol (syntax->datum #'name))) value)
2023-08-23 07:41:19 -0400 < qkote> oh ok
2023-08-23 07:43:38 -0400 < qkote> when should I use with-syntax and is there a somethings that with-syntax can do that #` can't do?
2023-08-23 07:44:47 -0400 < dpk> with-syntax can match a pattern like syntax-case can, and within the body of with-syntax the pattern variables from that pattern will be available as if they’d been in the syntax-case pattern
2023-08-23 07:45:14 -0400 < dpk> but in principle you can choose to write a macro in either style
2023-08-23 07:45:28 -0400 < dpk> it’s generally a matter of preference
2023-08-23 07:46:14 -0400 < qkote> ok thanks a lot, this was a big help I couldn't find answers anywhere else :) 
2023-08-23 07:51:31 -0400 < dpk> syntax->datum is needed because syntax objects, as mentioned, have to remember what variables were in scope at the point they were created. if we use ‘let’ in the expansion of our macro, we always want that to be the ‘let’ which we know about, not one which the macro user has potentially rebound at the place where they’re using the macro. they also carry around information that’s useful for debugging when an error occurs, like the 
2023-08-23 07:51:31 -0400 < dpk> file and line number the syntax object was found at. but in procedural syntax-case macros we sometimes want to access the datums without that syntactic information, especially if they’re things like numbers or strings, as in your example
2023-08-23 07:52:59 -0400 < dpk> if they’re in fact symbols, they represent identifiers, which are the bits where we’re actually concerned about remembering that scope information. if you want to convert something into an identifier so it becomes a variable name, you use datum->syntax, but you have to tell it where to get that scope information from
2023-08-23 07:53:40 -0400 < dpk> to do this, you use another identifier, but it does appear that Guile lets you use other wrapped syntax objects as well. the first argument to datum->syntax is the identifier whose scope will be copied onto the new variable you’re creating
2023-08-23 07:55:17 -0400 < qkote> so the first argument to datum->syntax can be any identifier  that is present during the macro expansion  
2023-08-23 07:55:40 -0400 < qkote> so the identifier has to be a bound identifier is that right?
2023-08-23 07:55:43 -0400 < dpk> usually this should be the keyword that was used to invoke the macro, so you usually change your pattern from, in your example, (_ name value) to something like (kw name value) and do (datum->syntax #’x (string->symbol etc etc etc)). Guile probably takes the keyword for you when you give it the entire value of x, but i’m not sure
2023-08-23 07:56:12 -0400 < dpk> to your first question: yes; to your second, not necessarily!
2023-08-23 07:56:22 -0400 < qkote> hmm
2023-08-23 07:57:11 -0400 < qkote> do you know of any projects or source file that has a lot of syntax-case macros that I can study? 
2023-08-23 07:57:17 -0400 < dpk> the exception to the rule i gave above is that sometimes you’re creating new identifier names based on a symbol/identifier the user gave you. maybe you don’t like Scheme’s record system and are making your own, and you want something like (define-struct mytype) to automatically give the user procedures called make-mytype, mytype?, and probably some more for the fields
2023-08-23 07:58:05 -0400 < qkote> yeah I think racket has a similar feature 
2023-08-23 07:58:05 -0400 < dpk> in that case you want to use mytype as the first argument to datum->syntax, because that identifier might have come out of a macro expansion itself, and all the derivatives of it should have the same scoping information, even if that identifier isn’t bound anywhere (yet)
2023-08-23 07:58:40 -0400 < dpk> hmm, i’m not sure i can think of one
2023-08-23 08:00:31 -0400 < qkote> ok thanks again I'm going to play around with syntax-case macros a bit more and try to find some more questions for you guys thanks again it was a huge help 
2023-08-23 08:05:19 -0400 < sham1> Isn't the use of with-syntax so identical that it's just a macro over syntax-case
2023-08-23 08:06:30 -0400 < dpk> yep
2023-08-23 08:28:31 -0400 < mnieper``> qkote: Please see here: https://github.com/mnieper/scheme-macros
2023-08-23 08:28:55 -0400 < mnieper``> It is a tutorial (written by myself), which hopefully covers also all corner cases.
2023-08-23 09:47:50 -0400 < jcowan> dpk: the main reasons for making a new form was that R6RS `library` is not extensible, and we needed at least `include` and the possibility of new things later, like declarations.
2023-08-23 09:49:40 -0400 < lockywolf> never had a need to use syntax-case :(
2023-08-23 09:52:50 -0400 < jcowan> Most people barely use syntax-rules; they certainly don't exploit its Turing-completeness.
2023-08-23 09:55:53 -0400 < qkote> mnieper``: thanks seems like a great resource examples given towards end are just what I was looking for
2023-08-23 10:17:47 -0400 < mnieper``> jcowan: Why did you *need* to include `include'? Independently of this, why wouldn't have top-level include sufficed? (So a typical library would have been (library (foo) (export ...) (import ...) (include ...)).)
2023-08-23 10:23:35 -0400 < jcowan> I don't know the exact answer (it would require a search of the list archives), but I believe that the answer is the same as before: to allow static analysis.  Certainly `include-library-declarations` cannot be reduced to some macro in the body of the library.
2023-08-23 10:23:51 -0400 < jcowan> s/the answer/the general answer
2023-08-23 10:24:56 -0400 < mnieper``> `include-library-declarations' was only added late as an afterthought IIRC.
2023-08-23 10:25:05 -0400 < jcowan> True.
2023-08-23 10:25:45 -0400 < mnieper``> R7RS already includes `include' at the top-level of a program, so static program analysis cannot be the reason.
2023-08-23 10:27:22 -0400 < jcowan> That too was an afterthought (and I opposed it)
2023-08-23 10:28:12 -0400 < jcowan> It is not reasonable to look for reasons for the output of a political process.
2023-08-23 10:35:02 -0400 < jcowan> I used to often be asked "Why did WG1 decide on this or that", to which the invariable answer is either "We didn't decide, we just inherited it from R5RS" or "More people voted for it than against it."  Trying to extract a rationale would be futile.
2023-08-23 13:28:54 -0400 < dpk> anyone seriously exploiting the Turing-completeness of syntax-rules (without em-syntax-rules as a wrapper, say) should reconsider their life decisions
2023-08-23 13:29:20 -0400 < dpk> (i, as the author of such abominations as https://gitlab.com/dpk/presrfis/-/blob/master/keyword-arguments/lambda-optional.scm, have already done this)
2023-08-23 13:30:56 -0400 < dpk> (that one looks worse than it is because of some code duplication which i could eliminate: the parsing code is duplicated for the two different forms, because i thought they had to have somehow slightly different syntax, but they ended up being the same)
2023-08-23 13:44:52 -0400 < Zipheir> dpk: People have fun with Turing tar-pits all the time. There's nothing wrong with that. Now, I wouldn't recommend using syntax-rules that way in practical programs, of course.
2023-08-23 15:16:12 -0400 < dpk> what naming convention should we adopt for a *macro* which expands into #t or #f?
2023-08-23 15:16:31 -0400 < sham1> Probably just the same as predicats
2023-08-23 15:16:39 -0400 < sham1> <name>?
2023-08-23 15:17:14 -0400 < acdw> why is a different naming convention needed?
2023-08-23 15:17:42 -0400 < dpk> why i ask: with identifier properties we can have a macro version of CL’s boundp/fboundp, and with meta-cond, this actually becomes useful
2023-08-23 15:20:23 -0400 < dpk> i think a different naming convention might tip people off that what they want (when writing code) is not (bound? 'some-identifier) but (bound? some-identifier), and (when reading code) that some-identifier will not be interpreted as a variable whose value is the name of a variable which will be tested for boundness, but is actually the name that will be tested for boundness itself
2023-08-23 15:20:52 -0400 < acdw> ohhh that makes sense
2023-08-23 15:21:35 -0400 < dpk> i note that Kiselyov called his magic trick for detecting symbols/identifiers in syntax-rules macros symbol?? with two question marks, but that's the only precedent i know of
2023-08-23 15:22:39 -0400 < dpk> also, we might actually want a bound? procedure for use in macro transformers, which will take an identifier as a syntax object, rather than a static name
2023-08-23 15:24:28 -0400 < sham1> (identifier-bound? identifier)
2023-08-23 15:24:35 -0400 < sham1> Just specify that it's syntax
2023-08-23 15:26:47 -0400 < Zipheir> It's either that, ??, or a whole new notational convention.
2023-08-23 15:27:02 -0400 < sham1> bound‽
2023-08-23 15:27:35 -0400 < Zipheir> If you're OK with non-ASCII names, that or ¿bound might be acceptable.
2023-08-23 15:27:36 -0400 < dpk> hehe. i’ve given up on the idea of exporting lambda as λ because i don’t think people would buy it. ‽ is even more out there
2023-08-23 15:27:39 -0400 < sham1> Or if an ever more silly suggestion is allowed: bound¿
2023-08-23 15:27:55 -0400 < Zipheir> Hah, same character, different position.
2023-08-23 15:28:13 -0400 < dpk> sham1 is probably correct that just following the standard for predicate procedures is the right thing to do
2023-08-23 15:29:52 -0400 < dpk> i’d also like a better name for meta-cond than meta-cond, but have not yet come up with one
2023-08-23 15:29:53 -0400 < haugh> I keep flirting with unicode but it feels like dancing along the ledge of a deep ravine where can be seen the worth of passions pledged
2023-08-23 15:30:11 -0400 < haugh> i.e. APL
2023-08-23 15:30:52 -0400 < sham1> But yeah, I think that just sticking to the "expected" naming convention is probably for the best
2023-08-23 15:32:01 -0400 < acdw> ?? seems like a good compromise. tells the reader it's different but still uses ascii and .. stuff
2023-08-23 15:32:43 -0400 < Zipheir> Sticking to ASCII at this point is atavistic, but that's not a reason for roccoco names.
2023-08-23 15:32:49 -0400 < aeth> I just render "lambda" as "λ" locally even though the file still has it as "lambda"
2023-08-23 15:33:09 -0400 < aeth> It usually doesn't affect indentation so it usually doesn't cause issues.
2023-08-23 15:33:14 -0400 < Zipheir> haugh: APL has nothing on Agda.
2023-08-23 15:33:16 -0400 < acdw> or boundm? or mbound? or .. .something. I don't know if bound?? is rococo exactly ..  i mean there's only 2 levels we're talking about here
2023-08-23 15:33:22 -0400 < dpk> Zipheir: the problem with Unicode identifiers is that people complain they can’t type them
2023-08-23 15:33:34 -0400 < acdw> it'd be one thing if there were arbitrary .. bound???????? is getting a little ridiculous
2023-08-23 15:33:45 -0400 < aeth> which is why "lambda" becoming "λ" (which I can type, because I added it to my compose key) is good.
2023-08-23 15:33:51 -0400 < aeth> backspace on λ and get lambd
2023-08-23 15:33:58 -0400 < acdw> or have a separate "this is a macro" convention,,, like $bound? or &bound? or something idk
2023-08-23 15:34:28 -0400 < sham1> I'd say that identifier-bound? would be the best, because the fact that it's calling the thing an identifier should probably clue the reader in that it's not just a simple procedure
2023-08-23 15:35:06 -0400 < sham1> Let's not overcomplicate this
2023-08-23 15:35:20 -0400 < Zipheir> dpk: At some point they're going to have to bite the bullet.
2023-08-23 15:35:23 -0400 < sham1> Although $bound? would be reminiscent of Kernel. Not sure we'd be ready for that
2023-08-23 15:35:40 -0400 < dpk> and anyway, the bikeshed should clearly be painted red
2023-08-23 15:35:48 -0400 < acdw> no, maroon!
2023-08-23 15:35:58 -0400 < sham1> It should match the rest of the nuclear power plant. Concrete gray!
2023-08-23 15:36:00 -0400 < acdw> dammit we've talked about this. maroon will bring out the colors of the surrounding hills
2023-08-23 15:36:18 -0400 < Zipheir> I'm in favor of exporting λ.
2023-08-23 15:36:24 -0400 < sham1> Ditto
2023-08-23 15:36:29 -0400 < sham1> Just as an option
2023-08-23 15:37:19 -0400 < dpk> according to the plan, lambda will be in the second fascicle, which i expect to be quite lightweight
2023-08-23 15:37:25 -0400 < dpk> early 2024
2023-08-23 15:37:36 -0400 < dpk> we’ll see what people have to say about it then
2023-08-23 15:38:24 -0400 < Zipheir> Anything is better than Haskell's horrible \ lambda.
2023-08-23 15:38:58 -0400 < acdw> idk i think /. from shen might be worse
2023-08-23 15:39:10 -0400 < acdw> i think ... or is it .\ ? either way
2023-08-23 15:39:12 -0400 < Zipheir> It's backwards as well as being ASCII art.
2023-08-23 15:39:20 -0400 < acdw> exactly!
2023-08-23 15:39:23 -0400 < haugh> I like gauche's circumflex lambdas
2023-08-23 15:40:13 -0400 < aeth> if you're going to use ASCII art might as well make it ^_^ instead of lambda
2023-08-23 15:40:44 -0400 < aeth> or I guess ^-^ is Lispier
2023-08-23 15:41:48 -0400 < sham1> UwU
2023-08-23 15:43:06 -0400 < acdw> uwu-lisp
2023-08-23 15:43:07 -0400 < gwatt> .\ at least _looks_ like the actual λ
2023-08-23 15:43:19 -0400 < aeth> sort of
2023-08-23 15:43:36 -0400 < aeth> although it "breaks" \
2023-08-23 15:43:41 -0400 < gwatt> even if it's terrible to type on a standard US keyboard. Two wide pinkie movements? no thanks
2023-08-23 15:43:51 -0400 < dpk> yes, we can’t use anything with \ in
2023-08-23 15:44:07 -0400 < gwatt> .\\
2023-08-23 15:44:12 -0400 < aeth> much better
2023-08-23 15:44:20 -0400 < sham1> I don't have a trouble typing `.\` on a US layout. On the Finnish layout? No chance, requires AltGr and that makes it horrible
2023-08-23 15:44:40 -0400 < aeth> \ isn't particularly easy to type, especially since if you miss you hit enter/return
2023-08-23 15:44:41 -0400 < sham1> Any trouble, even
2023-08-23 15:45:01 -0400 < acdw> just make .. a lambda
2023-08-23 15:45:24 -0400 < haugh> typing five keys is a good reminder that procedure creation isn't free
2023-08-23 15:45:35 -0400 < Zipheir> \ doesn't even exist. :)
2023-08-23 15:45:35 -0400 < haugh> six
2023-08-23 15:45:53 -0400 < aeth> or maybe just use ⅄, which looks close enough to λ
2023-08-23 15:45:58 -0400 < Zipheir> cf. https://xkcd.com/1638/
2023-08-23 15:46:05 -0400 < gwatt> I like "L" as an alias for lambda
2023-08-23 15:46:18 -0400 < sham1> defn
2023-08-23 15:46:24 -0400 < acdw> Y looks like an upside down lambda
2023-08-23 15:46:32 -0400 < gwatt> sham1: that'd be an alias for define
2023-08-23 15:46:35 -0400 < sham1> That's reserved for the Y combinator
2023-08-23 15:46:36 -0400 < haugh> I like cut and cute from SRFI-26 but they're not quite flexible enough.
2023-08-23 15:46:50 -0400 < haugh> and it's weird to mix an english word with <> and <...>
2023-08-23 15:46:57 -0400 < sham1> gwatt: fine. `fn`
2023-08-23 15:47:05 -0400 < Zipheir> The lack of "deep" cut is the problem with SRFI 26.
2023-08-23 15:47:09 -0400 < acdw> what's wrong with lambda ?
2023-08-23 15:47:26 -0400 < sham1> It's long according to some
2023-08-23 15:47:44 -0400 < haugh> Zipheir, agreed. I'm working on an anaphoric syntax rn. Trying to use only words
2023-08-23 15:47:48 -0400 < aeth> just replacing "lambda" with λ on the rendering side works well enough
2023-08-23 15:47:52 -0400 < aeth> it looks cool, yes
2023-08-23 15:47:57 -0400 < Zipheir> Indeed, Al* Petrofsky suggested that 'cut' wouldn't even be necessary if 'lambda' were λ.
2023-08-23 15:48:03 -0400 < gwatt> I think that having "L" as lambda, L0 for (lambda () ...) and (L1 <id> ...) as (lambda (<id>) ...) would remove the need for cut
2023-08-23 15:48:22 -0400 < Zipheir> Just embrace λ.
2023-08-23 15:48:27 -0400 < aeth> (λ ()
2023-08-23 15:48:30 -0400 < aeth> (lambda ()
2023-08-23 15:48:42 -0400 < gwatt> Zipheir: idonwanna
2023-08-23 15:49:02 -0400 < acdw> # is clojurian syntax, let's just keep overloading #
2023-08-23 15:49:12 -0400 < haugh> I'm attracted to the flat declaration, especially in HOF-oriented code.
2023-08-23 15:49:13 -0400 < aeth> what if we translate the entire language into Greek so people will have to use Greek keyboards anyway so typing λ isn't a big deal?
2023-08-23 15:49:15 -0400 < Zipheir> I guess a few implementations still cough on non-ASCII identifiers.
2023-08-23 15:49:25 -0400 < acdw> aeth: that's perfect
2023-08-23 15:49:49 -0400 < gwatt> but in all seriousness, how I type non-ascii characters is copy+pasting from a web-search or kcharselect
2023-08-23 15:49:56 -0400 < aeth> ρ7ρς
2023-08-23 15:50:06 -0400 < Zipheir> gwatt: There's got to be a better way.
2023-08-23 15:50:17 -0400 < aeth> I can change my keyboard, and usually there's one that lines up with QWERTY more or less, e.g. for Greek
2023-08-23 15:50:23 -0400 < aeth> but kcharselect is often just as fast for short usage
2023-08-23 15:50:35 -0400 < aeth> and if I need to use it a lot, like with λ, I can just add it to my compose key (if it's not already in it)
2023-08-23 15:50:36 -0400 < Zipheir> I'm using the old greybeard Slackware and I have Xorg's compose key set up.
2023-08-23 15:50:38 -0400 < gwatt> Zipheir: if it takes longer than typing "L" than it's not better, at least not for me
2023-08-23 15:50:57 -0400 < haugh> ϋιμ ωινσ αγαιν
2023-08-23 15:51:01 -0400 < sham1> Р7РС
2023-08-23 15:51:20 -0400 < aeth> for me it's altgr l l, but I think I added it on my own
2023-08-23 15:51:53 -0400 < Zipheir> gwatt: OK, but if you've got any ability to bind keys typing λ is hardly going to take as many keystrokes as 'lambda'.
2023-08-23 15:51:53 -0400 < sham1> Annoyingly that string looks exactly like you could type those Cyrillic characters with Latin
2023-08-23 15:52:01 -0400 < aeth> <Multi_key> <l> <l> : "λ" U03BB # GREEK SMALL LETTER LAMBDA
2023-08-23 15:52:02 -0400 < sham1> \lambda
2023-08-23 15:52:06 -0400 < aeth> in .XCompose
2023-08-23 15:52:11 -0400 < sham1> I can do that in Emacs
2023-08-23 15:52:24 -0400 < aeth> still only a bit faster than lambda
2023-08-23 15:53:05 -0400 < acdw> while we're talking about symbol names, let's change < to decreasing? and > to increasing?
2023-08-23 15:53:06 -0400 < aeth> but what I do is I use pretty-lambdada in Emacs, which gives the pretty-lambda-mode
2023-08-23 15:53:14 -0400 < acdw> or vice-versa, see i get those confused
2023-08-23 15:53:17 -0400 < aeth> https://www.emacswiki.org/emacs/download/pretty-lambdada.el
2023-08-23 15:53:33 -0400 < Zipheir> It's the ultimate bikeshed issue, but I think that "whether or not to use Unicode" is a silly question at this point.
2023-08-23 15:53:46 -0400 < acdw> aeth: you know that `prettify-symbols-mode` is included in emacs right?
2023-08-23 15:54:15 -0400 < acdw> 🚲 🏚 scheme
2023-08-23 15:54:29 -0400 < sham1> If nothing else, being able to use Unicode would shut up naysayers
2023-08-23 15:54:38 -0400 < sham1> Although that's probably not a goal as such
2023-08-23 15:54:51 -0400 < aeth> then R7RS-large can finally be the Perl 6 that detractors have always called it
2023-08-23 15:54:52 -0400 < haugh> Zipheir, somebody got mad at me last week 'cus I use ⇒ for my in-line tests; said it doesn't render in their carefully-selected terminal font
2023-08-23 15:55:09 -0400 < gwatt> perl6/raku galloped into full unicode support  &usage
2023-08-23 15:55:13 -0400 < sham1> Yes
2023-08-23 15:55:14 -0400 < Zipheir> haugh: *sigh*
2023-08-23 15:55:20 -0400 < aeth> But what are we going to rename R7RS-large to? "Raku" is already taken
2023-08-23 15:55:34 -0400 < sham1> ⚛️++ is an atomic increment in Raku
2023-08-23 15:55:39 -0400 < sham1> It's a clever glyph, but still....
2023-08-23 15:56:06 -0400 < Zipheir> sham1: Seriously?
2023-08-23 15:56:10 -0400 < dpk> if SGML is the Common Lisp of markup languages, Raku is nothing more than the Common Lisp of programming languages
2023-08-23 15:56:10 -0400 < aeth> well, my terminal renders 🐈fine
2023-08-23 15:56:16 -0400 < gwatt> aeth: gumbo. or some other food where you just throw anything and everything you have in a pot and hope for the best
2023-08-23 15:56:19 -0400 < sham1> Zipheir: yes
2023-08-23 15:56:35 -0400 < sham1> Zipheir: https://docs.raku.org/type/atomicint#postfix_%E2%9A%9B++
2023-08-23 15:56:38 -0400 < aeth> I suggest that we call the language 🐱
2023-08-23 15:56:45 -0400 < aeth> you have to fully embrace the unicode
2023-08-23 15:56:46 -0400 < sham1> How do you pronounce that
2023-08-23 15:56:51 -0400 < haugh> in french
2023-08-23 15:56:56 -0400 < sham1> I don't speak Unicode
2023-08-23 15:56:57 -0400 < Zipheir> sham1: Thanks. Well, it does seem pretty Perlish.
2023-08-23 15:57:12 -0400 < aeth> > Name: CAT FACE
2023-08-23 15:57:28 -0400 < acdw> +1 for gumbo
2023-08-23 15:57:31 -0400 < aeth> but if that's too simple you can use the slightly different 😸
2023-08-23 15:57:33 -0400 < acdw> more food names please
2023-08-23 15:57:34 -0400 < Zipheir> Unicode must be a Wonka factory playground for Larry Wall with his love of sigils.
2023-08-23 15:57:43 -0400 < aeth> (the latter is "grinning cat face with smiling eyes")
2023-08-23 15:58:06 -0400 < aeth> I don't know what to do with shrimp because there are two options: 🍤 🦐
2023-08-23 15:58:38 -0400 < gwatt> one of them appears to be cooked and the other alive
2023-08-23 15:58:45 -0400 < acdw> well clearly 🦐 is before it's compiled and 🍤 is after
2023-08-23 15:58:47 -0400 < gwatt> do with that observation what you will
2023-08-23 15:59:08 -0400 < aeth> well, Java would be 🏭
2023-08-23 15:59:17 -0400 < aeth> or rather 🏭🏭
2023-08-23 15:59:53 -0400 < haugh> Zipheir, would you trade 26's splicing syntax <...> for "deeper" anaphors?
2023-08-23 16:00:11 -0400 < aeth> instead of λ we can use 🐑da
2023-08-23 16:00:51 -0400 < sham1> Zipheir: thankfully you can also just write `atomic-fetch-inc` and not need to use the sigil, but yeah
2023-08-23 16:00:54 -0400 < acdw> aeth: now we're talking
2023-08-23 16:01:21 -0400 < sham1> Also TIL that Raku supports kebab case
2023-08-23 16:02:27 -0400 < acdw> dammit you're telling me there's no kebab emoji
2023-08-23 16:02:39 -0400 < gwatt> Even more than C++, when asked the question "Should we support $feature/$functionality/$aesthetic", Raku's answer is always "YES"
2023-08-23 16:03:03 -0400 < aeth> I can't wait until an R7RS-large implementation of it
2023-08-23 16:03:20 -0400 < gwatt> I wonder if there's a scheme impl for the parrot vm
2023-08-23 16:03:35 -0400 < sham1> gwatt: C++ is similar except that it also asks "will this hurt performance?"
2023-08-23 16:04:14 -0400 < dpk> aeth: jcowan’s Algol 60 to Scheme compiler, except it’s a Raku to Scheme compiler?
2023-08-23 16:04:16 -0400 < Zipheir> haugh: Probably, but there should be some way to correctly handle variadic procedures.
2023-08-23 16:04:48 -0400 < aeth> dpk: might as well get a universal language environment out of it
2023-08-23 16:04:55 -0400 < aeth> although Lua would probably be much easier to start with than a larger language
2023-08-23 16:05:13 -0400 < gwatt> why not racket? it's already a platform for devising new languages
2023-08-23 16:05:33 -0400 < sham1> Yeah, compiling Lua to Scheme would be interesting. Scheme to Lua, not so much. Although you'd get the insane performance of LuaJIT
2023-08-23 16:05:51 -0400  * acdw whispers fennel (though that's not scheme)
2023-08-23 16:06:25 -0400 < aeth> gwatt: yes, you could probably implement Racket on top of R7RS-large, too
2023-08-23 16:07:20 -0400 < aeth> sham1: I suspect that LuaJIT is optimized for the impressive microbenchmarks that it advertises with, so compiling another language to it would probably put it on slow paths
2023-08-23 16:11:51 -0400 < sham1> Eh, maybe
2023-08-23 16:12:48 -0400 < sham1> Of course whether or not that's the case, the micro-benchmark results are still quite impressive when it's faster than even the kinds of JIT compilers with millions upon millions of Eurodollars behind them
2023-08-23 16:12:51 -0400 < Zipheir> You could script your game in Scheme instead of Lua.
2023-08-23 16:13:06 -0400 < sham1> Probably a restricted Scheme. Call/cc? Nah
2023-08-23 16:14:01 -0400 < dpk> LuaJIT gets its numbers in part by doing something Lispers consider sacrilege: implementing almost everything in C and nothing in the language itself
2023-08-23 16:14:09 -0400 < Zipheir> It probably wouldn't be much of an improvement over Lua, either, if you didn't design the game to be Scheme-friendly.
2023-08-23 16:14:24 -0400 < Zipheir> GIMP is a sad example of how lame Scheme scripting can be.
2023-08-23 16:14:50 -0400 -!- mirai_ is now known as mirai
2023-08-23 16:18:26 -0400 < sham1> You'd also have to care about the Scheme scripting API
2023-08-23 16:18:34 -0400 < sham1> GIMP didn't care about script-fu
2023-08-23 16:18:55 -0400 < sham1> Also wasn't script-fu a relatively ancient Scheme dialect?
2023-08-23 16:19:42 -0400 < sham1> Oh, actually it's *just* R5RS. I seem to recall it being a lot more ancient
2023-08-23 16:19:49 -0400 < sham1> And it even had the latest stable release in 202
2023-08-23 16:19:51 -0400 < sham1> 2020
2023-08-23 16:23:04 -0400 < Zipheir> It's not even R5RS. You have to use defmacro. :-/
2023-08-23 16:23:35 -0400 < acdw> define-this
2023-08-23 16:23:52 -0400 < Zipheir> The GIMP source is also full of barbarisms like (let ((var #f)) (set! var some-actual-value) ...), as if let were a declaration.
2023-08-23 16:24:16 -0400 < dpk> poor man’s letrec
2023-08-23 16:24:16 -0400 < Zipheir> So Scheme in GIMP was clearly some kind of accident.
2023-08-23 16:24:36 -0400 < Zipheir> dpk: That's what I thought when I first saw that. But no.
2023-08-23 16:25:13 -0400 < Zipheir> They've got Python scripting now, which is probably a better fit.
2023-08-23 16:26:08 -0400 < aeth> sham1: JS JITs don't optimize for microbenchmarks
2023-08-23 16:26:22 -0400 < aeth> see e.g. https://news.ycombinator.com/item?id=37134723
2023-08-23 16:27:43 -0400 < aeth> as far as GIMP goes, it's... not very good in general, just passable
2023-08-23 16:28:05 -0400 < aeth> if GIMP was good, then Photoshop wouldn't be able to extract monopolist rent from its monopoly by going to a subscription model, one of the first software suites to do so
2023-08-23 16:28:35 -0400 < aeth> the things people name as alternatives are generally other (though cheaper) commercial software that are much newer than GIMP (which, yes, have budgets, but GIMP had time on its side)
2023-08-23 16:29:01 -0400 < aeth> and Krita, but that's much more limited than GIMP, just for drawing, not photo editing
2023-08-23 16:29:22 -0400 < sham1> I like GIMP although that's probably more due to me being used to it. A problem that I've noticed is that people hear "free photoshop replacement" and think that it'll do everything photoshop does
2023-08-23 16:29:51 -0400 < sham1> (And of course another issue is that people don't necessarily understand what "free" here implies)
2023-08-23 16:29:53 -0400 < aeth> Even if you just make memes in GIMP you'll run into annoyingly common bugs in e.g. the way you put text on top of images. Something that I'm sure 100,000 people have encountered and probably at least 100 have reported.
2023-08-23 16:30:39 -0400 < sham1> People expect GIMP to be good at drawing, which is why the whole "why you no make circle" thing exists
2023-08-23 16:30:47 -0400 < aeth> as for "free", that's entirely on the FSF's bizarre attempt to win a losing linguistics battle
2023-08-23 16:31:03 -0400 < sham1> True
2023-08-23 16:31:05 -0400 < aeth> google "free software" and you're not going to really find free software instead of freeware
2023-08-23 16:31:24 -0400 < sham1> Well I'd probably find free software, but that's because of how Google has profiled me
2023-08-23 16:31:35 -0400 < sham1> For the general audience, yeah, free software is freeware
2023-08-23 16:31:42 -0400 < aeth> on DDG it's #6 for me. https://duckduckgo.com/?q=free+software&ia=web
2023-08-23 16:31:49 -0400 < aeth> but DDG shows different results by region
2023-08-23 16:31:56 -0400 < sham1> Or even more insidiously "pay-with-your-data-ware"
2023-08-23 16:31:57 -0400 < aeth> the rest are entirely freeware
2023-08-23 16:32:23 -0400 < aeth> and since FSF.org is about ideology, people are just going to bounce when they get there and don't find the download link right away
2023-08-23 16:32:37 -0400 < aeth> no match for "download" at all
2023-08-23 16:32:43 -0400 < sham1> Mmhm
2023-08-23 16:34:18 -0400 < aeth> what's worse is that "Apache OpenOffice" is the result below FSF.org for me... the crappy abandonware that still has the name recognition, rather than LibreOffice. Of course, Linux distros don't have that issue because they switched basically overnight, but everyone on Windows is probably still on OpenOffice
2023-08-23 16:35:23 -0400 < dpk> as a would-be professional photographer, all of the free software for image editing is just remarkably, hilariously bad. this is in fact true of all free software intended to provide alternatives to tools for real professional creatives
2023-08-23 16:35:36 -0400 < dpk> with one possible exception (Blender)
2023-08-23 16:35:47 -0400 < aeth> Photos, yes. But Krita is good for drawing.
2023-08-23 16:35:57 -0400 < dpk> there may be a number of reasons for this
2023-08-23 16:36:10 -0400 < sham1> Programmers don't care
2023-08-23 16:36:37 -0400 < aeth> It's probably because artists and photographers are taught Adobe vendor lock-in
2023-08-23 16:36:44 -0400 < dpk> err, no
2023-08-23 16:36:48 -0400 < dpk> everyone hates Adobe software
2023-08-23 16:37:04 -0400 < dpk> everyone who has to use it absolutely hates and despises it and wants desperately to use something else
2023-08-23 16:37:11 -0400 < dpk> there is some file-format lock-in
2023-08-23 16:37:20 -0400 < aeth> Are the alternatives largely Adobe compatible in workflow and file formats?
2023-08-23 16:37:33 -0400 < sham1> Yeah, I don't think they like Adobe's BS
2023-08-23 16:38:02 -0400 < dpk> there is some market network effect type thing (an an analogue photographer, i need Negative Lab Pro, so even if Apple brought back Aperture tomorrow (i wish), i would still have to fork out for Lightroom Classic in practice)
2023-08-23 16:38:35 -0400 < aeth> sham1: Well, definitely not in 2023. Adobe has long since entered the "charge $999999999999999..." part of the monopoly phase.
2023-08-23 16:39:10 -0400 < dpk> but Adobe’s monopoly position is one that’s made them complacent about software quality, and which is allowing some competitors to chip away at their dominance
2023-08-23 16:39:47 -0400 < dpk> but free software is not a viable alternative because … ???
2023-08-23 16:40:00 -0400 < dpk> community-maintained free software is actually very good at parts of this
2023-08-23 16:40:25 -0400 < dpk> one of the Photoshop competitors that is slowly taking away Adobe’s users is Affinity Photo, which uses libraw underneath to open RAW files
2023-08-23 16:41:09 -0400 < dpk> libraw is incredible. far better than Apple’s RAW support (which is generally pretty damn good itself), maybe even better than Adobe’s
2023-08-23 16:41:29 -0400 < dpk> but trying to get free software developers to design user interfaces is … well, it’s not working out
2023-08-23 16:42:09 -0400 < dpk> oh, i forgot the one other free software app which is actually a viable competitor in the space targetted at pro-level creative people: Musescore
2023-08-23 16:42:28 -0400 < dpk> because they got someone on board who actually knows what they’re doing
2023-08-23 16:42:41 -0400 < dpk> and knows and cares about what people who use the software want
2023-08-23 16:43:00 -0400 < dpk> i wonder if Blender did the same
2023-08-23 16:44:59 -0400 < aeth> to be fair
2023-08-23 16:45:03 -0400 < aeth> nobody can design user interfaces anymore
2023-08-23 16:45:25 -0400 < aeth> major software products have forgotten to do things like make buttons look like buttons so you know what's clickable/tappable and what isn't
2023-08-23 16:45:41 -0400 < aeth> minimalism to the point where everything has fallen to the level that a programmer could make
2023-08-23 16:46:08 -0400 < aeth> also, hide everything behind a hamburger menu instead of having anything be discoverable
2023-08-23 16:48:21 -0400 < aeth> also, moving from checkboxes to a binary slider is... awful. Because combined with minimalism and everyone wanting to do their own style, it's often very unclear what's on and off.
2023-08-23 16:50:27 -0400 < sham1> Yeah, those are annoying
2023-08-23 16:52:05 -0400 < acdw> clearly they should be light switches! /s
2023-08-23 16:52:42 -0400 < aeth> yes, flip those on the side in your own app so it's different from everyone else's
2023-08-23 16:52:58 -0400 < dpk> the argument about flat UI elements is common, but i’m not exactly convinced. remember what buttons and check boxes and stuff looked like on Mac OS before Platinum?
2023-08-23 16:53:03 -0400 < aeth> see, that's what having professional designers on every software project actually gives you: everyone wanting to have their own signature design that you have to learn
2023-08-23 16:53:04 -0400 < dpk> they were just rectangles as well
2023-08-23 16:53:30 -0400 < aeth> dpk: Android is pretty bad with its buttons
2023-08-23 16:54:00 -0400 < aeth> Some are a solid color background and some are... indistinguishable from text.
2023-08-23 16:54:16 -0400 < aeth> Cancel       (OK)
2023-08-23 16:54:20 -0400 < aeth> Basically weaponized dark patterns
2023-08-23 16:54:42 -0400 < sham1> I like how Motif looks: <https://techpubs.jurassic.nl/manuals/0530/developer/Debugger_UG/sgi_html/figures/widget.gif>
2023-08-23 16:54:47 -0400 < sham1> This is what we've lost
2023-08-23 16:54:57 -0400 < sham1> You can tell that the buttons are interactable
2023-08-23 16:55:06 -0400 < sham1> The only real annoying part IMO is the menubar
2023-08-23 16:55:20 -0400 < aeth> sham1: yes, Win 9x is probably the peak of usability to everyone who isn't an Apple fan
2023-08-23 16:55:48 -0400 < aeth> although, really, Win 9x with a few subtle modern touches, so probably more like the "classic" view of XP or maybe Vista.
2023-08-23 16:56:07 -0400 < aeth> it's funny to see bottom tabs, though. Web browsers have basically killed those off
2023-08-23 16:56:08 -0400 < dpk> you’ll never beat Mac OS 7.0 https://guidebookgallery.org/screenshots/macos70
2023-08-23 16:56:58 -0400 < aeth> dpk: I'll grant them that there's a lot of character to that software keyboard being "3D"
2023-08-23 16:57:41 -0400 < aeth> I don't think many people want a return to one-button mice, though
2023-08-23 16:58:04 -0400 < acdw> https://store.kde.org/p/1985239/ this is a good one
2023-08-23 16:58:05 -0400 < sham1> Finally found a nice picture of a Windows 98 GUI, and yeah, I like how clear the interaction points are: <http://www.learningcomputer.com/blog/wp-content/uploads/2016/03/windows_98_find.gif>
2023-08-23 16:58:26 -0400 < aeth> acdw: or https://store.kde.org/p/1253201/
2023-08-23 16:58:46 -0400 < sham1> I personally have just fallen (again) in love with WindowMaker and the very NeXTSTEP-like design
2023-08-23 16:59:11 -0400 < sham1> As far as I'm concerned, NeXTSTEP looks incredible
2023-08-23 16:59:26 -0400 < aeth> There's a fun KDE theme on the Steam Deck that's... classic Steam client themed (even though I never used that era of the Steam client)
2023-08-23 16:59:27 -0400 < acdw> oh yeah, the good stuff. i like Be/Haiku as well
2023-08-23 16:59:30 -0400 < aeth> this one: https://www.gamingonlinux.com/2022/07/steam-deck-beta-gets-firefox-as-flatpak-mentions-qfuture-controller-hardware-revisionsq/
2023-08-23 16:59:30 -0400 < rudybot> https://teensy.info/ggDSVx2COK
2023-08-23 16:59:36 -0400 < aeth> https://uploads.golmedia.net/uploads/articles/article_media/20555171591658960215gol1.png
2023-08-23 16:59:56 -0400 < dpk> the turquoise background of Windows 9x was a classic Microsoft aesthetic goof. there were some good points in that UI, though – it came from the golden age of testing UIs on people who weren’t yet very good with computers
2023-08-23 17:00:25 -0400 < dpk> i never liked any of the grey window looks though, on NeXTSTEP, or Mac OS Platinum, or Windows
2023-08-23 17:00:43 -0400 < dpk> the simple white-on-black and very restrained use of colour in System 7 has always seemed perfect to me
2023-08-23 17:00:58 -0400 < aeth> the three button _ [] X is classic... the nice, fat 3D scrollbars, etc., were all nice.
2023-08-23 17:01:07 -0400 < dpk> but let’s not get started on the absurd look of the early Mac OS X releases
2023-08-23 17:01:17 -0400 < acdw> aw i like #008000
2023-08-23 17:01:43 -0400 < aeth> old Windows backgrounds and themes definitely looked better on the more limited, CRT monitors of the time, though.
2023-08-23 17:01:46 -0400 < acdw> though the pixel-sized crosshatch black/white (also default with x11!) is great
2023-08-23 17:01:52 -0400 < dpk> (black on white, not white on black … time to sleep soon)
2023-08-23 17:02:36 -0400 < sham1> I personally don't mind the greys on things like nextstep and whatnot. Especially since the "regions" are clearly separated, which wouldn't be like this in modern apps where you'd instead use a straight-up different colour
2023-08-23 17:03:16 -0400 < sham1> This to me is a very pretty interface: <http://toastytech.com/guis/ns33nfsmanager.png>
2023-08-23 17:03:22 -0400 < haugh> ew, mouse users
2023-08-23 17:03:25 -0400 < sham1> Then again, I also like brutalist architecture
2023-08-23 17:03:38 -0400 < aeth> things used to be themeable in the old days, though... nowadays if things are themeable, it's often just a paywalled color swap (e.g. Discord)
2023-08-23 17:03:56 -0400 < aeth> custom themes often did well even when the original was kind of boring, e.g. with mIRC
2023-08-23 17:03:59 -0400 < aeth> or winamp, I guess
2023-08-23 17:04:53 -0400 < sham1> Modern UIs look way too sterile
2023-08-23 17:04:53 -0400 < aeth> sham1: I don't like the contrast of gray-on-gray that a lot of the older UIs might have had. Not like that has gone away, though
2023-08-23 17:05:36 -0400 < Zipheir> I've been able to do a lot with GIMP, and I wish it would stop trying to copy all of Photoshop's superficial details. Its stability has not been great recently, however.
2023-08-23 17:05:42 -0400 < acdw> i wonder how much of that aesthetic came from the grayness of office furniture, like filing cabinets and steel desks and stuff
2023-08-23 17:05:44 -0400 < aeth> some good things in that UI, though, such as colors and detail in the logos (which are harder to do in vectors, but not impossible, so it's sad people gave up)
2023-08-23 17:06:00 -0400 < aeth> strange contrast of how colorful the logos are and how boring the UI theme is, though
2023-08-23 17:06:08 -0400 < aeth> possibly intentional to make the icons pop more
2023-08-23 17:06:32 -0400 < Zipheir> sham1: What was that screenshot of?
2023-08-23 17:06:42 -0400 < aeth> Interesting how even that has X in the upper right for close. Pretty much everyone uses that convention except for Twitter's embedded tweets
2023-08-23 17:06:46 -0400 < sham1> NeXTSTEP 3.3 IIRC
2023-08-23 17:06:59 -0400 < Zipheir> Ah, nice.
2023-08-23 17:07:14 -0400 < sham1> Yeah, 3.3
2023-08-23 17:07:41 -0400 < Zipheir> aeth: Yeah, the icons are unusually nice.
2023-08-23 17:07:58 -0400 < aeth> Zipheir: GIMP does some things very poorly, such as having lots of destructive transformations (to the point where you better save the originals and a bunch of intermediate steps everywhere) and very, very, very poor handling of text (which is probably one of the main things people want to do with image editing in the meme era of the internet)
2023-08-23 17:08:10 -0400 < Zipheir> I'm waiting for the "flat, pastel, preschool" school of graphic design to go away.
2023-08-23 17:09:05 -0400 < Zipheir> aeth: OK. I have noticed the first problem, but I haven't done much with text in Gimp, so I'll take your word on the second.
2023-08-23 17:09:19 -0400 < aeth> It's remarkably bad even for the basics with text
2023-08-23 17:10:08 -0400 < aeth> It doesn't support emoji properly, it constantly messes up your formatting and sometimes resets the style to a style that's not even the original/default one, etc.
2023-08-23 17:10:16 -0400 < aeth> I don't think it has spellcheck, either
2023-08-23 17:10:38 -0400 < aeth> And most effects, even e.g. shadow or outline, are things you have to do manually or with scripts
2023-08-23 17:10:47 -0400 < Zipheir> At the API level, it's unfortunate that GIMP's approach is always imperative: perform-destructive-transformation!
2023-08-23 17:11:05 -0400 < aeth> and, yeah, the destructive nature doesn't really help because text shouldn't be
2023-08-23 17:11:19 -0400 < Zipheir> Especially with text manipulation.
2023-08-23 17:11:27 -0400 < aeth> iirc, if you do something destructive on a text layer, that's it, it's done, you can no longer modify the text... and most operations are destructive
2023-08-23 17:11:42 -0400 < aeth> or maybe it just resets to the original, and you have to remember to reapply everything
2023-08-23 17:12:32 -0400 < acdw> is there any reason not to use srfi-135 immutable texts in text-heavy applications? I'm not planning to mutate any text
2023-08-23 17:13:04 -0400 < aeth> well, if you're making something that edits text, you wouldn't use any of this... you'd probably use something like https://en.wikipedia.org/wiki/Trie
2023-08-23 17:13:18 -0400 < Zipheir> acdw: You mean the sample implementation?
2023-08-23 17:13:32 -0400 < acdw> yeah? or any other implementation i suppose
2023-08-23 17:14:01 -0400 < acdw> is a trie like a rope, aeth? and it's not for editing, just processing
2023-08-23 17:14:02 -0400 < Zipheir> acdw: Go ahead. The sample implementation is excellent, except for reading texts.
2023-08-23 17:14:15 -0400 < Zipheir> I don't know what aeth is talking about :-D
2023-08-23 17:14:34 -0400 < acdw> you mean read like, into scheme structure? or something else
2023-08-23 17:14:43 -0400 < Zipheir> I mean I/O.
2023-08-23 17:15:06 -0400 < Zipheir> It does a lot of conversion to/from strings, which is not great.
2023-08-23 17:15:07 -0400 < dpk> acdw: one might be that texts are likely to go away in a future R7RS Large. however, at present they’re the only way to get something like string-ref with reasonable performance on all R7RS small Schemes
2023-08-23 17:15:36 -0400 < Zipheir> SRFI 135 isn't going anywhere.
2023-08-23 17:15:46 -0400 < dpk> the SRFI isn’t going anywhere, that’s true
2023-08-23 17:15:50 -0400 < acdw> huh, good to know. i guess if i don't need random access to a string it doesn't really matter so much?
2023-08-23 17:16:03 -0400 < dpk> well, define random access
2023-08-23 17:16:08 -0400 < Zipheir> acdw: It does, if you want to do lots of substring operations cheaply.
2023-08-23 17:16:35 -0400 < dpk> if you’re on Chibi and you start doing string-ref on any successive character indexes, what you get is quadratic performance
2023-08-23 17:16:46 -0400 < dpk> i think the same is true on current versions of Chicken with the utf8 egg
2023-08-23 17:17:12 -0400 < Zipheir> dpk: Are we talking about removing things like (scheme text) that were voted in, now?
2023-08-23 17:17:13 -0400 < acdw> hm. then i might need to examine my code and see what's needed. this is probably all premature optimization anyway; i'm putting off finishing my project
2023-08-23 17:17:44 -0400 < aeth> Btw, you can sort of avoid destructive operations for some things in GIMP even if it doesn't want you to work that way. For photo editing, you can put a layer over a layer and turn on transparency on the top layer and only edit the transparency sublayer of the layer (but it's easy to accidentally edit the layer instead). So it does that right, as long as you don't need to resize/rotate/etc. You could 
2023-08-23 17:17:50 -0400 < aeth> technically fake-crop through applying 100% transparency. But if someone wants to use Scheme for image programs, it's probably best to start from scratch with new software.
2023-08-23 17:17:59 -0400 < Zipheir> There's also SRFI 130 cursors if you want to read through a string index-by-index.
2023-08-23 17:18:06 -0400 < Zipheir> s/There's/There are/
2023-08-23 17:18:08 -0400 < dpk> Zipheir: string-ref is going to get a performance guarantee and string-set! is going to be deprecated, so texts no longer seem nearly as necessary
2023-08-23 17:18:33 -0400 < acdw> in terms of names, i do think "string" makes more sense for a bytearray and "text" for well, text
2023-08-23 17:18:37 -0400 < aeth> dpk: what's the mutable string, then?
2023-08-23 17:18:38 -0400 < Zipheir> dpk: Understood.
2023-08-23 17:18:39 -0400 < acdw> but that ship has probably sailed
2023-08-23 17:18:51 -0400 < dpk> aeth: what do you mean?
2023-08-23 17:18:56 -0400 < aeth> if you can't string-set! anymore
2023-08-23 17:19:12 -0400 < Zipheir> acdw: What implementation are you using, btw?
2023-08-23 17:19:18 -0400 < acdw> chicken
2023-08-23 17:20:05 -0400 < aeth> Randomly mutating the middle of a string is fairly niche in modern software, but mutable strings still have a use if they're adjustable, e.g. in Common Lisp you can vector-push-extend on adjustable strings that act as basically string buffers.
2023-08-23 17:20:06 -0400 < Zipheir> acdw: You may want to at least look at https://wiki.call-cc.org/eggref/5/srfi-130 and https://wiki.call-cc.org/eggref/5/srfi-135. They're both my eggs.
2023-08-23 17:20:35 -0400 < dpk> the answer to the question i think you’re asking is that string-set! is just going to have bad performance, and it’s not very well optimized for the actual string mutation applications that exist. you can use bytevectors or u32vectors to implement strings with in a way that makes sense for your application
2023-08-23 17:20:42 -0400 < dpk> *strings with mutation
2023-08-23 17:21:02 -0400 < Zipheir> acdw: The 135 egg includes some I/O extensions, too.
2023-08-23 17:21:22 -0400 < dpk> we’re not making strings *more* mutable by making them adjustable length, either :P
2023-08-23 17:21:41 -0400 < acdw> Zipheir : thanks!
2023-08-23 17:21:55 -0400 < dpk> we have string ports as real string buffers in R7RS small, for the case you’re talking about
2023-08-23 17:23:35 -0400 < Zipheir> Yeah, string ports solve the buffer problem, I think.
2023-08-23 17:25:39 -0400 < dpk> Zipheir: this isn’t a final decision, btw. there will probably need to be a second vote. the Batteries fascicles will start coming out in 2026 or 2027 at the earliest according to my current plans, at which point the texts issue becomes relevant. (it might be earlier if we issue, say, Environment and Batteries fascicles in parallel)
2023-08-23 17:26:19 -0400 < dpk> (this is all contingent on me being selected chair, and i’m still half expecting the SC to meet next week and then announce Will Clinger is taking over or something like that)
2023-08-23 17:27:10 -0400 < Zipheir> Got it.
2023-08-23 18:04:22 -0400 < jcowan> aeth: It's actually GREEK CAPITAL/SMALL LETTER LAMDA, which is the way the letter name is spelled in Modern Greek
2023-08-23 18:05:30 -0400 < jcowan> I'm not opposed to λ (which for me is AltGr+M l) as an alternative to lambda, but I don't expect everyone to use Knight-style keyboards
2023-08-23 18:05:53 -0400 < jcowan> I mean AltGr+m l, sorry
2023-08-23 18:07:31 -0400 < jcowan> the Moby/Whacking Latin keyboards give you about 1000 typeable characters, preempting only AltGr; only math-style Greek is included, though (no accents)
2023-08-23 18:08:06 -0400 < jcowan> I have always wanted to collaborate with someone on developing versions of them for MacOS and X
2023-08-23 18:26:51 -0400 < acdw> we could change the spelling to lamda
2023-08-23 18:31:05 -0400 < MrtnMrtn> jcowan: How do I find [lambda] on my keyboard layout, (without switching the layout). Is it possible?
2023-08-23 18:31:25 -0400 < jcowan> It depends on your layout.
2023-08-23 18:31:43 -0400 < jcowan> Also your OS, and what layers (if any) above the keyboard driver you have.
2023-08-23 18:32:17 -0400 < MrtnMrtn> jcowan: emacs -nw older ubuntu, danish keyboard layout.
2023-08-23 18:32:48 -0400 < jcowan> My guess is you do not have Greek support.
2023-08-23 18:33:13 -0400 < MrtnMrtn> I can switch to Greek keyboard layout, and type λ that way I guess.
2023-08-23 18:33:38 -0400 < MrtnMrtn> However, then it is probably faster to type `lambda` I guess.
2023-08-23 18:34:07 -0400 < MrtnMrtn> Which keyboard layout do you have, jcowan ? 
2023-08-23 18:34:21 -0400 < jcowan> Moby Latin, Windows
2023-08-23 18:34:47 -0400 < MrtnMrtn> Windows? ... Man .. I hate to be behind WIndows ...
2023-08-23 18:37:45 -0400 < dpk> better than being behind bars
2023-08-23 18:38:14 -0400 < MrtnMrtn> dpk, I doubt it. :D
2023-08-23 18:38:27 -0400 < MrtnMrtn> In some cases, perhaps.
2023-08-23 18:44:15 -0400 < Zipheir> MrtnMrtn: https://stackoverflow.com/questions/10192341/how-to-enter-greek-characters-in-emacs might be useful.
2023-08-23 18:44:36 -0400 < sp1ff``> I use C-x 8 RET
2023-08-23 18:44:39 -0400 < sp1ff``> (in Emacs)
2023-08-23 18:45:01 -0400 < sp1ff``> or `insert-char'
2023-08-23 18:46:57 -0400 < MrtnMrtn> Zipheir: Thanks!  Now I feel better.
2023-08-23 18:48:14 -0400 < Zipheir> yw. Given it's Emacs, there must be at least a dozen ways to do it.
2023-08-23 18:49:23 -0400 < MrtnMrtn> sp1ff``: What do you type after C-x 8 RET? *lambda doesn't seem to work for me.
2023-08-23 18:49:55 -0400 < MrtnMrtn> Anyhow, if you are using lambda with any regularity, I am guess "M-g l" is the way to go, with the example code.
2023-08-23 18:50:28 -0400 < sp1ff``> MrtnMrtn: I get a list of Unicode code points. I can, e.g. select "GREEK SMALL LETTER LAMBDA" and get λ
2023-08-23 18:50:34 -0400 < MrtnMrtn> λ
2023-08-23 18:51:15 -0400 < MrtnMrtn> λ
2023-08-23 18:51:17 -0400 < sp1ff``> I know there are libraries that give a more ergonomic interface, but I haven't looked into them
2023-08-23 18:51:24 -0400 < MrtnMrtn> Yeah, that works, sp1ff`` 
2023-08-23 18:52:17 -0400 < MrtnMrtn> However, ``C-x 8 ret 03bb'' ret seems easier, provided you can remember the number.
2023-08-23 18:53:02 -0400 < sp1ff``> Sure-- but I just don't use it enough for the numbers to stick
2023-08-23 18:53:11 -0400 < Zipheir> That's a lot of keys for one character.
2023-08-23 18:53:24 -0400 < MrtnMrtn> But idealy you would make it to a key, I guess. Perhaps even the ones jcowan mentioned.
2023-08-23 18:53:31 -0400 < MrtnMrtn> map*
2023-08-23 18:54:11 -0400 < Zipheir> I've got <Compose> CHAR * mapped to the Greek transliteration of CHAR (roughly).
2023-08-23 18:54:28 -0400 < Zipheir> Er, * CHAR.
2023-08-23 18:54:48 -0400 < MrtnMrtn> I don't have a space cadet keyboard yet ..
2023-08-23 18:54:57 -0400 < jcowan> Eh.  I don't remember why I chose AltGr+m and not AltGr+g
2023-08-23 18:55:24 -0400 < MrtnMrtn> AltGr+m gives me micro.
2023-08-23 18:55:45 -0400 < jcowan> AltGr+g gives me ᵹ.
2023-08-23 18:55:54 -0400 < jcowan> "insular g"
2023-08-23 18:55:57 -0400 < MrtnMrtn> AltGr+g gives me ŋ (whatever that is).
2023-08-23 18:56:27 -0400 < jcowan> Its name is "angma"
2023-08-23 18:56:47 -0400 < jcowan> I type it with AltGr+p n (p = phonetic)
2023-08-23 18:57:17 -0400 < MrtnMrtn> However, M-g seems to already be a prefix.
2023-08-23 18:58:45 -0400 < jcowan> I guess that should be spelled "agma" (but pronounced "angma")
2023-08-23 18:58:49 -0400 < MrtnMrtn> (local-set-key (kbd "M-g l") "λ")
2023-08-23 18:58:52 -0400 < MrtnMrtn> seems to work.
2023-08-23 18:58:58 -0400  * jcowan nods
2023-08-23 18:59:32 -0400 < MrtnMrtn> I guess global would be better, but I used local as a test.
2023-08-23 19:01:20 -0400 < MrtnMrtn> In my Emacs, "M-g l" happens to be unbound, so that will do for now.
2023-08-23 21:33:55 -0400 < acdw> I thought it was eng
2023-08-23 22:30:42 -0400 < klovett> in the tooth but, i used a NeXTcube (@ NeXT) & in every way a better ux than my Sun 3/60.
2023-08-23 23:04:54 -0400 < klovett> & @ home, a cube "networked" via kermit w/ the sun & a gateway running windows-386 - closest i ever came to being like the movies
2023-08-23 23:44:29 -0400 -!- enzutwo is now known as enzuru
2023-08-23 23:55:12 -0400 < mdhughes> I just did some key assignments to make Cmd-Y λ in all my text areas, then macro'd λ in my library, but that doesn't really help anyone else's machine.
--- Day changed Thu Aug 24 2023
2023-08-24 00:35:30 -0400 -!- Netsplit *.net <-> *.split quits: jcowan, torresjrjr_, acetakwas, Gliese852, oenone
2023-08-24 00:35:30 -0400 -!- jcowan_ is now known as jcowan
2023-08-24 00:42:06 -0400 -!- Netsplit over, joins: Gliese852
2023-08-24 00:49:52 -0400 < lockywolf> I just use ibus, and type in λ
2023-08-24 00:50:29 -0400 < lockywolf> I use ibus for everything other than PinYin and Russian.
2023-08-24 00:51:10 -0400 < lockywolf> Sorry, I type in Super-Shift-e lambda SPC
2023-08-24 00:52:31 -0400 < lockywolf> I don't see much use for λ in general. In Emacs I use prettify-symbols
2023-08-24 00:52:48 -0400 < lockywolf> for some math and greek symbols
2023-08-24 00:53:36 -0400 < lockywolf> Anyway, I am studying maxima, and I keep being amused by the way their "expressions" work.
2023-08-24 00:54:09 -0400 < lockywolf> makes me re-think functions vs macros
2023-08-24 01:08:26 -0400 < lockywolf> but I can't understand what was the need to make a new syntax, when CL was just enough
2023-08-24 01:26:09 -0400 < cow_2001> Someone wrote a thing! http://dpk.io/r7rswtf
2023-08-24 01:26:33 -0400 < cow_2001> Oh!  Turns out the author is here!
2023-08-24 01:30:00 -0400 < cow_2001> Lots of wee scifi novels references in it.
2023-08-24 01:30:51 -0400 < sham1> I have a hunch that the URL gives a hint
2023-08-24 01:36:01 -0400 < cow_2001> Yes, I just noticed that
2023-08-24 01:36:03 -0400 < cow_2001> .
2023-08-24 05:03:13 -0400 < Guest67> hello everyone, i was wondering if there was a way to have something like the debugger included in drracket in emacs, is there anything like that?
2023-08-24 05:26:28 -0400 < schemer> Guest67: AFAIK there's no plugin like that for emacs. But you could take a look at the code of drracket and try to extract the debugger (https://github.com/racket/drracket/blob/2657eafdcfb5e4ccef19405492244f679b9234ef/drracket/gui-debugger/debug-tool.rkt) from it, and integrate it to emacs.
2023-08-24 05:26:28 -0400 < rudybot> https://teensy.info/PxVK5rrEBU
2023-08-24 05:27:25 -0400 < Guest67> rudybot i mean isn't that just a common debugger ? what kind of debugger do you use for your scheme ?
2023-08-24 05:27:45 -0400 < Guest67> i mean i would expect other debuggers already existing for emacs that do a similar thing
2023-08-24 05:33:56 -0400 < Guest67> people which implementations of scheme are "interactive" as common lisp? i mean to the point where one can basically change the live running image, just re-compiling functions on the run
2023-08-24 05:35:25 -0400 < schemer> Guest67: The spec doesn't include a common debugger, so different implementations may provide different debuggers
2023-08-24 05:41:31 -0400 < schemer> Perhaps scheme48 or mit-scheme may fit your needs.
2023-08-24 05:46:15 -0400 < flatwhatson> guile is nicely interactive with geiser
2023-08-24 06:03:13 -0400 < op-to> yeah, was gonna say, aren't most schemes interactive through geiser?
2023-08-24 08:48:06 -0400 < dpk> hmm, POSIX wizards needed again: ENVIRONMENTS now claims that, because O_NONBLOCK applies to an ofile and not just to a single fd, if we wanted to have even just basic primitives for non-blocking I/O (nothing so advanced as an event loop, even), we couldn’t have it work on standard input, standard output, or standard error without breaking regular Scheme I/O procedures on those ports. however, i should probably check if this is true
2023-08-24 08:48:43 -0400 < dpk> is it possible to get a different ofile that is connected to the same place as fds 0, 1, and 2 that are open when a program starts?
2023-08-24 08:49:53 -0400 < dpk> or, even better: is there now some alternative way to do non-blocking I/O on those without setting a global flag?
2023-08-24 08:51:26 -0400 < jobol> fcntl(F_SETFL, O_NONBLOCK) or smth around that
2023-08-24 08:53:44 -0400 < LeoNerd> Annoyingly, no you can't. And what's worse is that O_NONBLOCK affects the actual file device thingy, not just your process's copy of it
2023-08-24 08:53:57 -0400 < LeoNerd> So if you O_NONBLOCK then your parent shell will see it when you exit
2023-08-24 08:55:21 -0400 < jobol> I'm doing that on some code: put stdin as not blocking and poll it and a socket, it works well on linux
2023-08-24 08:56:22 -0400 < dpk> LeoNerd: sometimes people tell me that Unix is a well-designed operating system, based around the principles of every piece doing one thing well
2023-08-24 08:56:42 -0400 < dpk> usually, it turned out the people who designed those pieces apparently only needed half of an ass
2023-08-24 08:56:58 -0400 < ecraven> well, maybe at some point it was that way, but that was 30 years ago :-/
2023-08-24 08:57:00 -0400 < mdhughes> I often use stty to do that for text UIs, but you have to echo everything, flush after every write, and check input availability.
2023-08-24 08:57:05 -0400 < LeoNerd> dpk: Hah! :) Yes
2023-08-24 08:57:19 -0400 < mdhughes> It's fine, but it's not designed to be used exactly like blocking, buffered IO.
2023-08-24 08:57:21 -0400 < LeoNerd> The principle was sound enough; it just often hasn't really been implemented that well in practice
2023-08-24 08:57:49 -0400 < mdhughes> And make sure you can stty reset when you're done, or your terminal is hosed.
2023-08-24 08:58:05 -0400 < dpk> what’s worse is that i remember first learning that this is a problem with Unix non-blocking I/O over ten years ago from this page by djb http://cr.yp.to/unix/nonblock.html
2023-08-24 08:58:14 -0400 < dpk> and he had the problem probably twenty or twenty-five years ago
2023-08-24 08:58:23 -0400 < LeoNerd> If I could go back in time, I think the first thing I'd do is add an -1/EEOF error code on EOF, and say that read(). et.al. returning 0 just means "nothing yet, try again later". and then we can get rid of the stupidity that is EAGAIN
2023-08-24 08:58:24 -0400 < dpk> *and* suggested a solution
2023-08-24 08:58:50 -0400 < LeoNerd> DNIX had a great idea. Nobody else has implemented it :sadface:
2023-08-24 09:01:37 -0400 < dpk> jobol: what you are doing will work until something that expects to be using blocking IO on stdin or on that socket does something which will block. as LeoNerd mentions, this ‘something’ could be the shell which originally started your program
2023-08-24 09:03:35 -0400 < jobol> dpk, init isn't a shell
2023-08-24 09:04:03 -0400 < jobol> ooops
2023-08-24 09:04:24 -0400 < jobol> not in daemon of course, my mad
2023-08-24 09:05:50 -0400 < dpk> yes, if you’re lucky enough to have control over all the ofiles in your program, you’re fine
2023-08-24 09:06:03 -0400 < dpk> unfortunately we can’t assume that, and it is not true of most user space programs
2023-08-24 10:13:22 -0400 < sham1> dpk: TBF, being well designed and having warts isn't mutually exclusive. Also see Scheme and mutable strings
2023-08-24 10:13:27 -0400 < sham1> Zing
2023-08-24 10:13:54 -0400 < sham1> Or Common Lisp and mutable strings. Or Emacs Lisp and mutable strings. Damn mutable strings, you ruined Lisps
2023-08-24 10:14:23 -0400 < acdw> let's write our own lisp, with immutable strings and black jack
2023-08-24 10:55:52 -0400 < Zipheir> Black jack?
2023-08-24 10:57:39 -0400 -!- mirai_ is now known as mirai
2023-08-24 11:07:05 -0400 < acdw> joke on the whole "I'll make my own x, with blackjack and strippers"
2023-08-24 11:07:20 -0400 < acdw> it ... wasn't a great joke tbh
2023-08-24 11:07:59 -0400 < mdhughes> Someone hasn't watched enough Futurama.
2023-08-24 11:07:59 -0400 < Franciman> futurama reference, Zipheir 
2023-08-24 11:08:12 -0400 < Franciman> i'll make my own scheme called futurama
2023-08-24 11:08:32 -0400 < mdhughes> It should be named after a crime or criminal, so Bender Scheme is better!
2023-08-24 11:08:43 -0400 < Franciman> :D
2023-08-24 11:08:47 -0400 < Franciman> bender scheme is awesome
2023-08-24 11:08:55 -0400 < Franciman> what is the peculiarity going to be?
2023-08-24 11:08:55 -0400 < acdw> bender scheme is a great name
2023-08-24 11:09:06 -0400 < sham1> Best way to program alcoholic robots, I'm sure
2023-08-24 11:09:17 -0400 < acdw> when it errors out it'd just say "Bite my shiny metal ass"
2023-08-24 11:09:38 -0400 < mdhughes> Everything's about bending, not pipes. And it explodes if you type "antiquing"
2023-08-24 11:09:54 -0400 < acdw> lmao
2023-08-24 11:10:26 -0400 < gwatt> I predict you'll get 40% done with it
2023-08-24 11:10:40 -0400 < Franciman> LOL acdw 
2023-08-24 11:11:50 -0400 < Franciman> do we want to do it?
2023-08-24 11:11:52 -0400 < Franciman> all together?
2023-08-24 11:12:03 -0400 < Franciman> it will be the new implementation by #scheme channel
2023-08-24 11:13:34 -0400 < acdw> let's do it, sure
2023-08-24 11:13:43 -0400  * acdw has no experience with language implementation
2023-08-24 11:13:47 -0400  * Franciman neither
2023-08-24 11:13:48 -0400  * acdw barely knows scheme
2023-08-24 11:13:52 -0400 < acdw> lmao
2023-08-24 11:13:57 -0400 < acdw> i do know posix shell
2023-08-24 11:13:58 -0400  * Franciman too
2023-08-24 11:14:05 -0400 < Franciman> (re: barely knows scheme)
2023-08-24 11:14:07 -0400 < acdw> there's no way we could fail
2023-08-24 11:15:29 -0400 < Franciman> (bender (scheme))
2023-08-24 11:17:05 -0400 < acdw> i mean parens look like bent pipes
2023-08-24 11:17:45 -0400 < Franciman> DAMN
2023-08-24 11:18:03 -0400 < Franciman> mdhughes: sham1 acdw you are creating the ultimate object
2023-08-24 11:18:23 -0400 < acdw> ultimate object?
2023-08-24 11:18:24 -0400 < Franciman> the ultimate scheme implementation
2023-08-24 11:18:27 -0400 < acdw> oh lol
2023-08-24 11:18:32 -0400 < Franciman> sorry autocomplete xD
2023-08-24 11:19:18 -0400 < acdw> ahahah
2023-08-24 11:21:03 -0400 < mdhughes> I'm really trying hard not to rat-hole myself into building another compiler/interpreter. Making something R6RS-ish that compiles to C like CHICKEN but *fast*, is what I want to do.
2023-08-24 11:23:26 -0400 < Franciman> mdhughes: why not webasm?
2023-08-24 11:24:05 -0400 < mdhughes> There's already good Schemes for WASM. Doing native code like a C binary is a pain in the ass in every Scheme, for different reasons.
2023-08-24 11:24:54 -0400 < mdhughes> CHICKEN really could be fine if it A) was R6RS, B) had Boehm GC, C) didn't take 30s per compile minimum.
2023-08-24 11:25:29 -0400 < mdhughes> But memory management on C side sucks Bender's shiny metal ass.
2023-08-24 11:26:19 -0400 < Franciman> why bohem gc is good?
2023-08-24 11:26:40 -0400 < gwatt> Do you want compilation to C for a native binary, or do you want extensive interaction with C libraries?
2023-08-24 11:29:37 -0400 < Zipheir> "Enough" TV for me is as little as possible.
2023-08-24 11:30:59 -0400 < Zipheir> CHICKEN 5 has definitely been faster than previous versions.
2023-08-24 11:31:19 -0400 < acdw> chicken 6 has utf8!
2023-08-24 11:31:34 -0400 < Zipheir> Yeah.
2023-08-24 11:32:02 -0400 < Zipheir> I claim a very small amount of credit for nagging Felix about the lack of Unicode.
2023-08-24 11:33:03 -0400 < Zipheir> I guess it means that every modern CHICKEN egg won't have to depend on foof's utf8 library anymore.
2023-08-24 11:39:11 -0400 < acdw> nice!
2023-08-24 11:39:29 -0400 < acdw> honestly I'm pumped about that. utf8 is a requirement for modern software in my vire
2023-08-24 11:39:43 -0400 < mdhughes> Boehm lets you use normal C code, but have everything tracked by normal GC.
2023-08-24 11:40:19 -0400 < mdhughes> And yeah, utf8 is a big deal, the previous use of it really slowed down anything that did string work.
2023-08-24 11:42:24 -0400  * acdw whispers immutable strings
2023-08-24 11:43:27 -0400 < taylan> I thought Chicken's GC strategy was considered fairly good?
2023-08-24 11:43:30 -0400 < mdhughes> Sometimes you're doing work that needs to mutate in place, like regexp. The alternative is you do everything in u8vectors with entirely custom scan/edit functions.
2023-08-24 11:43:38 -0400 < Zipheir> I doubt those will ever gain traction in CHICKEN.
2023-08-24 11:43:39 -0400 < taylan> what do they call it again... jumping off the empire state building?
2023-08-24 11:44:24 -0400 < taylan> "Cheney on the MTA" was the more serious name I think
2023-08-24 11:44:54 -0400 < Zipheir> I think Cheney on the MTA was the antithesis of the "Empire State" approach. Lots of little jumps.
2023-08-24 11:45:54 -0400 < Zipheir> cf. https://web.archive.org/web/20190211233325/http://home.pipeline.com/~hbaker1/CheneyMTA.html
2023-08-24 11:46:29 -0400 < taylan> there seems to be a live version of that URL here: https://plover.com/~mjd/misc/hbaker-archive/CheneyMTA.html
2023-08-24 11:46:37 -0400 < Zipheir> Oh, nice.
2023-08-24 11:47:14 -0400 < Zipheir> I don't know much about Cheney, but the idea of almost-overflowing the C stack on a regular basis sounds wonky to me.
2023-08-24 11:49:17 -0400 < taylan> don't all high-level language implementations rely on one or another wonky thing? :)
2023-08-24 11:49:37 -0400 < taylan> I'm pretty sure Boehm GC is wonky in its own ways...
2023-08-24 11:50:02 -0400 < taylan> Not sure if the problem of "things looking like pointers to Scheme objects but not really being so" was ever solved?
2023-08-24 11:50:32 -0400 < Zipheir> I can't untangle Boehm's C, so it's wonky.
2023-08-24 11:50:55 -0400 < Zipheir> "Nobody can debug a complicated garbage collector. You have to be able to look at it and know it's right." --Sussman
2023-08-24 11:52:07 -0400 < sham1> Cheney got stuck on the MTA
2023-08-24 11:52:18 -0400 < sham1> Alongside Charlie. So sad
2023-08-24 11:52:30 -0400 < acdw> the line got shut down due to lack of funding
2023-08-24 11:52:32 -0400 < Zipheir> It's a brilliant name.
2023-08-24 11:53:50 -0400 < taylan> oh, I thought "Cheney on the M.T.A." was referring to something serious/technical, didn't know it was yet another joke :D
2023-08-24 11:54:31 -0400 < taylan> I wish I was retired already.  I'd like to implement a Scheme in Zig.
2023-08-24 11:56:33 -0400 < acdw> that'd be fun
2023-08-24 12:09:02 -0400 < Zipheir> I wonder if there's been any work on a minimal functional-language-implementation language that provides that provides the low-level details like tail-calls and garbage collection.
2023-08-24 12:09:51 -0400 < Zipheir> Maybe it could run on a LLLM--Low-Level Lambda Machine.
2023-08-24 12:11:08 -0400 < Zipheir> Because most of the first things that people have to do when implementing ML, Scheme, etc. in language X is to implement a lot of the same functional infrastructure.
2023-08-24 12:13:06 -0400 < mdhughes> There's a few proto-schemes inside other Schemes & such.
2023-08-24 12:14:57 -0400 < Zipheir> I know of https://groups.scheme.org/prescheme/
2023-08-24 12:19:24 -0400 < sham1> I don't know if an LLLM would be thought of as interesting
2023-08-24 12:19:52 -0400 < sham1> I'd almost bet that it certainly wouldn't be thought of as being interesting enough to be a thing
2023-08-24 12:20:04 -0400 < Franciman> taylan: i'd like to do that too
2023-08-24 12:20:58 -0400 < sham1> I don't think that Scheme-in-Zig would be that radically different from Scheme-in-C, other than in terms of having a more limited selection of target architectures due to being confined to LLVM
2023-08-24 12:21:23 -0400 < Franciman> would be fun to code, probably
2023-08-24 12:21:31 -0400 < Franciman> because you have a bunch of different amenities
2023-08-24 12:21:34 -0400 < taylan> I think the problem with such a generic "base" would be that there's trade-offs with any strategy you go with, so it's never going to be truly generic
2023-08-24 12:21:55 -0400 < taylan> sham1: are they still confined to LLVM?
2023-08-24 12:22:58 -0400 < sham1> IIRC yes
2023-08-24 12:23:18 -0400 < taylan> looks like it yeah  https://ziglang.org/documentation/0.11.0/#Targets
2023-08-24 12:23:44 -0400 < Zipheir> sham1: Maybe a VM wouldn't be interesting, but wouldn't a minimal functional target language be useful?
2023-08-24 12:24:16 -0400 < Zipheir> Compiling functional languages seems to take a lot of wheel-reinventing.
2023-08-24 12:24:32 -0400 < sham1> I mean that'd just be the Lambda calculus
2023-08-24 12:24:53 -0400 < Zipheir> It would be more like ISWIM, actually.
2023-08-24 12:25:15 -0400 < Zipheir> Since that's easier to implement efficiently.
2023-08-24 12:26:29 -0400 < Zipheir> My point is that the hard parts of compiling Scheme/ML/etc. are things like tail-recursion, continuations, and garbage collection which could be provided by the target language.
2023-08-24 12:26:30 -0400 < sham1> That's still lambda calculus
2023-08-24 12:27:52 -0400 < gwatt> Zipheir: I think compiling languages seems to take a lot of wheel-reinventing, regardless of functional or not
2023-08-24 12:28:57 -0400 < Zipheir> gwatt: So wouldn't it be good to have a target language with the hardest-to-invent wheels in place?
2023-08-24 12:29:29 -0400 < sham1> The problem with that is that those hardest-to-invent wheels often have very wide consequences in terms of the implementation strategy
2023-08-24 12:31:04 -0400 < Zipheir> That's something that all language implementations have to deal with.
2023-08-24 12:31:53 -0400 < gwatt> I guess the fact thta language implementation requires wheel-reinventing, it must be that language designers & implementors find it worthwhile to reinvent
2023-08-24 12:31:55 -0400 < Zipheir> Given that more complicated languages like Idris are being built on Scheme, it might be that Scheme (or a minimal subset thereof) is the language I'm talking about.
2023-08-24 12:32:30 -0400 < Zipheir> Things like LLVM get a lot of use.
2023-08-24 12:33:32 -0400 < Zipheir> But you could argue that's a matter of portability, not the features it provides (which are minimal).
2023-08-24 12:34:45 -0400 < sham1> You also get compilers trying to get out of LLVM after they first built their compilers on-top of LLVM and it seems exceedingly difficult
2023-08-24 12:34:45 -0400 < gwatt> IIRC llvm has some peculiarities, like for a while TCO worked on x86 but not arm. also, the rust folks had to ship around a modified version to fit their needs, so even llvm requires some re-invention
2023-08-24 12:35:40 -0400 < sham1> Rust being one of these languages whose reference compiler is ontop of a bundled LLVM, as noted, and which they're trying to get rid of with Cranelift
2023-08-24 12:36:34 -0400 < Zipheir> Ugh, "reference compiler".
2023-08-24 12:37:21 -0400 < sham1> Yeah. There ain't no Rust spec, just whatever rustc does. And that's where jcowan would come in were he to go there
2023-08-24 12:37:49 -0400 < sham1> Or whomever
2023-08-24 12:38:04 -0400 < Zipheir> Someday someone will reinvent Backus-Naur form and it will be hailed as a great discovery.
2023-08-24 12:41:34 -0400 < sham1> Everything old is new again
2023-08-24 13:06:59 -0400 < gwatt> There's also gccrs, though that's still relatively incomplete
2023-08-24 13:15:30 -0400 < dpk> if anyone has followers in the PL/compilers world on Mastodon, i’d appreciate a boost to get some answers, if there indeed are any https://c.im/@dpk/110944396853673091
2023-08-24 13:19:41 -0400 < gwatt> I'm not even sure the optimization argument makes sense for scheme, since you can eval at runtime and access libraries that weren't statically determined
2023-08-24 13:21:04 -0400 < sham1> dpk: done
2023-08-24 13:21:15 -0400 < sham1> Also followed for good measure
2023-08-24 13:22:17 -0400 < dpk> gwatt: ah, but you can statically detect whether eval is used! *taps forehead*
2023-08-24 13:22:30 -0400 < dpk> that’s another case this argument gets trotted out in
2023-08-24 13:22:42 -0400 < gwatt> I guess that's fair
2023-08-24 13:23:57 -0400 < dpk> probably actually the more relevant one, because nearly no Scheme implementations actually serve the case of compiling a program to a completely static binary (which is also the unspoken argument behind a lot of sufficiently-smart-compiler type arguments about things Scheme should/shouldn’t provide, such that e.g. R6RS and arguably the Foundations are over-optimizing for this one use case)
2023-08-24 13:24:53 -0400 < dpk> in reality, implementations like Chez achieve world-beating speed and somehow manage to also support a REPL where you can load any compiled library you like
2023-08-24 13:32:10 -0400 < jcowan> The trouble with conservative (Boehm-style) GCs is that they aren't actually properly tail recursive.  Most of the time it's good enough, but when it isn't you are out of luck. That's why Racket switched to precise GC, because spurious OOM situations.
2023-08-24 13:33:21 -0400 < jcowan> I'm not sure you can't implement your own eval portably, in which case static detection is ineffective.  But maybe you can't.
2023-08-24 13:35:27 -0400 < jcowan> Chicken never comes close to actually overflowing the C stack.  In effect, Cheney treats the C stack as the fixed-size nursery for a generational garbage collector.
2023-08-24 13:36:27 -0400 < jcowan> Zipheir: Now someone has to nag Felix about syntax-case.
2023-08-24 13:40:25 -0400 < jcowan> As for the Unix Way, everything nonblocking and thready does not and never will belong to it. The unit of concurrency in Unix is the process, and everything else is a kludge.  If you complain that processes are too slow, work on making them fast (in the kernel), and *everyone* will benefit.
2023-08-24 13:43:00 -0400 < Franciman> do you like CEK machines for interpreting scheme?
2023-08-24 13:43:08 -0400 < Franciman> well, slight variations thereof
2023-08-24 13:43:27 -0400 < ober> .oO(Scheme Machines)
2023-08-24 13:44:04 -0400 < Franciman> do you have a reference for those?
2023-08-24 13:45:33 -0400 < dpk> jcowan: except every GUI app and since about 15 years every network daemon is absolutely dependent on non-blocking IO
2023-08-24 13:47:01 -0400 < dpk> the other bit of snark i wanted to make earlier is: we had a typical ‘Windows bad’-type Linux Guy here last night, but here’s a case where (without knowing for sure) I absolutely *guarantee* the Windows API got its shit right, because if your OS assumes from day one there’s a GUI, especially when that GUI is co-operatively multitasking, you *need* it to work
2023-08-24 13:48:35 -0400 < jcowan> That's because the implementation strategy is reading from an event queue with no actual concurrency at all.
2023-08-24 13:49:11 -0400 < jcowan> Which is fine if you have a Sufficiently Schemey Compiler to do the inversion of controll for you.  But in those days no Windows programmer did.
2023-08-24 13:49:57 -0400 < sham1> Inversion of control? Do you mean CPS?
2023-08-24 13:50:10 -0400 < sham1> Because at least to me IoC means something completely different
2023-08-24 13:50:21 -0400 < jcowan> What does it mean to you?
2023-08-24 13:50:44 -0400 < Franciman> callbaqs
2023-08-24 13:50:46 -0400 < Franciman> ?
2023-08-24 13:51:01 -0400 < sham1> Dependency injectiony stuff with things like Spring and such. But apparently it's more about the event callback stuff, yeah
2023-08-24 13:51:09 -0400 < sham1> Well, you can implement that with CPS of course
2023-08-24 13:51:41 -0400 < jcowan> Can and should.  Otherwise you are just doing CPS by hand
2023-08-24 13:52:32 -0400 < sham1> Which, tbf, people aren't exactly adverse towards. I mean we do that in Scheme but in other languages as well. Less we talk about Node.js and its cascades of callbacks, the better
2023-08-24 13:53:11 -0400 < Zipheir> Callbacks seem fine to me so long as there isn't some global state they're all modifying.
2023-08-24 13:53:25 -0400 < sham1> But TIL about that use of IoC. Now that I think of it, the way the Java community uses the term seems rather strange
2023-08-24 13:56:20 -0400 < jcowan> I think it's fundamentally the same idea, I just can't work out exactly how at this point.
2023-08-24 13:57:01 -0400 < jcowan> My counterexample to callbacks is this: imagine writing a recursive descent parser in an OS like TOPS-10, where all I/O is callback-driven.
2023-08-24 13:57:29 -0400 < jcowan> The event loop keeps reentering you, but you lose the stack context needed to maintain the recursion.
2023-08-24 13:58:14 -0400 < jcowan> So instead you write tyour parser and put it through CPS so that it can be invoked bit by bit.
2023-08-24 13:59:47 -0400 < Franciman> jcowan: why should i use cps when i can use call/cc?
2023-08-24 14:00:01 -0400 < jcowan> It's manual.
2023-08-24 14:00:20 -0400 < Franciman> i don't understand how you make it automatic
2023-08-24 14:00:29 -0400 < jcowan> Call/return is a very natural way of thinking not just for programmers but for everyone who follows an algorithm, like a cook.
2023-08-24 14:00:44 -0400 < jcowan> (Cooking requires some concurrency, but you try to minimize it.)
2023-08-24 14:00:51 -0400 < jcowan> Juggling is a more obvious case.
2023-08-24 14:01:20 -0400 < jcowan> Franciman: I mean a compiler that does CPS for you, like most Scheme compilers.
2023-08-24 14:01:59 -0400 < Franciman> i don't understand
2023-08-24 14:02:08 -0400 < Franciman> how it enables you to have a parser
2023-08-24 14:02:20 -0400 < Franciman> that intersperses well with async IO
2023-08-24 14:02:24 -0400 < Franciman> for TOPS-10
2023-08-24 14:03:44 -0400 < jcowan> the parser is written in terms of reading a token, but it has to be able to yield because the whole token might not be available yet
2023-08-24 14:04:21 -0400 < jcowan> Stdio is a kind of coroutining, and CPS allows coroutining on top of subroutining.
2023-08-24 14:04:25 -0400 < Franciman> and how does the compiler help you with that? [sorry if I am being pedantic, it's that I'm curious, not that i want to debunk you lol]
2023-08-24 14:04:46 -0400 < Franciman> i thought you had to put some extra care in designing the parser
2023-08-24 14:04:51 -0400 < jcowan> I need to leave, so I can't do the research to refresh my memory of the discussion right now'
2023-08-24 14:06:16 -0400 < Franciman> np!
2023-08-24 17:22:07 -0400 < MrtnMrtn> WB dave0 
2023-08-24 17:24:13 -0400 < MrtnMrtn> WB seninha 
2023-08-24 17:25:06 -0400 < dave0> thanks MrtnMrtn 
2023-08-24 17:25:26 -0400 < MrtnMrtn> Yw dave0.  I hope you're having a pleasent evening.
2023-08-24 17:33:32 -0400 < dave0> MrtnMrtn: it's my day of rest!
2023-08-24 17:33:50 -0400 < dave0> gonna do some coding
2023-08-24 17:34:30 -0400 < MrtnMrtn> Enjoy. I should probably get some rest myself.
2023-08-24 17:38:30 -0400 < dave0> :-)
2023-08-24 17:49:41 -0400 < dpk> who had the idea to make the ellipsis renamable and allow it to be used as a literal in syntax-rules for R7RS small?
2023-08-24 17:49:49 -0400 < dpk> whoever it was, it was truly an inspired idea
2023-08-24 17:51:02 -0400 < dpk> i’m writing the sample implementation of the syntax-case pattern matcher for the macrological fascicle and only just realized how well those two things work together
2023-08-24 17:53:02 -0400 < gwatt> The ellipsis alias is much nicer than sprinking (... ...) throught your code.
2023-08-24 18:09:40 -0400 < Zipheir> dpk: I think it was Riastradh https://srfi.schemers.org/srfi-46/srfi-46.html
2023-08-24 18:32:19 -0400 < dpk> the operational description in R6RS of how syntax decides if its output is wrapped or unwrapped is nearly useless
2023-08-24 18:32:52 -0400 < dpk> naively implemented, you will have worse than quadratic performance, as far as i can tell
2023-08-24 18:33:44 -0400 < dpk> i think n squared times m squared where n is the length of your template and m is the nesting depth?
2023-08-24 18:34:14 -0400 < dpk> but then there’s ‘The output produced by syntax is wrapped or unwrapped according to the following rules. the copy of (<t1> . <t2>) is a pair if <t1> or <t2> contain any pattern variables,’
2023-08-24 18:34:36 -0400 < dpk> i assume it means it is an unwrapped pair, but what does ‘contain’ mean?
2023-08-24 18:35:57 -0400 < dpk> ‘the copy of (<t> <ellipsis>) is a list if <t> contains any pattern variables’ is even more confusing. surely if there’s an ellipsis, <t> must be (or ‘contain’) a pattern variable, so it will always be a list?
2023-08-24 18:37:30 -0400  * dpk looks to see if SRFI 93 elucidates any better (the SRFIs have rationale and stuff that was omitted from the final report)
2023-08-24 19:46:22 -0400 < cow_2001> This book reminds me of The Little books.
2023-08-24 19:48:25 -0400 < cow_2001> Out of nowhere there is an aside on French pastry and people watching in Parisian cafes.
2023-08-24 19:50:09 -0400 < cow_2001> Or maybe it is more of a Pratchett thing?  Adams?  Wes Anderson?
2023-08-24 19:50:25 -0400 < cow_2001> Amilie(?)?
2023-08-24 19:51:30 -0400 < jcowan> cow_2001: Which book?
2023-08-24 19:51:49 -0400 < cow_2001> jcowan: https://craftinginterpreters.com/representing-code.html#the-visitor-pattern
2023-08-24 19:55:16 -0400 < jcowan> It's more conversational than the LBs, which talk to you like a Zen master a lot of the time.
2023-08-24 19:57:11 -0400 < cow_2001> It's the sudden talk about food.  Then again, the little schemer is just one list of lists of food.
2023-08-24 19:57:24 -0400 < Zipheir> Uh oh, Design Patterns.
2023-08-24 19:57:31 -0400 < cow_2001> Zipheir: ;p
2023-08-24 19:58:12 -0400 < Zipheir> Actually, _A Little Java_ is a book entirely about "the visitor pattern", so I suppose I shouldn't be snarky.
2023-08-24 19:59:06 -0400 < cow_2001> It's good to know stuff.
2023-08-24 19:59:42 -0400 < Zipheir> Have you looked at the Gang of Four book?
2023-08-24 19:59:45 -0400 < cow_2001> Most of this Java stuff goes way over my head.
2023-08-24 20:00:01 -0400 < cow_2001> I have only heard of it.  Never did Java.
2023-08-24 20:00:55 -0400 < Zipheir> It's interesting, but it has a sort of all-caps THE RULES OF PROGRAMMING FROM ON HIGH tone.
2023-08-24 20:01:25 -0400 < cow_2001> The One And Only Way.
2023-08-24 20:01:51 -0400 < Zipheir> Which is funny, because some of the Design Patterns really only make sense in C++ or Java, AFAICT.
2023-08-24 20:02:34 -0400 < aeth> I never really understood that smugness
2023-08-24 20:02:40 -0400 < cow_2001> Working around limitations?
2023-08-24 20:02:41 -0400 < aeth> every language has design patterns, just different ones
2023-08-24 20:02:47 -0400 < cow_2001> Hmm.
2023-08-24 20:03:41 -0400 < Zipheir> It has inspired some good research, like Jeremy Gibbons's https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf
2023-08-24 20:03:58 -0400 < cow_2001> I never walked a mile in their shoes.  I have a friend who is just learning Java and he loves it.
2023-08-24 20:05:13 -0400 < Zipheir> That's a good attitude. I used to try to be a cool kid and make "java bad" jokes, but it turns out I was mostly ignorant.
2023-08-24 20:05:41 -0400 < Zipheir> There is a funny satire of Design Patterns style: http://wiki.c2.com/?KansasCityAirConditioner
2023-08-24 20:06:03 -0400 < aeth> Java's a perfectly fine language... just a bit too much boilerplate and a build system that's very 90s. It's no worse than C++, except you get null pointer and array index out of bounds exceptions instead of "Segmentation fault". Also, your functions have to pretend to be methods on classes because that's how they do modules entirely.
2023-08-24 20:06:22 -0400 < aeth> but a ton of real world Java looks like https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
2023-08-24 20:06:34 -0400 < aeth> so it's not the language, it's everything surrounding the language
2023-08-24 20:08:15 -0400 < aeth> If it wasn't for Minecraft and Android, people would probably think that Java's only usable/used/useful in enterprise situations.
2023-08-24 20:09:49 -0400 < Zipheir> One thing that surprised me when I worked through _A Little Java_ was how hard it was to just evaluate some Java.
2023-08-24 20:10:06 -0400 < Zipheir> No REPL or anything.
2023-08-24 20:10:16 -0400 < aeth> there are some tools that do that
2023-08-24 20:10:23 -0400 < aeth> but I think you're generally supposed to use an IDE that does it for you
2023-08-24 20:10:38 -0400 < aeth> wheras in C and C++ I usually just compile a little program to see what happens because little programs compile quickly
2023-08-24 20:11:14 -0400 < aeth> definitely tough to get instant feedback without the REPL and without extremely quick compilation, but that applies even to trendy languages like Rust
2023-08-24 20:11:24 -0400 < cow_2001> Put prints everywhere.
2023-08-24 20:12:18 -0400 < aeth> That doesn't really help when the language isn't built for the REPL because an arbitrary object won't have a printable representation
2023-08-24 20:12:24 -0400 < aeth> So even just priting something is going to be a bit involved
2023-08-24 20:12:34 -0400 < cow_2001> Oh boy.
2023-08-24 20:13:03 -0400 < aeth> *printing
2023-08-24 20:13:30 -0400 < dpk> i can’t imagine doing extended programming without a REPL
2023-08-24 20:13:48 -0400 < aeth> It's harder to know exactly what's going on, yes
2023-08-24 20:13:53 -0400 < aeth> You never really get full confidence
2023-08-24 20:14:23 -0400 < aeth> But that's not something you can hold against specifically Java since C and C++ also have that issue on top of memory unsafety so your lack of 100% understanding of what's going on is going to potentially cause critical errors
2023-08-24 20:14:32 -0400 < cow_2001> I haven't gotten in the habit of testing using the REPL.
2023-08-24 20:14:34 -0400 < dpk> one of the reasons Chibi core is so fun to hack despite being in C is because compiles are so fast, you can essentially test in the REPL immediately
2023-08-24 20:14:51 -0400 < Zipheir> The not-so-subtle point that Matthias Felleisen makes in _A Little Java_ is "you should probably use Ocaml instead".
2023-08-24 20:14:57 -0400 < cow_2001> I just put example code temporarily and rerun stuff.
2023-08-24 20:15:31 -0400 < dpk> it’s not a REPL for C, but having a quick-compiling REPL for the language you’re implementing in C is the next best thing
2023-08-24 20:15:44 -0400 < aeth> fast feedback doesn't seem to be a major priority anywhere, which is weird
2023-08-24 20:15:55 -0400 < aeth> some people just tolerate minutes of waiting even in 2023 when computers are so fast
2023-08-24 20:15:59 -0400 < aeth> so weird
2023-08-24 20:16:05 -0400 < aeth> I guess they're the same people who don't block ads
2023-08-24 20:16:19 -0400 < cow_2001> They like their office chair fencing.
2023-08-24 20:16:28 -0400 < dpk> programmers find it hard to think beyond their tool horizon
2023-08-24 20:16:38 -0400 < dpk> everyone, including me
2023-08-24 20:16:55 -0400 < Zipheir> aeth: Maybe they're the same people who ship an entire Web-rendering engine to give their timer app a GUI.
2023-08-24 20:17:09 -0400 < aeth> at least the web has a REPL
2023-08-24 20:17:12 -0400 < cow_2001> There is a thing in animal behaviour research.  Umwalt or somesuch.
2023-08-24 20:17:33 -0400 < Zipheir> Umwelt.
2023-08-24 20:17:59 -0400 < cow_2001> Some fishing birds would not recognise a fish if it was laying on the ground.  You have to put it in water.
2023-08-24 20:18:03 -0400 < cow_2001> Let it swim.
2023-08-24 20:18:25 -0400 < aeth> In fact, the web has near instant feedback no matter you do, a principle that makes blocking adblockers basically impossible unless you DRM the entire web because you can just delete any unwanted element yourself if you want.
2023-08-24 20:18:26 -0400 < cow_2001> It is outside their world.
2023-08-24 20:18:48 -0400 < cow_2001> I guess this tool horizon is similar.
2023-08-24 20:19:07 -0400 < dpk> well, i just made up the term
2023-08-24 20:21:05 -0400 < dpk> it’s sometimes about seeing something new and going ‘why would i need that?’ (the classic idea of the blub paradox), but more often simply that imagining new tools is hard, and there’s a cultural bias against spending too long on your tools (‘yak shaving’) vs other programming tasks
2023-08-24 20:21:24 -0400 < Zipheir> "It is not only the performing artist who is, in a very real sense, shaped by the instrument he plays; this holds as well for the Reasoning Man, and I leave it to you to determine how disturbed you are going to be by this observation." --EWD
2023-08-24 20:22:12 -0400 < dpk> once you’ve got used to developing with a REPL it’s hard to go back, but i both know there must be something better than a REPL and have a hard time doing the creative thinking to find out what that might be
2023-08-24 20:22:24 -0400 < jcowan> CL folks say that CL has only one design pattern: (in the traditional caps) USE THE WHOLE LANGUAGE
2023-08-24 20:23:16 -0400 < dpk> . o O ( maybe the thing better than a REPL is GitHub Copilot, but i refuse to participate in GPLwashing and general mass licence violation )
2023-08-24 20:23:41 -0400 < jcowan> the point being that a design pattern is a stereotyped way of using a language, so in CL (or Scheme) if you discover such a design pattern, you should reduce it to a macro, thus extending the language.
2023-08-24 20:23:45 -0400 < Zipheir> dpk: It's similar to some things we take for granted in programming, like almost everything being first-class.
2023-08-24 20:24:22 -0400 < Zipheir> That was Paul Graham's objection to Design Patterns, IIUC.
2023-08-24 20:24:28 -0400 < aeth> CL has many, many design patterns, mostly relating to macros. You can write macros to make macros, negating the purpose of these design patterns, but CL itself only has one, DEFINE-MODIFY-MACRO, which lets you write INCF-style macros. http://www.lispworks.com/documentation/HyperSpec/Body/m_defi_2.htm
2023-08-24 20:24:39 -0400 < Zipheir> "A Design Pattern is an inefficient macro."
2023-08-24 20:24:49 -0400 < mdhughes> The reason Java's so IDE-centric is in the good case, you can write a teeny little main class or JUnit test case, hit Cmd-R or whatever, and it outputs. Compiler design focused on classes means you don't need a full rebuild. ALMOST like a REPL, except awful.
2023-08-24 20:24:52 -0400 < dpk> yes, i was just about to say what aeth said
2023-08-24 20:25:26 -0400 < mdhughes> Design Patterns was very much "we applied Chris Alexander's principles to our Smalltalk & C++ code, and these are our paths".
2023-08-24 20:25:50 -0400 < mdhughes> It wasn't supposed to be prescriptive, but "here's how you find your paths". An industry took it as holy writ isntead.
2023-08-24 20:26:03 -0400 < Zipheir> (If Copilot is a mass license-violator, so is everyone who writes both proprietary and FOSS code. At least, that's where we're heading.)
2023-08-24 20:26:18 -0400 < dpk> a more powerful language maybe makes some patterns obsolete or invisible, but it will create more of them which use its more powerful features
2023-08-24 20:26:48 -0400 < mdhughes> Lisps call a lot of their patterns "HOF".
2023-08-24 20:27:03 -0400 < Zipheir> mdhughes: It was certainly written like holy writ.
2023-08-24 20:27:07 -0400 < mdhughes> But in Java, embodying them in classes/interfaces can be hard.
2023-08-24 20:27:31 -0400 < mdhughes> Zipheir: It's really not, it's a pretty mellow book. The people *after* Gamma et al. were more dogmatic.
2023-08-24 20:27:38 -0400 < Zipheir> Hmm.
2023-08-24 20:29:29 -0400 < mdhughes> Back when I was in that industry, I spent half my time trying to get Big Java School recent grads to actually read papers or books, and understand them, instead of "teacher said to do exactly this, so I am a machine"
2023-08-24 20:30:00 -0400 < Zipheir> Still, I don't remember any discussion of how they discovered all of those patterns. They're presented as if they're supposed to be self-evident.
2023-08-24 20:31:30 -0400 < Zipheir> Not that there aren't good or at least interestning books in the oracular style. "The world is all that is the case."
2023-08-24 20:39:05 -0400 < cow_2001> mdhughes: guile --no-auto-recompile -L . blah/blah.scm is how I C-r.
2023-08-24 20:39:18 -0400 < mdhughes> It's just that easy!
2023-08-24 20:39:24 -0400 < cow_2001> ~_~
2023-08-24 20:39:51 -0400 < mdhughes> <IT Crowd new 911 number yustub clip>
2023-08-24 20:40:19 -0400 < cow_2001> Hey, bash has ↑
2023-08-24 20:40:26 -0400 < cow_2001> !
2023-08-24 20:40:38 -0400 < cow_2001> History, that is.
2023-08-24 20:41:22 -0400 < cow_2001> If your phone doesn't have speedial, get a new phone!
2023-08-24 20:41:40 -0400 < cow_2001> Or dialing app or whatever………
2023-08-24 20:46:12 -0400 < jcowan> Zipheir: Yes, the Tractatus 1.1 sounds like a thunder god shouting from the top of his mountain: "DIE WELT IST ALLES, WAS DER FALL IST".
2023-08-24 20:46:33 -0400 < cow_2001> I really need to learn how to properly use the repl.
2023-08-24 20:46:41 -0400  * cow_2001 reads the manual.
2023-08-24 20:47:58 -0400 < jcowan> I always wanted to outfit a REPL (Chibi's, perhaps, since it is written in straightforward Scheme) so that it would generate test cases.  It remembers the last expression and its value, and then @OK causes that to be written out as a test case to the current test-case file.
2023-08-24 20:48:36 -0400 < jcowan> So as you do random testing of this that and the other, you eventually grow a test file.
2023-08-24 20:49:01 -0400 < cow_2001> Argh.  Again, it is a reference, not a tutorial. ~_~
2023-08-24 20:49:36 -0400 < cow_2001> Why is GNU so good at writing references and not tutorials?
2023-08-24 20:50:40 -0400 < cow_2001> Why would I use ,import and not ,load, for example?
2023-08-24 20:50:49 -0400 < cow_2001> Or vica versa………
2023-08-24 20:51:00 -0400 < jcowan> They are a lot easier for programmers to write.  Elisp actually has a good tutorial because it was written by an amateur programmer.
2023-08-24 20:51:38 -0400 < cow_2001> Yes, eintr, or something.
2023-08-24 20:51:50 -0400 < cow_2001> It is lovely 
2023-08-24 20:51:52 -0400 < cow_2001> .
2023-08-24 20:51:54 -0400 < jcowan> Well, let's start with why you would use them instead of (load ...) and (import ...).  The answer is that if you have messed up what is imported, you may not have them available.
2023-08-24 20:52:44 -0400 < cow_2001> Not have them available?
2023-08-24 20:53:22 -0400 < jcowan> The difference between import and load generally is that import is a macro that pulls in a library specified by its name, whereas load is a procedure that pulls in a file specified by its pathname.  So you can use load if you want to determine what to read in programmatically.  Include is in between: it is a macro, but it deals with files rather than libraries.
2023-08-24 20:53:41 -0400 < jcowan> s/by its pathname/by an expression that evaluates to a pathname
2023-08-24 20:55:10 -0400 < cow_2001> Oh.
2023-08-24 20:55:24 -0400 < cow_2001> Oh!
2023-08-24 20:55:54 -0400 < cow_2001> so (load …) and (import …) may overwrite the names load and import.
2023-08-24 20:56:05 -0400 < cow_2001> but not ,load and not ,import
2023-08-24 20:56:06 -0400 < jcowan> yes
2023-08-24 20:56:27 -0400 < jcowan> Similar bad things happen if you redefine quote, and then ' stops working.
2023-08-24 20:56:34 -0400 < cow_2001> Oh boy.
2023-08-24 20:57:20 -0400 < jcowan> ditto for quasiquote
2023-08-24 20:58:07 -0400 < cow_2001> Okay, so I want to work on some (define-library (blah moo) …) module that lives in blah/moo.scm.  What do I do?
2023-08-24 20:58:24 -0400 < jcowan> What do you mean by "work on it"?
2023-08-24 20:58:34 -0400 < cow_2001> With the repl.
2023-08-24 20:58:43 -0400 < cow_2001> Just ,import?
2023-08-24 20:59:26 -0400 < cow_2001> I open both the repl and the file in an editor.
2023-08-24 20:59:37 -0400 < daviid> cow_2001: use geiser
2023-08-24 20:59:42 -0400 < cow_2001> The repl in some terminal, not editor.
2023-08-24 20:59:46 -0400 < cow_2001> Hmm.
2023-08-24 20:59:50 -0400 < jcowan> It depends on whether you are doing white-box or black-box testing.  I always write a foo.scm file (foo.sld in Chibi) that uses include to pull in the actual code file "foo-impl.scm")
2023-08-24 21:00:03 -0400 < cow_2001> I really should read geiser's manual then.
2023-08-24 21:00:31 -0400 < jcowan> If you want to break the library abstraction barrier, you can load the foo-impl.scm file
2023-08-24 21:01:13 -0400 < cow_2001> Black box is using the API and white box is tinkering with implementation innards stuff?
2023-08-24 21:01:23 -0400 < daviid> yes, read and use geiser ... we all do (almost all guilers i mean)
2023-08-24 21:01:28 -0400 < jcowan> yes
2023-08-24 21:02:08 -0400 < jcowan> I often for example use define-record-printer in the impl file, protected by (cond-expand (chicken ...))
2023-08-24 21:02:22 -0400 < jcowan> that way I can see the objects I'm dealing with in a more useful way
2023-08-24 21:03:57 -0400 < jcowan> Getting the library wrapper correct is tricky: it wants to be called foo.bar.baz.scm in Chicken, foo/bar/baz.sld in Chibi, foo/bar/baz.scm in Guile, foo.<implementation>.sls in most R6RS systems, etc.
2023-08-24 21:05:03 -0400 < cow_2001> I have geiser set up, but I never really picked up on the more advanced stuff.  I use the documentation showing C-c C-d C-d all the time, rarely C-. and C-, which go in and out a definition.
2023-08-24 21:05:56 -0400 < cow_2001> Oh, yeah, it took me a while to get the naming right.  I had dots in my module names and Guile did not like it.
2023-08-24 21:20:38 -0400 < flatwhatson> cow_2001: you "work on" a module by entering it (ie. making it the current module)
2023-08-24 21:21:47 -0400 < flatwhatson> ,module (blah moo) ;; or geiser-mode-switch-to-repl-and-enter
2023-08-24 21:22:33 -0400 < flatwhatson> now anything you evaluate happens in the context of that module, you can redefine stuff or call non-exported procedures
2023-08-24 21:23:53 -0400 < cow_2001> Hmm.
2023-08-24 21:27:03 -0400 < flatwhatson> though geiser is pretty clever, you don't need to do this just to reload a single procedure
2023-08-24 21:28:03 -0400 < flatwhatson> geiser-eval-definition can be used to redefine something without switching modules
2023-08-24 21:29:05 -0400 < flatwhatson> so you test something in the repl, encounter a bug, find the code, fix it, geiser-eval-definition, goto 10
2023-08-24 21:31:02 -0400 < flatwhatson> also geiser-eval-buffer can be used like this, though you need to consider side-effects of re-evaluating the top level of that module (eg. redefining record types invalidating previous instances)
2023-08-24 21:45:25 -0400 < cow_2001> Oh boy.
2023-08-24 21:45:57 -0400 < cow_2001> No way of marking "Hey, this is a perfect piece of code.  Eval only once."
2023-08-24 21:45:59 -0400 < cow_2001> ?
2023-08-24 21:46:03 -0400 < flatwhatson> define-once
2023-08-24 21:46:08 -0400 < cow_2001> Woops.
2023-08-24 21:47:23 -0400 < cow_2001> But there is no such thing for records.
2023-08-24 21:47:27 -0400 < flatwhatson> not sure if there's an equivalent for define-record-type, i just avoid it by being careful when it matters
2023-08-24 21:47:36 -0400 < cow_2001> Ah.
2023-08-24 21:48:09 -0400 < flatwhatson> this is where CLOS/GOOPS can do a better job, allowing you to "upgrade" instances
2023-08-24 21:49:17 -0400 < flatwhatson> https://www.gnu.org/software/guile/manual/html_node/Redefinable-Classes.html
2023-08-24 22:00:32 -0400 < acdw> afaik chicken is flexible enough to work with foo/bar/baz.scm,,, you'll just need to be careful with the egg file 
--- Day changed Fri Aug 25 2023
2023-08-25 05:19:06 -0400 < MrtnMrtn> WB gnomon 
2023-08-25 06:52:30 -0400 < dpk> mnieper (if you read this): do you think it’s possible to implement syntax parameters in terms of identifier properties? section 4.1 (Implementation) of the Barzilay/Culpepper/Flatt paper seems to suggest that Racket uses/used a comparable approach, but my (probably too naive) attempt along similar lines in Chez Scheme didn’t work (the parameterization wasn’t visible at the site of the parameter’s use)
2023-08-25 08:00:14 -0400 < MrtnMrtn> seninha: Bad connection?
2023-08-25 08:00:37 -0400 < seninha> MrtnMrtn: yeah
2023-08-25 08:02:54 -0400 < MrtnMrtn> sucks.
2023-08-25 13:24:56 -0400 -!- hernan_ is now known as hernan
2023-08-25 14:42:11 -0400 < gwatt> dpk: I kind of suspect not. You mentioned chez, which has similar functionality called fluid-let-syntax, which doesn't appear to be implementable on top of identifier properties
2023-08-25 18:46:40 -0400 < jcowan> The Steering Committee is awake, has sent me an email with their ideas, which I am now discussing with them.  Further news next week, I hope.
2023-08-25 18:47:33 -0400 < Zipheir> The suspense!
2023-08-25 18:48:15 -0400 < aeth> I'm going to guess what some online seem to think: R8RS, which is just Racket in its entirety.
2023-08-25 18:49:36 -0400 < Zipheir> Unlikely.
2023-08-25 18:51:46 -0400 < aeth> yes, but https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law
2023-08-25 18:53:22 -0400 < Zipheir> I've said it before, but Racket is More R6 than R6™.
2023-08-25 18:53:49 -0400 < aeth> perhaps we can split Scheme into even and odd languages to compromise?
2023-08-25 18:54:13 -0400 < Zipheir> Isn't there some fan rule that says that every odd-numbered Star Trek movie is trash?
2023-08-25 18:54:53 -0400 < Zipheir> (Unwarranted, I'd say, since the first one was unusually ambitious.)
2023-08-25 18:55:49 -0400 < aeth> II, IV, VI, VIII, hmm, holds up through that, arguably
2023-08-25 18:56:50 -0400 < aeth> if you continue the numbering. https://en.wikipedia.org/wiki/Star_Trek#Film
2023-08-25 18:57:18 -0400 < aeth> though arguably First Contact (VIII) is the only good one from the TNG era
2023-08-25 18:57:27 -0400 < jcowan> I can rule that out.  They are concerned that we don't have any actual implementers on board at present, and have proposed a rule of the form "N implementations are required for any feature to go in".  I have told them I support this; the value of N is still under discussion.
2023-08-25 18:57:52 -0400 < Zipheir> Good to know.
2023-08-25 18:59:07 -0400 < jcowan> However, given that all Schemes are FLOSS now, the implementation doesn't have to be done by the core team.
2023-08-25 19:01:34 -0400 < Zipheir> Does a portable implementation of FEATURE count as something every implementation supports?
2023-08-25 19:01:45 -0400 < Zipheir> I assume not.
2023-08-25 19:02:57 -0400 < aeth> Zipheir: I would assume it would only count if the implementation actually adopts it
2023-08-25 19:03:02 -0400 < aeth> Although that could be tricky
2023-08-25 19:03:40 -0400 < aeth> as to whether it's "core" or not
2023-08-25 19:04:08 -0400 < jcowan> Uncertain.  I have asked the SC to propose a principle for which fully portable features should be included in R7RS, as without htat it is difficult to reply to "There should be no fully portable features".
2023-08-25 19:04:55 -0400 < Zipheir> Thanks.
2023-08-25 19:05:09 -0400 < Zipheir> aeth: Adopts and endorses, I guess.
2023-08-25 19:05:37 -0400 < aeth> if they mean independent implementations, it could be tricky
2023-08-25 19:06:28 -0400 < jcowan> Independent Schemes, not necessarily implementations (e.g. Chez and Racket don't count as two)
2023-08-25 19:11:24 -0400 < aeth> it just occurs to me that if the schemes weren't independent, they'd be a racket
2023-08-25 19:14:00 -0400  * jcowan laughs loudly
2023-08-25 19:15:27 -0400 < jcowan> The wording I have is not final, but it speaks of acceptance by the implementation community *or* provision by an outside party (the proposer and friends).
2023-08-25 19:37:27 -0400 < dpk> aeth: i hope the steering committee is intelligent enough to realize that merely changing the name would not change the fundamental underlying political problems
2023-08-25 19:42:40 -0400 < dpk> jcowan: even then, what is ‘fully portable’? the point of the independently form is that a compiler might be able to optimize it better than begin, but do we have to have two independent compilers that actually do that?
2023-08-25 19:43:06 -0400 < dpk> (i wouldn’t be too sad to see independently on the chopping block compared to some other features, it’s just an example)
2023-08-25 20:00:10 -0400 -!- Netsplit *.net <-> *.split quits: grettke, micro, Gliese852, Origin, oenone_
2023-08-25 20:00:18 -0400 -!- Netsplit over, joins: micro
2023-08-25 20:00:27 -0400 -!- Netsplit over, joins: Gliese852
2023-08-25 20:00:34 -0400 -!- Netsplit over, joins: Origin
2023-08-25 20:17:23 -0400 < Zipheir> So much for Marc's dream of core immutable pairs, I guess.
2023-08-25 20:17:43 -0400 < dpk> we have numerous implementations which enforce that
2023-08-25 20:18:12 -0400 < dpk> https://docs.scheme.org/surveys/immutable-literals/
2023-08-25 20:21:22 -0400 < Zipheir> Oh, I meant all lists being immutable modulo the library of strictly mutable ones.
2023-08-25 20:21:36 -0400 < Zipheir> À la Racket.
2023-08-25 20:21:57 -0400 < dpk> what we’re maybe lacking is Schemes which have a way to create pairs which are immutable which aren’t literals, and a way to detect when a pair is immutable without actually trying to mutate it, but i hope i could file those under ‘trivialities’ (if your implementation already supports creating *these* pairs and marking them as immutably, why not also these pairs over here?) and ‘cleanup’ (it’s indisputably the Wrong Thing to 
2023-08-25 20:21:57 -0400 < dpk> neither have a way to detect whether a pair is immutable before mutating it, nor in fact whether a pair mutation failed silently when you tried)
2023-08-25 20:22:04 -0400 < dpk> oh, that was never going to happen anyway
2023-08-25 20:22:33 -0400 < dpk> not for R7RS, and by extension probably not for any RnRS
2023-08-25 20:22:54 -0400 < dpk> (i repeat, can you imagine someone looking at what a pain in the arse R7RS Large was to get completed and saying, ‘yeah, let’s do that again’?)
2023-08-25 20:23:55 -0400 < Zipheir> It's certainly not the Time Warp.
2023-08-25 20:26:27 -0400 < dpk> maybe if R7RS really, really succeeds at its goal of re-unifying the Scheme community and gets even hardline R5RSers/reluctant R7RS smallers like Chicken Scheme on board the same train as R6RSers like Chez, then a hypothetical R8RS would not look nearly such a dangerous or difficult prospect. but, though i obviously really want to see that happen, in reality the best we can hope for is maybe that we don’t turn the two way split into a three 
2023-08-25 20:26:27 -0400 < dpk> way split
2023-08-25 20:32:51 -0400 < Zipheir> I also hope can reunite on R7RS, or on R8RS if it's necessary.
2023-08-25 21:21:25 -0400 < aeth> R8RS as a small patch on R7RS-small and perhaps the early parts of R8RS-large wouldn't fragment things further, at least
2023-08-25 21:28:45 -0400 < jcowan> You can always make immutable pairs with eval given that literals are immutable:  (eval ''(a b c) (interaction-environment) should do the trick.
2023-08-25 23:28:22 -0400 < mdhughes> That's mutable in Chez REPL.
2023-08-25 23:30:05 -0400 < mdhughes> And in a script, sometimes REPL is less generous. Nope!
--- Day changed Sat Aug 26 2023
2023-08-26 00:15:28 -0400 < Zipheir> Weird. I guess that's an example of an R6 REPL disagreeing with R6.
2023-08-26 01:19:33 -0400 -!- ced1 is now known as cedb
2023-08-26 01:32:30 -0400 -!- ced1 is now known as cedb
2023-08-26 01:38:28 -0400 < jcowan> Since R6 doesn't standardize a REPL, that's legal.
2023-08-26 02:12:58 -0400 < mnieper``> Zipheir jcowan: This is a wrong interpretation of what's going on. 
2023-08-26 02:14:05 -0400 < mnieper``> The value of '(1 2 3) (e.g. when returned by the REPL in Chez) *is* immutable (by the report), but the implementation Chez does not enforce this immutability.
2023-08-26 02:14:22 -0400 < mnieper``> There is no MUST in R6RS about enforcing this.
2023-08-26 02:14:44 -0400 < mnieper``> Thus, there are immutable pairs in Chez where no exception is raised when they are mutated.
2023-08-26 02:15:59 -0400 < mnieper``> Zipheir: My dream of immutable pairs (and only (!) immutable pairs because everything else does not solve the problems banning mutable pairs would) is not for R7RS-large but for a later future.
2023-08-26 02:17:15 -0400 < mnieper``> I only hope that the use of mutability of pairs in the R7RS-large standard will be reduced to an absolute minimum beyond R7RS-small so that they can more easily removed later. R6RS showed how one could do it.
2023-08-26 02:47:28 -0400 < lisbeths> I have been thinking alot about this language called sub-L
2023-08-26 02:47:59 -0400 < lisbeths> and it is a subset of lisp that is used to write portable code by some company. They take sub-L and compile it to something else
2023-08-26 02:48:31 -0400 < lisbeths> And I have been thinking about a subset of scheme used to handle portability of code between schemes
2023-08-26 02:48:54 -0400 < lisbeths> Has something like this been done before? Is there a better solution?
2023-08-26 02:49:21 -0400 < lisbeths> I really want to write for GUILE but it doesn't run on JVM, CLR, or LLVM
2023-08-26 02:50:06 -0400 < mnieper``> jcowan: Why wouldn't Chez and Racket count as two independent implementations?
2023-08-26 02:50:49 -0400 < mnieper``> That sounds like an arbitrary rule.
2023-08-26 02:51:48 -0400 < mnieper``> Just as CHICKEN uses C as a backend, Racket uses a modified version of Chez. And Racket is much, much more than Chez and even the core semantics differ (because Racket is not R6RS).
2023-08-26 02:55:30 -0400 < mnieper``> dpk: I saw your question. Answer later.
2023-08-26 05:52:38 -0400 < dpk> yes, i think discarding the independence of Chez and Racket as implementations has to be conditional on what specific feature is meant
2023-08-26 05:52:57 -0400 < dpk> for macro expansion, they are obviously independent
2023-08-26 05:53:14 -0400 < dpk> for runtime features, obviously not so much, though it depends which feature is meant
2023-08-26 05:54:19 -0400 < jcowan> Of course those points are correct, but this is not about correctness, it is about the perception of correctness.
2023-08-26 05:56:01 -0400 < jcowan> If you have a third proposal to "N = 3" and "N = 2 where restrictions are placed on the two", by all means present it to the SC.
2023-08-26 05:57:28 -0400 < jcowan> mnieper: ^^
2023-08-26 05:58:43 -0400  * dpk shrugs
2023-08-26 05:59:05 -0400 < dpk> all the features we currently have as SRFIs satify N=2 with restrictions on independence
2023-08-26 05:59:24 -0400 < dpk> a couple things people want in the pre-SRFI stage are currently N=0
2023-08-26 06:59:57 -0400 < MrtnMrtn> Is it me, or did scheme use to be much more popular?
2023-08-26 07:07:13 -0400 < dpk> when and for what purpose?
2023-08-26 07:11:46 -0400 < MrtnMrtn> dpk: If memory serves, this channel used to be busy as coitus.
2023-08-26 07:13:22 -0400 < dpk> this does not answer my question
2023-08-26 07:14:38 -0400 < MrtnMrtn> I am not sure what you wish to know? Are you new to scheme?
2023-08-26 07:16:10 -0400 < dpk> not quite, no
2023-08-26 07:24:35 -0400 < mnieper``> dpk jcowan : Even for runtime features, Racket and Chez are quite different.
2023-08-26 07:24:54 -0400 < mnieper``> Chez has native threads, Racket doesn't. Racket has delimited continuations, Chez doesn't.
2023-08-26 07:25:07 -0400 < mnieper``> Racket's default pairs are immutable, Chez's aren't, etc.
2023-08-26 07:25:17 -0400 < mnieper``> The runtime libraries are independent, etc.
2023-08-26 07:25:39 -0400 < mnieper``> Counting Racket and Chez as one is like counting Gambit-C and CHICKEN as one.
2023-08-26 07:27:37 -0400 < mnieper``> jcowan: N = 3 is much much better than N = 2 with restrictions on Racket/Chez because the latter treatment is strongly politically biased.
2023-08-26 07:28:10 -0400 < mnieper``> N = 2 without special treatment of two implementations is a possible third proposal.
2023-08-26 07:28:34 -0400 < mnieper``> However, I don't see myself in a position to present it to the SC because the SC's discussion is private between them and you.
2023-08-26 07:29:57 -0400 < dpk> with N = 3 we will definitely be looking at tossing features like identifier properties out (only Chez and Unsyntax, and aiui the SC would probably also consider Unsyntax too minor); and with that will go the sample implementation of syntax-case bzw. we will entirely lose the ability to implement syntax-case in terms of other primitives defined in the report
2023-08-26 07:30:23 -0400 < mnieper``> Independently of this, any N = X proposal may yield an outcome where half of the existing Schemes implement half of the features and the other half implements the other half of features.
2023-08-26 07:31:09 -0400 < mnieper``> dpk: N = X would mean that eventually X Schemes have a feature, no?
2023-08-26 07:31:43 -0400 < mnieper``> But you also make a good point wrt Unsyntax. It is a portable implementation of s-c in R7RS.
2023-08-26 07:32:17 -0400 < mnieper``> An implementation can simply ship it instead of a native expander.
2023-08-26 07:32:24 -0400 < mnieper``> So what does portable implementation mean?
2023-08-26 07:33:09 -0400 < dpk> syntax-case itself only has two independent (and correct) implementations to my knowledge, discounting psyntax and Chez’s expander as not being independent of one another, and allowing only Unsyntax
2023-08-26 07:33:21 -0400 < dpk> err, allowing only Unsyntax besides those two
2023-08-26 07:40:17 -0400 < mnieper``> dpk: Why do you always count psyntax and Chez as non-independent?
2023-08-26 07:40:50 -0400 < dpk> because they have a common origin in Dybvig’s original implementations of syntax-case for Chez, even if they diverged
2023-08-26 07:41:17 -0400 < dpk> KHTML, WebKit, and Blink are not independent implementations of the HTML and CSS standards either
2023-08-26 07:48:29 -0400 < mnieper``> psyntax is no more similar to Chez's expander than would any expander written by someone who knows Chez's source code very well.
2023-08-26 07:51:36 -0400 < mnieper``> psyntax is by Abdulaziz Ghuloum and Kent Dybvig, while Chez's expander is by R. Kent Dybvig, Oscar Waddell, Bob Hieb, Carl Bruggeman, Andy Keep.  Correct me if I am wrong, but psyntax didn't start by modifying Chez's source code but by starting with a blank piece of paper.
2023-08-26 07:52:17 -0400 < dpk> https://scheme.com/syntax-case/psyntax.ss says ‘Extracted from Chez Scheme Version 7.3 (Feb 26, 2007)’
2023-08-26 07:52:35 -0400 < mnieper``> In any case, it shows that N = X doesn't mean much unless it is clear how to count - and this is the hard part.
2023-08-26 07:52:44 -0400 < dpk> yes, also true
2023-08-26 07:52:57 -0400 < dpk> that’s one kind of political machination i am concerned about
2023-08-26 07:53:40 -0400 < dpk> the other is someone going ‘well, the implementation you just added to Chibi doesn’t count, because the reason you added it was just so that the feature would qualify as having enough implementations’
2023-08-26 07:54:20 -0400 < mnieper``> dpk: The psyntax version you point out is not the one in use by Loko, say.
2023-08-26 07:54:32 -0400 < mnieper``> Your psyntax version is pre-R6RS.
2023-08-26 07:56:45 -0400 < mnieper``> So we have Chez/psyntax (old) + Unsyntax + psyntax (new) as three independent versions.
2023-08-26 07:57:51 -0400 < mnieper``> The N = X idea works much better where it is clear who the stakeholders are.  E.g. in the old times, for JavaScript standards, we had Firefox + Chrome + Edge + Safari as the main players.  Something like N = 2 made sense there.
2023-08-26 07:58:02 -0400 < mnieper``> And it was well-defined, which engine shipped what.
2023-08-26 09:04:44 -0400 < lockywolf> What does actually make a language "kind of a Lisp"?
2023-08-26 09:04:52 -0400 < lockywolf> lambdas?
2023-08-26 09:04:58 -0400 < lockywolf> first-class functions?
2023-08-26 09:05:28 -0400 < lockywolf> In which sense is JavaScript "a lisp"?
2023-08-26 09:09:04 -0400 < mnieper``> Ask N lispers and get 2^N answers.
2023-08-26 09:14:27 -0400 < lockywolf> on the old times there was no Edge
2023-08-26 09:15:53 -0400 < mnieper``> I meant Microsoft's JS engine whatever it was called.
2023-08-26 09:16:33 -0400 < lockywolf> in the "old times" you could write DHTML in two languages, in MS Jscript, and in MS Visual Basic
2023-08-26 09:18:08 -0400 < mnieper``> I didn't mean times that old.
2023-08-26 09:19:57 -0400 -!- mirai_ is now known as mirai
2023-08-26 09:38:02 -0400 < mdhughes> JS's not a Lisp, but it's lispy. Sometimes even Schemey, but only Safari has guaranteed TCO. It *is* a Self, it has very similar semantics.
2023-08-26 10:03:51 -0400 < sham1> ChakraCore
2023-08-26 11:38:37 -0400 < mnieper> sham1: Thank you!
2023-08-26 12:05:48 -0400 < Zipheir> lockywolf: One thing that Lisps seem to have that most other languages don't is pairs instead of an actual list type. So improper lists are (I think?) unique to Lisp.
2023-08-26 12:06:53 -0400 < Zipheir> Otherwise, S-expressions and a general functional flavor are the Lispy qualities.
2023-08-26 12:29:42 -0400 < dpk> update: apparently identifier properties are more widely supported than i thought! i should have checked https://docs.scheme.org/srfi/support/ first
2023-08-26 12:30:07 -0400 < dpk> apart from Chez, IronScheme and Loko also supports them. (using psyntax, of course)
2023-08-26 12:30:56 -0400 < dpk> presumably the IronScheme/Loko patches of psyntax for identifier properties could also be ported to Guile
2023-08-26 12:31:32 -0400 < dpk> but in any case, we definitely have 3 implementations for identifier properties, which is a big concern off my mind
2023-08-26 12:34:58 -0400 < dpk> hmm, i can’t actually find the IronScheme impl for it though
2023-08-26 12:39:03 -0400 < dpk> nor for Loko
2023-08-26 12:39:08 -0400 < dpk> so maybe the table is wrong, sigh
2023-08-26 15:26:20 -0400 < mnieper``> I guess so (that the table is wrong).
2023-08-26 15:26:39 -0400 < mnieper``> But isn't the question which features are going to be implemented and not which features are implemented?
2023-08-26 15:29:35 -0400 < mnieper``> Zipheir: Improper lists are a Lisp misfeature. :)
2023-08-26 15:34:56 -0400 < Zipheir> Agreed.
2023-08-26 15:46:53 -0400 < Zipheir> lockywolf: There you go: Lisp is best characterized by a misfeature. :)
2023-08-26 16:24:15 -0400 < aeth> to be fair, they're more of a misfeature in Scheme than in other Lisps
2023-08-26 16:26:06 -0400 < aeth> for instance, list? is supposed to be a proper list in Scheme, and verifying this is O(n), so writing correct Scheme means an O(n) verification... that's uh... actually a big-Theta, not a big-O. Because it's going to walk the whole list.
2023-08-26 16:28:09 -0400 < Zipheir> Yes.
2023-08-26 16:28:19 -0400 < aeth> In Common Lisp, you'd usually assume it has no dot and then fail when you get to the dot, which if you rely on side effects is less correct, but it's going to walk the list half as often and most of the time you're right. Although that's still the same big-O because O(2n) => O(n).
2023-08-26 16:28:28 -0400 < aeth> because LISTP checking in CL is fast
2023-08-26 16:30:23 -0400 < aeth> improper/proper checking is not quite the same as a cons pair because it's really pair-or-nil
2023-08-26 18:38:31 -0400 < cow_2001> How do I start writing useful Scheme?  I wrote a dumb little script in Guile a while ago that may or may not be useful to those who like minimalist desktops.
2023-08-26 18:39:25 -0400 < cow_2001> Wrote a bit of……… whatsitcalled……… little example programs for prescheme's demo repo.
2023-08-26 20:12:00 -0400 < mdhughes> Same as any language, pick a project and start working on it. If you don't know enough yet for a problem, you learn it. Takes a while, may not ship, but you'll learn from it.
2023-08-26 20:13:53 -0400 < mdhughes> You don't have to call list?, you can just use pair? and do runtime checks or assume cdr will explode at some point.
2023-08-26 20:16:05 -0400 < mdhughes> Lists are nice, you don't have to keep an index, just a single pointer. It's like C strings (and linked lists, the universal data type there).
2023-08-26 21:59:37 -0400 < lockywolf> cow_2001: for "small but useful" Scheme projects there is a scheme-script github organisation
2023-08-26 22:00:21 -0400 < lockywolf> Aimed at storing demos of useful stuff
--- Day changed Sun Aug 27 2023
2023-08-27 00:22:08 -0400 -!- daviid is now known as Guest2355
2023-08-27 02:30:26 -0400 < mdhughes> l
2023-08-27 02:30:51 -0400  * mdhughes didn't wait for cmd-tab to finish
2023-08-27 04:57:51 -0400 < dpk> in which ur fave (SRFI) is problematic: https://codeberg.org/scheme/r7rs/issues/146
2023-08-27 05:15:25 -0400 < wasamasa> I don't see it listed there
2023-08-27 05:16:26 -0400 < wasamasa> I definitely did not like srfi-125 and srfi-146 though
2023-08-27 05:16:58 -0400 < wasamasa> clearly it's time for someone to deliberately break compatibility with r5rs-r7rs and make a dysfunctional scheme everyone wants to use
2023-08-27 05:17:23 -0400 < wasamasa> like this thing: https://github.com/mattwparas/steel
2023-08-27 05:37:57 -0400 < dpk> oh, fuck. i think R7RS’s define-library is incompatible with AOT compilation and dynamic linking
2023-08-27 05:38:07 -0400  * dpk headache
2023-08-27 05:39:34 -0400 < dpk> if library (x) contains a (cond-expand ((library (y)) (define-something))), and (x) if AOT compiled as a dynamically-linkable library when (y) isn’t installed, you don’t get the something from define-something, even if library (y) is available at run time
2023-08-27 05:40:52 -0400 < dpk> *(x) is AOT compiled
2023-08-27 05:42:13 -0400 < dpk> there’s not much we can do about this other than warn about it
2023-08-27 05:42:15 -0400 < jcowan> No more you should.  
2023-08-27 05:43:27 -0400 < jcowan> This is like complaining that if you compile a program and change the source, the compiled program doesn't automatically get recompiled.
2023-08-27 05:44:17 -0400 < sham1> Yeah, to me that's a problem with the way the AOT compilation is done and how the dependencies are handled
2023-08-27 05:46:47 -0400 < dpk> we could maybe ask implementations to keep track of uses of the library clause of cond-expand, save that information in AOT compiled libraries, and check if any libraries that weren’t available at compile time are now available at run time to warn about it. but that would almost certainly have to be a SHOULD at most (or an ‘are encouraged to’ more realistically)
2023-08-27 05:47:24 -0400 < sham1> Should probably be a non-normative "ought"
2023-08-27 05:48:31 -0400 < sham1> Anyway, I'm feeling a bit controversial this Sunday so... should we specify a REPL environment
2023-08-27 05:48:54 -0400 < sham1> Like in a sense "if you provide a REPL, here's how you should do it"
2023-08-27 05:49:18 -0400 < dpk> i think my plan is more or less to copy what R7RS small said about it
2023-08-27 05:49:38 -0400 < sham1> Well R7-small basically says nothing
2023-08-27 05:49:41 -0400 < dpk> which boils down to ‘there might be a REPL, but we can’t say much that is useful to a programmer about how it might work’
2023-08-27 05:50:32 -0400 < sham1> I don't see why we couldn't say something about how a REPL could be, I mean CL for example managed it
2023-08-27 05:50:54 -0400 < dpk> yes, CL has a distinction between interpreted and compiled code which Scheme doesn’t know
2023-08-27 05:52:02 -0400 < dpk> i am trying to make sure that tree-walking remains a valid strategy for implementing the R7RS Foundations, since it’s the only way to get REPL semantics that aren’t ‘hopeless’, but R6RS compatibility might make that impossible. i haven’t yet worked that out fully
2023-08-27 05:53:08 -0400 < sham1> I suppose that in lieu of an official specification there could be an unofficial thing to try to make things better
2023-08-27 05:53:42 -0400 < dpk> (arguably the classic Lisp tower of tree-walking interpreter / byte-code interpreter / AOT compilation is too out of fashion to be worth considering anyway)
2023-08-27 05:54:17 -0400 < dpk> there is https://small.r7rs.org/wiki/ChezReplSemantics/ for an R6RS-compatible REPL semantics (that still might not be what people actually want)
2023-08-27 06:16:30 -0400 < dpk> sham1 reminded me i wanted to make a list like this https://codeberg.org/scheme/r7rs/wiki/Foundations-implementation-types
2023-08-27 08:40:36 -0400 < shamelessshill> Reccos for learning Scheme (specificcally Guile)? Books, preferably.
2023-08-27 08:49:59 -0400 < dpk> impatient chap
2023-08-27 09:12:01 -0400 < wasamasa> nickname said it all
2023-08-27 09:13:13 -0400 < wasamasa> like, I remember some nick frequenting a bunch of IRC channels and asking some very specific questions about SICP/Scheme
2023-08-27 09:13:47 -0400 < wasamasa> http://gnufans.net/~fsbot/logtmp/230827.131333.zISBZI.txt
2023-08-27 09:14:08 -0400 < wasamasa> they never uses shill in the nick though
2023-08-27 10:24:09 -0400 < mnieper``> dpk: cond-expand is not incompatible with AOT compilation if the right (and only reasonable) meaning of AOT is used. We have a runtime phase and we have expand-time phases. AOT compilation freezes the expand-time state. And cond-expand can be interpreted as being evaluated at expand-time.
2023-08-27 10:24:36 -0400 < mnieper``> The reason why I say that this is the only reasonable meaning of AOT (for Scheme) is the existence of procedural macros.
2023-08-27 10:25:05 -0400 < mnieper``> Their results depend on the systems state when they are expanded. cond-expand is just the tip of the iceberg. 
2023-08-27 10:25:57 -0400 < mnieper``> Nevertheless, cond-expand (here for libraries) is a misfeature that tries to emulate what a package manager/installer should do (and could do better).
2023-08-27 10:26:19 -0400 < mnieper``> Say you have the portable library (bar) exporting bar that runs in O(n).
2023-08-27 10:26:44 -0400 < mnieper``> However, with (foo) available, (bar) implements bar in O(1). And uses cond-expand for this.
2023-08-27 10:27:27 -0400 < mnieper``> Now we have a problem if (foo) is principally available for the system, but currently not installed by the user.
2023-08-27 10:27:55 -0400 < mnieper``> What we really want is a test whether (foo) can be installed (and the user maybe prompted for it). 
2023-08-27 10:28:12 -0400 < mnieper``> Second comment:
2023-08-27 10:28:54 -0400 < mnieper``> The "top-level is hopeless" means something different. 
2023-08-27 10:29:31 -0400 < mnieper``> Whatever R7RS REPL semantics is used, the top-level remains hopeless.
2023-08-27 10:29:50 -0400 < mnieper``> The phrase "R6RS-compatible REPL" doesn't make much sense, does it?
2023-08-27 10:30:52 -0400 < mnieper``> In any case, we should (or even must) specify REPL semantics because they are needed for (interaction-environment).
2023-08-27 10:33:11 -0400 < mnieper``> Third comment: 
2023-08-27 10:35:40 -0400 < mnieper``> If the Batteries are stripped down considerably, do we need the Foundations/Batteries split anymore? Maybe then it is time to at least reconsider Lassi's approach for the bulk of the (former) Batteries libraries, namely by developing outside of the actual RnRS standard (but more organized than a bunch of independent SRFIs would be).
2023-08-27 10:37:42 -0400 < mnieper``> For the rest, we would end up with something like R6RS+ (in an R7RS-disguise), so two questions come up: Why would the result gain a larger percentage of followers in the Scheme community than R6RS? And why wouldn't we then just use an (updated) R6RS?
2023-08-27 11:32:55 -0400 < sham1> And from there we might get even another question: why do R7RS at all if Large just ends up being R6RS with some minor tweaks
2023-08-27 11:37:49 -0400 < Zipheir> The top-level is hopeless iff people don't want to come up with consistent top-level semantics.
2023-08-27 11:38:03 -0400 < Zipheir> It's become a thought-ending slogan, though.
2023-08-27 11:38:27 -0400 < mnieper> sham1: Yes. It is not that one cannot use, say, SRFI 1 just because minimal R6RS ships with a slightly different set of list procedures.
2023-08-27 11:40:55 -0400 < mnieper> Zipheir: That the top-level is hopeless (TM) means exactly one thing. And this cannot be fixed in a relatively static language with macros like Scheme.
2023-08-27 11:56:30 -0400 < Zipheir> That may be. I just don't care for the Racket community's tendency to copy-paste that slogan whenever there's a question about top-level semantics.
2023-08-27 13:07:20 -0400 < mdhughes> Top level is only hopeless because DrRacket destroys the environment whenever you edit a source file.
2023-08-27 13:08:23 -0400 < mdhughes> Which, it's infuriating, but it's *so* infuriating and horrible a decision, I stop to ponder if it's based on some real user research or something. And then I decide no, it's just easier than removing/replacing objects from an edited source file. Laziness.
2023-08-27 13:09:36 -0400 < mdhughes> You *could* tag every object from the source file, and when it's modified in REPL untag it, and on editing remove all tagged items and load the source. But that'd take like an hour or two of engineering time. (delete-environment) takes 10 seconds.
2023-08-27 13:45:34 -0400 < MrtnMrtn> mdhughes: Then it is not only infuriating, but also frustrating. I guess we will have to wait for benign soul to implement the tagging scheme, or just switch to Emacs and forget about Dr. Racket.
2023-08-27 13:46:19 -0400 < mdhughes> racket in shell works sanely, but of course you have to do some kind of cutting and pasting to put functions in it.
2023-08-27 13:46:46 -0400 < MrtnMrtn> mdhughes: Can you include files?
2023-08-27 13:46:59 -0400 < mdhughes> Sure. It's actually a normal enough REPL that way.
2023-08-27 13:55:02 -0400 < MrtnMrtn> Cool.
2023-08-27 13:55:45 -0400 < MrtnMrtn> I wonder if some AI could implement the missing code in Dr. Racket btw.
2023-08-27 13:56:21 -0400 < dpk> remember how we utterly failed to convince people that ‘the cloud’ is just someone else’s computer?
2023-08-27 13:56:35 -0400 < dpk> maybe next we can utterly fail to convince them that ‘AI’ is just someone else’s code/writing/picture
2023-08-27 13:57:55 -0400 < MrtnMrtn> dpk: Sounds like it a feasable quest.
2023-08-27 14:05:25 -0400 < Zipheir> dpk: Sorry, that's bogus.
2023-08-27 14:07:08 -0400 < Zipheir> The output of a very complicated neural net is as much J. Random Hacker's code as my code is mnieper's (I've read a lot of his implementations, and bits may have popped in my head on occasion).
2023-08-27 14:19:44 -0400 < mdhughes> AI is just Eliza with extra funny text parsers.
2023-08-27 14:20:11 -0400 < mdhughes> (LLM AI, not the other kind, which is less impressive but more dangerous)
2023-08-27 14:23:21 -0400 < Zipheir> We've gone a long way from ELIZA.
2023-08-27 14:24:15 -0400 < MrtnMrtn> dpk: Mission accomplished already? :mindblown:
2023-08-27 14:30:34 -0400 < Zipheir> mdhughes: At this point, syntax highlighting scripts probably do more complicated analysis than ELIZA!
2023-08-27 14:30:42 -0400 < mdhughes> "extra funny".
2023-08-27 14:31:34 -0400 < mdhughes> I mean, accurately it's a markov chainer, but the prompt & response format stuff is more like Eliza, just weighted/rewarded instead of typed in.
2023-08-27 14:32:06 -0400 < Zipheir> Are you talking about ChatGPT?
2023-08-27 14:32:43 -0400 < mdhughes> If you give a raw markov chain or neural net text with no weighting, you get random text back. If you weight it every time it makes a sentence you like, pretty soon it's just a parrot again.
2023-08-27 14:33:12 -0400 < Zipheir> That's extremely simplified.
2023-08-27 14:33:32 -0400 < mdhughes> None of which *means* anything, because it can't, it's just a grid of numbers attached to words (or colors in an image, etc.)
2023-08-27 14:34:06 -0400 < Zipheir> Well... Similar state values can describe a neuron.
2023-08-27 14:34:31 -0400 < Zipheir> Meaning is in the mind of the beholder.
2023-08-27 14:34:32 -0400 < mdhughes> Of course that's all human brains are, too. That's why we don't mean anything except whatever inputs were rewarded in school.
2023-08-27 14:35:50 -0400 < Zipheir> mdhughes: Have you turned Skinnerian on us? :)
2023-08-27 14:36:20 -0400 < mdhughes> The '50s-80s AI attempts to do logic in Lisp were hilarious, since we can't do logic well ourselves, so how would we program it?
2023-08-27 14:36:42 -0400 < mdhughes> Always have been. Humans are chimps that talk.
2023-08-27 14:36:52 -0400 < Zipheir> "Anything worth doing is worth doing badly."
2023-08-27 14:38:41 -0400 < mdhughes> Anyway. Sun is way up, I need to hide in darkness.
2023-08-27 14:57:57 -0400 < dpk> for the curious, the fruits of today’s hacking: an incomplete implementation of a variant of SRFI 125 (none of the ‘implementation-specific’ or ‘legacy’ stuff is supported) which remembers the orders keys were inserted http://dpk.io/temp/srfi-125-ordered.scm http://dpk.io/temp/srfi-125-ordered.sld
2023-08-27 14:59:18 -0400 < dpk> (and probably does so more memory-efficiently than your favourite Scheme’s native hash tables)
2023-08-27 16:35:04 -0400 < sham1> Open addressing or closed addressing?
2023-08-27 16:37:17 -0400 < dpk> open addressing, using the PRNG from SRFI 27 to cycle through different hash values. better solutions are possible, i just took the one that seemed easiest to implement quickly
2023-08-27 16:37:56 -0400 < dpk> probably replacing the PRNG with something less absurdly computationally expensive would be an easy performance boost
2023-08-27 16:42:47 -0400 < sham1> Double hashing I'd say
2023-08-27 16:45:09 -0400 < sham1> Although I feel that the best way to ensure performance would be to think of the distribution of the entries, for example by using prime numbers up to some constant N and then going with powers of 2
2023-08-27 17:02:08 -0400 -!- Netsplit *.net <-> *.split quits: taylan, sandra, MrtnMrtn, FiskFan1999, libfud, teiresias, jbalint, mdhughes, deltab, gramian,  (+2 more, use /NETSPLIT to show all of them)
2023-08-27 17:02:08 -0400 -!- polyrob_ is now known as polyrob
2023-08-27 17:02:08 -0400 -!- terrorjack7 is now known as terrorjack
2023-08-27 17:08:20 -0400 < dpk> it’s actually my first time writing a hash table with open addressing (it’s kind of intrinsic to this technique, at least if you actually want to remember insertion order and not just save memory)
2023-08-27 17:10:18 -0400 -!- Netsplit over, joins: sandra
2023-08-27 18:34:44 -0400 -!- teiresias2 is now known as teiresias
2023-08-27 19:34:20 -0400 < cow_2001> Zipheir: "A more controversial power of operators is the ability to remove a user from the connected network by 'force', i.e., operators are able to close the connection between any client and server.  The justification for this is very delicate since its abuse is both destructive and annoying, and its benefits close to inexistent.  For further details on this type of action, see section 3.7.1
2023-08-27 19:34:22 -0400 < cow_2001> (KILL)." Funny, innit?
2023-08-27 19:38:48 -0400 < Zipheir> Hah.
2023-08-27 19:39:02 -0400 < Zipheir> The good old K-line.
2023-08-27 19:39:04 -0400 < aeth> IRC was one of the original attempts at a "fediverse"
2023-08-27 19:39:17 -0400 < aeth> until people forked it and made an Eris-Free network. https://en.wikipedia.org/wiki/EFnet
2023-08-27 19:45:40 -0400 < cow_2001> There are many federations.
2023-08-27 19:45:51 -0400 < cow_2001> I mean, within Activitypub.
2023-08-27 19:46:21 -0400 < aeth> right, because the last thing you want is an entire server full of trolls and spammers, especially once you start supporting things like images
2023-08-27 19:46:39 -0400 < aeth> in the end you'll end up with IRC, where in theory you could federate, but in practice, the individual servers are all in one "network"
2023-08-27 19:46:48 -0400 < cow_2001> Oh boy.  Imagine fosstodon invaded by baraag………
2023-08-27 19:47:09 -0400 < cow_2001> or Poast.
2023-08-27 19:47:31 -0400 < Zipheir> Federated IRC servers is not a bad idea.
2023-08-27 19:47:37 -0400 < Zipheir> s/is/are/
2023-08-27 19:48:44 -0400 < Zipheir> Although federation makes less sense in for chatroom-style communication.
2023-08-27 19:48:51 -0400 < Zipheir> Grr, s/in //
2023-08-27 19:49:19 -0400 < cow_2001> What I thought was funny was how the authors do not think it is a very useful thing to have, the ability to ban network wide.  As if the year 2000 was blessed by a lack of flooders.
2023-08-27 19:50:56 -0400 < Zipheir> RFC 1459 is from 1993, so the awareness of massive-scale spam was probably lower.
2023-08-27 19:51:46 -0400 < aeth> there's some naiveness to the design
2023-08-27 19:52:10 -0400 < aeth> e.g. why +n in an IRC channel? *n*o external messages
2023-08-27 19:52:18 -0400 < aeth> why the hell would it default to allowing external messages by default?
2023-08-27 19:52:26 -0400 < aeth> could be useful for bots and stuff, I guess
2023-08-27 19:52:43 -0400 < aeth> now try to moderate a channel where the troll is coming from outside of the room and you can't kickban them
2023-08-27 19:52:50 -0400 < cow_2001> "A-net soon vanished" :(
2023-08-27 19:52:51 -0400 < aeth> while using a sockpuppet to see who is replying
2023-08-27 19:53:59 -0400 < aeth> Of course, we're not limited to back then
2023-08-27 19:54:24 -0400 < aeth> There's lots of naiveness in modern networked stuff from people who should know better, such as peer-to-peer networking in a video game where of course people are going to cheat when you make it that easy
2023-08-27 20:37:06 -0400 < cow_2001> Bit offtopic, but does anyone knows a good posix networking introduction?  I am reading that part in the Guile manual and it is all Suomi to me.
2023-08-27 20:42:15 -0400 < Zipheir> cow_2001: You can't do better than W. Richard Stevens's books.
2023-08-27 20:43:18 -0400 < Zipheir> cow_2001: https://en.wikipedia.org/wiki/UNIX_Network_Programming and, for more fundamental stuff, https://en.wikipedia.org/wiki/TCP/IP_Illustrated
2023-08-27 20:46:32 -0400 < Zipheir> cow_2001: Vol. 1 of UNP is probably all you need for an introduction.
2023-08-27 20:53:31 -0400 < cow_2001> Spooky specs.
2023-08-27 20:54:32 -0400 < cow_2001> I think I found a typo in either the first IRC RFC or the client RFC
2023-08-27 20:54:46 -0400 < cow_2001> Minor and inconsequential.
2023-08-27 20:56:53 -0400 < cow_2001> Oh, I remember that UNIX book scene.
2023-08-27 21:31:23 -0400 < cow_2001> Zipheir: Thank you.
2023-08-27 22:19:04 -0400 -!- mdhughes_ is now known as mdhughes
2023-08-27 22:24:38 -0400 < jcowan> dpk: I think the reason that people stopped using open addressing is that the load average can't be very big (~ 50%) as opposed to chaining which typically has 100% load average.
2023-08-27 22:25:27 -0400 < jcowan> aeth: That's pretty much what Riastradh is, and yet he's not a bot (I've met him IRL)
2023-08-27 22:28:20 -0400 < aeth> someone who joins, reads up on logs, says something, and leaves can still be moderated by ops because when they join you see their mask.
2023-08-27 22:28:41 -0400 < aeth> someone who never joins would afaik have to be moderated by /whowas, which doesn't seem to last very long, e.g. Riastradh isn't in /whowas
2023-08-27 22:28:53 -0400 < aeth> and even that requires some specialized IRC knowledge to even know that it exists
2023-08-27 22:29:03 -0400  * jcowan nods
2023-08-27 22:30:02 -0400 < mdhughes> Yeah, I make my own hashtables in C and whatever open addressing, it has better cache coherency, but it requires more memory than chains. Most are optimized the other way.
2023-08-27 22:30:18 -0400 < mdhughes> And for big sets, finding your hash misses can be very expensive.
2023-08-27 22:30:28 -0400 < jcowan> The Usenet analogue was James "Kibo" Parry, aka He Who Greps", notorious for joining any conversation in which his name or nick was mentioned
--- Day changed Mon Aug 28 2023
2023-08-28 00:09:56 -0400 < Zipheir> He Who Greps is a terrific epithet.
2023-08-28 00:24:57 -0400 < cow_2001> Holy hell.  Author of TCPv3 swapped 2nd and 3rd arguments of memset 10 times in the first version.  C is truly scary.
2023-08-28 00:38:08 -0400 < jcowan> James Scoble has a similar name: He Who PubSubs
2023-08-28 00:39:45 -0400 < jcowan> I had to clear cookies, and now codeberg.org won't let me log in again (error 500).  Anyone have an idea about this?
--- Log closed Mon Aug 28 01:46:16 2023
--- Log opened Mon Aug 28 01:58:30 2023
2023-08-28 01:58:30 -0400 -!- Irssi: #scheme: Total of 191 nicks [0 ops, 0 halfops, 0 voices, 191 normal]
2023-08-28 01:58:30 -0400 -!- Irssi: Join to #scheme was synced in 6 secs
2023-08-28 02:34:18 -0400 < dpk> jcowan: there’s #codeberg channel on Liberachat
2023-08-28 02:34:26 -0400 < jcowan> thanks
2023-08-28 02:34:36 -0400 < jcowan> it was a global problem, now fixed
2023-08-28 02:39:42 -0400 < dpk> jcowan: this technique is kept between 1/2 and 2/3rds full in the ‘hash table’ proper, but each entry in that table takes up only 8 or 16 bits for a typical hash table, extending only when there are more than 2**8, 2**16, 2**32 entries. then there’s an extra pointer-sized overhead for each actual entry in the hash table. together, these are cheaper in memory terms than most open addressing systems, because the cost of unoccupied slots is 
2023-08-28 02:39:42 -0400 < dpk> altogether smaller
2023-08-28 02:40:07 -0400 < jcowan> Understood.
2023-08-28 02:40:17 -0400 < dpk> and indeed probably more efficient than closed addressing systems where each entry is two words instead of one
2023-08-28 06:02:33 -0400 -!- rgherdt_ is now known as rgherdt
2023-08-28 09:17:25 -0400 < dpk> mnieper: when we were looking at reformulating the description of marks and substitutions, you objected to my suggestion of ‘lexical address’ as an alternative name for a substitution. however, i can’t remember why. can you? (if it helps, you settled on ‘lexical environment’)
2023-08-28 09:24:16 -0400 -!- rgherdt_ is now known as rgherdt
2023-08-28 09:26:01 -0400 < dpk> my instinct is to go with ‘timestamp’ for mark (you planned to change the Tonderian ‘colour’ to this, i think), explaining that it marks *when* an identifier was introduced, for the purpose of keeping identifiers introduced by successive macro expansions separate, and ‘lexical address’ for substitution, explaining that it marks *where* an identifier was introduced in the source code. (though these are two slightly different meanings 
2023-08-28 09:26:01 -0400 < dpk> of ‘introduced’, sigh.) i still lack a good correspondence for ‘antimark’ in this system; however, we originally intended to leave this out as it is an optimization and therefore implementation detail of the expander. i’m still tempted to do that, even if it means people writing new expanders and following the spec without knowing there’s an optimization missing will end up with quadratic performance
2023-08-28 09:26:56 -0400 < mnieper`> dpk: If you look at, say, (datum->syntax #'id 'foo), the meaning of the newly forged identifier "foo" is looked up in the lexical environment of the identifier "id".  If we associate the lexical environment with an identifier directly in our language, `datum->syntax' is straightforward.  If we, instead, just speak of a lexical address, `datum->syntax' has to look up the lexical environment corresponding to the address *somewhere else*,
2023-08-28 09:26:56 -0400 < mnieper`> at least conceptually.
2023-08-28 09:27:26 -0400 < mnieper`> But "lexical address" or "lexical position" has its own merits.
2023-08-28 09:27:51 -0400 < mnieper`> dpk: Yes, I have been favouring timestamp (or history).
2023-08-28 09:28:12 -0400 < dpk> oh, we can use both. an identifier carries a history, which is a set of timestamps
2023-08-28 09:28:24 -0400 < mnieper`> Right.
2023-08-28 09:31:16 -0400 < mnieper`> dpk: We may need to mention anti-marks (with a different language).  Consider the following:
2023-08-28 09:32:58 -0400 < mnieper`> (define-syntax foo (lambda (x) (syntax-case x () [(foo id) (bound-identifier=? #'id #'bar)])))
2023-08-28 09:33:14 -0400 < mnieper`> And then: (foo #'bar)
2023-08-28 09:33:58 -0400 < mnieper`> Without anti-marks, #'bar (in the disguise of #'id) and #'bar in the transformer have the same marks.
2023-08-28 09:34:15 -0400 < mnieper`> s/have/would have.
2023-08-28 09:34:38 -0400 < mnieper`> Did we consider this is our attempt to reword the algorithm?
2023-08-28 09:35:15 -0400 < mnieper`> bbl
2023-08-28 09:36:24 -0400 < dpk> i’m not sure if we considered that or not
2023-08-28 09:42:58 -0400 < dpk> maybe we just call them ‘transformer started timestamps’ and ‘transformer finished timestamps’ or similar
2023-08-28 09:43:12 -0400 < dpk> or ‘before transformer timestamps’ and ‘after transformer timestamps’
2023-08-28 09:44:44 -0400 < jcowan> pre-, post-?
2023-08-28 09:45:06 -0400 < jcowan> that is, "transformer {pre,post}-timestamp"
2023-08-28 09:46:06 -0400 < dpk> yes, also good
2023-08-28 10:17:25 -0400 < sham1> If we use timestamps then start and finish is probably the appropriate metaphor 
2023-08-28 10:19:05 -0400 < dpk> however, it needs to be clear that the timestamps refer only to a single stage of macro expansion. one timestamp is applied before a single transformer begins its work, another one is applied after it has returned, and the two cancel each other out on the input form
2023-08-28 10:35:27 -0400 < dpk> this is a first draft, possibly too cutesy: The hygienic context contained in a wrap consists of a history, which is a set of time-stamps, and a lexical environment, which keeps track of identifiers’ lexical addresses. The history is used in the expansion process to keep track of when an identifier was introduced: the time-stamps within the history are of two types, recalling respectively the entry and exit of identifiers into and out of a 
2023-08-28 10:35:27 -0400 < dpk> transformer when it is called in a single macro transcription step. The lexical environment keeps track of where in the code identifiers were introduced and bound.
2023-08-28 10:37:21 -0400 < dpk> (there follows a note offering a bilingual R6RS-R7RS glossary for these terms)
2023-08-28 10:40:27 -0400 < mnieper`> There is actually a reason for why we should not change the official terminology. Everything that has been written so far about (correct) s-c implementations uses the marks/substitutions terminology. Inventing a new terminology that is not in the literature has to be well-justified.
2023-08-28 10:42:12 -0400 < dpk> iirc Kohlbecker’s original paper calls marks timestamps, though he did not have to come up with a term for antimark because he didn’t have those
2023-08-28 10:51:03 -0400 < Franciman> are we talking the same Kohlbecker who does proof mining?
2023-08-28 10:54:17 -0400 < dpk> probably not: Kohlbecker got his PhD in computer science on the subject of hygienic macro expansion and then pretty much immediately retired from computing to become a pastor
2023-08-28 10:54:54 -0400 < Franciman> lol
2023-08-28 10:56:47 -0400 < jcowan> I think the proof miner is Kohlenbach
2023-08-28 10:58:36 -0400 < Franciman> oh sorry fellows
2023-08-28 10:58:39 -0400 < Franciman> my fault
2023-08-28 10:58:41 -0400 < Franciman> yes
2023-08-28 10:58:56 -0400 < Franciman> but not always faults are too bad, i learnt about Kohlebecker's story. It was amusing
2023-08-28 11:02:10 -0400 < duncanm> jcowan: I got the sense that if I take Scheme48's module system and rename a few things (structure -> library, etc), it'll be R7RS compatible (even though it also supports more things like for-syntax), am I right in thinking that? 
2023-08-28 11:02:26 -0400 < jcowan> I don't know.
2023-08-28 11:02:31 -0400 < duncanm> ohh
2023-08-28 11:02:44 -0400 < duncanm> on the surface, they look quite similar
2023-08-28 11:02:57 -0400 < jcowan> mmm, is the S48 library system static??
2023-08-28 11:03:04 -0400 < duncanm> i think so?
2023-08-28 11:03:31 -0400 < flatwhatson> s48 also has interfaces
2023-08-28 11:03:53 -0400 < duncanm> right, but i think there's a way to do it anonymously, which makes them work like exports in R7RS modules
2023-08-28 11:05:34 -0400 < flatwhatson> are you looking at updating s48 for r7rs?
2023-08-28 11:05:46 -0400 < duncanm> just doing some reading
2023-08-28 11:06:28 -0400 < flatwhatson> what does it mean for a library system to be static jcowan?
2023-08-28 11:07:16 -0400 < duncanm> yea, i'm not completely understanding the distinction either, but I read that the Chez module system is more 'syntactic'
2023-08-28 11:08:26 -0400 < mnieper`> "static" means that one can tell at expand-time which libraries are used and which identifiers are exported and imported.
2023-08-28 11:09:13 -0400 < mnieper`> (works best without `eval')
2023-08-28 11:10:08 -0400 < duncanm> mnieper`: you're the one working on unsyntax, right? I've been meaning to study its code
2023-08-28 11:10:25 -0400 < mnieper`> Yes, that's me.
2023-08-28 11:13:56 -0400 < duncanm> mnieper`: it looks like you wrote your own expander? cool
2023-08-28 11:14:50 -0400 < flatwhatson> s48 interfaces/modules are usually used in a way which could be "static", but they're runtime structures and there's a procedural interface
2023-08-28 11:15:25 -0400 < acdw> can someone point me to this unsyntax thing? and the psyntax too if possible; i'm in the dark
2023-08-28 11:15:44 -0400 < duncanm> https://gitlab.com/nieper/unsyntax I'm clicking here
2023-08-28 11:16:01 -0400 < mnieper`> duncanm: It helped a lot that I was able to study Chez's and psyntax's source code. And that I wrote an R7RS/ER-expander previously.
2023-08-28 11:17:16 -0400 < mnieper`> acdw: Both Unsyntax and psyntax are frontend that take an R[67]RS program and libraries and expand it so that library references are resolved and all macros are expanded.
2023-08-28 11:17:40 -0400 < mnieper`> The result is then fed into the host system's `eval' (or output as a Scheme program).
2023-08-28 11:17:48 -0400 < acdw> ty :)
2023-08-28 11:18:10 -0400 < mnieper`> This means that the host system does not need to implement a particular macro or module system.
2023-08-28 11:19:32 -0400 < sham1> Although you'd probably want to implement them due to the frontends (reasonably) dropping some of the "incompatible" information such as file locations for identifiers
2023-08-28 11:22:45 -0400 < mnieper`> sham1: The frontends collect this information. They can be easily modified to pass this information to the backend. Unsyntax doesn't do it by default because this would need implementation-specific code.
2023-08-28 11:52:23 -0400 < jcowan> In fact you can tell before expand time: you just need to read the `library` S-expression
2023-08-28 11:53:34 -0400 < mnieper`> only if you don't count `cond-expand' to expand-time.
2023-08-28 11:54:55 -0400 < mnieper`> R6RS's library system is without this caveat, of course.
2023-08-28 11:55:31 -0400 < jcowan> And include-library-declaratons.  
2023-08-28 11:56:07 -0400 < jcowan>  But all of that can be done before expand time
2023-08-28 12:06:14 -0400 < gwatt> can include-library-declarations be done properly before expand-time? If there's macros in there that expand to definition forms, you'd need to expand them to figure out what to export
2023-08-28 12:06:37 -0400 < mnieper`> include-library-declarations cannot contain macros.
2023-08-28 12:06:47 -0400 < mnieper`> It is an include on library-language-level.
2023-08-28 12:07:08 -0400 < mnieper`> jcowan's and my explanation just differ in the definition of "expand-time".
2023-08-28 12:08:00 -0400 < gwatt> so putting a define-record-type inside include-library-declarations wouldn't export the record?
2023-08-28 12:08:02 -0400 < mnieper`> In any case, you need to know the environment before being able to make sense of an R7RS library definition (even if you know all the imported libraries).
2023-08-28 12:08:13 -0400 < mnieper`> gwatt: no, that's a syntax error.
2023-08-28 12:08:44 -0400 < mnieper`> You would have to wrap it in `begin', but then it becomes part of the proper library body.
2023-08-28 12:09:02 -0400 < gwatt> hmm, that sounds less than stellar
2023-08-28 12:09:48 -0400 < mnieper`> In what sense?
2023-08-28 12:11:39 -0400 < gwatt> That include-library-declarations is limited to scanning for pre-expansion define & define-syntax. It seems pretty limited.
2023-08-28 12:12:10 -0400 < mnieper`> With include-library-declarations you splice in library declarations.
2023-08-28 12:12:21 -0400 < mnieper`> Not define or define-syntax.
2023-08-28 12:13:51 -0400 < mnieper`> (The R7RS `define-library' is a strange mix between an actual library definition and a (too often too simple) library configurator.)  
2023-08-28 12:15:38 -0400 < gwatt> Ok, I re-read the include-library-declarations description. I though it did something totally different. nevermind.
2023-08-28 13:00:20 -0400 < jcowan> You could write a library-expander that would be almost portable: you'd need to configure it with the Appendix B cond-expand symbols and two procedures, one to determine if a library exists (searches a library path) and another to read an include or include-lib-decls file (also searches a path).
2023-08-28 13:00:45 -0400 < jcowan> and then you'd get an R6RS library: export, import, body.
2023-08-28 19:36:23 -0400 -!- robin_ is now known as robin
2023-08-28 19:43:50 -0400 -!- ced2 is now known as cedb
2023-08-28 21:20:43 -0400 < haugh> Anybody comfortable with extending SRFI-42? I would love an example of how to compose first-ec with fold{,3}-ec in order to bake early termination into a custom comp. 
2023-08-28 22:24:30 -0400 < Zipheir> fold-ec strikes me as a weird part of SRFI 42, especially since it's specified to use set!.
2023-08-28 22:24:57 -0400 < Zipheir> haugh: Have you heard of streams?
2023-08-28 22:27:38 -0400 < Zipheir> Stream procedures tend to compose more easily than SRFI 42 forms.
2023-08-28 22:48:37 -0400 < haugh> Zipheir, right, I've noticed it's not very popular 'round these parts, but my main impl. provides it and most of what I'm doing fits very well with the eager paradigm. I can actually solve my problem at the qualifier level, but I've been using custom comprehensions in this module. 
2023-08-28 22:49:34 -0400 < Zipheir> Interesting.
2023-08-28 22:50:17 -0400 < Zipheir> I didn't mean to complain about SRFI 42. I like it, for the most part. It just seems that the qualifiers are meant to be compositional and not the -ec forms.
2023-08-28 22:52:15 -0400 < haugh> well the source provides the examples of any?-ec and every?-ec but these are - I'm not sure how to word this - very "top level" applications. I'm trying to provide an additional expression slot, like an auxillary test, that can trigger early termination
2023-08-28 22:52:46 -0400 < haugh> s/source/sample implementation/
2023-08-28 22:53:19 -0400 < haugh> Maybe I need to sleep on it and give streams a try in the morning
2023-08-28 23:26:51 -0400 < Zipheir> haugh: Sounds good. If you come up with something that works, it would be cool if you wrote it up. SRFI 42 doesn't have many examples, which may be one reason why it hasn't seen much use.
2023-08-28 23:27:29 -0400 < Zipheir> haugh: You might also want to take a look at ranges, from SRFI 196.
2023-08-28 23:27:47 -0400 < haugh> +1
--- Day changed Tue Aug 29 2023
2023-08-29 01:42:17 -0400 < cow_2001> b
2023-08-29 01:42:19 -0400 < cow_2001> err
2023-08-29 01:44:24 -0400 < cow_2001> I have about bajillion windowing systems each with a unique way of switching between their different windows.  tmux, termux, emacs, android's windowing, weechat's windowing.
2023-08-29 01:44:28 -0400 < cow_2001> Argh.
2023-08-29 01:44:58 -0400 < cow_2001> Replace "windowing" with their respective lingo.
2023-08-29 06:29:21 -0400 < lockywolf> tabbing
2023-08-29 06:30:01 -0400 < lockywolf> nestedness of views is an intrinsic property of computing
2023-08-29 06:30:23 -0400 < lockywolf> but some things just work better with some use-cases
2023-08-29 06:30:54 -0400 < lockywolf> it is broadly connected to "attention management", like, which things should attract which attentions
2023-08-29 06:31:02 -0400 < lockywolf> "how much attention"
2023-08-29 06:31:28 -0400 < lockywolf> tabbing seems to be really better for "web pages"
2023-08-29 06:31:54 -0400 < lockywolf> although Opera has been insisting on MDI for a very long time
2023-08-29 06:32:07 -0400 < lockywolf> had been
2023-08-29 07:17:32 -0400 < cow_2001> This book has a Java implementation and a C implementation of the didactic language.  I am skipping the Java implementation because it is Suomi to me.  Started the C bits and it looks fairly comprehensible.
2023-08-29 07:19:41 -0400 < cow_2001> It is offtopic, because Scheme plays no part in this.
2023-08-29 07:20:05 -0400 < cow_2001> But this is now my main jibber jabber place about my learnings.
2023-08-29 07:41:27 -0400 < myrkraverk> Hi.  I'm using Racket for R5RS, and I'm wondering, is there any way to interact with the outer Racket exceptions?
2023-08-29 07:41:45 -0400 < myrkraverk> I'm fairly new to Scheme, and Racket, so I'm not sure how this language runtime mixing really works.
2023-08-29 07:42:36 -0400 < myrkraverk> In particular, within my R5RS environment, (error "foo") is undefined in the REPL.
2023-08-29 07:43:12 -0400 < dpk> yes, R5RS does not define any error handling system
2023-08-29 07:43:47 -0400 < dpk> it might be possible to import ‘native’ Racket libraries into Racket’s R5RS implementation, but i don’t know
2023-08-29 07:44:17 -0400 < dpk> you’ll probably have more luck asking in Racket forums (their IRC channel is sadly a pretty dead place, but they have a web forum and a Discord server)
2023-08-29 07:44:31 -0400 < myrkraverk> Thanks, I'll look into that.
2023-08-29 07:46:15 -0400 < mnieper`> Racket probably offers SRFI 23 for R5RS code.
2023-08-29 07:52:11 -0400 < myrkraverk> If so, it's not enabled by default, afaict.  (error "foo") is undefined.
2023-08-29 07:55:27 -0400 < myrkraverk> Yup, it works.  (#%require srfi/23) to the rescue.
2023-08-29 07:55:31 -0400 < myrkraverk> Thank you.
2023-08-29 08:04:57 -0400 -!- rgherdt__ is now known as rgherdt
2023-08-29 08:48:13 -0400 < lockywolf> Is anyone here familiar with Maxima (macsyma)?
2023-08-29 09:17:02 -0400 < jcowan> lockywolf: whereas other things work better with Coca-Cola
2023-08-29 09:20:03 -0400 < lockywolf> jcowan: ?
2023-08-29 09:20:47 -0400 < lockywolf> perhaps I am out of context
2023-08-29 09:20:56 -0400 < jcowan> you wrote "but some things just work better with some use-cases", which reminded me of an old Coke slogan from my youth
2023-08-29 09:21:43 -0400 < jcowan> (in use 1963-69)
2023-08-29 09:24:13 -0400 < lockywolf> https://www.youtube.com/watch?v=DUAK7t3Lf8s
2023-08-29 10:04:41 -0400 < jcowan> thanks, I needed that laugh
2023-08-29 10:58:39 -0400 < jcowan> cow_2001: What is this book, and what is the didactic language?
2023-08-29 10:59:14 -0400 < acdw> lockywolf: lmao incredible
2023-08-29 11:08:22 -0400 < cow_2001> jcowan: Crafting Interpreters.  It looks like a book for laymen.
2023-08-29 11:09:02 -0400 < cow_2001> I don't know what I am doing.
2023-08-29 11:09:08 -0400 < cow_2001> With my life.
2023-08-29 11:11:57 -0400 < acdw> do any of us
2023-08-29 11:35:23 -0400 < wasamasa> cow_2001: I also recall seeing a go book on that topic, that may be more accessible than java
2023-08-29 11:36:16 -0400 < wasamasa> cow_2001: https://interpreterbook.com/
2023-08-29 11:36:47 -0400 < wasamasa> cow_2001: but then there is Lisp in small Pieces, the Nils Holm books and several more papers/books in the lisp space
2023-08-29 11:44:05 -0400 < jcowan> LiSP is super expensive the last time I looked, though the 2nd ed (in French only) may be cheaper.
2023-08-29 11:44:41 -0400 < jcowan> The Holm books are quite good, and the implementation language is C
2023-08-29 11:45:29 -0400 < wasamasa> just reading the freely available source code of the latter is very enlightening
2023-08-29 11:45:31 -0400 < jcowan> the Scheme is called Plan 9 from Empty Space, unrelated to the PLan 9 OS
2023-08-29 11:46:41 -0400 < Zipheir> cow_2001: Another (GC-less) Scheme interpreter in C: http://peter.michaux.ca/articles/scheme-from-scratch-introduction
2023-08-29 11:46:43 -0400 < jcowan> s/Plan/Scheme
2023-08-29 11:46:45 -0400 < jcowan> https://t3x.org/s9fes/
2023-08-29 11:47:27 -0400 < jcowan> you can build SfS using the BDW GC
2023-08-29 11:48:31 -0400 < jcowan> of course, mnieper` will waggle his finger at you because BDW (libgc) doesn't provide proper tail recursion
2023-08-29 11:48:38 -0400 < jcowan> though it is preetty close
2023-08-29 12:01:23 -0400 < Zipheir> lockywolf: I can't see much reason for tabbing, at least when you've got a decent window manager. I suppose it makes sense in Apple-land, where every program gets just one dock entry.
2023-08-29 12:05:21 -0400 < acdw> ugh apple window management is like, the worst
2023-08-29 12:16:43 -0400 < mnieper`> jcowan: Only if we are looking for a sample implementation of Scheme (where "sample" means "with no variance" in the language of https://srfi.schemers.org/srfi-process.html). :)
2023-08-29 12:17:16 -0400 < jcowan> fair rneough
2023-08-29 12:18:32 -0400 < jcowan> two things I can't find: 1) where you wrote down the problem with conservative GC, and 2) where you and I explained to dpk why O(1) hash tables matter
2023-08-29 12:19:12 -0400 < dpk> the latter might have been in this channel rather than in the issue tracker. i also can’t find the latter
2023-08-29 12:19:56 -0400 < mnieper`> 1) https://codeberg.org/scheme/r7rs/issues/105#issuecomment-989105
2023-08-29 12:23:06 -0400 < mnieper`> The Clinger paper that defined PTCs as used in the RnRS encompasses GC because it also handles the example (let loop ((x #f)) (loop #f)).  By the Clinger paper it has to run in O(1) space, so the fresh locations allocated in each iteration have to be garbage collected.
2023-08-29 12:23:33 -0400 < mnieper`> Of course, any serious implementation doesn't allocate locations on the heap for this example.
2023-08-29 12:23:59 -0400 < mnieper`> But, conceptually, it does and the Clinger paper handles all allocations the same.
2023-08-29 12:24:14 -0400 < mnieper`> As for 2) can you remind me of the context?
2023-08-29 12:24:31 -0400 < dpk> for 2, i was previously arguing we should ditch SRFI 125 in favour of just SRFI 146
2023-08-29 12:25:17 -0400 < mnieper`> I think I remember. You argued to replace hash tables by hash maps, right?
2023-08-29 12:25:22 -0400 < dpk> yes
2023-08-29 12:26:38 -0400 < Zipheir> A lot of programmers seem very fond of old-fashioned destructive-update hash-tables.
2023-08-29 12:26:39 -0400 < dpk> essentially the problem was, iirc, that some algorithms using dictionaries become less efficient by a significant asymptotic factor (more than the log n of the individual dictionary accesses would suggest) when using hashmappings
2023-08-29 12:27:45 -0400 < jcowan> Zipheir: s/programmers/implementers, I think, so programmers are stuck with them
2023-08-29 12:28:19 -0400 < jcowan> just like implementers keep reinventing dynamic scope and then adding (or switching to) lexxical scope, a la Bourbon
2023-08-29 12:28:24 -0400 < dpk> fwiw i think mnieper` is wrong about conservative GC, by failing to apply the golden rule of interpretation (don’t interpret things in ways that produce absurdities, and i would class ‘conservative GCs conflict with tail recursion’ as an absurdity considering the topic of Clinger’s paper). Wittgenstein’s rule applies, to some extent: Clinger’s paper is an attempt to formalize an intuitive notion (in the sense of intuitionism), so if 
2023-08-29 12:28:24 -0400 < dpk> the paper contradicts the intuitive notion, it is not evidence that the intuition is wrong but the paper’s formalization
2023-08-29 12:28:31 -0400 < mnieper`> HAMTs have essentially O(1) access because the depth is limited by 5 or 10. In the final buckets, one has linear search, but this is similar to hash tables.
2023-08-29 12:28:32 -0400 < jcowan> ("learned nothing and forgotten nothing")
2023-08-29 12:29:41 -0400 < mnieper`> One needs to prove that in all scenarios, (persistent) hash maps can be equally efficient as old-fashioned hash tables.
2023-08-29 12:30:01 -0400 < jcowan> dpk: That seems to be Shutt's point on fexprs: the fexpr paper is formally correct, but it isn't actually what you want.
2023-08-29 12:30:15 -0400 < dpk> or, an alternative way of stating the second argument: go ask Clinger and i bet he’ll either say he didn’t realize his definition has this problem and it should be fixed, or he’ll say you’ve misinterpreted his definition
2023-08-29 12:30:17 -0400 < mnieper`> Hash tables can be updated in-place; hash maps (without linear update!) stress the GC.
2023-08-29 12:31:17 -0400 < mnieper`> dpk jcowan: What is your intuition about my loop example?
2023-08-29 12:31:51 -0400 < dpk> well, HAMTs *can* also be updated in-place. careful, you’ll have me on an anti-hash-table warpath again at this rate :D
2023-08-29 12:33:00 -0400 < jcowan> anyway, I think your idea of hash tables preserving insert order is the Right Thing'
2023-08-29 12:33:24 -0400 < mnieper`> dpk: Re HAMTs: That's why I wouldn't throw linear-update out of the window; but we need to make it safe.  This is actually possible for all collection types, but not for SRFI 1.
2023-08-29 12:33:45 -0400 < mnieper`> The reason is that SRFI 1 values (lists) are bare, not wrapped.
2023-08-29 12:35:09 -0400 < dpk> jcowan: would you be willing to submit a revision of SRFI 125 with ordering (incl. hash-table-fold-right) and without the SRFI 69 compatibility/implementation-specific stuff? i can supply the sample implementation, since all that still needs to be done in mine are some utility procedures and more testing and performance optimization
2023-08-29 12:35:44 -0400 < jcowan> indeed'
2023-08-29 12:35:45 -0400 < dpk> mnieper`: yes, i want to ask Arthur more about his approach
2023-08-29 12:36:05 -0400 < mnieper`> By safe, I mean that either 1) a violation is reported when potentially mutated arguments are reused or 2) some copy-on-write mechanism is used.
2023-08-29 12:36:17 -0400 < mnieper`> Shiro and I discussed it quite some time ago on the SRFI mailing lists.
2023-08-29 12:36:51 -0400 < dpk> Arthur’s approach (actually Clojure’s, i think) is 2
2023-08-29 12:37:10 -0400 < jcowan> I wanted to talk about fold/fold-right vs foldl/foldr.  What do you think about using the first convention for accumulator-first a la SRFI 1 and the second convention for accumulator-second?
2023-08-29 12:37:37 -0400 < mnieper`> dpk: I haven't yet followed the collection-type discussion on Codeberg.
2023-08-29 12:38:05 -0400 < jcowan> I can do that, but I don't know when
2023-08-29 12:38:29 -0400 < jcowan> oops, swap first and second
2023-08-29 12:38:29 -0400 < mnieper`> jcowan: fold-left is R6RS's fold with accumulator first.  So it would be enough to find a good name for fold-right-REVERSED
2023-08-29 12:38:43 -0400 < mnieper`> I would reuse the "x" from SRFI 1's xcons
2023-08-29 12:38:50 -0400 < dpk> i would rather simply keep the fold/fold-right names. the (srfi n) libraries then have the Shivers-style folds when they were originally defined with them, and the versions we put in Batteries libraries have Campbell-style folds. we can warn about the difference in the report text
2023-08-29 12:39:09 -0400 < jcowan> I think that will be very confusing
2023-08-29 12:39:18 -0400 < jcowan> it's a silent breaking change
2023-08-29 12:39:23 -0400 < mnieper`> jcowan: I agree!
2023-08-29 12:40:31 -0400 < jcowan> and anyway, Shivers-style is much more intutitive for lists.  I'm not thrilled with reusing the X convention.  Currently everything vector-like has Campbell-style, and everything else has Shivers-style.
2023-08-29 12:40:36 -0400 < jcowan> s/X/s
2023-08-29 12:40:41 -0400 < jcowan> er, s/X/x
2023-08-29 12:40:47 -0400 < jcowan> as in xcons
2023-08-29 12:41:14 -0400 < jcowan> I also don't like -reversed much, because it sounds like we are processing the sequence in reverse
2023-08-29 12:42:29 -0400 < mnieper`> Re tail-calls/intuition: The problem shows up when you try to formalize what you call "intuition". It is not obvious what the "intuitive notion" is, so that is no evidence for Clinger's paper being wrong.
2023-08-29 12:44:17 -0400 < mnieper`> If any formalization cannot handle the loop example (which can be vastly generalized), it fails its goal.  By the way, have you read the paper?  It is quite explicit, so nothing needs to be read into it.
2023-08-29 12:44:30 -0400 < mnieper`> jcowan: For fold-right, we actually do.
2023-08-29 12:44:56 -0400 < mnieper`> So maybe fold-reversed is not that bad, leaving us with fold/fold-left/fold-right/fold-reversed
2023-08-29 12:45:33 -0400 < mnieper`> fold and fold-right have the accumulator last; fold-left and fold-reverse first.
2023-08-29 12:45:54 -0400 < jcowan> I was inspired by the change in arrays, where Feeley switched from fold/fold-right to foldr/foldl and switched to Campbell-style
2023-08-29 12:45:55 -0400 < mnieper`> fold and fold-left process the sequence in order; fold-right and fold-reversed in reversed order.
2023-08-29 12:46:28 -0400 < jcowan> It can process them in any order, actually.
2023-08-29 12:46:38 -0400 < jcowan> you just wind up the stack
2023-08-29 12:46:43 -0400 < jcowan> if you do it the "wrong" way
2023-08-29 12:47:21 -0400 < mnieper`> fold/fold-right from SRFI 1 define the order.
2023-08-29 12:47:33 -0400 < mnieper`> Because the "kons" argument can have side effects.
2023-08-29 12:48:21 -0400 < jcowan> Ah, right
2023-08-29 12:48:53 -0400 < jcowan>  perhaps we should just design an S-expression/syntax-case representation for ML and have done.
2023-08-29 13:09:52 -0400 < mnieper`> I have been thinking again about our Steme attempt again lately.
2023-08-29 13:11:21 -0400 < mnieper`> dpk jcowan: The Clinger paper actually gives the following example: (let loop ((i 0) (x #f)) (unless (= i n) (loop (+ i 1) (make-vector n))))
2023-08-29 13:11:32 -0400 < mnieper`> And says that it must run in O(n) space.
2023-08-29 13:13:03 -0400 < mnieper`> In a Scheme without a GC, it uses O(n^2) space.  A conservative GC need not be better than no GC (in theory, not in practice, of course).
2023-08-29 13:44:44 -0400 < mdhughes> For any new hash* impl, benchmark it in https://ptrace.fefe.de/wp/ and see if you can beat the Python impl's time. If your test never finishes running before your machine crashes, it's not a good hash*.
2023-08-29 13:46:52 -0400 < Zipheir> Python's hash-tables are very fast indeed. They trounced CHICKEN's SRFI 69 implementation, IIRC.
2023-08-29 13:47:06 -0400 < dpk> from the description of the problem in README, a hash table is not even the right data structure here
2023-08-29 13:47:17 -0400 < dpk> at least not for the second part
2023-08-29 13:47:39 -0400 < dpk> (‘output words and counts, sorted in descending order by count’)
2023-08-29 13:47:49 -0400 < dpk> you want a binary tree for that
2023-08-29 13:48:10 -0400 < Zipheir> True.
2023-08-29 13:48:51 -0400 < Zipheir> When a language implementation has fast hash tables, people abuse them to do just about everything.
2023-08-29 13:50:27 -0400 < mdhughes> Zipheir: I know, I struggled to ever beat the Python one, in CHICKEN or Chez. It's a good hard benchmark.
2023-08-29 13:50:44 -0400 < mdhughes> Have fun writing a performant btree then!
2023-08-29 13:52:04 -0400 < Zipheir> There are btrees and Btrees.
2023-08-29 13:53:13 -0400 < Zipheir> Haskell's IntMaps are tr(ee|ie)s, and they're pretty damn fast.
2023-08-29 13:54:25 -0400 < mdhughes> My own solution was to get the key/value vectors, and a custom sort, and I could just about get equal speed if I was cleverer than clear.
2023-08-29 13:55:25 -0400 < mdhughes> But then as I tested other data structures there, I had to go to more conventional outputs, and it lost speed there as well as slower storage than a hashtable.
2023-08-29 14:07:20 -0400 -!- rgherdt__ is now known as rgherdt
2023-08-29 14:47:14 -0400 < dpk> mnieper`: sorry, another ‘can this be done in terms of identifier properties’ question. this one really feels like it should be possible (because only regular lexical scoping is involved) but i can’t work out how to make the scopes work out properly. can one implement with-ellipsis in terms of identifier properties, with an ellipsis? helper procedure (argument is one identifier and whatever additional info like the lookup procedure) used 
2023-08-29 14:47:15 -0400 < dpk> by syntax-case and syntax to detect the ellipsis?
2023-08-29 14:51:55 -0400 < dpk> wait, i think i have it
2023-08-29 14:52:32 -0400 < dpk> you need to store the ellipsis in an identifier property on another binding, i think? so not the key is important but the identifier it’s attached to
2023-08-29 14:53:36 -0400 < dpk> or … no, then i have the same issue. (how do i get that binding with its properties in the place where the possible ellipsis is used)
2023-08-29 15:11:52 -0400 < mnieper``> dpk: Sorry, I think I forgot to answer your earlier question on identifier properties.
2023-08-29 15:13:20 -0400 < mnieper``> For with-ellipsis, what you can do is to define a secret identifier (and some property on it) in the scope of where with-ellipsis is used.
2023-08-29 15:15:29 -0400 < mnieper``> However, SRFI 211 says that with-ellipsis has splicing behaviour. This is harder to emulate.
2023-08-29 15:16:05 -0400 < dpk> hmm, is that the case for Guile’s original too?
2023-08-29 15:16:16 -0400  * dpk test
2023-08-29 15:16:19 -0400 < mnieper``> I don't know.
2023-08-29 15:16:33 -0400 < mnieper``> But splicing behaviour is the best for the programmer.
2023-08-29 15:16:48 -0400 < dpk> Guile’s is not splicing
2023-08-29 15:17:03 -0400 < mnieper``> You can always get non-splicing, but not the other way round.
2023-08-29 15:17:09 -0400 < dpk> (with-ellipsis banana (define x 1) x) => 1; x outside the body is unbound
2023-08-29 15:17:55 -0400 < mnieper``> Internal defines complicate the language. Sigh!
2023-08-29 15:19:13 -0400 < mnieper``> For checking the property on the secret identifier, make sure to use the lexical environment of s-c or syntax, so that macros defined elsewhere but expanded into the with-ellipsis scope are not touched.
2023-08-29 15:20:06 -0400 < dpk> ah, but we want (with-ellipsis x (syntax-rules () etc)) to work, surely? even though syntax-rules has its own means of renaming ellipsis
2023-08-29 15:20:17 -0400  * dpk checks if that actually does what she expects in Guile
2023-08-29 15:20:52 -0400 < dpk> yes, it does
2023-08-29 15:21:09 -0400 < mnieper``> And what does it do?
2023-08-29 15:21:26 -0400 < dpk> (define-syntax foo (with-ellipsis ::: (syntax-rules () ((_ x :::) '(x :::)))))
2023-08-29 15:21:34 -0400 < dpk> (foo 1 2 3) matches and returns (1 2 3)
2023-08-29 15:22:36 -0400 < dpk> hmm, and also in Unsyntax
2023-08-29 15:22:47 -0400 < mnieper``> Ah, wait, I give the same example in SRFI 211
2023-08-29 15:22:49 -0400 < dpk> so either Unsyntax doesn’t do what you just described, or i misunderstood what you described
2023-08-29 15:23:34 -0400 < mnieper``> No, you didn't misunderstand. I am contradicting myself. Possibly because of the time of the day.
2023-08-29 15:24:31 -0400 < mnieper``> Actually, macros are probably not affected; only transformers written outside macros.
2023-08-29 15:25:09 -0400 < mnieper``> So as described in SRFI 211 and implemented in Guile and Unsyntax, with-ellipsis has syntax-parameter-like semantics.
2023-08-29 15:34:23 -0400 < dpk> hmm, how can it be implemented then? it will be pretty annoying if my sample implementation of syntax-case in terms of the R4RS procedures and identifier properties (which thus far just does (free-identifier=? maybe-ellipsis #'...)) cannot be completed because of this one missing piece
2023-08-29 15:35:41 -0400 < dpk> err, #'(... ...) of course
2023-08-29 15:36:10 -0400 < dpk> (except not, because it’s R4RS syntax which doesn’t know about ellipsis)
2023-08-29 15:37:56 -0400 < dpk> i think i have a trick in mind, using syntax parameters, but it is also too late in the day for me to be able to think properly if it will work
2023-08-29 15:41:58 -0400 < dpk> something like (the low-level equivalent of) (define-syntax-parameter with-current-ellipsis (syntax-rules () ((_ passthru-keyword . rest) (passthru-keyword (… ...) . rest)))); with-ellipsis parameterizes the with-current-ellipsis macro to pass through a different identifier, and the first stage of expanding syntax-case, syntax, and quasisyntax is to invoke with-current-ellipsis to expand to e.g. (%syntax-case current-ellipsis stx lits clauses 
2023-08-29 15:41:58 -0400 < dpk> ...)
2023-08-29 16:12:04 -0400 -!- ec_ is now known as ec
2023-08-29 16:28:20 -0400 < mnieper``> What is a particularly clean dialect of S-expressions? Already Scheme's version uses quite a lot of rules (peculiar identifiers, complex number syntax, etc.).
2023-08-29 16:29:40 -0400 < dpk> Lisp 1.5
2023-08-29 16:30:32 -0400 < dpk> or Lisp 1.0 (which i think is the name given to the definition in McCarthy’s original paper?)
2023-08-29 16:33:47 -0400 < mnieper``> I am currently browsing the Lisp 1.5 manual.
2023-08-29 16:33:56 -0400 < mnieper``> Does it even have numbers in S-expressions?
2023-08-29 16:36:43 -0400 < mnieper``> Ah, it is in section IV.
2023-08-29 16:37:09 -0400 < mnieper``> "Numbers should not be used as variables or function names."
2023-08-29 16:37:25 -0400 < mnieper``> (let ((3 4)) 3)   ...
2023-08-29 16:37:32 -0400 < mnieper``> Why not!
2023-08-29 16:37:41 -0400 < acdw> we could just breathe dirt!
2023-08-29 16:38:13 -0400 < Zipheir> Just quote your numerical constants. What's the big deal? :)
2023-08-29 16:38:59 -0400 < mnieper``> In this model - to the extreme -, (quote 3) would be the symbol with the name 3.
2023-08-29 16:39:08 -0400 < Zipheir> Ah. True.
2023-08-29 16:39:11 -0400 < mnieper``> 3 would be a symbol evaluating to 3, to which it is initially bound.
2023-08-29 16:39:51 -0400 < mnieper``> It makes perfect sense (as long as all numbers and strings are initially bound to their respective values).
2023-08-29 16:41:06 -0400 < acdw> forth vibes
2023-08-29 16:43:55 -0400 < dpk> one of Python 2’s party tricks involving things there for hysterical raisins was the ability to rebind True and False
2023-08-29 16:44:43 -0400 < dpk> earlier versions of Python did not have True and False constants, only 1 for true and 0 for false, but programmers wanted to be clean so often bound True and False as variables to these integers at the tops of their programs
2023-08-29 16:44:45 -0400 < mnieper``> In Scheme, you can rebind lambda, let, and quote, ...
2023-08-29 16:45:08 -0400 < dpk> to stop those programs breaking when real True and False constants were added, the ability to ‘rebind’ them had to remain
2023-08-29 16:45:32 -0400 < dpk> also, one wart of that era which survives even into Python 3: True + True == 2
2023-08-29 16:46:47 -0400 < dpk> (True and False can generally stand for the integers 1 and 0 in arithmetic expressions)
2023-08-29 16:46:48 -0400 < mnieper``> The more I think about it, the less strange I find Lisp 1.5's approach to declare between ( ... ) in S-expressions as (atomic) symbols.
2023-08-29 16:47:17 -0400 < mnieper``> The lexical syntax becomes extremely simple (and this is what is usually part of the advertisments for S-expressions).
2023-08-29 16:47:34 -0400 < mnieper``> s/declare/declare everything
2023-08-29 16:48:00 -0400 < sham1> Wait, there are numbers in LISP 1.0? I thought it was just symbols and CONS
2023-08-29 16:48:04 -0400 < dTal> True + True == Frour
2023-08-29 16:48:12 -0400 < sham1> Thus "symbolic expression"
2023-08-29 16:48:17 -0400 < mnieper``> sham1: I am looking at Lisp 1.5
2023-08-29 16:48:58 -0400 < dpk> i just realized that it makes total sense that numbers were symbols in Lisp 1.5 because it was written for an IBM machine with hardware support for decimal arithmetic
2023-08-29 16:49:23 -0400 < sham1> Well I didn't know that Lisp 1.5 has numbers either
2023-08-29 16:49:56 -0400 < sham1> Although I suppose that numbers would have been a subset of symbols
2023-08-29 16:52:15 -0400 < mnieper``> "pseudo-atomic symbols"
2023-08-29 16:54:16 -0400 < mnieper``> dpk: Lisp 1.5 also supports octal numbers in the form -3Q11
2023-08-29 17:04:34 -0400 < dpk> hmm, interesting
2023-08-29 17:04:59 -0400 < aeth> oh wow, True + True is 2? No, everyone knows it's 4
2023-08-29 17:05:46 -0400 < aeth> hmm, interesting, so it has 0 as False
2023-08-29 17:06:12 -0400 < aeth> so you can just do 42 * False
2023-08-29 17:06:28 -0400 < dpk> anyway, time to sleep for me
2023-08-29 17:06:45 -0400 < mnieper``> dito
2023-08-29 19:48:16 -0400 -!- deltab_ is now known as deltab
2023-08-29 21:14:42 -0400 < cow_2001> What do you think of Hylang?
2023-08-29 21:18:20 -0400 < flatwhatson> you're probably better off just coding in python
2023-08-29 22:54:03 -0400 < jcowan> I've never used Hy, but it looks pretty interesting
2023-08-29 22:54:19 -0400 < jcowan> macros are a lot more straightforward than decorators
--- Day changed Wed Aug 30 2023
2023-08-30 00:18:10 -0400 < lockywolf_> aeth: I think that True should be 0, and False should be anything other than True
2023-08-30 00:18:26 -0400 < lockywolf_> which reflects the fact that there is only one truth, but many lies
2023-08-30 00:19:56 -0400 < lockywolf_> and you can also encode an error code into the value of False
2023-08-30 00:48:52 -0400 < aeth> well, that's what multiple return values are for
2023-08-30 00:49:02 -0400 < aeth> if you really want to get creative instead of writing code that's idiomatic anywhere
2023-08-30 00:49:19 -0400 < aeth> (values #f 324678)
2023-08-30 00:56:16 -0400 -!- ced1 is now known as cedb
2023-08-30 01:18:04 -0400 < lockywolf_> I was being ironic actually
2023-08-30 01:18:25 -0400 < lockywolf_> I don't even think that returning an error in the second value is a good idea.
2023-08-30 01:18:33 -0400 < lockywolf_> Errors should be thrown as exceptions.
2023-08-30 01:21:25 -0400 < aeth> so you mean like this? (values #f (raise ...)) ;-p
2023-08-30 01:21:35 -0400 < jcowan> See SRFI 189 for every known method of representing success and failure, and conversion procedures between them
2023-08-30 01:39:13 -0400 < mnieper`> Re LISP 1.5: I found this great article: https://www.reddit.com/r/lisp/comments/fqs19u/differences_between_lisp_15_and_common_lisp_part_1/
2023-08-30 01:45:28 -0400 < lockywolf_> maxima nowadays run on Common Lisp, but when it was written, in 1968, there was no Common Lisp
2023-08-30 02:27:24 -0400 < dpk> > In LISP 1.5, the comma was equivalent to a blank character; both could be used to delimit items within a list.
2023-08-30 02:27:50 -0400 < dpk> Clojure actually restores a Lisp 1.5 feature in this regard? okay, weird
2023-08-30 02:55:24 -0400 < mnieper`> In Clojure, you can do (+,1,2)?
2023-08-30 03:00:29 -0400 < dpk> yes, it’s a somewhat curious wart. (unquote is spelled ~ rather than , because of this, but Clojure also doesn’t have ‘real’ quasiquote but a pseudo-hygienic one)
2023-08-30 03:03:08 -0400 < flatwhatson> i think the optional comma is so you can feel comfortable migrating from javascript/json
2023-08-30 03:03:52 -0400 < flatwhatson> things like [1,2,3] are valid EDN (clojure's data notation) and JSON
2023-08-30 03:21:41 -0400 < lockywolf_> Maxima also has [1, 2, 3]
2023-08-30 03:39:35 -0400 < lockywolf_> I am really feeling that "maxima", as well as a lot of "CAS" systems are a "mis-design".
2023-08-30 03:40:16 -0400 < lockywolf_> Why would expressions be different from functions?
2023-08-30 03:40:50 -0400 < lockywolf_> differentiating between evaluating an expression and a function seems really odd
2023-08-30 03:42:35 -0400 < mnieper`> In mathematics, a polynomial is different from the polynomial function it defines.  [In case this is related.]
2023-08-30 03:43:01 -0400 < mnieper`> Consider, for example, X^2 + X over the field F_2.
2023-08-30 03:43:16 -0400 < mnieper`> It is non-zero as a polynomial but zero as a polynomial function.
2023-08-30 03:57:25 -0400 < lockywolf_> well, canonically equivalent to zero
2023-08-30 03:57:37 -0400 < lockywolf_> I am not sure it is legitimate to call it being zero.
2023-08-30 03:59:09 -0400 < lockywolf_> in scheme we may have a procedure (define (x) 0), and a procedure (define (x) (- 1 1))
2023-08-30 03:59:34 -0400 < lockywolf_> equivalent as functions, but not equivalent as procedures
2023-08-30 04:00:32 -0400 < lockywolf_> so, my argument is that "the same difference is observed in Scheme"
2023-08-30 04:04:41 -0400 < mnieper`> In mathematics (from where the example stems), it *is* equal to zero.
2023-08-30 04:05:13 -0400 < mnieper`> But, yes, you can consider Scheme programs as terms/expressions and the compiled procedures produced from it as the "functions" from above.
2023-08-30 04:05:26 -0400 < mnieper`> jcowan: I don't understand your latest Codeberg comment about type tests.
2023-08-30 04:08:29 -0400 < jcowan> Comparators contain four procedures: a type test predicate, an equality predicate, an ordering predicate (not used for hash tables) and a hash function.  It is an error to insert an association whose key fails the type test predicate
2023-08-30 04:08:57 -0400 < jcowan> therefore, the equality predicate and has function can be partial functions
2023-08-30 04:09:14 -0400 < jcowan> this is not hte case for R6RS hashtables
2023-08-30 04:09:52 -0400 < mnieper`> If I do (make-hashtable symbol-hash symbol=?) I get a hash table that only handles symbols.
2023-08-30 04:10:25 -0400 < mnieper`> If I try to insert something else, I will get an assertion violation (as I would with a SRFI 125 hash table with a symbol? predicate).
2023-08-30 04:15:57 -0400 < jcowan> I don't see that rasiing such a violation is allowed
2023-08-30 04:19:09 -0400 < dpk> it would be raised not by the hashtable directly, but when its implementation tries to call symbol-hash or symbol=? on a key of the wrong type
2023-08-30 04:19:39 -0400 < dpk> this, of course, depends on those actually checking the type and not just delegating to eq-hash and eq?
2023-08-30 04:19:43 -0400 < sham1> dpk: yeah, the Clojure quasiquote is weird. Of course the Clojure community doesn't really like macros (maybe understandably) and they have a mantra which is basically "data > procedures > macros" so if something can be data, it ought to be
2023-08-30 04:20:18 -0400 < sham1> Although to be fair, with the fact that maps are a first class citizen of the language, representing complex structures as data might not be that bad
2023-08-30 04:21:01 -0400 < dpk> well, ‘never use a macro when a procedure will do’ is also good Lisp practice in general
2023-08-30 04:29:34 -0400 < mnieper`> symbol-hash and symbol=? have to check their types. 
2023-08-30 04:49:00 -0400 < lockywolf_> mnieper`: in "ideal Platonian mathematics" it might be zero, but not to a student being taught to manipulate algebraic expressions in school
2023-08-30 04:55:18 -0400 < mnieper`> But this is the fault of the student not understanding what he is talking about.
2023-08-30 04:55:29 -0400 < dpk> Macsyma is not designed for high school use
2023-08-30 04:56:09 -0400 < mnieper`> It is like saying that 1/3 < 1/2 only in an ideal world because a student does not understand it because 3 > 2.
2023-08-30 05:22:08 -0400 < lockywolf_> no, it is saying that neither mathematical expressions nor scheme procedures faithfully reflect mathematical functions
2023-08-30 05:25:15 -0400 < lockywolf_> which is not unexpected
2023-08-30 06:20:05 -0400 < mnieper`> lockywolf_: The term "mathematical expression" is actually even more subtle.
2023-08-30 06:21:09 -0400 < mnieper`> By "x^2 + x" one can either mean the string/external representation or its interpretation, which is a polynomial in x.
2023-08-30 06:21:32 -0400 < mnieper`> On the other hand, "(lambda (x) (* x x))" directly evaluates to a procedure (= function).
2023-08-30 10:35:54 -0400 < mnieper`> How does CL translate `foo? Also to (quasiquote foo)?
2023-08-30 10:36:07 -0400 < mnieper`> Or doesn't the reader touch `?
2023-08-30 10:43:37 -0400 -!- ced2 is now known as cedb
2023-08-30 11:03:54 -0400 < taylan> mnieper`: In the CLHS, the "backquote" seems to be defined under "2.4. Macro Characters" and it seems to be unspecified how exactly it works, so long as the result is what one would expect: http://www.lispworks.com/documentation/lw50/CLHS/Body/02_df.htm
2023-08-30 11:04:20 -0400 < taylan> s/Macro Characters/Standard Macro Characters/
2023-08-30 11:08:57 -0400 < mnieper`> So if "foo" is any macro, it is not guaranteed that (foo `(bar ,baz)) is a well-defined form because `... is only defined when it appears in expression context?
2023-08-30 11:11:37 -0400 < taylan> I'm still trying to understand it myself :D  man, CL is complicated
2023-08-30 11:11:50 -0400 < mnieper`> Thanks!
2023-08-30 11:12:14 -0400 < mnieper`> I just ran some tests with clisp and sbcl. Something like ',x is not allowed.
2023-08-30 11:12:41 -0400 < mnieper`> SBCL does not even produce an s-expression from '`,x.
2023-08-30 11:13:46 -0400 -!- dstein64- is now known as dstein64
2023-08-30 11:22:49 -0400 < taylan> from what I understand, a macro foo called like (foo `(bar ,baz)) would indeed need to be written in such a way that it will be agnostic to the structure of the object it will receive in place of `(bar ,baz) because it can't be known
2023-08-30 11:25:05 -0400 < taylan> The macro function may be called on the object (foo (list (quote bar) baz)) or on something like (foo (backquote (bar (unquote baz)))).  Things like "backquote" and "unquote" are not defined in CLHS.
2023-08-30 11:25:42 -0400 < mnieper`> Or, in the case of SBCL on some object that contains a #s(...) form.
2023-08-30 11:26:45 -0400 < taylan> yeah, seems to be "everything goes" so long as evaluating that part of the object would result in what one would expect
2023-08-30 11:27:53 -0400 < mnieper`> Scheme is much more predictable here.
2023-08-30 11:28:28 -0400 < acdw> how many schemes have reader macros?
2023-08-30 11:28:29 -0400 < mnieper`> The only wart I see here is the ,@ token, which needs two characters (and makes @ as part of identifiers problematic).
2023-08-30 11:28:48 -0400 < mnieper`> acdw: In a sense ' ` , ,@ are all reader macros.
2023-08-30 11:29:01 -0400 < mnieper`> 'foo reader-expands to (quote foo), etc.
2023-08-30 11:29:36 -0400 < acdw> mnieper` right, i guess i mean user-definable reader macros
2023-08-30 11:30:09 -0400 < mnieper`> As I think about it, a second wart of Scheme's approach is that the reader is agnostic to the context.
2023-08-30 11:31:46 -0400 < mnieper`> While it makes sense to reader-expand `foo to (quasiquote foo) in expression context, it makes less sense that I can write a procedure as (let () (define ,x (* x x)) (unquote 3)) => 9
2023-08-30 11:32:07 -0400 < mnieper`> That ought to be an error.
2023-08-30 11:32:11 -0400 < mnieper`> But isn't.
2023-08-30 12:57:36 -0400 < myrkraverk> Does Scheme have a standard test suite, for compilers/interpreters/parsers ?
2023-08-30 12:59:28 -0400 < dpk> there is a de facto standard for R7RS at https://github.com/ashinn/chibi-scheme/blob/master/tests/r7rs-tests.scm
2023-08-30 12:59:48 -0400 < dpk> many of those tests are derived from examples in the R7RS small report
2023-08-30 13:07:20 -0400 < myrkraverk> Good to know.  Anything older, since I'm currently reading L.i.S.P 2nd. ed., in French?
2023-08-30 13:07:44 -0400 < myrkraverk> Hence why I'm playing in the R5RS environment, in Racket.
2023-08-30 13:08:30 -0400 < dpk> hmm, Chibi also has https://github.com/ashinn/chibi-scheme/blob/master/tests/r5rs-tests.scm
2023-08-30 13:08:41 -0400 < myrkraverk> Cool.
2023-08-30 13:09:15 -0400 < dpk> but they’re ancient (dating back to the repo’s primordial commit) and themselves might not have been debugged very well
2023-08-30 13:10:43 -0400 < myrkraverk> *nod*  I'll keep that in mind.
2023-08-30 13:35:40 -0400 < amirouche> myrkraverk: weclome :)
2023-08-30 13:35:47 -0400 < amirouche> I am a french citizen too 
2023-08-30 13:35:51 -0400 < dpk> i am not happy with the phrasing ‘Syntax parameters are a mechanism for rebinding a macro definition within the dynamic extent of a macro expansion.’ of SRFI 139
2023-08-30 13:36:11 -0400 < amirouche> myrkraverk: I just glimpsed into LiSP 2nd ed
2023-08-30 13:36:11 -0400 < dpk> ‘dynamic extent’ sounds like dynamic scoping of macro definitions or something, which this is not
2023-08-30 13:36:36 -0400 < myrkraverk> amirouche, I'm not, but I can read most of French.  Enough to grok the important bits.
2023-08-30 13:36:44 -0400 < myrkraverk> Can't write it, though.
2023-08-30 13:36:50 -0400 < amirouche> fun
2023-08-30 13:37:26 -0400 < dpk> hmm, it seems that wording comes from the Guile manual
2023-08-30 13:37:28 -0400 < Zipheir> I found LiSP hard even in translation.
2023-08-30 13:37:44 -0400 < Zipheir> Mainly because of the author's random digressions.
2023-08-30 13:37:58 -0400 < myrkraverk> On chapter one, I can say it's not that easy to read.
2023-08-30 13:38:31 -0400 < myrkraverk> I'm tempted to write my own notes as a "reader guide."
2023-08-30 13:38:36 -0400 < myrkraverk> Not sure if I will, though.
2023-08-30 13:38:51 -0400 < amirouche> My first impression is that LiSP is of historical importance, but not state of the art
2023-08-30 13:38:52 -0400 < dpk> and the Barzilay/Culpepper/Flatt paper says ‘We therefore consider that such dynamically scoped values can be applied to our problem at the syntax level—with similar benefits’
2023-08-30 13:39:27 -0400 < myrkraverk> amirouche, I haven't finished it either, but maybe /crafting interpreters/ is a better introduction to the subject in general.
2023-08-30 13:39:36 -0400 < Zipheir> What subject?
2023-08-30 13:39:41 -0400 < dpk> and section 3 is all about justifying their analogy to dynamic variable scoping …
2023-08-30 13:39:52 -0400 < myrkraverk> Zipheir, implementing interpreters.
2023-08-30 13:40:10 -0400 < myrkraverk> Though, it doesn't do Lisp in particular.
2023-08-30 13:40:17 -0400 < Zipheir> myrkraverk: The easiest book on that is probably Essentials of Programming Languages.
2023-08-30 13:40:37 -0400 < myrkraverk> Fair, I'll add that to my to-read-someday list.
2023-08-30 13:41:07 -0400 < Zipheir> Implementing interpreters is a rather minor part of programming language theory, until you want to implement highly-efficient practical interpreters.
2023-08-30 13:41:28 -0400 < myrkraverk> *nod*
2023-08-30 13:41:38 -0400 < myrkraverk> But one has to start somewhere.
2023-08-30 13:42:29 -0400 < Zipheir> Yes.
2023-08-30 13:44:08 -0400 < amirouche>  /crafting interpreters/ is a helping hand to get started on the subject, like tutorials do. Unlike LiSP, that is rooted in academia, and build upon prior art, and wants to be comprehensive.
2023-08-30 13:44:37 -0400 < Zipheir> "rooted in academia"...
2023-08-30 13:45:38 -0400 < amirouche> crafting interpreters is not gratis anymore, that is good to know.
2023-08-30 13:46:10 -0400 < myrkraverk> I have a hardcopy, as I prefer those.  I never checked if it was still online.
2023-08-30 13:46:26 -0400 < Zipheir> For one thing, I think the author of LiSP is absolutely right, if austere, to insist that you understand formal semantics to implement the language.
2023-08-30 13:46:50 -0400 < amirouche> I only buy books I want to share with my significant others
2023-08-30 13:46:53 -0400 < Zipheir> I don't know if Crafting Interpreters covers semantics.
2023-08-30 13:47:23 -0400 < amirouche> s/books/dead tree books/
2023-08-30 13:48:09 -0400 < myrkraverk> I'm not sure either.  It's rather -- poor -- in the theoretical details.
2023-08-30 13:49:12 -0400 < myrkraverk> I prefer dead tree books for two reasons, though the second reason is doable with screens as well: 1) I can take a break from screens and still learn, and 2) typing in the code is the best way to learn.
2023-08-30 13:49:39 -0400 < Zipheir> I guess that's the trade-off. On the one hand, you have programming language theory, books on which tend to treat implementation as a detail, and then the whole empirical science/craft/art of writing interpreters and compilers.
2023-08-30 13:49:53 -0400 < myrkraverk> About 2) : typing in the code forces me to read every character, symbol, of the code, and typing it in means I get a sense of what it does.
2023-08-30 13:50:08 -0400 < Zipheir> Good points.
2023-08-30 13:50:57 -0400 < myrkraverk> The best book I've read on compiler theory, at least the parsing bits, is Holub's C compiler.
2023-08-30 13:50:59 -0400 < amirouche> copying by typing is very good habit
2023-08-30 13:52:52 -0400 < dpk> parsing is not really the essence of compiling, though
2023-08-30 13:53:13 -0400 < dpk> (of course, being a Lisper and having an allergy to lexical syntax, i would say this)
2023-08-30 13:53:27 -0400 < myrkraverk> On L.i.S.P. in particular, I find that I need to study the code more, possibly run it through a debugger to see it in action, and of course implement the missing bits so far in chapter one.  This may be related to my unfamiliarity with Scheme.
2023-08-30 13:53:53 -0400 < Zipheir> dpk: That's one complaint I have about the old Dragon Book. It spends quite a lot of space on parsing compared to "real" compilation.
2023-08-30 13:54:22 -0400 < myrkraverk> The new SSA book is missing some bits in the details, when it comes to implement things, as well.
2023-08-30 13:54:29 -0400 < jcowan> The Dragon book is about presenting the state of knowledge at the time.  Parsing was not yet a solved problem.
2023-08-30 13:54:42 -0400 < myrkraverk> But since I don't even have a parser for Scheme, of my own, I can't say I can try to apply SSA yet.
2023-08-30 13:54:57 -0400 < Zipheir> jcowan: Wait, has it been solved when I wasn't looking? :)
2023-08-30 13:55:16 -0400 < myrkraverk> Unicode parsing is not a solved problem, and probably never will be.
2023-08-30 13:56:33 -0400 < Zipheir> myrkraverk: A general point: Unless you're actively studying parsing, you can factor it out by using S-expression syntax and 'read' in Scheme.
2023-08-30 13:57:16 -0400 < jcowan> In the sense that nobody writes their own LALR(1) parsing tables any more.
2023-08-30 13:57:21 -0400 < myrkraverk> *nod*  But eventually, I want to implement my own, of those too.
2023-08-30 13:57:38 -0400 < Zipheir> jcowan: True.
2023-08-30 13:57:52 -0400 < myrkraverk> [Not necessarily a LALR(1) parsing table, that came in while I was typing.]
2023-08-30 13:58:19 -0400 < Zipheir> But we haven't figured out linear-time parsing of non-LALR(1) languages, yet, or anything like that.
2023-08-30 13:59:08 -0400 < Zipheir> myrkraverk: Implement your own 'read'er, you mean?
2023-08-30 13:59:15 -0400 < myrkraverk> Yes.
2023-08-30 13:59:19 -0400 < Zipheir> Cool.
2023-08-30 14:07:25 -0400 < myrkraverk> If I get anywhere in [trying to] interpret Scheme, is Appel's /Compiling with Continuations/ at all applicable?
2023-08-30 14:07:52 -0400 < myrkraverk> I've thumbed through the book, but I don't have a copy.
2023-08-30 14:09:41 -0400 < Zipheir> myrkraverk: It's an interesting presentation of his SML compiler, but it's not very accessible as a book. Prepare to get into some very hairy details.
2023-08-30 14:09:59 -0400 < Zipheir> EoPL has a much simpler presentation of a CPS interpreter.
2023-08-30 14:10:37 -0400 < Zipheir> myrkraverk: You might also read this post by Matt Might. https://matt.might.net/articles/cps-conversion/
2023-08-30 14:26:06 -0400 < mnieper`> Appel's book applies.
2023-08-30 14:26:31 -0400 < mnieper`> Zipheir: What is not accessible?
2023-08-30 14:30:07 -0400 < Zipheir> mnieper`: Compiling With Continuations
2023-08-30 14:30:43 -0400 < Zipheir> I don't think it's very readable.
2023-08-30 14:31:07 -0400 < sham1> A-Normal Form is of course another one to consider. It's more alike to SSA and the like
2023-08-30 14:31:11 -0400 < sham1> More "standard"
2023-08-30 14:32:15 -0400 < sham1> And not in the way where CPS and SSA are technically compatible, but just in the mental model and how the IR "looks"
2023-08-30 14:32:23 -0400 < Zipheir> Yes. Some of the GHC authors have been very big on using ANF instead of CPS.
2023-08-30 14:43:06 -0400 < myrkraverk> Well, one of the points of doing this in the first place is to explore different techniques.  If I only wanted "something that works" I might just finish /crafting interpreters/ and try to force that framework to work for me.
2023-08-30 14:43:31 -0400 < myrkraverk> Which I guess is not really a good strategy, in the long run.
2023-08-30 14:43:39 -0400 < sham1> Well I'd say that looking into ANF is just good for that
2023-08-30 14:43:49 -0400 < myrkraverk> ANF?
2023-08-30 14:44:41 -0400 < sham1> A-Normal FOrm
2023-08-30 14:45:26 -0400 < myrkraverk> Ah.  That's a title or technique I'm not familiar with.
2023-08-30 14:45:29 -0400 < sham1> https://matt.might.net/articles/a-normalization/
2023-08-30 14:45:46 -0400 < sham1> Just like CPS it's based on the lambda calculus
2023-08-30 14:46:47 -0400 < sham1> But unlike CPS, what it essentially does is that when you have code like (do-thing (do-other-thing)), that'd get transformed into the equivalent of (let ((immediate-computation-0 (do-other-thing))) (do-thing immediate-computation-0))
2023-08-30 14:47:34 -0400 < Zipheir> If you study programming languages, those kinds of transformations will start to seem simple.
2023-08-30 14:47:52 -0400 < myrkraverk> Ah.
2023-08-30 14:47:56 -0400 < myrkraverk> Yeah, something to learn.
2023-08-30 14:48:14 -0400 < sham1> What we'd say is that unlike CPS, ANF is in so-called "direct style"
2023-08-30 14:48:47 -0400 < sham1> Same as SSA (single static assignment)
2023-08-30 14:49:03 -0400 < sham1> That being the model used for example by the LLVM bytecode
2023-08-30 14:49:05 -0400 < dpk> meh, ANF is just another way of writing CPS. instead of lambda, sometimes you use let. Schemers should already know the two are equivalent
2023-08-30 14:49:31 -0400 < sham1> Well they're all equivalent to SSA as well, but there's clarity to be had in representation
2023-08-30 14:50:07 -0400 < myrkraverk> Good to know.
2023-08-30 14:50:13 -0400 < sham1> For example register allocation is conceptually easier at least to me with ANF or SSA vs CPS
2023-08-30 14:50:16 -0400 < Zipheir> The important thing is that you can preserve language semantics when going between all of these different forms.
2023-08-30 14:51:30 -0400 < dpk> so, the syntax parameter-based/secondary expansion implementation of with-ellipsis i suggested last night seems to work even in syntax-rules! the question is now, whether we want to expose the expand-with-current-ellipsis as a specified syntax form, so that user-defined pattern matchers can also use the built-in with-ellipsis form to control the name of ellipsis
2023-08-30 14:52:14 -0400 < Zipheir> Hmm.
2023-08-30 14:53:11 -0400 < dpk> for clarity: (expand-with-current-ellipsis keyword . rest) simply expands to (keyword current-ellipsis . rest), so that the macro transformer bound to keyword can compare identifiers somewhere within rest to the current ellipsis
2023-08-30 14:54:30 -0400 < dpk> e.g. the first stage of my syntax-case sample implementation simply expands (syntax-case stx lits clause …) into (expand-with-current-ellipsis %syntax-case stx lits clause …), when then becomes (%syntax-case ellipsis stx lits clause …)
2023-08-30 14:56:09 -0400 < mnieper`> CPS is only equivalent to SSA when the continuation labels are well-known (no first-class continuations). Otherwise, CPS is vastly more expressive.
2023-08-30 14:58:34 -0400 < myrkraverk> Does that expressiveness translate into "better optimizations" ?
2023-08-30 14:59:52 -0400 < mnieper`> No; it is more complicated (because it can accomplish more). See Appel's book for how to deal with it, for example.
2023-08-30 15:01:12 -0400 < mnieper`> dpk: with-ellipsis really is a hack to make a simple implementation of R7RS-style syntax-rules in terms of syntax-case possible; for syntax-case/syntax it isn't necessary at all.
2023-08-30 15:01:28 -0400 < mnieper`> So I wouldn't make it even more prominent.
2023-08-30 15:04:17 -0400 < myrkraverk> Copy that.  Putting Appel's book on my to-read-in-the-future as well.
2023-08-30 15:04:34 -0400 < mnieper`> Two alternatives to with-ellipsis are: (1) implement syntax-rules natively or (2) provide syntax-case/ellipsis and syntax/ellipsis that take an ellipsis argument as first argument.  Then explain syntax-case, syntax, syntax-rules in terms of those.
2023-08-30 15:06:28 -0400 < dpk> renaming the ellipsis is useful for readability even if not strictly necessarily
2023-08-30 15:06:29 -0400 < mnieper`> myrkraverk: Alternatively, get rid of call/cc and first-class continuations earlier (before cps conversion), e.g. by implementing them by copying (parts) of the stack. Then do the CPS transformation and you have basically SSA
2023-08-30 15:07:09 -0400 < dpk> and e.g. our variation of cut may wish to use the ellipsis to replace <...>
2023-08-30 15:07:20 -0400 < sham1> You basically have SSA but backwards
2023-08-30 15:07:24 -0400 < sham1> Inside out
2023-08-30 15:08:35 -0400 < myrkraverk> I'll keep that in mind.  Time to study some basics first.
2023-08-30 15:08:42 -0400 < mnieper`> dpk: You can always use ... in templates (as (... ...), which is not much of a deal or as ::: with a (with-syntax ([::: #'(... ...)]) ...) around the templates.
2023-08-30 15:09:03 -0400 < Zipheir> The nice thing about CPS in interpreters is that it makes exceptions and (obviously) first-class continuations easy to implement.
2023-08-30 15:09:06 -0400 < mnieper`> And you can use ... in patterns by replacing it with ::: and adding a fender (ellipsis? #':::).
2023-08-30 15:09:54 -0400 < mnieper`> All that's easy to read and understand in source code.
2023-08-30 15:10:40 -0400 < mnieper`> You don't have the problem with nested syntax-case as with nested syntax-rules because you can easily move the nested thing out of the lexical scope of the outer syntax-case.
2023-08-30 15:10:42 -0400 < dpk> we don’t have a predicate ellipsis?. i don’t think there is a way to implement one with the primitives we have
2023-08-30 15:11:07 -0400 < mnieper`> (free-identifier=? #'::: #'(... ...))
2023-08-30 15:11:31 -0400 < mnieper`> As a procedure, it is part of my toolbox.
2023-08-30 15:11:37 -0400 < dpk> that won’t do the right thing inside with-ellipsis, though, which is why i suggest expand-with-current-ellipsis
2023-08-30 15:12:07 -0400 < dpk> and with-ellipsis is staying in because it’s codified in SRFI 211 and has support from Guile, Unsyntax, and Chibi (though the latter is not R6RS compliant)
2023-08-30 15:12:19 -0400 < mnieper`> I have been suggesting to get rid of with-ellipsis so that doesn't apply.
2023-08-30 15:13:16 -0400 < mnieper`> that = won't do the right thing.
2023-08-30 15:15:00 -0400 < mnieper`> BTW, it just occurs to me that with-ellipsis can break code.
2023-08-30 15:19:49 -0400 < mnieper`> Namely, syntax-case can be used outside of macro transformers (as a general pattern matcher), and I have used it meaningfully as such.  Think of a (better) version SRFI 115's regexp where the "re" is actually a syntax object, not a datum, to maintain source location info.  The match will be done at runtime.  Every macro that expands into code containing syntax-case will like break if used with with-ellipsis.
2023-08-30 15:20:06 -0400 < mnieper`> s/with/within (last sentence)
2023-08-30 15:20:17 -0400 < mnieper`> s/like/likely
2023-08-30 15:21:26 -0400 < mnieper`> I didn't think of it while writing and implementing SRFI 211, but it is a broken attempt.
2023-08-30 15:22:23 -0400 < mnieper`> The basic problem is that we introduce a meaning-changing dynamic property.
2023-08-30 15:23:42 -0400 < mnieper`> The same would apply if we suddenly introduced an ordinary parameter that would change the meaning of, say, +.
2023-08-30 15:39:36 -0400 < mnieper> A lexically scoped with-ellipsis wouldn't have this problem.
2023-08-30 15:44:01 -0400 < cedb> i need to write some docs thats gonna contain like design considerations and maybe a bit of a tutorial in stuff people might not know (event loop shenanigans in py), i wanted to do it with org
2023-08-30 15:44:23 -0400 < cedb> is there like a standard pkg for sane defaults and like automatic file splitting with TOC and hyperlinks in general
2023-08-30 15:44:58 -0400 < sham1> org?
2023-08-30 15:45:10 -0400 < sham1> Why not latex
2023-08-30 15:56:19 -0400 < daviid> sham1: writing doc, i'd use texinfo or skribilo https://www.nongnu.org/skribilo/
2023-08-30 15:58:20 -0400 < mnieper`> daviid: Do you have experience with writing texinfo using Org?
2023-08-30 15:59:59 -0400 < daviid> no, i write texinfo 'directly', no such experience
2023-08-30 16:02:24 -0400 < myrkraverk> In chapter one, Queinnec uses (getprop a b c) and (getprop a b) and mentions (get ...) and (put ...) as possible implementations.
2023-08-30 16:02:52 -0400 < myrkraverk> In order to get a working example out of chapter one, using R5RS in Racket, what can I use?  Hash tables in SRFI 69?  Something else?
2023-08-30 16:05:21 -0400 < myrkraverk> (#%require srfi/69) ; seems to work, but I've not tested further.
2023-08-30 16:05:44 -0400 < mnieper`> You can also use a Scheme that supports symbol properties directly.
2023-08-30 16:06:01 -0400 < mnieper`> E.g. Guile or Chez, but there are certainly many more.
2023-08-30 16:06:18 -0400 < myrkraverk> *nod*  One of the annoyances I'm trying to deal with is Windows as the base system.
2023-08-30 16:06:23 -0400 < myrkraverk> But maybe Chez works?
2023-08-30 16:06:53 -0400 < myrkraverk> Or Guile in Msys2.
2023-08-30 16:08:15 -0400 < myrkraverk> But for now, I'll try to see how easy it is to do this with Racket.
2023-08-30 16:08:51 -0400 < mnieper`> myrkraverk: WSL 2.
2023-08-30 16:09:31 -0400 < myrkraverk> *nod*  So far, I want to avoid that.  More to do with persistence than aynthing else.
2023-08-30 16:13:57 -0400 < mnieper`> Persistence?
2023-08-30 16:14:22 -0400 < myrkraverk> In not using WSL2.
2023-08-30 16:15:25 -0400 < daviid> myrkraverk: i've used guile in msys2, which is great, easy to install, maintain, you may distribute the folder - one folder, even if guile + the all gnome stack (for example, could be anything else in msys2 ...) - that's all you need to get users to use your stuff ... and no headache perfect imo
2023-08-30 16:15:46 -0400 < myrkraverk> I'll keep it in mind.
2023-08-30 16:27:41 -0400 < mnieper`> dpk: still there?
2023-08-30 16:28:02 -0400 < dpk> just about. i need to go, i have more Lithuanian tomorrow, but i can stay maybe 5 minutes
2023-08-30 16:30:40 -0400 < mnieper`> How would you solve the with-ellipsis problem? Making it lexically, not dynamically scoped?
2023-08-30 16:30:46 -0400 < mnieper`> Or just remove it?
2023-08-30 16:31:06 -0400 < mnieper`> But if you are in a hurry, let us talk tomorrow or the day after.
2023-08-30 16:36:16 -0400 < dpk> we can talk about solutions tomorrow. for now i will simply spec (bzw. have already specced) with-ellipsis as it is in Guile, Unsyntax, Chibi, and SRFI 211, and if we want to correct it, we can think about that later
2023-08-30 16:37:56 -0400 < mnieper`> Yes, we actually must correct it (unless we want to export a with-ellipis-aware and a non-with-ellipsis-aware syntax-case/syntax, reducing with-ellipsis to absurdity).
2023-08-30 16:38:34 -0400 < mnieper`> Maybe with-ellipsis wasn't such a good idea of Guile after all.
2023-08-30 16:53:09 -0400 < jcowan> mnieper`: What good is source location in regular expressions?
2023-08-30 16:56:37 -0400 < mnieper`> jcowan: If you have a syntax error in the regular expression.
2023-08-30 16:57:26 -0400 < jcowan> Fair enough.  But that will not help you if your regex is a runtime object, even if it's a literal
2023-08-30 16:58:14 -0400 < mnieper`> Depending on the implementation, you will get a detailed syntax error at runtime.
2023-08-30 17:07:51 -0400 < mnieper`> Run the following in Chez as an R6RS top-level program (using scheme --program <filename>): https://paste.debian.net/1290531/
2023-08-30 17:34:54 -0400 < gwatt> Out of fairness, that's because you're using a syntax-object as the syntax-case argument, and chez scheme allows syntax-objects to retain source location information.
2023-08-30 17:35:38 -0400 < gwatt> I don't think any other object type gets that special treatment
2023-08-30 18:47:01 -0400 < mdhughes> I have the new Not-Dragon Book (Aho, Lam, Sethi, Ulmann), and it's very dry & C-based but goes deep from lexing to machine code generation & optimization for multiple CPUs/threads. Not bad, but it's a couple University courses of material.
2023-08-30 18:47:35 -0400 < mdhughes> The more fun way is to just build an interpreter like SICP or any of a bunch of other ways tells you, and have fun experimenting.
2023-08-30 18:47:46 -0400 < Zipheir> Doch.
2023-08-30 21:14:09 -0400 < Pixel_Outlaw> Hello all, unfortunatly I've got a Java only mandate from work and being a Lisp guy I was wondering if any Schemes can be easily embedded. I see Kawa we used to use Clojure at work but the new mandate is "only java source code".
2023-08-30 21:14:44 -0400 < Pixel_Outlaw> So I was hoping for something made of .java files that can be tossed into a core library to meet these miserable requirements.
2023-08-30 21:25:53 -0400 < daviid> Pixel_Outlaw: "only java source code" ... will get you nowhere :( - kawa compiles to a .class file, but i don't think any lisp/scheme 'on a jvm' will produce java source code, though i am not sure either - you may ask on the kawa maiing list - or biwa or bigloo ... don't know
2023-08-30 21:27:36 -0400 < Pixel_Outlaw> Ah, ok, thanks daviid 
2023-08-30 21:59:56 -0400 < cow_2001> Then I reflect that all things happen, happen to one, precisely now. Century follows century, and things happen only in the present. There are countless men in the air, on land and at sea, and all that really happens happens to me.
2023-08-30 22:05:15 -0400 < acdw> hmmmmmmmm
--- Day changed Thu Aug 31 2023
2023-08-31 00:38:30 -0400 < lockywolf_> mdhughes: which edition is that?
2023-08-31 00:39:14 -0400 < lockywolf_> 2006 should still have the dragon
2023-08-31 00:52:04 -0400 < mdhughes> 2nd. Mine has a chess knight projected on a wall as a real horse.
2023-08-31 00:52:31 -0400 < mdhughes> It may be a semi-legal Indian edition, because that was a couple bucks instead of $60+.
2023-08-31 00:55:50 -0400 < mnieper> gwatt: That's the point.
2023-08-31 05:32:34 -0400 < jobol> announce: pure R7RS-small QR-code generator: https://gitlab.com/jobol/qrcode-gen
2023-08-31 05:33:52 -0400 < sham1> Oh that's nice
2023-08-31 05:39:15 -0400 < jcowan> I've just added TR7 to the list of R7RS implementations linked from r7rs.org
2023-08-31 05:43:45 -0400 < jobol> jcowan, nice
2023-08-31 16:20:42 -0400 -!- ced2 is now known as cedb
2023-08-31 16:26:00 -0400 < dpk> mnieper, mnieper``: ping?
2023-08-31 16:26:15 -0400 < mnieper``> Online as...
2023-08-31 16:26:20 -0400 < mnieper``> mnieper``. :)
2023-08-31 16:27:05 -0400 < mnieper``> dpk: In case you have sent me something privately, I haven't received it.
2023-08-31 16:27:26 -0400 < dpk> i’m about to, i wanted to check which one to use!
2023-08-31 16:27:43 -0400 < mnieper``> The `` right now :)
2023-08-31 16:27:50 -0400 < aeth> but what about mnieper`
2023-08-31 16:28:18 -0400 < aeth> Personally, I think mnieper` is cooler than mnieper or mnieper``
2023-08-31 16:29:06 -0400 < mnieper``> mnieper` is my other Emacs instance on a different machine (currently out of my reach).
2023-08-31 16:29:36 -0400 < mnieper``> mnieper` is short for (mnieper quotequasi)?
2023-08-31 16:29:58 -0400 < Zipheir> Too bad IRC doesn't allow ′, ″, ...
2023-08-31 16:30:39 -0400 < aeth> IRC allows everything (except spaces, no easy way around that because it's a mostly space-separated protocol so arbitrary spaces can only show up in a few places like message bodies)
2023-08-31 16:30:46 -0400 < aeth> it's just a matter of what ircd and the IRC clients permit
2023-08-31 16:31:17 -0400 < Zipheir> OTOH, this is #scheme, so alt accounts should be Zipheir*, Zipheir**, ..., I guess.
2023-08-31 16:31:48 -0400 < aeth> Zipheir, -Zipheir-, --Zipheir--
2023-08-31 16:31:54 -0400 < aeth> start a new, annoying convention that's representable in Scheme
2023-08-31 16:31:55 -0400 < Zipheir> aeth: True. I was thinking of the RFC, but then, that's very old news.
2023-08-31 16:32:11 -0400 < aeth> https://modern.ircdocs.horse/
2023-08-31 16:32:24 -0400 < Zipheir> .horse?
2023-08-31 16:32:30 -0400 < aeth> unfortunately, it's permanently WIP (without the fun "under construction" GIFs that 90s IRC websites would have in that situation)
2023-08-31 16:32:45 -0400 < aeth> so you still need the (outdated) RFCs for some things
2023-08-31 16:32:58 -0400 < gwatt> Why not ".horse". Damn near everything else is a gtld too
2023-08-31 16:33:09 -0400 < aeth> Zipheir: yeah, the TLD authority (ICANN?) sold out
2023-08-31 16:33:20 -0400 < aeth> though it really should be docs.irc
2023-08-31 16:33:36 -0400 < dpk> mnieper``: i PM’d you
2023-08-31 16:33:37 -0400 < aeth> or maybe ircdocs.chat
2023-08-31 16:33:49 -0400 < mnieper``> dpk: Just reading! 
2023-08-31 16:33:51 -0400 < Zipheir> aeth: That's a useful reference. Thanks.
2023-08-31 16:33:56 -0400 < aeth> hmm, there's a channel so you could do irc.channel
2023-08-31 16:33:59 -0400 < aeth> possibly taken, though
2023-08-31 16:34:30 -0400 < Zipheir> The explosion of TLDs lately has been hard to keep track of.
2023-08-31 16:34:43 -0400 < acdw> nah .horse TLD is the best one
2023-08-31 16:34:54 -0400 < gwatt> I think irc.info would make sense, and it's an older tld too
2023-08-31 16:36:23 -0400 < aeth> Zipheir: IRC is basically a disorganized combination of https://ircv3.net/ and https://ircdocs.horse/ (particularly <https://modern.ircdocs.horse/>) and https://github.com/ircv3/ircv3-ideas/issues and https://github.com/ircv3/ircv3-specifications/issues and https://github.com/ircv3/ircv3-specifications/pulls in addition to the RFCs
2023-08-31 16:37:22 -0400  * acdw should register acdw.horse
2023-08-31 16:37:32 -0400 < aeth> IRC needs IRFIs like SRFIs, would be simpler
2023-08-31 16:37:37 -0400 < Zipheir> aeth: And they say Scheme has had a rough time with standardization!
2023-08-31 16:38:18 -0400 < aeth> although note that if you implement a draft from ircv3.net or one of the three Github links, and it winds up not becoming part of IRCv3, that's on you
2023-08-31 16:38:51 -0400 < Zipheir> That's always a danger when implementing experimental protocol features.
2023-08-31 16:39:07 -0400 < Zipheir> That describes everything going on with Gemini at the moment.
2023-08-31 16:39:40 -0400 < aeth> I'm impressed that they use three different places for drafts, though. Four if you count the drafts (rather than final stuff) on ircv3.net
2023-08-31 16:39:52 -0400 < aeth> technically "ideas" can just be ideas, but there are some drafts there
2023-08-31 16:40:25 -0400 < aeth> and I suppose you can put a draft anywhere
2023-08-31 16:40:38 -0400 < Zipheir> Issue trackers are actually a good place to work on standards, modulo their dependence on JS.
2023-08-31 16:41:05 -0400 < aeth> yeah, but then you have to get a codeberg account or something
2023-08-31 16:41:16 -0400 < Zipheir> And that.
2023-08-31 16:41:35 -0400 < aeth> because gitlab post-IPO is starting to fail, and github probably will last longer because Microsoft is using it as a loss leader, but it won't last forever because eventually someone high up at Microsoft will realize how "undermonetized" github is
2023-08-31 16:41:50 -0400 < acdw> is gemini still a thing
2023-08-31 16:42:34 -0400 < aeth> Gemini was never a thing because it's too limited.
2023-08-31 16:42:43 -0400 < Zipheir> Sure, the *real* concern with using trackers as discussion boards is that the service may roll up the carpet.
2023-08-31 16:43:16 -0400 < acdw> apparently UseNet is back (not that it left)
2023-08-31 16:43:17 -0400 < dpk> once the macrological fascicle is released (usual disclaimer applies), public comments will be welcomed, and if you don’t want to get a Codeberg account you will be able to email them to me and i will file them as issues for you. i will probably even accept anonymous submissions by this route, provided the content is not an obvious troll
2023-08-31 16:43:20 -0400 < Zipheir> acdw: This was written in the last 3 months, so it's still generating some noise in the curl world. https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/
2023-08-31 16:43:40 -0400 < aeth> People want hyperlinked text documents. You want to roll back the web to 2004 or so without the JS and with some JS-required features addressed (since JS is sometimes used for a reason, even though it's 95% overkill now)
2023-08-31 16:43:51 -0400 < acdw> yeah they've been trying to get curl to pick it up for some time. I thought Daniel made excellent points
2023-08-31 16:44:00 -0400 < Zipheir> dpk: Thanks, that's going above and beyond.
2023-08-31 16:44:28 -0400 < Zipheir> acdw: Like about how vague the spec is?
2023-08-31 16:45:18 -0400 < aeth> The problem with the web is everyone rolled Flash features into the web while in the '00s you could just disable Flash and get a decent web (and even adblock that way!). You can't disable JS and get anything other than a blank page for so many sites, though.
2023-08-31 16:45:33 -0400 < aeth> (We didn't really need adblockers in the '00s because the annoying ads used Flash)
2023-08-31 16:45:40 -0400 < Zipheir> Hah.
2023-08-31 16:47:10 -0400 < Zipheir> dpk: I'm looking forward to the macrofascicle, even if I can't pronounce it.
2023-08-31 16:48:35 -0400 < aeth> hmm
2023-08-31 16:48:42 -0400 < aeth> can r7rs-large have a web alternative built-in?
2023-08-31 16:49:12 -0400 < Zipheir> aeth: What do you want, scribble-over-TCP?
2023-08-31 16:49:19 -0400 < aeth> just use HTTP to serve s-expressions; protocols aren't that interesting
2023-08-31 16:49:35 -0400 < Zipheir> So Scribble over HTTP, then.
2023-08-31 16:50:02 -0400 < aeth> I guess that would require an HTTP SRFI first, though
2023-08-31 16:50:13 -0400  * aeth checks to see if there is an "HTTP" result yet. No.
2023-08-31 16:50:28 -0400 < aeth> I would've assigned a 20% probability to that.
2023-08-31 16:50:45 -0400 < Zipheir> Instead of websockets, should Scheme have webports?
2023-08-31 16:51:01 -0400 < aeth> Although I guess you need a TCP/IP SRFI before the HTTP SRFI before the networked document SRFI
2023-08-31 16:51:13 -0400 < aeth> unless you just do the latter and leave the networking entirely to the implementation
2023-08-31 16:51:42 -0400 < acdw> Zipheir yep
2023-08-31 16:52:10 -0400 < acdw> omg webports yessss
2023-08-31 16:52:21 -0400 < acdw> i'm also down for scribble over http .. or something like it
2023-08-31 16:52:30 -0400 < acdw> how portable is scribble anyway? or the other thing
2023-08-31 16:53:07 -0400 < acdw> i was into gemini for a while around the lockdown ... lost interest around the time drew devault decided to blackhole clients requesting favicon.txt
2023-08-31 16:53:13 -0400 < acdw> or threatened to
2023-08-31 16:53:35 -0400 < aeth> is it a no-image protocol?
2023-08-31 16:53:37 -0400 < Zipheir> Racket supports scribble. I know chibi has a scribble parser and I think foof writes the docs in it.
2023-08-31 16:54:16 -0400 < Zipheir> aeth: The Racket flavor supports images. https://docs.racket-lang.org/scribble/
2023-08-31 16:54:27 -0400 < aeth> I mean Gemini
2023-08-31 16:54:31 -0400 < acdw> aeth: gemini is a plaintext protocol that was written to make one request at a time. one client author thought it'd be fun to do an optional spec for /favicon.txt containing one emoji character, but that's UNACCEPTABLE apparently
2023-08-31 16:54:40 -0400 < aeth> I understand resisting images... inline images, especially in replies, make social media worse (HN and Tildes and Lobsters don't have it... Lemmy does...) and I'd never use an IRC client with it... but for general documents, you kind of need images for a lot of things
2023-08-31 16:55:05 -0400 < aeth> I mean, just basic hyperlinked stuff need multimedia to some extent and the web still underutilizes it. Most videos/etc. are in "apps"
2023-08-31 16:55:28 -0400 < aeth> Wikipedia has nowhere near as many videos as you'd think, although it actually has some videos now, unlike in the '00s
2023-08-31 16:55:31 -0400 < Zipheir> acdw: I think the idea of a one-character favicon is pretty brilliant, actually, even if it's not necessary.
2023-08-31 16:56:04 -0400 < Zipheir> aeth: I think they had a hard time finding a usable codec for many years.
2023-08-31 16:56:27 -0400 < acdw> i thought it was great fun! and that's what i liked about gemini too, really. like, it clearly was never going to be for anything actually serious or business..-y. human scale, ya know? so i thought drew's response was pretty extreme
2023-08-31 16:56:45 -0400 < aeth> but hypermedia absolutely needs images
2023-08-31 16:56:51 -0400 < aeth> what makes the web toxic is the *scripting*
2023-08-31 16:56:53 -0400 < acdw> gemini was more going for gopher plus a bit
2023-08-31 16:56:55 -0400 < aeth> the tracking, the ads, etc.
2023-08-31 16:57:05 -0400 < acdw> it was made by gopher enthusiasts who wanted basically a better gopher
2023-08-31 16:57:19 -0400 < aeth> yeah, which makes gemini overrated
2023-08-31 16:57:34 -0400 < aeth> because what 99% of people who don't like the modern web want is an old web, not a new gopher
2023-08-31 16:57:51 -0400 < aeth> maybe HyperCard
2023-08-31 16:58:05 -0400 < acdw> yeah, that's kind of where i ended up
2023-08-31 16:58:12 -0400 < Zipheir> Especially since doing TLS correctly with gemini requires a lot of additional work that no-one implementing gemini clients/servers seems to want to do.
2023-08-31 16:58:32 -0400 < Zipheir> So it's still basically Gopher.
2023-08-31 16:59:48 -0400 < aeth> Gemini kind of using Markdown is sort of good, but you'd want something closer to an extended Markdown (using the always-extended tables stuff) imo
2023-08-31 17:00:06 -0400 < aeth> probably with the addition of some styling, colors, etc. And inline images (but not animated images and sadly probably not videos)
2023-08-31 17:00:57 -0400 < aeth> You could probably get there with IRC levels of formatting capabilities, although IRC doesn't use a human readable text source.
2023-08-31 17:01:13 -0400 < Zipheir> aeth: But then someone will suggest that the markup should only indicate structure, not appearance, and that styling should be done with external style sheets...
2023-08-31 17:01:31 -0400 < Zipheir> The eternal recurrence!
2023-08-31 17:01:36 -0400 < aeth> The main problem with colors is that some people use dark themes and some people use light themes and what's visible depends on which (which is an issue with e.g. IRC colors)
2023-08-31 17:02:22 -0400 < Zipheir> Which is why styles should always be optional.
2023-08-31 17:03:13 -0400 < Zipheir> (Optional and overridable.)
2023-08-31 17:05:52 -0400 < acdw> time is a flat circle
2023-08-31 17:06:16 -0400 < acdw> you could embed raw terminal escapes in gemtext documents and a lot of clients (even gui ones) would render em
2023-08-31 17:06:47 -0400 < Zipheir> People would *hate* that.
2023-08-31 17:07:08 -0400 < Zipheir> You could probably find a way to do blinking text, and then they'd hate you even more. :)
2023-08-31 17:07:12 -0400 < acdw> lmaoooo
2023-08-31 17:07:20 -0400 < acdw> what's the ANSI escape for marquee ....
2023-08-31 17:07:48 -0400 < aeth> terminals are too limited, though
2023-08-31 17:08:03 -0400 < aeth> because what you basically want is a terminal with inline images, kind of like graphical (outside of the terminal) emacs
2023-08-31 17:09:03 -0400 < acdw> sixel!
2023-08-31 17:09:07 -0400 < acdw> it's a thing™
2023-08-31 17:09:52 -0400 < aeth> yeah, but even if Gemini supports those, that isn't really the way to do it... you'd want separate URLs for the images instead of inlining them
2023-08-31 17:10:09 -0400 < aeth> and not have to rely on the terminal-specific functionality (leaving it up to the terminal to use something like sixels or whatever)
2023-08-31 17:10:33 -0400 < aeth> Although I personally think that terminals should just stop emulating VTs
2023-08-31 17:10:43 -0400 < acdw> mm yeah 
2023-08-31 17:10:52 -0400 < aeth> if you want to "cat" hello-world.png it should just let you do it
2023-08-31 17:11:12 -0400 < acdw> hell yeah
2023-08-31 17:11:15 -0400 < aeth> PDFs are a bit trickier because of the pages...
2023-08-31 17:11:36 -0400 < acdw> if emacs can do it ...
2023-08-31 17:11:50 -0400 < aeth> I think Emacs renders PDFs to images, which you can then go through as "pages" one at a time
2023-08-31 17:12:25 -0400 < acdw> indeed that's what it does w/ docview mode. pdf-tools requires an external library that i think hooks into mupdf or smeothing
2023-08-31 17:33:53 -0400 < mdhughes> Daniel's complaints are all: Yes, that's the point. We like Gopher, it's just not on TLS, and the format's a little obscure. Gemini is simpler & safer.
2023-08-31 17:37:56 -0400 < aeth> the problem with Gemini is that it's overhyped... it's aimed at the 100 people who still want Gemini, while it's often marketed at the several million or so people who want the old web (although there's several different tiers of "old" there for the web)
2023-08-31 17:37:58 -0400 < mdhughes> I read several gemlogs, I'd run my own except I haven't bothered to install it on my server.
2023-08-31 17:38:05 -0400 < aeth> s/still want Gemini/still want Gopher/
2023-08-31 17:38:27 -0400 < mdhughes> Most people don't know what they want, they just turn on the TV/web and click click click watch some ads.
2023-08-31 17:38:38 -0400 < mdhughes> For those who give a trace of a shit, there's alternatives.
2023-08-31 17:38:48 -0400 < Zipheir> His points about TLS are very sharp, though. It's not "safer" without actually storing and verifying certificates (client and server), which most of the clients/servers don't do.
2023-08-31 17:39:34 -0400 < aeth> no, there isn't an alternative, there really is no "old web", which is why Gemini keeps getting mentioned to such people (which is a much larger crowd than the people who want new-Gopher)
2023-08-31 17:39:37 -0400 < mdhughes> He doesn't know anything about what the clients do.
2023-08-31 17:39:52 -0400 < mdhughes> At least, he never mentions testing or using any, just reading a non-spec.
2023-08-31 17:40:25 -0400 < mdhughes> aeth: I'm on fediverse, which is the hideaway for people who didn't want "twitter".
2023-08-31 17:40:32 -0400 < Zipheir> I did try to find a Gemini client that took certificates seriously. I certainly can't find any servers that don't just handwave client certs.
2023-08-31 17:40:49 -0400 < Zipheir> (Including my Scheme one, which I'm hoping no-one uses.)
2023-08-31 17:40:52 -0400 < mdhughes> I'm reading a bunch of gemlogs, many of which are about low-tech computing.
2023-08-31 17:41:09 -0400 < aeth> The Fediverse is already 95% of the way along the enshittification train. Images in replies is just ewww... A picture is worth a thousand words and so any image reply dominates the other replies.
2023-08-31 17:41:26 -0400 < aeth> The only reason social media sites added that (as a late feature!) is because appealing to the memers expands the audience
2023-08-31 17:41:30 -0400 < aeth> The Fediverse doesn't need that
2023-08-31 17:41:56 -0400 < mdhughes> People want to share images.
2023-08-31 17:42:19 -0400 < mdhughes> Fedi has a nice culture about it, tho, you CW stuff that's disturbing, and alt-text everything. You get SHUNNED if you violate those repeatedly.
2023-08-31 17:42:50 -0400 < aeth> An image or an "album" of images as the thread starter is a lot more reasonable than images in replies, although most "good" Reddit clones don't allow images at all and I understand their perspective.
2023-08-31 17:43:12 -0400 < mdhughes> aeth: Also, this is purely a personal thing, but I have a content filter there for any bullshit term Cory Doctorow writes. I'm gonna add it here, too.
2023-08-31 17:43:18 -0400 < aeth> Amusingly, none of such sites are federated, while the fediverse (lemmy, mastodon, etc.) is, despite text being way easier to distribute that images
2023-08-31 17:43:29 -0400 < aeth> s/that images/than images/
2023-08-31 17:44:23 -0400 < aeth> mdhughes: it's the word of the year for a reason... every site sucks now, and they started really sucking around the same time
2023-08-31 17:44:42 -0400 < aeth> although personally, my tolerance for BS is lower than most people's so I started having problems with large parts of the web 10 years ago.
2023-08-31 17:44:48 -0400 < mdhughes> We often have conversations with more images & links. There's some problems with threading in most fedi clients, but the content is fine as long as people all follow cultural standards.
2023-08-31 17:44:51 -0400 < aeth> (it's just that now they crossed thresholds that bother everyone else)
2023-08-31 17:45:44 -0400 < acdw> i mean i use fedi mostly for shitposting
2023-08-31 17:45:55 -0400 < aeth> mdhughes: I just have no interest in a federated twitter because Twitter's 2006 introduction was already pretty late in the life of the "good" web and was kind of the beginning of the end, along with Reddit and Facebook etc.
2023-08-31 17:45:58 -0400 < mdhughes> The web as I liked it died somewhere between 1999 to O'Reilly's "Web 2.0" conference in 2004.
2023-08-31 17:46:06 -0400 < acdw> mdhughes: I might need to filter cory too....
2023-08-31 17:46:23 -0400 < mdhughes> fedi, at its best, is just like classic ICQ, AIM, LiveJournal culture.
2023-08-31 17:46:40 -0400 < aeth> I'm far more critical of the fediverse given the context of wanting something beween 1991's gopher and early 2010s Twitter
2023-08-31 17:46:46 -0400 < aeth> the "old web" as I said
2023-08-31 17:47:02 -0400 < aeth> although there really are a bunch of old webs people want
2023-08-31 17:47:13 -0400 < mdhughes> And that's the good thing. I loved Gopher the first time, I've always been cranky at the "World Wide Web" thing.
2023-08-31 17:47:41 -0400 < aeth> Some people would be fine with a "modernized" (and far more secure) version of phpBB/MediaWiki/Wordpress that every site in the late '00s seemd to have. Some people want Geocities.
2023-08-31 17:48:15 -0400 < acdw> i want a forum that works like modern goodness but looks like the 90s thing ... the new fora are so whitespacey
2023-08-31 17:48:35 -0400 < aeth> M O D E R N m e a n s p a d d i n g
2023-08-31 17:48:39 -0400 < aeth>  
2023-08-31 17:48:58 -0400 < acdw> at least 3em of padding
2023-08-31 17:49:24 -0400 < mdhughes> Some people want h4xx0r n00z, some of us don't want to live in hell.
2023-08-31 17:50:15 -0400 < aeth> lots of stuff from the '00s are fine in style but really just lack a max width (which is far too controversial still somehow because a bunch of people (perhaps Mac users, because having things windowed is more culturally normal there) seem to think that you should constantly be resizing your web browser every time you switch sites/tabs to have things perfectly fit manually)
2023-08-31 17:50:27 -0400 < mdhughes> Display & clients used to be native software. You'd have a nice local program that handled all the network stuff, didn't use a browser to try to render complex layouts.
2023-08-31 17:50:35 -0400 < aeth> '90s require switching from serif to sans serif on top of that, as well as removing any really ugly/clashing background if it's there
2023-08-31 17:51:37 -0400 < sham1> Also you can no longer have gifs of dancing skeletons
2023-08-31 17:51:50 -0400 < sham1> Well you *can*, but it's just not the same
2023-08-31 17:52:40 -0400 < aeth> this is what will stop people from using Gemini
2023-08-31 17:52:50 -0400 < aeth> no dancing baby
2023-08-31 17:53:36 -0400 < mdhughes> Lagrange doesn't, but there's nothing stopping a Gemini client from loading inline images.
2023-08-31 17:53:59 -0400 < sham1> Also as linked above, Daniel Stenberg's blog post about Gemini from the eyes of being the maintainer of cURL
2023-08-31 17:54:04 -0400 < mdhughes> And I've seen a lot of ASCII/Emoji art.
2023-08-31 17:54:17 -0400 < acdw> my main beef w/ unstyled web is lack of max width yeah
2023-08-31 17:54:41 -0400 < mdhughes>  So make a custom style sheet, set body { max-width: 6in !important; }
2023-08-31 17:54:52 -0400 < aeth> unstyled web is a lot better once you replace your browser's default to a sans serif (they usually use serif)
2023-08-31 17:54:59 -0400 < aeth> to the point where you might not even notice it's unstyled
2023-08-31 17:54:59 -0400 < sham1> There's a reason why coding styles go somewhere around 80 to 120 characters wide and why newspapers for example have columns
2023-08-31 17:55:40 -0400 < aeth> 80 is punched cards
2023-08-31 17:55:48 -0400 < aeth> 100-120 is more reasonable if you don't use punched cards
2023-08-31 17:56:02 -0400 < aeth> we should probably check to see how many people program Scheme with punched cards
2023-08-31 17:56:09 -0400 < sham1> Oh sure, although it also helps readability. Heck, if anything you could go even lower
2023-08-31 17:56:23 -0400 < sham1> That's just due to how eyes work
2023-08-31 17:56:26 -0400 < aeth> 94-100 seems optimal for me because of indentation and long names
2023-08-31 17:56:29 -0400 < mdhughes> TRS-80 was 64x16, and no use for larger screen has ever been found.
2023-08-31 17:56:50 -0400 < aeth> actually widescreens are good because you can tile 2-4 columns
2023-08-31 17:56:59 -0400 < aeth> I don't see the use for ultrawides because who needs 6-8 columns?
2023-08-31 17:57:02 -0400 < mdhughes> If your function doesn't fit in that, you've made it too big.
2023-08-31 17:57:07 -0400 < sham1> Yeah, like a newspaper
2023-08-31 17:58:37 -0400 < aeth> Imo, 1440p is really nice because a lot of stuff is *still* designed for 1280x720/1280x800 (or possibly even the older CRT 1024x768)... So at 2560x1440 (or 2560x1600 if you can find one) you can basically permanently do a split down the middle and treat your setup like two monitors.
2023-08-31 17:58:54 -0400 < acdw> mdhughes: can i do that for only pages taht don't set their own max-widths?
2023-08-31 17:59:13 -0400 < aeth> 1920x1080 (or twice that on each dimension, i.e. 4K) seems too wide to have most things fullscreen, but too narrow to have it split down the middle.
2023-08-31 17:59:25 -0400 < aeth> (at least if you do 4K with 2x scaling, which is common)
2023-08-31 17:59:43 -0400 < mdhughes> acdw: You could take out the !important, and probably the page overrides it? You'd have to test, CSS is junk.
2023-08-31 18:01:01 -0400 < aeth> I guess I should also mention the cheap-tier 1366x768 laptops as a possible reason for why things still fit in 1280-wide tiles
2023-08-31 18:01:47 -0400 < acdw> mmm yes indeed
2023-08-31 18:01:54 -0400 < aeth> combined with < 1366 that's about 8% (alone it's about 5%) of the Steam hw survey (and these are machines nice enough to game on... many cheaper machines still exist)
2023-08-31 18:02:10 -0400 < mdhughes> Also may as well set a TRS-80 font, and img { display: none !important; } and now the web looks good.
2023-08-31 18:16:47 -0400 < aeth> old fonts is 100% nostalgia
2023-08-31 18:17:28 -0400 < aeth> if there's one good side effect from over-minimalism (which has led to e.g. buttons not looking like buttons, or people thinking that [ ( )] is more intuitive than [x] for binary state in GUIs, etc., etc.) it's that font nerds have made a lot of fonts
2023-08-31 18:17:32 -0400 < aeth> of all types
2023-08-31 18:17:45 -0400 < aeth> because fonts are the only expression that the extreme minimalism of modernity allows
2023-08-31 18:19:04 -0400 < Zipheir> You can express yourself by using whitespace in daring ways!
2023-08-31 18:26:21 -0400 < aeth> another amusing thing is that there's probably more people working on retro stuff now than back in the day (which day depends on how retro) because computing was small back when retro was current... and you had to rush things because everything would quickly obsolete while now you have all of the time in the world
2023-08-31 18:28:04 -0400 < aeth> also, modern tooling makes making things easier
2023-08-31 18:28:08 -0400 < aeth> e.g. probably more PICO-8 games than "authentic" 8-bit games by several orders of magnitude
2023-08-31 18:29:04 -0400 < aeth> and Gemini (as ultra-niche as it is) is probably larger than Gopher ever got (in absolute, not relative, terms)
2023-08-31 21:47:02 -0400 < lockywolf_> aeth: most fonts are garbage
2023-08-31 21:48:35 -0400 < aeth> lockywolf_: yes, but if more people are making fonts, and Sturgeon's law remains the same, then the 90% that's crap is larger, but so is the 10% not-crap (and maybe 1% good)
2023-08-31 21:51:08 -0400 < lockywolf_> well, I know only about 3 fonts which cover all the alphabets I need
2023-08-31 21:55:04 -0400 < aeth> lockywolf_: you know three?
2023-08-31 21:55:12 -0400 < aeth> lockywolf_: what's the third?
2023-08-31 21:55:26 -0400 < aeth> DejaVu and Noto are the two I know of that try to cover "everything"
2023-08-31 21:57:08 -0400 < aeth> But Cyrillic in general seems to have terrible font treatment. Most just look ugly. Greek, which isn't that different, tends to look much nicer.
2023-08-31 21:57:13 -0400 < aeth> And it's entirely down to fonts.
2023-08-31 21:57:21 -0400 < lockywolf_> aeth: Sarasa
2023-08-31 21:57:36 -0400 < lockywolf_> and I don't thing DejaVu covers what I need
2023-08-31 21:58:12 -0400 < lockywolf_> it is Noto, Source and Sarasa. Ah, maybe also WenQuanYi 
2023-08-31 21:59:43 -0400 < aeth> ah, CJK fonts?
2023-08-31 22:00:18 -0400 < aeth> now that's an area that basically needs high DPI screens
2023-08-31 22:00:31 -0400 < aeth> to not look awful
2023-08-31 22:01:15 -0400 < aeth> I didn't know that DejaVu was lacking there.
2023-08-31 22:20:06 -0400 < jcowan> Cyrillic had a century of Socialist Realism, in fonts as in everything else. Give it time.
2023-08-31 22:22:00 -0400 < aeth> yes
2023-08-31 22:27:39 -0400 < jcowan> Also, Lagrange will inline images provided you click on the links yourself, which is the Gemini ethos (no preloading!)
2023-08-31 23:25:26 -0400 < mdhughes> I've gone completely over to using Fira Sans, Mono, Code for all my web stuff. It's close enough to Futura that I can live with it, and it looks the same almost everywhere.
2023-08-31 23:26:02 -0400 < mdhughes> And a lot of my local text is Fira, but not all; system fonts can stay San Francisco or whatever it is now.
2023-08-31 23:27:40 -0400 < mdhughes> The Fira Code ligatures aren't that big a deal in a syntax-less language like Scheme, but they make a huge difference in JS.
2023-08-31 23:34:03 -0400 < mdhughes> Original Fira has latin, greek, cyrillic. FiraGo adds Arabic, Devanagari, Georgian, Hebrew and Thai (but I don't use those, so haven't switched anything)
2023-08-31 23:46:01 -0400 < jcowan> I find monowidth ligatures very offputting.  I saw them in an ORA book once, and Java files just look very very strange.