var ASM_CONSTS = [(function(){
        var err = new Error;
        print('Stacktrace: \n');
        print(err.stack)
    } // ...

After all, Math.round was called on a perfectly innocuous 11.1 and not some crazy NaN.

This is a common point of confusion because in a browser the global object is traditionally the same as window (or “self” or “frames”) so there wasn't a difference for many years until ES5 introduced strict mode, which left the default as undefined instead of silently using the global object, and things further fractured with Node (where it's “global”) and Web Workers (where only “self” works). (In browsers this is also complicated by the Window/WindowProxy distinction — see https://blog.whatwg.org/windowproxy-window-and-location and especially https://mathiasbynens.be/notes/globalthis#terminology)

A couple years back, “globalThis” was added to make it easier to write portable code across different environments without having to check various names: https://github.com/tc39/proposal-global

I don't think is not a particularly JavaScript-specific issue because any language which inherits scope can have the problem of a symbol not matching what you expected, which is why the ones which don't have compile-time checking tend to use linters which will report use of things which haven't been explicitly declared (not mention shadowing built-in names). If you want to blame JavaScript, the feature which would have made this more obvious would have been not ignoring extra arguments – print("foo") triggering an error at that point in the source would make it more obvious.

Both are true. Globals are stored on `window`.

> `print` is sugar for `this.print`

It is not.

"These kind of errors." Master Typikos said - and she told the student the story about the time when a bug in a runtime caused Math.Round to do IO although it's type was `Integer -> Float32 -> Float32`.

The student did not believe this story. Later he was enlightened.

EDIT: refined type

    run : DotNetCode -> IO ()

EDIT: 's/strong/powerful'

calling print() would not have failed in a stronger type system.

However, calling print("foo") would resolve to window.print("foo") which should have failed because window.print takes zero arguments.

That depends on the type system. The notation picozeta used suggests a Haskell-style system, where you wouldn't be able to call a function that does I/O from a function that is pure, which a type like `Integer -> Float32 -> Float32` would guarantee. You would need to explicitly permit I/O with a type like `Integer -> Float32 -> IO Float32` for the Round function for the call to print to compile in this sort of system.

Edit: Although it looks like the code that calls print in this case is actually another function, which might need to be in IO anyway if you were in this sort of type system, so maybe that doesn't help here.

f x = unsafePerformIO $ print "boom" >> return (pi * x)

The fact that Float32 -> Float32 does not permit IO is due to purity. 'Strong' is kind of an ambiguous term here.

The create-react-app project maintains a great list of "confusing browser globals" for exactly this situation! https://github.com/facebook/create-react-app/tree/master/pac...

You can use it along with ESLint to detect situations where a variable reference is technically valid (it will refer to the window property) but is probably not what you're intending.

Some of them are really easy to trip over, like `error`, `name`, and `open`. All global properties on the window!

I had a string like "Hello ${name}" and it would compile but crash at runtime.

Wasted a whole day, learned a lot about why even with great tools the JS ecosystem still has some fundamental crap at the bottom.

There's a `Module.print` that wraps `console.log` with a bit of logic. The code might have intended to call that one.

    window.Module = function (e, n, f) {
      var d = {
      },
      p = [
        'DEBUGGING ENABLED'
      ];
      return d.print = function (e) {
        return p.indexOf(e) < 0 && console.log('WASM: ' + e)
      },
      d.printErr = function (e) {
        return console.error('WASM: ' + e)
      },
      ...
      d
    }(e, n, f)

It happens in Firefox too, fwiw. Probably just a mono.js flaw.

- On Firefox for Android, it's impossible to type in a program, since when typing something as simple as "using System;" it'll garble the text like crazy

- On Android browsers in general, the Monaco editor on that page is too "smart" for its own good and presents a worthless context menu when I press and hold (i.e. to select all text or paste it in). Microsoft: could y'all not?

- On both the (presumably-Chromium-based) default browser on my Android phone and Firefox 52.9.0 ESR on a reasonably "recent" OpenIndiana, the Blazor runtime fails to run anything at all when I click "Run", complaining in the JS console (at least on OpenIndiana; didn't check on my phone, but the symptoms are the same) that "No .NET call dispatcher has been set".

- On a reasonably-recent nightly version of Haiku, loading try.dot.net at all causes WebPositive to outright crash within seconds.

[0]: https://microsoft.github.io/monaco-editor/

If Monaco wasn't so absurdly over-engineered it would be much easier to support on mobile browsers.

  C:\>copy WEB LPT1

Edit: To be more specific, "window" is only the global object for the scripting context in a browser window (anything inside "script" tags). Meaning, you would have to use the full form, "window.print()", when calling the print function from outside this context, like inside an event handler attribute of an HTML tag. (E.g., '<button onclick="window.print()">Print page<button>'. Here, a simple "print()" wouldn't work.)