ecto

Readers may enjoy my lisp, Loon, which takes heavy inspiration from Rust https://loonlang.com/guide/ownership

author here - the demos in the article are actually the Rust code compiled to WASM and running in your browser :)

Here's my take on CAD in the browser! https://vcad.io

I implemented a full kernel in rust and compile it to wasm https://github.com/ecto/vcad

<3

Thanks for the bug report! I'll have some time later this week to look into it. Just had a baby :)

Simply expand the observation vector!

No dude

Fantastic question :) one could extrapolate the possibility space here to see the potential. The interesting core here is the emergent behavior clearly visible in the vizs - what happens when you measure this in higher-dimensional and more connected networks? (What if it’s not noids?) I think this is underexplored in interpretability today

gpu

ok

Thanks, which of my pre-AI blog posts are your favorite?

Thanks for the feedback!

Awesome idea!

Thanks!

Are you not entertained?

Thanks for the feedback :~)

Thanks for the feedback, I flipped the two sections.

Sorry about your mouth!

Thanks I fucked that up! Updated to make the distinction clearer

What happens when you want to simulate millions of rules?

What if they weren't noids?

Thanks for the feedback :)

Please check out home.phyz.dev if you want to contribute!

hey author here, happy to answer any questions!

thanks for the kind words :)

You're right, ownership and effects are the real differentiators. The idea here is to let the compiler discover ownership rather than it being declared imperatively

Regarding algebraic effects, Loon uses continuations similar to Koka but more restrictive. Effects are declared with operations, and every side effect (IO, failure, async, state) is an effect that propagates through the call graph. The interesting part is `handle`, which lets you intercept effects:

  [handle [load-config "app.toml"]
    [IO.read-file path] [resume "mock contents"]
    [Fail.fail msg]     "default"]

Handling an effect subtracts it from the function's effect setso a function that handles all its IO internally is pure from the outside. This replaces exceptions, async/await, DI, and mocking with one mechanism. Testing is just handling effects with test data

Multi-arity: get lost! fork me?

<3

good questions

1. effects are tracked in the type system as row types, so they compose with HM inference pretty naturally. the tricky part is effect polymorphism. Loon handles that similarly to how koka does it, with row polymorphism. no ambiguity issues so far but idk

2. yes, macros are hygienic! documenting some binding situations would make a great first PR :)

3. easier to type!

exactly! I didn't post this (thank u whoever did though) so wasn't ready to launch yet. but the idea is it will SSR and hydrate each page. I want to pull it all out into a framework congruent to Next.js

hey thank you, should all be fixed now!

thank you <3 I will fix asap

loon is a lisp! https://github.com/ecto/loon

  [type Shape
    [Circle Float]
    [Rect Float Float]]
  
  [fn area [s]
    [match s
      [Circle r]  => [* 3.14 r r]
      [Rect w h]  => [* w h]]]
  
  [area [Circle 5.0]]

My dad taught me how to code with Borland C++ Builder, and I'm forever grateful.