Jonathan Rees

Bash may need a high level of authority as it's spawning processes and wiring them together, but those processes don't necessarily need to have as much access as you do themselves. Take the venerable `cowsay` for example. Currently, running `cowsay` (as with any other program) can cryptolocker your hard drive, delete all your files, reach out to arbitrary servers on the internet, etc. But how much access to your system does it actually need to do its job? Well, mostly... STDIN, and STDOUT, really. Yes, actually doing this is complicated. Another reply has linked to some broad info about object-capability security, but here's a good introduction to the subject: http://habitatchronicles.com/2017/05/what-are-capabilities/ ...and this paper is an excellent deep dive into a capability system: https://mumble.net/~jar/pubs/secureos/secureos.html

Let's see if I have this right. I could be wrong about the details here: Before it was called "Scheme," Sussman was writing papers about a lisp subset that could be optimized. Some folks tried to write an optimizing compiler, known as "T." http://mumble.net/~jar/tproject/ Common Lisp was a superset of a bunch of vendor Lisp systems, even more monstrously complex than any individual vendor Lisp. So if I follow the author: If a CL implementation was indeed faster and better-optimized than the simpler Scheme dialect, then what was the purpose of Scheme?

T 3.0 http://mumble.net/~jar/tproject/t3.0.tar.gz The most beautiful compiler for any language. P.S. Why not ask the specialists? the people hacking Lisp compilers for the love of it; unpaid and unsung heroes? Drop by #lisp or #scheme in Freenode and see who is there. Most competent Lisp compiler hackers wouldn't be caught dead in this neck of the woods; it's just us web guys, blowhards and joe nobodies.

Paul Graham has most of the work done for me: http://paulgraham.com/lisps.html He has A, B, C, D, E, F, G, I, J, K, L, M, N, O, P, S, V, and X - though I certainly can name some dialects of the same letters which are not listed. Not going to really bother on that one, though. This leaves H, Q, R, T, U, W, Y, and Z, of which I can supply Qi ( http://www.lambdassociates.org/ ) and T ( http://mumble.net/~jar/tproject/ ). Bringing the list of unnamed (for me) to: H, R, U, W, Y, Z. That's the best I can do. Anyone else?

You may find this paper helpful [1]. As noted there, syntax-rules consists really of two different parts: (1) the hygiene-preserving macro expander and (2) the pattern-matching facility. Once you wrap your head around the two pieces, it's actually pretty straightforward to implement them both. It's very common to write some "low-level" macro facility as a stepping-stone to syntax-rules (such as explicit-renaming macros or syntactic closures): the implementation of syntax-rules then becomes a composition of the pattern-matcher and the low-level facility. A tutorial implementation of an appropriate pattern-matcher can be found at [2],[3]. There's lots of good reading to be found at the ReadScheme Library [4]. Most if not all of the references in [1] can be found there. Tangentially: yeah, syntax-rules kinda flies in the face of the oft-mentioned minimalism of Scheme, but there's a reason for it: at the time syntax-rules was standardized, there was no consensus on which (if any) low-level facility should be standardized (and, really, there still isn't any such consensus). The reason syntax-rules operates as a pattern-template rewriting system rather than as a procedural system is that such a system is able to guarantee that the macros it produces are hygienic in a (comparably) simple and intuitive way. The idea was to standardize on a high-level system so that Scheme could have a standard macro facility, whilst leaving the low-level systems open for further…

It has a homepage, with sources, now: http://mumble.net/~jar/tproject/

This is a good article. Also good, along similar lines, is the W7 paper: "A Security Kernel Based on the Lambda-Calculus", Jonathan A. Rees, MIT AI memo 1564, 1996. Available as PDF at its official home at https://dspace.mit.edu/handle/1721.1/5944 and as readable HTML at jar's homepage at http://mumble.net/~jar/pubs/secureos/secureos.html.

Erratum: Rees says the first Scheme compiler was Steele's CHEAPY in 1977, not RABBIT in 1978: http://mumble.net/~jar/tproject/

"A security kernel based on the lambda calculus" http://mumble.net/~jar/pubs/secureos/ http://cap-lore.com/CapTheory/upenn/

> It compiled an object-oriented dialect of Scheme called T do you have a link for this? It's difficult to search for. update: ignore me, found a link in the comments: http://mumble.net/~jar/tproject/ first line: "It occurred to me recently that The T Project had no coherent presence on the web." :)

This was [1986], citation details: http://dl.acm.org/citation.cfm?id=13333 Rees maintains a related archive [most recently updated 2010] on his page at http://mumble.net/~jar/tproject/ That in turn links to Shivers's overview of T and the development of its compilers (including Orbit) at http://www.paulgraham.com/thist.html

One of earlier works combining high-security and functional programming was a security kernel for Scheme48: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.4213 http://mumble.net/~jar/pubs/secureos/ That was the Scheme mathematically-verified in VLISP project: https://en.wikipedia.org/wiki/PreScheme There was also a mathematically-verified, Scheme CPU: http://www.cs.indiana.edu/pub/techreports/TR544.pdf I imagine combining even these three components into an integrated systems would provide a lot more security and availability than the average desktop. The simplicity of the CPU might also aid in producing a NonStop-like solution for five 9's availability.

Jonathan Rees's 1995 paper "A Security Kernel Based on the Lambda Calculus" was enlightening. Not only was it capability-based security in Scheme -- but capabilities are lambdas! http://mumble.net/~jar/pubs/secureos/

Or object capability systems in general ... like the material at http://erights.org/ and the security kernel work from long long ago: http://mumble.net/~jar/pubs/secureos/ and http://mumble.net/~jar/pubs/secureos/secureos.html

No, but you could ran 'Pseudo Scheme' on it. http://mumble.net/~jar/pseudoscheme/ The native languages though were Lisp Machine Lisp and then also versions of Common Lisp, for example Symbolics Common Lisp.

And Jonathan had some small amendments: http://mumble.net/~jar/tproject/

I like the Rees OO ontology[1]. The set notation doesn't lend itself to easy reading, but it lets you break out the features of an object system in a more precise way. [1] http://mumble.net/~jar/articles/oo.html

Rees (http://mumble.net/~jar/) studied under Sussman at MIT and is one of the creators of Scheme48 (http://groups.csail.mit.edu/mac/projects/s48/).

Johnathan Rees' T project page has a list of errata to Shivers' article. http://mumble.net/~jar/tproject/

You can get the last versions of T here - http://mumble.net/~jar/tproject/ Haven't checked if there's any sample code.

Douglas Crockford has described Misty as vaporware (hence the name), whereas at Spritely we are building and shipping things that can be used. Rather than build an entirely standalone domain specific language, our research and development builds on top of Scheme because it's a multi-paradigm language that is easy to extend to implement new paradigms (such as the actor model) thanks to the powerful macro system. Lexical scope and first-class functions make Scheme amendable to the actor model (Scheme was initially created as an exploration of the actor model) and capability security. For the latter, we are inspired by Jonathan Rees' W7: A security kernel based on the lambda calculus. http://mumble.net/~jar/pubs/secureos/secureos.html We are also involved in a cross-organization effort to bring capabilities to everyone (on the network, at least) called OCapN and we are seeking implementers for as many programming languages as possible. https://ocapn.org/

T: http://mumble.net/~jar/tproject/

I think what Andrew Hejlsberg himself, the designer of C# and TypeScript, said speaks to the claims orange8 is making about TypeScript being a "VERY opinionated linter" and that "you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns". Andrew Hejlsberg's point is that TypeScript is a "multi-paradigm" language: it's not just strongly typed, but also structurally typed, interface based, plus everything else JavaScript itself is: dynamically typed, duck typed, functional, imperative, event driven, class based, prototype based, object oriented, etc. Even the term "object oriented" has a broad spectrum of independent meanings: JavaScript has many but not all of the a la carte menu of features or properties of "object orientation" that Jonathan Rees listed in response to Paul Graham's essay "Why Arc isn't Especially Object-Oriented". http://paulgraham.com/reesoo.html http://mumble.net/~jar/articles/oo.html http://paulgraham.com/noop.html Andrew Hejlsberg said: >I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming". It's a mistake to think that TypeScript restricts you to just one way of programming, and you have to give up the ways you used to program JavaScript. TypeScript ADDS to the number of ways you can program JavaScript. It's a superset of the multiple programming paradigms that JavaScript supports. You don't "loose a…

Interestingly, one of the pages you link (http://mumble.net/~jar/tproject/) links a paper (grep "1986: Kelsey dissertation on rewrite-based compilation ") that shows the implementation of a compiler with multiple frontends (BASIC, Scheme, Pascal) using only source-to-source) transformation. I find this interesting because in a certain way, this reminds me of how the go assembler works (https://www.youtube.com/watch?v=KINIAgRpkDA). For those who haven't seen the talk: basically the go compiler works on the assumption that pretty much all computer, in a way, move memory from one address to another, generate and handle interrupts, have call/return instructions and so on. Thus, the go compiler emits (IIRC) some sort of "intermediate assembler" (somehow similar to llvm's intermediate representation, but simpler) and then proceeds to "translate" such assembler to various platform native assembler. I clearly remember Rob Pike (in the talk) saying "so the task of supporting a new platform becomes a task in text processing" (okay, maybe it was worded a bit better). This might be a bit tangential, but it is interesting how some "new" ideas aren't that new after all. But I guess this is due to Rob Pike's deep experience and history with computers.

https://github.com/fogus/lithp http://picolisp.com/5000/-2.html http://mumble.net/~jar/tproject/ http://www.lambdassociates.org/Lib/libraries.htm http://www.newlisp.org/ http://www.paulgraham.com/arc.html http://sites.google.com/site/waspvm/ Fluchtpunkt Lisps are… Focused: Uncompromising in their vision Spartan: Devoid of the seemingly unnecessary comforts found in many modern languages Controversial: Not always by design, but often because of their design Fun