Live data from Hacker News

Scrapscript: A functional, content-addressable programming language

github.com

41–43 of 43 posts

Re: Scrapscript: A functional, content-addressable programming language

#41

Hi! It's me, I'm one of the interpreter and compiler authors. Happy to answer questions

Hello! This project looks very interesting. How would you compare it to Dhall, which seems to have similar aims? Is scrapscript Turing complete, or are there totality guarantees?

https://dhall-lang.org/

Re: Scrapscript: A functional, content-addressable programming language

#42
post #33

I am interested in this as a replacement for bash scripts The killer feature would be pulling in other scripts as libraries (they may be published anywhere) but I can lock down the hash of these dependencies inside of my script file. Is this possible?

FWIW we can do this* with bash in the nix ecosystem (not that this knowledge should deter you from checking out scrapscript). * you said locking the hash in the script, and in the nix approach these are generally locked in either a lockfile or in the nix expression. Can elaborate if you're curious.

Multiple files adds just a tiny bit of friction when moving things around, putting on Gist, sending on Slack, etc.

I would love for the Nix lock to somehow be embedded in the script.

Re: Scrapscript: A functional, content-addressable programming language

#43
post #33

Earlier quoted context omitted.

FWIW we can do this* with bash in the nix ecosystem (not that this knowledge should deter you from checking out scrapscript). * you said locking the hash in the script, and in the nix approach these are generally locked in either a lockfile or in the nix expression. Can elaborate if you're curious.

Multiple files adds just a tiny bit of friction when moving things around, putting on Gist, sending on Slack, etc. I would love for the Nix lock to somehow be embedded in the script.

You can inline the script within nix and get them all in one file (but that implies buy-in on nix, or maintaining 2 copies of the script).

At the risk of overstepping (it sounds like you might be a little interested) here are a few links in to some basics just-in-case.

For context, I extracted my bashrc into its own repo, and it in turn sources bash libraries for my shell history and git status plugins. It's also leaning on some libraries that are pulled in through those two. (To be clear, this is just a general example of the flake pattern with a separate lockfile. I can find or synthesize something with the inline script pattern if you ask.)

- Source statements: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...

- Nix expression responsible for resolving and ~linking these two dependencies in to the final script: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...

- Flake inputs for the two dependencies. Note that these can be specified as just the repo or a branch and updated by updating the lock through Nix, or they can be ~pinned to a specific rev: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...

- A gist with examples of the entire chain of scripts that get resolved together here: https://gist.github.com/abathur/09f06f1f34b003376017d7a5c031...

These all get handled separately, so they can technically have divergent implementations of the same external command (for example, one library could depend on libressl and one could depend on openssl--and each resolved library would independently point to the correct one.

Post reply on HN