scrapscript.py

They can definitely claim the above points and more are not goals, and Evan absolutely has every right to do so. But don’t be surprised when devs see it as dead.

Certainly that describes me, and when all the people who seemed to be like me got told to go sit on a cactus by the Elm core developers and bailed out to work with something else, my experiments got pretty much immediately shelved and Elm moved into the "interesting place to steal ideas from, actively hostile to my actually using it" category.

This may be unfair, but I'm pretty sure it's a reasonable description of what -did- happen, fair or not.

helloWorld : '{IO, Exception} () helloWorld _ = printLine "Hello World"

The example above is followed by explanation "{IO, Exception} indicates which abilities the program needs to do I/O and throw exceptions." Well, which abilities does it need then? No idea.

edit: not memoization, just hashing the AST of a function.

Modules and libraries are addressable based on their names or URI:s.

"Unison eliminates name conflicts. Many dependency conflicts are caused by different versions of a library "competing" for the same names. Unison references defintions by hash, not by name, and multiple versions of the same library can be used within a project." https://www.unison-lang.org/docs/what-problems-does-unison-s...

"Here's the big idea behind Unison, which we'll explain along with some of its benefits:

Each Unison definition is identified by a hash of its syntax tree.

Put another way, Unison code iscontent-addressed. Here's an example, the increment function on Nat:

increment : Nat -> Nat increment n = n + 1

While we've given this function a human-readable name (and the function Nat.+ also has a human-readable name), names are just separately stored metadata that don't affect the function's hash. The syntax tree of increment that Unison hashes looks something like:

increment = (#arg1 -> #a8s6df921a8 #arg1 1)

Unison uses 512-bit SHA3 hashes, which have unimaginably small chances of collision.

If we generated one million unique Unison definitions every second, we should expect our first hash collision after roughly 100 quadrillion years! " https://www.unison-lang.org/docs/the-big-idea/

I think scrapscript is a really interesting idea, mind, this isn't a "here's an alternative" type comment, it's a "here's things that I think are neat in a similar way to how I think scrapscript is neat" :)

Edit: I forgot something! https://trout.me.uk/lisp/termite-r7rs.pdf is a paper on adding library support to the cross-network (kinda erlangish) termite scheme extensions - and leans heavily on content addressable-ness. Termite itself has gone the way of small lisp projects but I kept this around specifically for the content addressable stuff having been solidly worked out in a language I understood; maybe that'll come in handy for ideas for you as well.

What does this mean? You hash dependencies?

> (3) a compiler that checks live servers for compatibility before deploying,

Why does a compiler need to talk to a server? Why should it? Seems like a huge step backwards in what a compiler is and expecting it to work later on.

I feel your pain on having to manage so many dependencies. I write primarily in Python, and the various pip / Pipenv / pipx / PDM / Poetry dependency managers drive me pretty crazy. That's not even accounting for the multiple Python versions I need!

That said, I'm surprised that you're trying to _alleviate_ this by implementing your FP language in Python. The Python ecosystem is full of half-documented config files, incompatible dependency trees, etc.

Have you considered implementing it in any other languages after the Python one proves its worth? For example, if the language becomes strong enough, would you consider writing a scrapscript compiler in scrapscript, itself?