2026-08-24 09:42:35 <lisbeths    > so previously I have been studying the connection between sectorlisp, sectorlambda (which is lambda calculus), and sector forth, that all fit into a boot sector
2026-08-24 09:43:28 <lisbeths    > well lately I have discovered that subleq and subleq+ are significantly more performant than lambda calculus, yet still offer a very minimal abstract machine
2026-08-24 09:44:45 <lisbeths    > the cost of an abstract machine is a loss of realtime performance, and a loss of general performance. the benefit is that if an abstract machine is written identically on two machines, those machines are guaranateed to compute the same results for the same input programs regardless of hardware spec
2026-08-24 16:10:59 <nmz-        > lisbeths: do you know haskell?
2026-08-24 16:12:05 <nmz-        > lisbeths: when haskell compiles, it compiles to lambda calculus, does a reduce algorithm, and then converts to c- which then compiles to your machine
2026-08-24 16:12:16 <nmz-        > completely portable
2026-08-24 16:14:57 <lisbeths    > so haskell doesnt exactly compile to pure lambdas afaik
2026-08-24 16:15:05 <lisbeths    > although it is purely functional
2026-08-24 16:15:10 <bjorkintosh > _nothing_ does.
2026-08-24 16:15:17 <lisbeths    > eh fastlisp does
2026-08-24 16:15:27 <bjorkintosh > and what runs your lambdas?
2026-08-24 16:15:34 <lisbeths    > a lambda calculus interpreter
2026-08-24 16:15:38 <bjorkintosh > lambdas all the way down?
2026-08-24 16:15:44 <lisbeths    > certainly not
2026-08-24 16:15:52 <lisbeths    > but haskell doesnt currently run on a pure lambda calculus interpreter either
2026-08-24 16:16:08 <nmz-        > the point is, the cost of losing performance can be ameliorated, even optimized
2026-08-24 16:16:09 <lisbeths    > you would encounter significant performance drops if you ran haskell entirely in one big lambda
2026-08-24 16:16:24 <lisbeths    > yes you can optimize a lambda calculus interpeter
2026-08-24 16:17:06 <nmz-        > a forth penalty is that each call is abstract, it can be inlined, but AFAIK inlining cannot be automated, using lambda > c- means inlining is possible
2026-08-24 16:17:40 <nmz-        > is auto...matatatatatable?
2026-08-24 16:17:46 <lisbeths    > I mean if you have a strategy to in a minimal way optimize lambda calculus to be more performant than subleq pls tell me how you would do that because that would be amazing
2026-08-24 16:18:00 <nmz-        > I don't, but haskell does
2026-08-24 16:18:32 <lisbeths    > yes they likely do, and it still would not be as performant as a version of haskell running on the haskell core
2026-08-24 16:18:41 <bjorkintosh > nmz-: you, like haskell??
2026-08-24 16:19:03 <nmz-        > I do not
2026-08-24 16:19:14 <bjorkintosh > why's that?
2026-08-24 16:19:30 <nmz-        > I just listened to an interview with explanations to the arquitecture
2026-08-24 16:20:11 <lisbeths    > ok please link me to the interview and I will ask #haskell about it
2026-08-24 16:20:26 <nmz-        > and was surprised on how they do optimization, apparently, they've always used this lambda calculus > c- pipeline
2026-08-24 16:21:06 <bjorkintosh > nmz-: I don't know much about that. they call the abstract machine lambda? or is it a different name?
2026-08-24 16:21:59 <nmz-        > https://www.youtube.com/watch?v=xcB_LF3cdqw
2026-08-24 16:24:41 <nmz-        > its 1:30:00, its a good interview and I for one learned a lot
2026-08-24 16:24:48 <nmz-        > 
ACTION goes and brews a coffee

2026-08-24 16:25:06 <bjorkintosh > nmz-: how are you brewing said coffee?
2026-08-24 16:25:34 <nmz-        > ha
2026-08-24 16:26:49 <bjorkintosh > https://aosabook.org/en/v2/ghc.html The Glasgow Haskell Compiler
2026-08-24 16:29:41 <lisbeths    > core is a tiny principled lambda calculus
2026-08-24 16:29:54 <lisbeths    > "In contrast Core is a tiny, principled, lambda calculus. It has extremely few syntactic forms, yet we can translate all of Haskell into Core."
2026-08-24 16:30:08 <lisbeths    > you were correct
2026-08-24 16:30:10 <lisbeths    > my mistake
2026-08-24 16:30:33 <lisbeths    > I had previously asked this question to the #haskell community several years ago and they had seemed to have given me a different answer
2026-08-24 16:33:10 <lisbeths    > that being said my belief is that the core ultimately emits c code, machine code, and/or llvm code
2026-08-24 16:33:16 <lisbeths    > thats similarly to how fastlisp works
2026-08-24 16:33:38 <nmz-        > it doesn't
2026-08-24 16:33:41 <nmz-        > it emits c- code
2026-08-24 16:33:54 <lisbeths    > https://aosabook.org/static/ghc/hscpipe2.png
2026-08-24 16:34:05 <lisbeths    > this architecture diagram eems to say that it can also emit machine code or llvm code
2026-08-24 16:34:10 <nmz-        > although maybe c- goes to c and then llvm or whatever
2026-08-24 16:34:23 <lisbeths    > I think what the diagram is saying is theres multiple targets
2026-08-24 16:35:37 <nmz-        > ah, you're right
2026-08-24 16:35:43 <bjorkintosh > ah I see. c-- is _not_ c. https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/cmm
2026-08-24 16:35:56 <nmz-        > ultimately is C
2026-08-24 16:36:03 <nmz-        > because nobody can replace llvm I guess
2026-08-24 16:36:13 <nmz-        > well, the zig guys are, but they're crazy
2026-08-24 16:36:25 <bjorkintosh > https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/cmm-type
2026-08-24 16:36:44 <lisbeths    > I think before the lambda calculus core has emitted c, that the compiletime computations will take a performance hit
2026-08-24 16:36:50 <lisbeths    > though maybe I will be surprised again
2026-08-24 16:37:17 <bjorkintosh > nmz-: what do you mean, are there not other back ends besides LLVM?
2026-08-24 16:38:09 <lisbeths    > in high level programming like in the cloud it is very difficult to remove the dependency of llvm from many projects, which hurts those projects because it is a massive compiler toolchain
2026-08-24 16:39:02 <bjorkintosh > GCC is dead or dying I'm guessing?
2026-08-24 16:39:27 <lisbeths    > the growing disdain for gcc is one of the reasons
2026-08-24 16:39:42 <lisbeths    > but there are a multitude of reasons why someone might target llvm
2026-08-24 16:39:54 <bjorkintosh > namely?
2026-08-24 16:40:05 <lisbeths    > there are many such examples. for example...
2026-08-24 16:40:25 <lisbeths    > there are many severless compute architectures in the cloud that run webassembly like in the browser/client rather than running a posix container
2026-08-24 16:40:35 <lisbeths    > so for these types of environments targeting llvm is necessary
2026-08-24 16:41:22 <lisbeths    > another reason is that there are some advanced compilation tools (which I do not know the names of) that llvm has that gcc does not yet have, and so for certain types of compilers they desire a mature piece of software with those tools
2026-08-24 16:41:35 <lisbeths    > still other people do not prefer gcc because of its license (which I think is illogical)
2026-08-24 16:41:42 <lisbeths    > many such reasons
2026-08-24 16:42:09 <lisbeths    > sometimes your company might insist you target llvm for some applications
2026-08-24 16:49:15 <lisbeths    > anyway I've asked the #haskell people how performant their lambda calculus core is, and theyve seemed to at first respond by saying something along the lines of, "the core emits fast c"
2026-08-24 17:00:09 <lisbeths    > ski: "what is the performance like of the core itself compared to compiled haskell" -- this makes no sense. Core is an intermediate step, in the compilation process, in GHC
2026-08-24 17:36:52 <xentrac     > that isn't a helpful response
2026-08-24 17:37:20 <xentrac     > maybe the shootout has a better answer for you; does it still feature Haskell?
2026-08-24 17:39:22 <xentrac     > https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/clang-ghc.html
2026-08-24 17:40:07 <lisbeths    > so there is some nuance as to whether ghc "is" lambda calculus
2026-08-24 17:40:12 <lisbeths    > we are still debating it in #haskell
2026-08-24 17:40:23 <lisbeths    > all they have told me is that it "is" a lambda calculus that is fast when it emits c
2026-08-24 17:41:31 <xentrac     > my summary: typically 3-7x slower than C, but sometimes not slower
2026-08-24 17:42:01 <lisbeths    > so what we are trying to determine is which is a faster abstract machine: lambda calculus, or subleq
2026-08-24 17:42:13 <lisbeths    > and somoene responded by saying that ghc is lambda calculus and ghc beats subleq
2026-08-24 17:42:21 <lisbeths    > ture however I believe ghc does that by emitting c or machine code
2026-08-24 17:45:53 <xentrac     > probably if you have to use something in the spirit of Church numerals the lambda calculus will be slower if you're implementing it on a real CPU
2026-08-24 17:46:33 <xentrac     > because the CPU has bit-parallel 32-bit or 64-bit adders that subleq takes advantage of and lambda-calculus doesn't
2026-08-24 17:46:39 <xentrac     > but GHC does
2026-08-24 17:57:18 <nmz-        > lisbeths: did you listen to it?
2026-08-24 17:58:36 <lisbeths    > which thing?
2026-08-24 17:58:48 <nmz-        > ...
2026-08-24 17:58:50 <nmz-        > :(
2026-08-24 17:59:03 <lisbeths    > thats not very effective communication nmz- just state what you want
2026-08-24 17:59:05 <lisbeths    > I am multitasking
2026-08-24 17:59:08 <nmz-        > the interview
2026-08-24 17:59:15 <bjorkintosh > lisbeths: https://www.youtube.com/watch?v=xcB_LF3cdqw
2026-08-24 17:59:23 <lisbeths    > sorry im reading this rn https://existentialtype.wordpress.com/2011/03/16/languages-and-machines/
2026-08-24 17:59:56 <xentrac     > nmz-: what interview?  we weren't talking about an interview
2026-08-24 18:00:07 <bjorkintosh > xentrac: ^
2026-08-24 18:00:33 <bjorkintosh > it's an interview with Simon "Haskell is Useless" P-J.
2026-08-24 18:01:05 <xentrac     > aha
2026-08-24 18:01:22 <xentrac     > anyway GHC is in the ballpark of Forth, and subleq is much slower
2026-08-24 18:02:06 <xentrac     > because GHC can take advantage of specialized hardware for things like *not* indirecting through pointers and *not* taking conditional branches.  also multiplication and bitwise operations
2026-08-24 18:06:34 <lisbeths    > ghc is in the ballpark of forth *if* it emits c or machine code or llvm
2026-08-24 18:16:22 <bjorkintosh > only thing lower than subleq is likely machine code.
2026-08-24 18:18:26 <lisbeths    > so in #haskell they have talked about some techniques to make lambda calculus more performant than subleq
2026-08-24 18:18:41 <lisbeths    > but what I am still working out is if ghc is the same thing as what lambda calculus is
2026-08-24 18:18:58 <lisbeths    > watching that talk now, nmz-
2026-08-24 18:20:05 <bjorkintosh > lisbeths: it's can't be.
2026-08-24 18:20:41 <lisbeths    > hmm?
2026-08-24 18:24:46 <bjorkintosh > lambda calculus is a tiny mathematical abstraction, whereas ghc is a compiler! how can they be the same?
2026-08-24 18:47:44 <lisbeths    > that is my precise point
2026-08-24 18:47:56 <lisbeths    > I am speaking of purely abstract machines
2026-08-24 18:48:15 <lisbeths    > not only purely abstract machines but purely abstract machines measured in kilobytes
2026-08-24 19:07:26 <lisbeths    > so it seems like the fastest most minimal way to compute lambda calculus in something like forth is called combinatorial graph reduction
2026-08-24 19:07:55 <lisbeths    > and it seems the cost of reducing a lambda calculus expression can be measured by the number of reductions it takes to reach a beta normal form given the reduction scheme you choose
2026-08-24 19:08:08 <bjorkintosh > lisbeths: why not a reverse polish lambda calculus?
2026-08-24 19:08:15 <lisbeths    > sure :)
2026-08-24 19:08:27 <lisbeths    > I think stanford is working on that
2026-08-24 19:08:43 <bjorkintosh > (or lisbeth)
2026-08-24 19:08:48 <bjorkintosh > stanford is a large organization.
2026-08-24 19:08:54 <lisbeths    > no i mean stanford is really working on that in some department
2026-08-24 19:09:00 <lisbeths    > let me find you the talk
2026-08-24 19:09:12 <bjorkintosh > lisbeth is a single, fast, nimble individual capable of converting food to lambda calculus
2026-08-24 19:10:21 <lisbeths    > so this student was studying concatenative combinators at stanford 8 years ago https://www.youtube.com/watch?v=_IgqJr8jG8M
2026-08-24 19:10:36 <lisbeths    > I dont know how that related to what stanford was doing at the time