Maybe a dumb question but does embeddable mean embeddable in web browsers? If so it would be awesome to include this in a web-based version of SICP.
Steel – An embeddable and extensible Scheme dialect
161–170 of 192 posts
Re: Steel – An embeddable and extensible Scheme dialect
#162Earlier quoted context omitted.
The bacon-rajan-cc link has only -implemented- a stop-the-world version, but notes right at the top of the README that it -can- be concurrent, and the stop-the-world-only-ness is only 'Currently.' https://trout.me.uk/gc/ has two Recycler papers if you want more details.
Samsara is implementing the same algorithm and seems to be further along. Though there's also 'shredder' https://github.com/Others/shredder with a different overall approach.
Ah, I see what you meant now. Thanks for mentioning Samsara, I shall try and remember it exists later today when I'm more caffeinated.
Re: Steel – An embeddable and extensible Scheme dialect
#163Earlier quoted context omitted.
As an evil user, this is potentially huge to me. Emacs happens to have the best balance of easy to setup configuration (relatively), powerful package ecosystem, and proper hackability of all editors I've found. It's not very fast though and has some conventions that feel archaic.
I'm also an Emacs evil user (neovim too). I think the kakoune editing model has the potential to surpass even the vim/evil model. Its default object-verb order makes it easy to preview and change selection before proceeding with the action. That's not possible with vim's normal mode. Vim does have the visual model. But then kakoune model also uses multiple cursors, making it more powerful. I really wanted to try kako…
> Sadly, multithreading is an afterthought for Emacs
It is, but it's usable. I'm actually amazed that, even after three major versions, the built-in threading is not used by the community.
Yes, the threads currently are not usable for number crunching in the background. And yes, there are bugs, and trying to do many things from the background thread doesn't work, sometimes in unexpected ways. You can still block the main thread from the background thread since some things block the event loop, no matter where they were started.
But, the threads do give you independent control flows. Whatever you cannot do in the background, you can offload to the main thread with a timer and a queue of lambdas.
The built-in threads are very, very bare-bones - it's around 15 functions, for threads, mutexes, and condition variables. They are very limited by their "mostly cooperative" nature. However, with a bit of sugar, they are usable for at least one thing: async processes and network communication.
In a background thread, you can "block" to wait for a child process to do something. It's natural and requires no macrology (async.el...). The same is true for network communication. You can block and wait for a response while the rest of Emacs does whatever. With just two functions, you can write code without blocking as if you used `call-process`. Sequential actions - call this, wait for it to finish, call that, wait for it to finish, etc. - can now be coded in a sequential way, without having to worry about callbacks, sentinels, and a poor-man FSM implementation that invariably appears in Elisp that doesn't use threads.
The threads built into Emacs, currently, are closer to green threads or coroutines, functionally, than to OS-level threads. But that's still a huge help in a bunch of important and pervasive scenarios. It's really strange that nobody seems to realize this.
With threads (as they are), the Continuation Passing Style compiler macro (in generator.el), and dynamic modules (for actual parallelism where needed) Emacs now has everything it needs to make it non-blocking by default. Of course, that would entail rewriting everything on top of these abstractions, so it's unrealistic - but for new code and packages? I think we're just one package (along the lines of dash, s, etc.) away from convenient concurrency and parallelism in Emacs. The problem, of course, is that someone needs to design and code that package...
Re: Steel – An embeddable and extensible Scheme dialect
#164Earlier quoted context omitted.
I saw your comment on the thread. A. Most WebAssembly implementations are bigger than Helix itself. B. WebAssembly is immature. C. Lisp is perfectly fine. Even if you don't like it, it's not the end of the world if you have to use it to configure Helix.
A. It's true that Wasmer is bigger, but even my phone has 16GB of RAM and 1TB of storage space. B. There are probably more computers running WebAssembly loads today than Lisp ones. C. Lisp is a mature language, almost too mature. I used it extensively in the '80s and it served me well then, but that was 40 years ago. At least have the decency to use a more modern language like Lua, which is what Neovim uses.
Lua is very weak for "programming in the large". It's just a little bit better than early JavaScript. Scripts are OK, but anything that requires more code with more structure requires incredible amounts of perseverance and discipline from all contributors. You can do fairly large programs in Lua as a small team of highly skilled hackers, but the barrier to entry will be much higher than if you did it in a language that offers ready-made abstractions.
I use AwesomeWM, which is basically Emacs of Window Managers, with Lua instead of Elisp. The code is very well written and documented, yet getting into it is much more complicated than if it was written in Python - even if that Python was written poorly.
Re: Steel – An embeddable and extensible Scheme dialect
#165Earlier quoted context omitted.
A-expressions are a choice, and it is fine to argue whether it is a good one. There are plenty of other ways of achieving honiconic syntax.
What's an A-expression? I tried looking it up but didn't find anything. I have heard of M-expressions but never of an actual implementation. Scheme also seems to have some SRFIs involving alternate syntax that's whitespace dependent, like SRFI 119 (wisp), SRFI 110 (sweet-expressions or T-expressions), or SRFI 49.
[deleted]
Re: Steel – An embeddable and extensible Scheme dialect
#166Earlier quoted context omitted.
As an evil user, this is potentially huge to me. Emacs happens to have the best balance of easy to setup configuration (relatively), powerful package ecosystem, and proper hackability of all editors I've found. It's not very fast though and has some conventions that feel archaic.
I'm also an Emacs evil user (neovim too). I think the kakoune editing model has the potential to surpass even the vim/evil model. Its default object-verb order makes it easy to preview and change selection before proceeding with the action. That's not possible with vim's normal mode. Vim does have the visual model. But then kakoune model also uses multiple cursors, making it more powerful. I really wanted to try kako…
I feel like the scheme transition could go better if it had been proposed today. The dev community is much larger and there seems to be more activity around this stuff today.
Case in point, the recent async updates, native compilation and more. They often leave something to be desired but are nevertheless huge upgrades.
Re: Steel – An embeddable and extensible Scheme dialect
#167Earlier quoted context omitted.
One option that might be suitable for a DSL, is implicit parens based on whitespace. A newline opens a new paren, and the paren closes when it reaches another line with the same indentation e.g: (defun factorial (x) (if (zerop x) 1 (* x (factorial (- x 1))))) could be rewritten as defun factorial (x) if (zerop x) 1 * x (factorial (- x 1))
Whitespace significance might be the choice even more controversial than Lisp parens. For myself, I appreciate both, but those that do not, really do not.
Probably there are more Python users out there than combined users of all lisp-like languages, which I guess would mean people are less scared of white-space significance than s-expressions :)
Re: Steel – An embeddable and extensible Scheme dialect
#168Earlier quoted context omitted.
I'm also an Emacs evil user (neovim too). I think the kakoune editing model has the potential to surpass even the vim/evil model. Its default object-verb order makes it easy to preview and change selection before proceeding with the action. That's not possible with vim's normal mode. Vim does have the visual model. But then kakoune model also uses multiple cursors, making it more powerful. I really wanted to try kako…
> Sadly, multithreading is an afterthought for Emacs It is, but it's usable. I'm actually amazed that, even after three major versions, the built-in threading is not used by the community. Yes, the threads currently are not usable for number crunching in the background. And yes, there are bugs, and trying to do many things from the background thread doesn't work, sometimes in unexpected ways. You can still block the…
> It is, but it's usable. I'm actually amazed that, even after three major versions, the built-in threading is not used by the community.
I'd say inertia. Emacs is large enough for people not to be aware of "simple" things, so the new threading primitives.. might take a few more years.
Re: Steel – An embeddable and extensible Scheme dialect
#169Earlier quoted context omitted.
So, if I use an editor config off the Internet, I need to inspect it for malware, because it's code, not configuration? Yes, there are languages for configuration - Jsonnet, Starlark, Dhall, which are execution safe - unlike Lisp and Lua!
FWIW, the plugin system is supposed to have sandboxing as well.
Scheme has sandboxing in the form of environments. You can evaluate[0] / load[1] untrusted code by applying an environment specifier[2] with all of the symbols you trust the code to use. For example, if you don't want the code to be able to use IO, simply don't add (scheme read) and (scheme write) to the environment that you eval / load the code with.
[0] https://index.scheme.org/filterset/r7rs_small/%28scheme%2520...
[1] https://index.scheme.org/filterset/r7rs_small/%28scheme%2520...
[2] https://index.scheme.org/filterset/r7rs_small/%28scheme%2520...
Re: Steel – An embeddable and extensible Scheme dialect
#170This is a surprise! Steel is my project, happy to answer any questions anyone might have
What are the immutable hash maps based on? How do you use functions or other maps as keys in them?