Hey, nice to see Ymacs is still used somewhere else than on my website :)
I don't know if you've been tracking it lately, but there was a big overhaul last year [1]. The version in your second link doesn't seem to work in current Firefox. If you'd like to update and need any help, please feel free to get in touch. (also, there's still some of your code in Ymacs :) although I kinda broke filename completion...)
An alternative to Scrappy is the free CodeBoot web app (https://codeboot.org), which allows you to create web apps in Python that are fully encapsulated in a URL. No installation is required—neither for the developer nor the user. Below is an example of a math practice app with simple user interaction through dialogs. To create a web app URL, right-click the "play" button and choose the type of link you want to generate.
For more complex UIs, CodeBoot provides an FFI for accessing the DOM directly from Python code. For example here is a dice throwing app with a button to roll the dice again. The text in the button has translations to multiple languages and will adjust to the browser's default.
I have designed 2 web based code playgrounds that you may find interesting.
https://try.gambitscheme.org is a playground for the Scheme language (specifically Gambit Scheme). It has a REPL and a code editor that saves files in the browser local storage. It also has a tutorial for learning the basics of Scheme.
https://codeboot.org is a playground for Python (there's an old version that supports JavaScript and we may resurrect it at some point). It was specifically designed as a simple IDE to teach programming to beginners and is in use at the Université de Montréal. Aside from the simple and intuitive UI, it has two important features for teaching:
1) Fine granularity single-stepping of Python code to help teach students how the computer goes about executing the code. It displays a bubble containing the variables in scope and their values.
2) It can bundle programs and the current state of execution in a URL that can be embedded in documents (HTML, PDF, PowerPoint, Keynote, etc) so that coding examples can be executed by the students in a single click. It also allows students to create simple web apps that require no installation and can easily be shared with others (because the URL contains all the relevant code of the app). You will find examples of this feature on the following pages:
LIPS has documentation builtin into every function. You can see the docstring when you hover over the name of the symbol in the REPL. It also has auto-indent. Also if you press enter you can get back and modify previous lines of code. History doesn't repeat lines only full S-Expressions so it's easy to rerun a big chunk of code.
Even though Try Gambit is a REPL it's not very user-friendly.
The try.gambitscheme.org web app has most of these features and more:
- REPL history with up/down arrows (explained on the landing page's README)
- You can use the "help" procedure to browse the full documentation
- TAB key for autocompletion
- In addition to the REPL there is a code editor to edit programs stored in the browser
- The system supports multiple threads, one REPL per thread
- There is a builtin tutorial to learn the basics of Scheme with examples executable in the REPL with a single click on a "run" button
- The REPL supports single stepping the execution of code
- Easy interface to JS with the SIX syntax extension, e.g. (let ((msg "hello")) \console.log(`msg, 1+2/3))
- The error messages are clear and precise giving the file and line number and highlighting in yellow the piece of code (in the REPL or file) that raised the exception. Just try this in both systems to see the difference:
> (define (f x) (/ 1 (* x x)))
> (f 5)
> (f "hello") ;; the * procedure will raise an exception and highlight "(* x x)"
- in Gambit History works on lines not S-Expressions like in LIPS
- With LIPS you don't need any new syntax to integrate with JavaScript you just use JavaScript directly (let ((msg "hello") (console.log msg)) SIX syntax doesn't look like Scheme.
- Help popup documentation, with LIPS you have documentation directly in the REPL (when you hover over the symbol) and you can access docstring as strings and assign them to values.
- You can create new syntax similar to scheme vectors and make representation the same as code
- You can manipulate almost everything in the language like environments that you can modify
- LIPS show stack trace not one line which gives an error that makes it easier to find where the error happens.
- The Bookmarks allow to run the REPL on every page even PDF files with R7RS spec.
- You can actually run the code that uses quotes (’ The apostrophe symbol) from the spec if you use syntax extension to add new syntax.
To be clear, I'm not claiming to be the first to have used the name Tiny-C, just that the confusion with TCC is not intentional. Your links to DDJ are great an bring back memories of the good old days when there was much to learn from reading DDJ and Byte magazine!
That's not on my TODO! But Gambit does have support for TCC. For example you can use TCC to compile a file to a dynamically loadable object file (aka shared library). The compilation is faster than gcc and the code size is typically smaller too:
$ cat hello.scm
(display "hello!\n")
$ gsc hello.scm
$ gsi hello.o1
hello!
$ ls -l hello.o1 # this is generated by gcc
-rwxrwxr-x 1 feeley feeley 18152 Mar 13 17:16 hello.o1
$ rm hello.o1
$ gsc -cc "tcc -shared" hello.scm
$ gsi hello.o1
hello!
$ ls -l hello.o1 # this is generated by tcc
-rwxrwxr-x 1 feeley feeley 4432 Mar 13 17:17 hello.o1
Author here. Just for context tinyc.c was created in 2000 (I found the file in my archives and the last modification date is January 12, 2001). I was not aware at the time of Fabrice Bellard's work which after all won the IOCCC in 2001, so the confusion with TCC was not intentional. My tinyc.c was meant to teach the basics of compilers in a relatively accessible way, from parsing to AST to code generation to bytecode interpreter. And yes it is the subset of C that is tiny, not a tiny compiler for the full C language.
Haven't looked at what it would take to support C89 (or other) fully. Certainly it is possible to extend the compiler in small increments to implement more stuff: all the operators, local variables, arrays, pointers, functions, etc. The hardest part I would say is implementing types (starting with the C syntax for types!) and also handling the memory allocation for them. Nothing too complex when you know what you are doing.
My personal interest is with higher-level languages and I have worked on various Scheme systems over the last 30 years. If you like small language implementations then take a look at Ribbit which is feature-full with a tiny VM. Also check out sectorlisp (not my work) which is a fascinating tour de force.
tinyc.c was designed to illustrate three things at once in a second year course on concepts of programming languages. The course had 4 parts: imperative programming (using C), functional programming (using Scheme), and logic programming (using Prolog), and programming language implementation. For the imperative programming part it was important to show enough of the C language for the following operating systems course, so we needed to show C manual memory management and pointers in a rather detailed way. So tinyc.c was principally an example of programming with pointers, including pointer arithmetic such as *pc++. It was indirectly an example of compiler and interpreter, subjects we also covered in the course. I have also used parts of the compiler in a third year compiler course but not as the basis of a project. I have always asked (forced?) my students to use Scheme to implement their compiler projects... a much friendlier language than C for compiler writing.
I'm not sure what you mean by "minimal set of instructions". What is more important for bootstrapping is to restrict the programming style used to write the compiler. So if that was the goal I would implement pointers and maybe arrays, and not implement other types such as structs (which can be useful but add complexity to the compiler, i.e. it is no longer the case that a value fits in a machine word). Functions and function call would obviously be useful to add. But that's about it.
What I'd love to do someday is to write a compiler for a fairly complete C subset in POSIX shell. The goal would be to use only a POSIX shell and this compiler to compile TCC, and then use TCC to bootstrap gcc, all from source. This would be a great tool for reproducible builds from source. If someone here finds this interesting and would like to help out, please reach out to me.
It has tail calls, continuations and even green threads (SRFI 18 compliant), and a decentralized module system that can load libraries directly from github and a JS FFI! See this paper for advanced examples that you can copy-paste to the REPL: http://www.iro.umontreal.ca/~feeley/papers/BelangerFeeleyELS...
I'm not sure what part of your project is web-based and what you mean by "web-based". Do you mean executing Lisp/Scheme code on the browser side or the server side? In any case you should consider Gambit Scheme that has a complete JavaScript backend. For example check out the https://try.gambitscheme.org site to see the online REPL in action.
Gambit supports the R7RS module system and has a decentralized module system that can automatically download libraries from git repositories. Take a look at the "Libraries" section of the online REPL's tutorial for a few examples, or just type at the REPL:
The Gambit Scheme REPL that comes with a tutorial, supports threads in the browser and has a JS FFI: https://try.gambitscheme.org
Gambit in emacs in the browser: https://feeley.github.io/gambit-in-emacs-in-the-browser/