All About E: A Language That Infiltrated JavaScript

I'm guessing you are not considering Erlang/Elixir "first class" then. Is it because they are hosted on the BEAM?

If the hosted VM part is what it comes down to you also have Pony. Haven't looked at it in quite a while but it always surprised me it didn't end up more popular.

There's Spritely Goblins, which takes a lot of inspiration from E. It's a library so it may feel bolted on to you, but in true lisp fashion it feels like it's part of the language when you're using it: https://docs.racket-lang.org/goblins/

I guess we would not need to compile it down to js and instead evaluate or jit it directly?

Could someone do this on an open source browser perhaps? Or would it require some initial big chunk of work?

I'm surprised that Microsoft haven't already done this with their Edge browser. At least offer a 'developer' mode which enables TypeScript support only during development

Map is in JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

TypeScript is designed in such a way that type annotations can't influence the runtime behavior. This is unlike e.g. Haskell, where types can drive code generation. Happy to elaborate more if necessary.

This means that transpiling TypeScript to JavaScript consists merely of stripping the type annotations + transpiling some of the syntactic features that might not be supported by the target JS version.

The "Type Annotations" proposal (https://github.com/tc39/proposal-type-annotations), IIRC championed partly by the TS team, will allow type annotations with almost-TS-like-syntax in plain JavaScript, which will make the "stripping type annotations" step unnecessary. You would still use the TS tooling to actually type-check the code, though.

Which exact part of TS do you want to be built into browsers?

What about ReScript? As far as I understand ReScript has a sound type system which would make it an even better foundation?

We can't phase out features of JS in browsers, quirky or otherwise, because that would prevent us from running existing, fully debugged, standards-compliant web pages. It would mean that programming for the web was like depositing rare books in a library that was already on fire.

No because most languages don't just compile to WASM... You need to compile and distribute a runtime or, in the case of dynamic languages, full interpreter with the web page. JS is way less code to ship depending on how much interactivity you want...

JavaScript is still the language that owns the platform, because WASM doesn't have any capabilities beyond compute, it up to the host to provide callbacks so that WASM code can call into the host, those callbacks are written in JavaScript.

> People can just use whatever language they want in the browser now.

Except, you know, WASM has zero access to browser APIs, and all interactions have to go through JavaScript.

And on top of that you need to load your language's entire runtime to make it work.

WASM does not interact with the DOM AFAIK. Of course one might (and probably somebody did) create a JavaScript programs interfacing a WASM web worker that sends user input in the JS -> WASM direction and executes DOM manipulation commands in the other one. All masked as a DOM library of the language that was compiled to WASM. Efficient? Probably no. Fast enough? Probably yes.

>Doesn’t WASM provide a graceful and natural end to JavaScript’s hegemony? People can just use whatever language they want in the browser now.

Not really since you can't manipulate the DOM from WASM.

See "Crockford Objects" here for example: https://levelup.gitconnected.com/crockford-objects-in-javasc...

This function creates a closure with a private variable, "n". When invoked the closure will increase n by the specified amount, but there is no way to decrease it.

    const incfac = () => { let n = 0; return m => (m > 0 ? n += m : n) };

A more extensive example due to Norm Hardy, presuming a multiuser Scheme interpreter that supports ocap security, is this Scheme program for voting on where to have lunch: http://cap-lore.com/CapTheory/Language/Lunch.html

    (define (mocntr) (let ((x 0)) (cons (lambda () (let ((yet #t))
         (lambda () (if yet (begin (set! yet #f) (set! x (+ 1 x)) x)))))
      (lambda () x))))
    (define lunchcrowd (list (lambda (x) (write (cons "for Bill" x)))
       (lambda (x) (write (cons "for Bob" x))
              ((cdr (assoc "Mandarin" (cdr x)))))))
    (define restaurants (list "Mandarin" "Casa Lupe" "Coffee Shop"))
    (define (noontime) (let ((bb
           (map (lambda(r) (cons r (mocntr))) restaurants)))
        (for-each (lambda (e) (e (cons "Lunchtime!" (map
          (lambda(r)(cons (car r) ((cadr r)))) bb)))) lunchcrowd)
        (lambda ()(map (lambda(x) (cons (car x) ((cddr x)))) bb))))

You can translate this into current versions of ES straightforwardly but it doesn't get much more readable.

Norm explains:

> An invocation of mocntr is made each day for each restaurant. It returns a source of options, one of which will be offered to each of the lunch crowd. The second lambda in the definition produces such an option. The variable yet in that proc remembers if the option has been taken. The third lambda produces the getter for the count.

> bb is created each day for lunch and constitutes the ballot box. It is a list of pairs <restuarant name, <option source, count getter>>. This list is iterated over first to send each vote solicitation, and then later to count the votes.

Unfortunately he's vitrified now, so if you send him questions he will answer after a long delay, if ever.

the ability to create and send an object that cannot be modified

I think Object.freeze is insufficient but there is value in immutable properties of objects. I wish TS understood this

Malicious code running in the same JS process, specifically malicious code that modifies an object you give it (that you retain references to) or that gives you an object and then changes it later. Running multiple mutually untrusting pieces of code in the same process was the main point of E, and that's what the modifications to JS being discussed here are aimed at.

The reason for such "frozen" objects is explained in http://www.erights.org/elang/kernel/auditors/index.html.

So first of all the article is a bit confusing: Object.freeze does make an object immutable:

    const t = Object.freeze({foo: "bar"});
    // throws an error in strict mode,
    // silently does nothing otherwise
    t.foo = "baz";
    // prints "bar"
    console.log(t.foo);

The tricky part is that it does not do so recursively:

    const t2 = Object.freeze({foo: {bar: "baz"}}); 
    // bar is still mutable
    t2.foo.bar = "oh no!";
    // prints "oh no!"
    console.log(t2.foo.bar);

Still, one can easily write a function to recursively do a depth-first walk on an object and make everything immutable, so this is not really a concern in practice (if anything it gives you more flexibility).

Anyway, what I think Miller meant is that immutability is not the main reason why they introduced Object.freeze.

If I understand correctly, the main idea is to prevent people from inserting malicious code in the prototype chain (or anywhere else they might be able to).

Because JavaScript is prototype based I could in theory create a new Array class that uses the original Array class as its own prototype, then replace the Array class with itself. If you then create a new array it would still work like a regular one - it just goes up the prototype chain after all.

The malicious part is that this custom array class could then also override all Array methods to secretly watch your data and send stuff to the web without you noticing, or do anything else really. Because, again, it can just call the original method of its prototype to also behave as normal without anyone noticing.

Object.freeze would let you make sure none of the fundamental JavaScript objects can be tampered with.

The other thing is that you can ensure that any the library you create cannot be tampered with by third-party libraries.

Internal encapsulation is essential to be able to import and run (partially) untrusted code, to limit its potential side effects, and it has to be implemented in the language itself.

How many more decades do you want to wait before programming languages and with them, actual programming practice, become secure? All major languages have failed us in this aspect - and avoiding their shortcomings won't be possible without these primitives. Until people realize this, the world will have to suffer a million hacks that could have been avoided otherwise.

https://medium.com/agoric/pola-would-have-prevented-the-even...

It does require a different mindset, perhaps even a conceptual inversion to understand and apply the security model, but that doesn't make it purely academic. Yes, it will remain that way if its logical truths are not implemented, but their applications and the consequences of ignoring them are very real.

To suggest that they only do it for their own sake is incredibly presumptuous.

freeze is used quite often (for immutability).

Proxies are there for security? It wasn't mentioned in the article and I don't see how it providers security, it only makes things easier to use, right?

I see a scrollbar here, though. Firefox, desktop.

Sorry, how do you unfreeze a frozen object? Only references I see online involve cloning it, which preserves the security properties of a frozen object.

As for harden(), whether its vulnerable to it's prototype chain in the way you describe depends entirely on how it's written. That said, these aren't amateurs so I expect they know what they're doing, and transitively freezing an object graph does add important security properties.

The security principle is largely based on OCAP-based permission scheme, where implicit access to an object is equal to the right to access, and freezing said object limits its use.

>"the properties of the object can no longer be changed" yes, unless someone else just unfreezes the object.

There doesn't appear to be any unfreeze method.

>This is still a problem, and the "harden" function that is described doesn't actually help because the things that it relies on could be poisoned.

I think the threat model here is untrusted code which runs after the "harden" function completes.

(I think this article would've been better if it had discussed threat models at the beginning.)