2026-08-25 21:40:12 <KipIngram   > Ok, now THAT is frustrating.  I was interested in pdf conversion to epub.  ChatGPT recommended a tool, pdf2epub.  I cloned the repo and commenced building it.  It hauled in all kinds of dependencis including PyTorch (which apparently is ENORMOUS).  I didn't fret too much because I was working in a virtual Python env.  Anyway, I finally got it running, and it RAN OUT OF RAM while converting my PDF.
2026-08-25 21:40:14 <KipIngram   > I HAVE 32 GB!!!!!!
2026-08-25 21:40:18 <KipIngram   > That is RIDICULOUS.
2026-08-25 21:40:40 <KipIngram   > I would like to see a pdf to epub converter written by Chuck - it's probably be about 100 kB.
2026-08-25 21:40:44 <KipIngram   > If that much.
2026-08-25 21:41:07 <KipIngram   > Doesn't anyone actually try to be clever anymore?  Or is the standard approrach "just throw the world at it"?
2026-08-25 22:18:18 <bjorkint0sh > KipIngram: worse. 'throw a datacenter at it'.
2026-08-25 22:33:21 <xentrac     > weird, why would you use PyTorch for PDF to epub conversion?
2026-08-25 22:35:29 <xentrac     > maybe it's using an LLM to try to figure out which text on different pages of a PDF is supposed to be part of the same flow?
2026-08-25 22:36:10 <xentrac     > lisbeths: I think the interpretive STG-machine implementation of GHC was already in the ballpark of Forth
2026-08-25 22:38:43 <xentrac     > btw, it's not "combinatorial graph reduction", which would be combinatorial reduction of graphs.  It's "combinator graph reduction", which is reduction of graphs of combinators.  You may be interested in looking at my λ-calculus compiler using combinator graph reduction at http://canonical.org/~kragen/sw/sk
2026-08-25 22:38:48 <xentrac     > it's written in JS
2026-08-25 22:40:06 <xentrac     > KipIngram: it makes a certain amount of sense that arbitrarily sophisticated AI could be applied to the problem of guessing which text in a PDF is the main flow of text and what order it's supposed to flow in
2026-08-25 22:41:11 <xentrac     > maybe if pdf2epub is doing that it has an option to use a slightly stupider LLM that fits in 32GiB or even 16GiB of RAM
2026-08-25 22:42:20 <xentrac     > lisbeths: I say it's a λ-calculus compiler, but actually it's augmented with arithmetic and conditionals
2026-08-25 22:43:10 <xentrac     > it compiles the λ-calculus expressions you give it to a tree of combinators, which it then reduces to normal form using normal-order combinator graph reduction
2026-08-25 22:56:22 <bjorkint0sh > xentrac: BAI 3 years ago (before AI), this conversion would not have involved any LLMs at all.
2026-08-25 22:56:33 <bjorkint0sh > and it would have been done successfully.
2026-08-25 23:15:02 <lisbeths    > so I dont think we're gonna be able to agree about GHC
2026-08-25 23:15:30 <lisbeths    > that being said the core thing we can agree or disagree on is that it would be useful to have extremely tiny abstract machines that fit onto microcontrollers
2026-08-25 23:15:55 <lisbeths    > previously I had thought subleq would be the smallest most performant one I knew of. turns out lambda calculus is significantly more performant
2026-08-25 23:16:30 <lisbeths    > futhermore I am working on a subset of c that is semi-abstract whos concept should be transferrable onto a subset of raw asm
2026-08-25 23:16:37 <bjorkint0sh > lisbeths: why do you want abstract machines in there when you already have the assembler?
2026-08-25 23:16:55 <hello-operator> Is is more performant?
2026-08-25 23:17:05 <lisbeths    > than subleq yes
2026-08-25 23:17:46 <hello-operator> I wouldn't have thought so? My experience of those machines is that they are very slow and use huge amounts of memory to do anything simple
2026-08-25 23:17:53 <lisbeths    > bjorkint0sh: for a low level microcontroller coder learning a new assembler language is not a tedious task. but for high level coders who dont often write in assembler this is sometimes considered a tedious task
2026-08-25 23:17:56 <bjorkint0sh > hello-operator: subleq 'jumps around' a lot. so it's not efficient.
2026-08-25 23:18:20 <lisbeths    > any abstract machine is going to be significantly slower than the compiled code that a good forth like jonesforth can emit
2026-08-25 23:18:47 <bjorkint0sh > lisbeths: sounds like a microcoded VM.
2026-08-25 23:19:02 <bjorkint0sh > in other news, I didn't know UEFI was a programming target at all.
2026-08-25 23:19:03 <hello-operator> Yeah, it's not efficient, but compared to lambda calculus? I think I'd want data before declaring that
2026-08-25 23:19:11 <lisbeths    > sure that is another way to say what it is. only an abstract machine is a very specific kind of microcoded vm
2026-08-25 23:19:42 <lisbeths    > an abstract machine boots up with no context of the outside machine that it is running on. it doesnt care what machine its running on and will run the same no matter where you encode it
2026-08-25 23:19:48 <hello-operator> My instincts is that subleq would be faster and use less memory (and be simpler to implement) than lambda calculus for a massive array of real problems
2026-08-25 23:19:59 <hello-operator> But those are just instincts
2026-08-25 23:20:05 <bjorkint0sh > lisbeths: of course it is. that's the point of virtual machines from the days of p-code and O-Code.
2026-08-25 23:20:22 <lisbeths    > that was my instinct too though the coders in here and in #haskell were showing me some tips for writing a lambda calculus evaluator that they claim would be significantly faster than subleq
2026-08-25 23:20:43 <lisbeths    > sure but the point I am trying to make is that not all virutal machines are true abstract machines
2026-08-25 23:20:45 <bjorkint0sh > to the present day ... where graal and the jvm and BEAM and CLR reign supreme.
2026-08-25 23:20:52 <bjorkint0sh > lisbeths: ah gotcha.
2026-08-25 23:21:05 <bjorkint0sh > so you want something like a G-Machine or a SECD machine in microcode?
2026-08-25 23:21:18 <lisbeths    > abstract machines guarantee portability of code as long as theres enough ram, whereaas a virtual machine only improves portability
2026-08-25 23:21:30 <hello-operator> Yeah, of course they would say that! All functional programmers are kings of "the sufficiently smart compiler" :D, what does the actual data say?
2026-08-25 23:21:55 <lisbeths    > so for forth coding if we were going to want a microcoded abstract virtual machine it would nto matter which one we chose. we would just want one that is small, fast, and totally abstract
2026-08-25 23:22:31 <lisbeths    > I will say that subleq i likely significantly smaller than lambda calculus
2026-08-25 23:22:36 <bjorkint0sh > lisbeths: is microcoding that easily accessible?
2026-08-25 23:22:54 <lisbeths    > also in subleq's defence: I think if you build finite state machines in subleq you will get a significant edge
2026-08-25 23:23:06 <lisbeths    > bjorkint0sh: I am not sure what you are asking
2026-08-25 23:23:12 <hello-operator> *significantly*, not only that if you are willing to complicate the implementation you can do the same to subleq programs as well!
2026-08-25 23:25:33 <bjorkint0sh > what I'm asking is, without an FPGA, how would you implement your ideal abstract machine?
2026-08-25 23:26:41 <lisbeths    > oh so on a sufficiently sized fpga you might dedicate some circuits to interpreting that abstract machine, otherwise you would compute the abstract the machine on one of the arm cores on the fpga
2026-08-25 23:26:50 <lisbeths    > it dependson what kind of fpga you're using
2026-08-25 23:27:23 <lisbeths    > my understanding is the majority of forth coders are using specialized low power microcontrollers most of the time. so this is the first time I am hearing of forth coders using fpgas
2026-08-25 23:28:47 <hello-operator> There are a number of Forth implementations that "run" (not quite the right word) directly on an FPGA, it's quite easy to do, it is much more difficult to implement an abstract machine that executes lambda calculus
2026-08-25 23:29:13 <lisbeths    > indeed
2026-08-25 23:29:33 <lisbeths    > if you were able to make an abstract forth, then it would indeed replace what I am talking about
2026-08-25 23:29:50 <lisbeths    > an example of an abstract forth-like machine is joy
2026-08-25 23:30:10 <lisbeths    > my understanding is standard forths like jonesforth are not actually true abstract machines they are merely "machines"
2026-08-25 23:31:48 <hello-operator> I don't think that really matters? You can take any real machine and treat it like it is abstract
2026-08-25 23:33:21 <hello-operator> Although Forth CPUs like the J1 or H2 do pretty much execute Forth directly
2026-08-25 23:33:35 <xentrac     > bjorkint0sh: no, generally speaking, BAI, conversions from PDF to epub could not be done automatically.  They required a lot of manual work, or they produced shitty output
2026-08-25 23:34:29 <lisbeths    > so there are many kinds of programs where the difference between an abstract machine and a regular machine wont matter
2026-08-25 23:34:42 <xentrac     > lisbeths: it's easy to agree about factual questions like how fast a particular version of GHC is for particular problems.  All you have to do is test it, or look up results from people who did
2026-08-25 23:34:44 <lisbeths    > and in fact a regular machine is preferable for most things becuase it is almost always mor eperformant
2026-08-25 23:35:07 <xentrac     > I don't think it's likely taht the lambda-calculus is significantly more performant than subleq
2026-08-25 23:35:07 <lisbeths    > however there are distinct differences from an abstract machine and a regular machine that can offer mathematical advantages
2026-08-25 23:35:32 <lisbeths    > so i dont *care* which one is more performant folks
2026-08-25 23:35:40 <lisbeths    > thats not really what I am here to discuss
2026-08-25 23:36:05 <lisbeths    > obviously every few years someone might break the barrier for the next most performant small abstract machine
2026-08-25 23:36:31 <xentrac     > I mean the lambda calculus doesn't have arithmetic or arrays, and subleq does have those
2026-08-25 23:37:35 <hello-operator> Oh, I was just interested in the performance bit, at least initially, but I still don't know what you mean or would get out of an "abstract machine"
2026-08-25 23:37:35 <lisbeths    > i agree that is why my initial thought was that subleq would be more efficient
2026-08-25 23:37:43 <lisbeths    > especially because subleq can have a jump table of subroutines
2026-08-25 23:38:14 <lisbeths    > all the engineers I was talking too last night was swearing up and down that lambda calculus was more efficient if you implmeent it as a graph reducer of combinators
2026-08-25 23:38:26 <lisbeths    > there is some limited merit to their claims but i dont know
2026-08-25 23:39:07 <hello-operator> Well, it depends on what it's going to do, if it is adding or subtracting a number it won't be!
2026-08-25 23:39:09 <xentrac     > bjorkint0sh: nowadays instead of executing microcode at one or a few operations per clock cycle, CPUs can execute normal instructions at one or a few operations per clock cycle; that's because now CPUs have instruction caches, branch prediction, RISC-like pipelining, superscalar execution, and out-of-order execution.  back in the 01970s, you had to write in microcode to get that kind of performance, but
2026-08-25 23:39:15 <xentrac     > you don't anymore
2026-08-25 23:40:11 <lisbeths    > so alot of people think adding and subtracting in a machine must be inefficient in lambda calculus becuase of the church encoding, but the curch encoding has a piss poor implementation of ints
2026-08-25 23:40:22 <lisbeths    > a much better implementation of ints in the church encoding is a list of booleans
2026-08-25 23:40:42 <xentrac     > lisbeths: I think the engineers you were talking to last night were probably thinking of GHC, which implements a variant of the λ-calculus which is augmented with things like arithmetic, arrays, and bitwise operations
2026-08-25 23:40:44 <lisbeths    > but yes substractoin would still be very slow compared to subleq whos primary option includes a subtraction
2026-08-25 23:41:02 <lisbeths    > yeah that is part of hwat I was trying to explain ot them last night is they arent going to run ghc on forth
2026-08-25 23:41:07 <hello-operator> Yeah, that's still piss poor compared to "ints"
2026-08-25 23:41:19 <xentrac     > well, a list of booleans is
2026-08-25 23:41:26 <hello-operator> yeah
2026-08-25 23:41:27 <xentrac     > but GHC isn't piss poor compared to "ints"
2026-08-25 23:41:32 <lisbeths    > yes I agree that is doggedly poor comprare d to a true on chip subtraction
2026-08-25 23:41:33 <xentrac     > they just added ints to it
2026-08-25 23:41:48 <hello-operator> xentrac: yeah, agreed
2026-08-25 23:41:59 <xentrac     > same thing I did in the λ-calculus compiler I wrote that I linked above
2026-08-25 23:42:06 <xentrac     > except I was using floats because JS
2026-08-25 23:42:09 <lisbeths    > so every time I talk about ghc everyone I speak about keeps telling me about the c code or th emachien code that ghc emits
2026-08-25 23:42:20 <lisbeths    > whereas I am not speaking about that I am speaking about lambda calculus
2026-08-25 23:42:36 <lisbeths    > and they cant tell me straight if lambda calculus is running in that machien code or if lambda calculus is compiling that code
2026-08-25 23:43:21 <lisbeths    > clearly any abstract machine that is allowed to emit machine code gains an incredible performance boost
2026-08-25 23:43:36 <lisbeths    > however then you have lost some abstraction because the machine code you emit is machine specific
2026-08-25 23:44:02 <lisbeths    > the primary reason to prot an abstract machine to forth in the first place is just so that you can write code that is truly portable
2026-08-25 23:44:17 <lisbeths    > s/prot/port
2026-08-25 23:45:19 <xentrac     > compiling the λ-calculus to machine code seems like a valid way to implement the λ-calculus
2026-08-25 23:45:40 <lisbeths    > ok can you show me an example of any lambda expression being compiled into pure machine code
2026-08-25 23:45:45 <lisbeths    > even the iota combinator?
2026-08-25 23:45:59 <xentrac     > and that remains true if you replace "λ-calculus" with "λ-calculus augmented with primitives for things like arithmetic"
2026-08-25 23:46:39 <lisbeths    > What I keep getting confused about with some of these engineers is they keep beating around the bush about if lambda expressions can performantly live inside of a piece of compiled machine code
2026-08-25 23:46:42 <xentrac     > I think you can just write down the ι combinator in Haskell and have GHC emit code for it?  That code isn't going to be invoking anythng like arithmetic
2026-08-25 23:46:51 <lisbeths    > ah thats a good idea
2026-08-25 23:47:03 <lisbeths    > Im gonna try to ask in #haskell about that
2026-08-25 23:47:05 <xentrac     > I don't think it's going to be very performant though!
2026-08-25 23:48:45 <bjorkint0sh > xentrac: as far as I know, microcode is still a viable technique.
2026-08-25 23:48:55 <bjorkint0sh > hello-operator: SECD machines and so forth exist.
2026-08-25 23:49:04 <bjorkint0sh > to interpret lambda.
2026-08-25 23:49:11 <lisbeths    > INEED! its not going to be perofrmant is it?
2026-08-25 23:49:14 <bjorkint0sh > btw, the 'S' in SECD stands for Stack
2026-08-25 23:49:30 <lisbeths    > :)
2026-08-25 23:49:40 <lisbeths    > yeah secd is significantly more performant afaik
2026-08-25 23:49:45 <bjorkint0sh > https://dev.to/dimension-ai/never-heard-of-microcode-nope-us-neither-but-its-really-important-14j8
2026-08-25 23:49:59 <lisbeths    > thas the whole point of why I brought this up is to find the most performant smallest abstract machine for embedded environments
2026-08-25 23:50:14 <bjorkint0sh > https://en.wikipedia.org/wiki/SECD_machine
2026-08-25 23:50:39 <bjorkint0sh > lisbeths: you might be reviving decades forgotten research, or pioneering a new one.
2026-08-25 23:50:55 <xentrac     > bjorkint0sh: that article is AI slop
2026-08-25 23:50:56 <lisbeths    > this is nothing new
2026-08-25 23:51:17 <bjorkint0sh > xentrac: is it? it didn't look like it to me, but I'll find a better one.
2026-08-25 23:51:18 <lisbeths    > i am merely investigating into performant abstract machines for embedded environments for my own benefit
2026-08-25 23:51:36 <bjorkint0sh > xentrac: sorry about the AI;DR ...
2026-08-25 23:52:48 <xentrac     > bjorkint0sh: it's true that Intel and AMD still have "CPU microcode", but it doesn't play the role that microcode played on the Z80 or 8086 or System/360
2026-08-25 23:52:51 <xentrac     > Model 20
2026-08-25 23:53:14 <bjorkint0sh > lisbeths: the mere investigation is still valid research.
2026-08-25 23:53:15 <xentrac     > or, perhaps most relevantly, the Alto or Symbolics 3600
2026-08-25 23:53:39 <hello-operator> MUXLEQ https://github.com/sysprog21/muxleq adds a single instruction to SUBLEQ and is much faster than SUBLEQ, the implementation there also includes ways of speeding things up by recognizing common instruction blocks and replacing them
2026-08-25 23:54:19 <lisbeths    > this is another key point is that subleq has already been improved upon
2026-08-25 23:54:29 <bjorkint0sh > with what, a MOV machine?
2026-08-25 23:55:06 <xentrac     > bjorkint0sh: on those machines, microcode ran a lot faster than normal machine code simply because it didn't have to waste memory cycles on instruction fetches, and in some cases because it could do multiple operations per cycle, like the "side-set" bits in RP2040 PIO
2026-08-25 23:55:16 <xentrac     > but that isn't the case with current machines
2026-08-25 23:55:40 <xentrac     > lisbeths: "most performant, smallest" is two different virtues, and there are tradeoffs between them
2026-08-25 23:56:10 <hello-operator> I think that's the problem, a better specification for what you want (and why) is needed
2026-08-25 23:56:52 <xentrac     > something like SUBLEQ is probably close to the smallest, but even something like Wirth's "RISC" or Chifir or the Cult of the Bound Variable's UM32 is vastly more performant, and still something you can implement by hand in under an hour
2026-08-25 23:56:56 <lisbeths    > yeah obviously there are tradeoffs between size and performance
2026-08-25 23:57:14 <lisbeths    > indeed subleq is incredibly small that is one of the advantages I have selected for in subleq
2026-08-25 23:57:25 <lisbeths    > writing a subleq is incredibly easy
2026-08-25 23:57:27 <bjorkint0sh > lisbeths: are you familiar with Peter Kogge's Symbolic Computing book?
2026-08-25 23:57:39 <xentrac     > I think the key performance weak points of subleq are multiplication and bitwise operations
2026-08-25 23:58:13 <bjorkint0sh > it's described here, if not: https://www.loper-os.org/?p=13
2026-08-25 23:58:37 <bjorkint0sh > it talks about the SECD (for lambda calculus and lisp) and Warren's Abstract Machine (for Prolog)
2026-08-25 23:58:43 <xentrac     > like, if your CPU has a hardware multiplier, invoking the multiply instruction is likely to be at least two orders of magnitude faster than interpretively doing a multiplication with subtractions, maybe three
2026-08-25 23:59:15 <xentrac     > for bitwise operations like AND and right shift, the slowdown is almost as bad
2026-08-25 23:59:22 <bjorkint0sh > hmm. if a subleq machine existed, you'd have to synthesize all the common operations. wouldn't it make sense to synthesize and express the common ops in hardware?
2026-08-25 23:59:31 <hello-operator> Also right shifts are slow!
2026-08-25 23:59:33 <lisbeths    > so threses a quote from chuck moore where he once mused something like "you dont technically need subtraction. you can just use addition"
2026-08-25 23:59:42 <lisbeths    > similarly I never use the division operator when I code
2026-08-25 23:59:50 <xentrac     > well, you can use addition if you have bitwise NOT