A New R6RS Scheme Compiler
weinholt.se
weinholt.se
It's a language family, or even philosophy, rather than a single language.
So the theory now is that you can write a smaller R7RS-small compliant scheme, and do all your language experimentation in that, and someone else could come along and bootstrap that into a fairly useful large implementation without a ton of effort, and modules you write on that scheme could then be reused on other implementations.
1. R7RS explicitly decided to repudiate R6RS, leading to the disagreement.
2. R6RS made changes that did not have consensus and the resulting vote didn't have a big enough super majority requirement, leading to a controversial standard.
3. There was always major disagreement about all the relevant points, and R5RS itself was only created by not introducing anything new post 1992, and by not taking a position on the controversial topics. So any standard effort was bound to be controversial.
Back when I was a regular Scheme user Racket had by far the biggest ecosystem and community, so it would be my suggestion if you're interested in exploring Scheme.
Have you tried Rebol/Red?
Here's small shell dialect I made while learning it: https://gitlab.com/maxvel/red-shell-dialect/blob/master/shel...
So you can do things like
shell/run [cat %/etc/passwd | grep {root} > myvar]
Also the language itself heavily utilizes this (called Parse dialog) for example they don't have regular expressions at all, JSON is parsed using it as well, GUI system is a fully separate dialog and so on.
Concept of a dialect (aka 'embedded DSL') is not tied to Parse - you can implement one with it for sure, but it's not a strict requirement.
Rebol is really nice with a lot of built-in primitives that make it super useful although Rebol is kind of dead now (some users exist, but no new versions in a while). Red is being worked on and if it ever reaches 1.0 could be a game changer.
I think it is pretty easy to build little DSLs, but I don't think macros are super easy unless I'm mistaken. If somebody could shed some light for me I'd appreciate it.
As for Red / Rebol vs. Racket content - I wrote an excessive post on that some time ago [3], in response to similar question.
TL;DR from language creation perspective is that Racket has state-of-the-art macro system and all the necessary infrastructure, and Red has metaDSL (that is, DSL for creating DSLs) called Parse [4], which is basically PEG on steroids (think OMeta) + a different take on homoiconicity, compared to Lisps, which, most of the time, renders custom readers and tokenizers unnecessary.
[1]: https://www.red-lang.org/2016/12/entering-world-of-macros.ht...
[2]: https://github.com/red/red/wiki/%5BNOTES%5D-How-Red-Works---...
[3]: https://www.reddit.com/r/redlang/comments/aebxct/contrast_re...
[4]: https://www.red-lang.org/2013/11/041-introducing-parse.html
IIRC, you were instrumental in building the ecosystem, and attracting many other contributing community members.
Network effects bootstrapping blame, where it's due. :)
People underestimate the upside of being able to paste any example snippet into your repl and have it work transparently in almost every scheme, without having to worry about libraries or eco-systems.
For anything more exotic, you grab the nearest SRFI and squeeze it around until it works in the scheme you're working with.
Scheme: it's so simple, any subgenius could use it!
I've been using racket quite a lot lately, really like it. The thing I do not like about racket is the whole "racket 2" effort. Abandon S-exps? Really? To leave behind the 'popularity boundaries' of lisps? d'oh How about you drop your common USP that you share with the other lisps to become .. what, exactly.. irrelevant?
Cf. your 'dialect' point: In reality, the languages are just (supposed to be) DSLs for specific (sub-)problems of your problem-space. I don't mind, at all. You just require the libraries written in that other dialect from racket and use the stuff in there, et voila.
Lisp Machines were word addressed so the technique wouldn't work for them.
With an aarch64 backend, and some graphics&GUI work, it might also make sense atop PostmarketOS Linux kernel, for handhelds.[1] If one needs to heavily rework Linux userland anyway, and especially if motivated by enthusiasm, it's an opportunity to rethink, rather than automatically inherit decades of desktop stack.
[1] Notes on approaching this incrementally at https://www.neilvandyke.org/postmarketos/ , though you could alternatively start by building up atop bare kernel&drivers, and Loko Scheme looks like a promising candidate for that.
> ...multiboot binaries for bare hardware
Multiple brownie points combo!
Congratulations on the work achieved.
The more the merrier.
Any compiled artifacts would need to be distributed (if they are distributed) under AGPL.
I'm a fan of Free software, but much prefer GPL/LGPL for compilers and runtimes/standard libraries.
That's exactly why, for example, LLVM ships with a modified version of the Apache license: http://llvm.org/foundation/relicensing/LICENSE.txt (see the bottom)
If I use an AGPL text editor, does my written text also become APGL?
Which I'm guessing is intentional.
"Linux’s license doesn’t extend to user space and I want that aspect to work the same for Loko."
Sounds like they really want something closer to gcc/glibc licensing.
Not quite sure if they really want to close the "proprietary fork running as compiler-as-a-service in the cloud"-hole that using the AGPL (with link exception) would close, though.
https://github.com/torvalds/linux/blob/master/Documentation/...
"The Linux Kernel is provided under the terms of the GNU General Public License version 2 only (GPL-2.0), as provided in LICENSES/preferred/GPL-2.0, with an explicit syscall exception described in LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file."
In other words, the Linux kernel isn't pure gplv2, but comes with an exception in order to allow linking.
> Loko is AGPLv3 for various reasons. There are benefits to using the AGPLv3 that I prefer to keep, but it's not a perfect match for a compiler + runtime. To make Loko more widely usable, to even developers of closed source applications, I would like to formulate a suitable exception to the license. People should not need to release the code to their application that is running on Loko. There are precedents in Linux and GCC.
> An expert in free software licenses is likely needed for this.
For a batch compiler, that is a language that doesn't need the compiler to run, write an AGPLv3 compiler without a linking exception and then demand sufficient funds be raised to release a version with the linking exception. This is then a way to write a Free Software compiler and still demand money for it, for many to actually want to use it. I wouldn't license something such as a Lisp compiler with the exception, however, as the implementation generally exists with the program and that removes some advantages of it being AGPLv3. Fortunately, it seems the author has used the AGPLv3 and any desired exception uses vague language not in the license, so it's legally irrelevant. I'd find it best if there were no exception for this program, but it's not my decision.
In closing, this has made me want again to write my own Scheme implementation, so perhaps I'll do that at some point soon.