mballantyne's comments

Racket's "places" work a similar way, though do a bit extra to get down to one memory copy, rather than two: https://www.cs.utah.edu/plt/publications/dls11-tsffd.pdf

I suggest "Programming Languages: Application and Interpretation", available free here: http://cs.brown.edu/courses/cs173/2012/book/ It's an undergraduate-level programming languages class textbook.

Other books burn a lot of time on things like lexing and parsing; this one does not. In the lisp tradition, it assumes s-expressions and gets to the juicy bits of programming language semantics immediately: lexical scope, first class functions, objects, etc.

I believe this is the implementation described in this paper published at POPL 2016:

https://www.microsoft.com/en-us/research/publication/transfo...

Though it probably also uses more recent work from the same group:

https://www.microsoft.com/en-us/research/people/sumitg/

My understanding is that Z3 is primarily an SMT solver (https://en.wikipedia.org/wiki/Satisfiability_modulo_theories), though it has also expanded to support queries beyond SMT.

SMT solvers excel at solving finite sets of equations involving finite or atomic data, like numbers, bitvectors, strings, and arrays of fixed length. They've been very successfully applied in software and hardware verification. They're also the essential tool for a big category of approaches to program synthesis.

This has some overlap with the sorts of numeric constraint solving available in prolog and with non-recursive prolog goals. Prolog however can express turing-complete computation with recursive goals, dynamically allocate data structures of unknown size, etc. that SMT cannot easily encode.

Z3 also has support for datalog-like queries. I don't know much about datalog, but my understanding is that it supports a more limited set of queries than prolog but can solve them more efficiently with a totally different algorithm than prolog's goal-directed depth first search.

Other search algorithms can take up lots of memory to store progress they've made down different paths. Having only one active state also lets you map unification down to efficient low level cpu operations. If you have multiple states, you either have to copy lots of data when you fork the state or you use a persistent data structure but can't use side effects, so everything is a bit slower.

It's a tradeoff though. I work on miniKanren, which is a logic programming language with a complete search that doesn't hit the nontermination issues you mention. The complete search lets us do some pretty cool stuff with program synthesis (though we're not about to put any programmers out of business just yet): https://www.youtube.com/watch?v=er_lLvkklsk

Note that you can implement iterative deepening depth first search on top of prolog if you want a complete search there. Iterative deepening takes a little more time but avoids the memory problems with breath-first. SWI has tools built in to help there: http://www.swi-prolog.org/pldoc/doc_for?object=call_with_dep... And I believe Ciao implements its iterative deepening library with a meta-interpreter: https://ciao-lang.org/docs/ciao/id_doc.html#0

When I've talked to senior researchers about these problems, they say that they have no problem finding distilled information about new results; they get it from in-person conversations at conferences that they attend frequently. The publishing of distilled research would most benefit low-status, newer researchers (like Ph.D. students), but it needs to be valued by senior researchers to make it into the incentive systems of hiring and grant funding. It seems like a tricky problem to fix the incentives here.

First, a small defense of Racket. Racket has a small core relative to its apparent size; most of the bloat is in optional library code. All the fancy special forms for pattern matching, classes, contracts, etc are just optional macros from the libraries, and everything eventually expands down into this rather small core language:

https://docs.racket-lang.org/reference/syntax-model.html#%28...

The default `#lang racket` is a big batteries-included language including all that stuff, but the core `#lang racket/base` isn't very big. I always program in `#lang racket/base` and pull in just the libraries I need. For me the most beautiful part of Racket is this juxtaposition of a small core language and a big extended language implemented through a standard library of macros.

You can also install a distribution of Racket that leaves out bloat like DrRacket, Slideshow and the teaching language packages from the release variants page: https://download.racket-lang.org/releases/6.8/

As to your question, Beautiful Racket appears largely a guide to the language extensibility features that are specific to Racket and not shared by other Scheme systems like Chibi. Things like the `#lang` system, lexer library, and syntax highlighting integration in DrRacket. I imagine you'd get the most benefit out of it by working through it in Racket, and subsequently thinking about how to apply the ideas in other systems like Chibi.

Spindle already has some of the things on your TODO list, but seems only semi-maintained. It'd be awesome if you two could join forces!

Can you elaborate on how syntax-case "violates the macro abstraction", and maybe what you think is important about the quality it breaks? Not a description I've heard before. I do agree it is complicated!

Author here, and I agree that using templates for complex code generation is a mess. However, it's a popular mess in some branches of high performance computing right now, especially for dealing with the transition to execution on GPUs. If you're stuck in C++ and want abstraction without runtime cost, templates are what you've got. An alternative option is to step outside of C++ and write a compiler or source-to-source translator in a more suitable language (the direction we've gone since), but that means existing C++ programs can't just drop in your DSL as a library without adding more bits to their toolchain.

If you do decide to make a complex library based on template meta-programming, you inevitably end up needing a meta-meta language to help build it because templates are so ill-suited to the task (especially before C++ 11). Many template-based libraries (like Eigen, http://eigen.tuxfamily.org/) have chosen to use preprocessor macros as that meta-meta language; we decided Racket was a better choice and this paper is our exploration of how that might work. I suppose an interesting takeaway is that even if user constraints force you to implement your DSL compiler as a template meta-program, you can still use an outside meta-meta language to help create the templates.

The statements regarding debuggability make two claims that I think are correct, if not particularly strong: 1. using Fulmar as a meta-meta language produces a more readable template meta-program to examine than do preprocessor macros; 2. Fulmar can catch some errors at the meta-meta level and provide nice errors (section 4.5) in places you might have otherwise received the nasty template expansion errors (again unlike preprocessor macros).

An academic paper summarizing studies on the effect of attitude interventions like those discussed in the OP:

https://labs.la.utexas.edu/adrg/files/2013/12/REVIEW-OF-EDUC...

Positive feelings of belonging and capability seem to be a surprisingly powerful form of race and class based privilege.

Do CRLs even work? My understanding is that the only browser that hard-fails to load a page if OCSP is blocked is Chrome for certs in CRLSets. Everyone else is vulnerable to MITM if access to the CRL / OCSP servers is blocked.

I would love to be wrong. Does anyone know if anything has changed for the better since 2011?

http://blog.spiderlabs.com/2011/04/certificate-revocation-be... http://dev.chromium.org/Home/chromium-security/crlsets https://www.imperialviolet.org/2011/03/18/revocation.html

AFAICT, here isn't really any benefit for most people. If you're using an Extended Validation certificate the revocation would remove the EV presentation in most browsers.

The only way you'd get a browser to totally fail to load the page in the case of a MITM that can block the OCSP servers is Chrome's CRLSets. Only a limited set of revocations are included due to space constraints though; mostly EV certs from select CAs and Intermediate CA certs.

A good solution to this problem would be short lived certificates, but that idea has yet to find much traction.

http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-shortliv... http://dev.chromium.org/Home/chromium-security/crlsets http://blog.spiderlabs.com/2011/04/certificate-revocation-be...

Heartbleed affects servers terminating TLS connections using certain versions of OpenSSL. It doesn't impact certificate operations a CA would be doing, and CA root certificates are kept far, far away from front end web servers that might run TLS. Usually in something like this: http://en.wikipedia.org/wiki/Hardware_security_module

The security promise is simply "this is better than plaintext email, which is what you'd use otherwise."

I'd rather have as much of my communication as possible protected from mass collection by my own government regardless of it's sensitivity.

Edit: Misunderstood your phrasing a little. Yes, ideally we would provide non-savvy users with trivially easy to use encryption strong enough to defeat hostile governments. I haven't seen it yet. I make no pretense of overpromising - I'd certainly expect a service such as I'm describing to prominently note that it shouldn't be used for material above a certain sensitivity and link to info on better options.

Yep. They would. Snowden should be using PGP on an air-gapped machine inside a faraday cage, right? This isn't for him. This is for the rest of us that are at most mildly interesting but don't want to give in to the surveillance state, or just want to send a password without blindly and completely trusting at least one third party. Isn't such a mid-security but easy to use solution valuable? The more PGP-armored messages there are (even if they could be broken with effort), the less suspicious any such use of crypto can be considered.

The server can only read arbitrary messages if it changes the runtime that it serves. If it were to serve the wrong runtime to more than a narrowly targeted set of users, it could be detected (by, say, a third party running an automated script to check for changes in the served files).

This also means that targets of interest would have to be identified at time of their use of the service (so as to avoid detection as above) by something other than the content they're sending, whereas a malicious service receiving the plaintext could search through all received plaintext for interesting content without detection.

It would make an attacker expend effort and risk per-target. In a world of mass data collection, that seems valuable for those who aren't targets of particular interest but want to avoid the dragnet.

I hadn't yet seen that particular article but I'm very familiar with those arguments. Thanks for the link!

I agree with them that building a crypto library in JS that can be trusted regardless of the security properties of the web application is impossible (content-controlled code, runtime malleability).

However, I don't think those points mean that building an application that as a whole has good security properties and uses JS crypto is impossible. If the entire application code is delivered on first load and code is never dynamically loaded, one should be able to audit and trust that complete application. That'd mean no ads, no google analytics, no CDNs, etc.

The next bit is reliable delivery. SSL is definitely needed. Because static code is all delivered on first load, an interested third party could download it at any time and see that it matches the audited code. The host would be caught if it attempted any attack that wasn't narrowly targeted.

And that's why it's better than just SSL. If the host receives the plaintext, there's zero chance of catching them.

Their points about graceful degradation and CSPRNGs are irrelevant; I'm only interested in targeting modern browsers with window.crypto.getRandomValues.