> cost $2,995 for binaries or $14,995 for sources

My goodness, this is hard to imagine from today when open source has driven the price of software (code itself) to nil. And that's the price from decades ago. While I'm glad I don't have to pay 15K for a C to PostScript compiler, as someone who might have written similar software if I'd lived back in those days - I can imagine an alternate timeline where I'd be getting paid to write such tools instead of doing it as a hobby project.

> NeScheme.txt

Nice rabbit hole about LispScript, what a cool idea. I've been re-studying Scheme recently, its history and variants like s7, and was appreciating its elegance and smallness as a language, how relevant it still is. One of the books I'm reading uses Scheme for algorithmic music composition. (Notes from the Metalevel: An Introduction to Computer Composition)

> make it a native library that can compile to the web (using actual DOM/HTML elements there, not canvas/WebGL/WGPU)

How interesting to hear. I've been exploring a way to write cross-platform GUI apps in C, using the Sokol library and possibly DearImgui. It's very convenient how it can build to WebAssembly and run the same way as the native app. But for larger canvas sizes it does eat more processing power, more than a typical website, and I was considering using DOM elements instead of canvas.

Good point about better accessibility too, and leveraging the feature set of modern web browsers.

A cross-platform GUI library that works with native and the web, so that the same application can be built for these targets with minimal changes. With the maturity and adoption of Wasm, I expect we'll see growing development in this direction. And some people have cautioned that treating the web as a blob of canvas and compile target to deploy opaque binaries is a step back from the potential of the web, like seeing the source (or source map at least), consistent handling of text, scrolling, accessibility features.

So I like your idea to "flip the script", I think in my own way I'm finding a similar approach.

It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library.

Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and even fundamental changes in design. I think community input and feedback can be particularly valuable at this stage.

I've realized that Zig is a language, in which people can write programs in vastly different styles. And these are not really compatible. This is not unlike C++, for example. I learned Zig in my own bubble, just using my previous programming knowledge, not relaying on existing Zig code much. If I saw Zig's own code at the early stages, I'd probably not pick the language, purely on the style of huge inlined switches and nested conditions all over the place.

Hogwash. False dualism is a sign of a lazy mind.

The spelling of the word is amanuensis. To help remember, it's based on "manus" meaning “hand”.

Duh

I should have checked before writing it. :-/

Also: not open source, not running on my machine.

Turning in the widening gyre, the falcon cannot hear the falconer. The center cannot hold.. The old prophecy is coming true.

I rather like "libz".

Not to be confused with zlib.

Prompts are cheap. Show me the spark of consciousness that brings the whole thing to life, that which makes all of it worthwhile and meaningful.

The project looks great! I browsed the codebase and enjoyed how much documentation there is about the user-facing and internal workings. I'm not familiar with the subject matter but I do love me a DSL, so the language design aspect was interesting to learn about.

I was curious how the language compiles to C, what the resulting code does, and how one interacts with it. It took a while of reading to find it, so maybe this could be linked from places where compilation is mentioned. This part is my favorite, it's cool how it works. Especially since you mention "anti-abstraction", I like seeing how the DSL maps to C.

https://github.com/rafa-rrayes/SHDL/blob/master/docs/docs/ar...

> Compiles circuits to C so that they can run anywhere

Input (Base SHDL):

  component Buffer(A) -> (B) { 
      n1: NOT; 
      n2: NOT;

      connect { 
          A -> n1.A; 
          n1.O -> n2.A; 
          n2.O -> B; 
      } 
  }

Output (C code):

  #include <stdint.h>
  #include <string.h>

  typedef struct {
      uint64_t NOT_O_0;
  } State;

  static inline State tick(State s, uint64_t A) {
      State n = s;
      
      // NOT gate inputs
      uint64_t NOT_0_A = 0ull;
      NOT_0_A |= ((uint64_t)-( (A & 1u) )) & 0x1ull;
      NOT_0_A |= ((uint64_t)-( ((s.NOT_O_0 >> 0) & 1u) )) & 0x2ull;
      
      // Evaluate NOT gates
      n.NOT_O_0 = (~NOT_0_A) & 0x3ull;  // 2 active lanes
      
      return n;
  }

  static inline uint64_t extract_B(const State *s) {
      return (s->NOT_O_0 >> 1) & 1ull;  // B from lane 1
  }

  ...

Thank you so much for taking the time to dig into the code and docs, it means so much to me!

Here’s the core idea behind how SHDL compiles to C.

At compile time, SHDL groups all gates of the same typea together and packs them into uint64_t bitfields. Each individual gate occupies exactly one bit. If there are more than 64 gates of a given type, multiple uint64_t's are used.

So for example, if a circuit contains: 36 XOR gates - 82 AND gates - 1 NOT gate

The compiler will generate: 1 uint64_t for XOR (36 bits used, rest unused) - 2 uint64_t's for AND (64 + 18 bits) - 1 uint64_t for NOT

Each of these integers represents the state of all gates of that type at once.

The generated C code then works lane-wise: during `tick()`, it computes the inputs for all gates of a given type simultaneously using bitwise operations, and then evaluates them in parallel. Because everything is packed, a single ~, &, |, or ^ operates on up to 64 gates at once.

So instead of iterating gate-by-gate, the simulation step becomes something like: build input bitmasks - apply one bitwise operation per gate type - write the result back into the packed state

In other words, a full simulation step can advance dozens or hundreds of gates using just a handful of native CPU instructions. That’s the main reason the generated C code is both simple and fast.

This also ties directly into the “anti-abstraction” idea sunce there’s no hidden scheduler, no opaque simulator loop, and no dynamic dispatch. The DSL maps very explicitly to bit-level operations in C, and you can see exactly how a logical structure becomes executable code.

The final result is a compiled C shared library, which we can interact from using python (or anything else if you want to build it)

I really appreciate you calling this out. Do you think I should make it clearer in the docs? Thanks again for the comment!

Very cool, I enjoyed the explanation about how bitwise operations are built up to work on a set of gates all at once. I was browsing more of the codebase, it's really well-organized and commented code. I like how SHDL is readable for beginners, the examples are all intuitive and self-explanatory.

As another commenter mentioned, integrating visual diagrams would add an interesting dimension. I saw some manually written ASCII diagrams on the documentation site, and could imagine a way to convert SHDL into diagrams. And a step further, a code playground to write and run SHDL circuits, to be able to see the circuits work visually.

For educational purposes, the docs could use more visual descriptions, like starting with the simplest circuits and show step by step what happens.