Cool! Looks like a company that grew out of §3.3.4 of SICP. Hardware oriented NixOS and GUIX users should be very interested in this: declarative PCB designs.
STk is a Scheme interpreter which can access to the Tk graphical package.
Concretely it can be seen as the John Ousterhout's Tk package where
the Tcl language has been replaced by Scheme.
The Scheme interpreter is now R4RS conformant.
This release provides an efficient object oriented system called STklos.
STklos is a full OO system with multi-inheritance, generic functions,
multi-methods and a true meta object protocol.
If in reading this introduction, you've come to realize that "Hey, Tcl is just like Lisp, but without a brain, and with syntax on steroids", you might wonder why Lisp isn't a more popular scripting language than Tcl. Lisp hasn't been a complete failure, by the way; it is used as an extension language by users of some popular programs, notably AutoCAD. But Tcl has been much more successful. It has been compiled into hundreds of larger programs, including AOLserver, which is why we wrote this book.
As a software developer, you're unlikely to get rich. So you might as well try to get through your life in such a way that you make a difference to the world. Tcl illustrates one way:
make something that is simple enough for almost everyone to understand
give away your source code
explain how to weave your source code in with other systems
btw: Lean 4 is getting all the buzz these days, but how many people know that Scheme/Racket is an extraction target language for the Rocq Prover (aka Coq).
The Rocq Prover implements a high-level program specification and mathematical language called Gallina that is based on an expressive formal language called the Polymorphic, Cumulative Calculus of Inductive Constructions that itself combines both a higher-order logic and a richly-typed functional programming language. Through a vernacular language of commands, the Rocq Prover allows:
to define data structures, functions or predicates, that can be evaluated efficiently;
to state mathematical theorems and software specifications;
to interactively develop formal proofs of these theorems;
to machine-check these proofs by a relatively small certification "kernel";
to extract certified programs to languages like OCaml, Haskell or Scheme.
As a proof development system, the Rocq Prover provides interactive proof methods, decision and semi-decision algorithms, and a tactic language for letting the user define its own proof methods. Connection with external computer algebra systems or theorem provers is available.
As a platform for the formalization of mathematics or the development of programs, the Rocq Prover provides support for high-level notations, implicit contents and other mechanisms for formalization at scale.
Another striking aspect of the evaluator is that it acts as a bridge between the data objects that are manipulated by our programming language and the programming language itself. Imagine that the evaluator program (implemented in Lisp) is running, and that a user is typing expressions to the evaluator and observing the results. From the perspective of the user, an input expression such as (* x x) is an expression in the programming language, which the evaluator should execute. From the perspective of the evaluator, however, the expression is simply a list (in this case, a list of three symbols: *, x, and x) that is to be manipulated according to a well-defined set of rules.
That the user’s programs are the evaluator’s data need not be a source of confusion. In fact, it is sometimes convenient to ignore this distinction, and to give the user the ability to explicitly evaluate a data object as a Lisp expression, by making eval available for use in programs. Many Lisp dialects provide a primitive eval procedure that takes as arguments an expression and an environment and evaluates the expression relative to the environment.
The difference is this is built in to many Lisps without the need to create a separate interpreter. And thus much more direct. It's definitional.
In fact, the original article excludes Lisp as an example of homoiconicity, but only because Lisp had not settled on a single representation in terms of s-expressions at the time of writing: “Finally, LISP is troubled with a dual language problem: an M-language, which is easy to read, and is used externally, and an S-language, with which the LISP processor operates, and which is usable externally only by the hardened initiates. It should be noted here that were the S-language the only LISP language, LISP would be close to being homo-iconic (excluding the machine-language functions).”
Don't Say “Homoiconic” (2018) (expressionsofchange.org)
88 points by dmux on Aug 11, 2019 | hide | past | favorite | 69 comments
You can click on the time-of-post to "vouch" for down-voted or "[dead]" comments to bring them back.
Otherwise, to read them, I will select the text which highlights it in high contrast. Ctl-A on many browsers or triple click on a paragraph.