Skip to content

Instantly share code, notes, and snippets.

View dherman's full-sized avatar

Dave Herman dherman

View GitHub Profile

Motivation

  • expression-oriented programming one of the great advances of FP
  • expressions plug together like legos, making more malleable programming experience in-the-small

Examples

Write in an expression-oriented style, scoping variables as locally as possible:

History

  • worked on this during ES2015 time frame, so never went through stages process
  • got punted to later (rightly so!)
  • goal for today: resume work on this, reassert committee interest via advancing to stage 1

Intuitions

  • sandbox
  • iframe without DOM

SOP Threat Model

  • evil.com:<script> ----🍪----> facebook.com/🤐.csv
    • fix: opaque response
  • evil.com:<script> ----🔟----> go/🤐.csv
    • fix: opaque response

CORS Threat Model

  • evil.com:XHR:X-Data --🍪--> facebook.com/🤐.json
@dherman
dherman / fibonacci.js
Last active December 28, 2016 21:12 — forked from hagino3000/fibonacci.js
asm.js sample
function fast_fib_module(stdlib, foreign, heap) {
"use asm";
function fib(n) {
n = n|0;
if (n >>> 0 < 3) {
return 1|0;
}
@dherman
dherman / rust-bindings.md
Last active December 21, 2016 00:51
from "Rust Bridge" to "Rust Bindings"

Hi! I'll keep this short: I'd like to change the name of this Slack to Rust Bindings, and to let go of the rustbridge.io domain, to allow the Rust Community subteam to make use of the name "Rust Bridge" for an outreach and training program.

I don't think there's a pressing need for a "Rust Bindings" domain or GitHub org (each project will probably want its own). But I do think it's nice to have this community Slack where people working on similar projects can hang out and discuss, so I think we should rename the Slack and keep it going.

Ping me in #general with any thoughts or concerns!

Happy holidays,

Dave

Module/Script Disambiguation

In the UnambiguousJavaScriptGrammar proposal, Bradley and John-David discussed the challenge of dealing with files that could successfully parse as either scripts or modules but have different execution behavior. This has a couple of issues:

  • Code written with the expectation of being executed in one mode could be executed in the wrong mode, without the ability to prevent this kind of erroneous execution.
  • Top-level scripts intending to be executed by Node via node myscript.js can't work for files that want to use import syntax, unless Node adds and mandates an un-ergonomic new command-line switch like node -m myscript.js.

Unambiguous Solution

In the UnambiguousJavaScriptGrammar proposal, the language would be changed to require that all module files contain at least one import or export declaration. The easiest way to ensure that a file is a module

neon::
  define_types!
  register_module!

neon::mem::
  Handle
  LockedHandle
  Managed
@dherman
dherman / let.js
Last active October 14, 2016 05:31
this.foo = "foo";
this.let = {
get foo() { console.log("getter!") },
set foo(x) { console.log("setter!") }
};
{
// let[foo]; // syntax error
(let)[foo]; // "getter!"
#[macro_use]
extern crate neon;
extern crate neon_sys;
use std::ops::Drop;
use neon::*;
pub struct Greeter {
greeting: String
}
#[repr(C)]
pub struct FunctionKernel<T: Value>(fn(Call) -> JsResult<T>);
impl<T: Value> Kernel<()> for FunctionKernel<T> {
extern "C" fn callback(info: &CallbackInfo) {
info.scope().exec(info, |call| {
let data = info.data();
let FunctionKernel(kernel) = unsafe { Self::from_wrapper(data.to_raw()) };
// error: the parameter type `T` might not live long enough
// note: the parameter type `T` must be valid for the anonymous lifetime #1 defined on the block at 6:39...