dharmatech 20 hours ago

I've been messing around with a language that I summarize as:

ALOE = Scheme + Smalltalk + Types

https://github.com/dharmatech/2026-09-02-aloe-racket

Prototype is in Racket.

  • attila-lendvai 16 hours ago

    you lost me at the receiver selector order.

    • Jtsummers 15 hours ago

      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:

        (my-account 'balance)
  (my-account 'withdraw 10)
      • so-cal-schemer 15 hours ago

        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:

          (define (make-account balance)
    (define (withdraw amount)
      (if (>= balance amount)
          (begin (set! balance 
                       (- balance amount))
                 balance)
          "Insufficient funds"))
    (define (deposit amount)
      (set! balance (+ balance amount))
      balance)
    (define (dispatch m)
      (cond ((eq? m 'withdraw) withdraw)
            ((eq? m 'deposit) deposit)
            (else (error "Unknown request: 
                   MAKE-ACCOUNT" m))))
    dispatch)

        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.

        3.1.1 Local State Variables

        https://sarabander.github.io/sicp/html/3_002e1.xhtml#g_t3_00...

  • mike_ivanov 16 hours ago

    Cool project, thank you for sharing. I've been thinking about something similar lately.

    However. "Send, not apply" - sigh.. how shall I put it.. let's try this - eyes_rolling_so_hard_they_fall_out_of_sockets.png

  • sroerick 7 hours ago

    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.

    • dharmatech 1 hour ago

      Very interesting! Nice to see the postgresql store.

      Thank you!

  • bjoli 3 hours ago

    I used ai liberally to write an s-expr language that compiles to c#.

    https://bjolang.koketteriet.se/

    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.

    • dharmatech 1 hour ago

      This is cool! Thank you! I'm a fan of C# and dotnet. Nice that you used F#!

      • bjoli 45 minutes ago

        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.