Yo! this is cool. I've been doing an interpreted lisp written in OCaml. pricklypear.rocks. https://github.com/sroerick/pricklypear . we are doing cactus driven development. I'll reach out. Would love to compare notes.
It uses local HM inference and traits instead of OO, and the concurrency is based on concurrentML. The design process was mostly about what I dont like about other languages and what I think racket and OCaml does correctly. All default data structures are immutable (using an RRB tree, a champ, b+trees and linked lists) with pretty fast implementations.
Speed wise it is about the same as c# without spans and ref structs, since that is what it compiles to.
Every function that touches IO is compiles in a sync and async variant, so writing "bjoroutines" is most of the time the same as writing regular code.
The GitHub page is borked, since they removed Org mode support a day ago, but the manual and reference can be found on the web page.
Thank you. The only thing I really miss in c#/dotnet are delimited continuations. That would have made it possible to have proper effect handlers (now they are only tail resumptive, meaning it can only mock things like file system access and so on) and remove colour from the language entirely.
The colour situation is ok, but us still a bit rough wrt higher order functions.
I am not around the MSFT Partner CDs with the .NET Framework 1.0 release, however I remember there was a Scheme compiler as part of the original samples.
I am curious how. I thought quite a lot about targeting MSIL, but i found no way of copying, capturing or slicing the call stack. Nor is it possible to reify even the whole stack as a first class object.
For delimited continuations I only managed to find mostly extremely inefficient ways of doing it. CPS transformations on dotnet are, at least if kept to be useful as delcc, slow as molasses.
Which is ultimately why I chose to compile to c# to use asyncmethodbuilder do do the state machine translation for me.
In many ways I feel I should have targetted OCaml instead, since I would have gotten a full effect handler system and delimited continuations for free.
Now I am generating two bodies for every defun that touches any suspending function, using asyncmethodbuilder, meaning I don't get any of the runtimeasync benefits coming in dotnet11.
Hopefully they'll give us a new asyncmethodbuilder that is somewhat more constrained but guarantees runtime async.
It's a common way to implement OO in Lisp-y languages, and it fits if you're taking Smalltalk as an inspiration. SICP has an example in chapter 3 (IIRC) of doing the same, but the selector had to be quoted as in:
Uses an internal lambda for dispatching on messages.
We can also create objects that handle deposits as well as withdrawals, and thus we can represent simple bank accounts. Here is a procedure that returns a “bank-account object” with a specified initial balance:
Each call to make-account sets up an environment with a local state variable balance. Within this environment, make-account defines procedures deposit and withdraw that access balance and an additional procedure dispatch that takes a “message” as input and returns one of the two local procedures. The dispatch procedure itself is returned as the value that represents the bank-account object. This is precisely the message-passing style of programming that we saw in 2.4.3, although here we are using it in conjunction with the ability to modify local variables.
Closures indeed! A key concept of Scheme that distinguished it from most Lisps at the time:
(LAMBDA ( <identifier list> ) <body> )
Lambda-expressions evaluate to procedures. Unlike most LISP systems, SCHEME does not consider a lambda-expression (an s-expression whose car is the atom LAMBDA) to be a procedure. A lambda-expression only evaluates to a procedure. A lambda-expression should be thought of as a partial description of a procedure; a procedure and a description of it are conceptually distinct objects. A lambda-expression must be “closed” (associated with an environment) to produce a procedure object. Evaluation of a lambda-expression performs such a closure operation.
The resulting procedure takes as many arguments as there are identifiers in the identifier list of the lambda-expression. When the procedure is eventually invoked, the intuitive effect is that the evaluation of the procedure call is equivalent to the evaluation of the <body> in an environment consisting of (a) the environment in which the lambda-expression had been evaluated to produce the procedure, plus (b) the pairing of the identifiers of the <identifier list> with the arguments supplied to the procedure. The pairings (b) take precedence over the environment (a), and to prevent confusion no identifier may appear twice in the <identifier list>. The net effect is to implement ALGOL-style lexical scoping [Naur], and to “solve the funarg problem” [Moses].
Thank you for checking it out! Fair warning, it's vibeslop and I really don't have a clue what I'm doing. I have very little background in compilers or FP or really anything. I'm honestly just shocked at how well it works.
If you want to kick the tires on it or even if you just find it interesting, please feel free to reach out! I'm kind of obsessed with this thing now, and would love and appreciate any feedback
Histamine has different pools, functions, and receptors in the body. You’re reducing it all to one single level that goes up or down with diet but that’s not how it works.
The brain histamine in your neurons is primarily synthesized from an amino acid. The histamine levels in neurons are different than the levels in mast cells.
There are a lot of degrees of hand waving in your theory that don’t work.
I definitely haven't looked into the underlying models of histamine to see how things work.
My observation is that, when I avoid histamine related foods, I sleep longer and fall asleep faster. The naive model is what led me to try that. But I totally acknowledge that there's likely way more at play under the hood. And I would like to know more about why this works! Or, at least why it works for me.
Thank you for pointing out the complexity of the underlying mechanism.
Were you using IBM Visual Age Smalltalk?