Trying to compile Basic is actually a bit trickier than just implementing an interpreter indeed. Like the FOR statement example you mentioned. Another messy situation is non-lexical FOR/NEXT like here [1], where NEXT can be encountered before a FOR statement, fairly certain I did not get it entirely right there.
Original Dartmouth BASIC had only 14 statement types, and it takes very little efforts to enumerate and implement all of them, even if you are just starting on a compiler journey and making things up suboptimally along the way.
The bonus upside for choosing BASIC as your first compiler project is that you get decades of vintage test programs to play with like this one [2].
What you described is called Continuum hypothesis[1]. Surprisingly it cannot be proven to be either true or false from(is independent of) ZFC set theory.
This number is the result of a "large number duel"[1] between MIT Associate Professor Agustin Rayo (The Mexican Multiplier) and Princeton Associate Professor Adam N. Elga (Dr. Evil)[2]. Possible the world record largest number by some standards.
I would recommend check out urealms[1]. It is a improv/role playing show running on rules similar (but simplifed) DnD rules. The format is a group of twitch personalities steam their gameplay for a live audience, contents including improv jokes, pre-planned dramma, pre-made animation cut scences and at the center of it, dice-roll based table top game play.
The primary tool used for the show is tabletop simulator[2], which is a game designed for any tabletop games: cards, dices, chess etc. and can be customized quite a bit. It's mostly a low-tech solution, replicating physical acts of throwing dices, moving pieces and shuffling cards on a virtual table. In addition, the creators of URealm also invested in other custom softwares and artwork. However, the show is a for-profit project seeks to provide entertainment value for an audience rather than purely for the enjoyment of participants.
Oh nice. I have been writing a BASIC bytecode interpreter (and a compiler for WebAssembly)[1] in Rust.
It's a bit slower to get rolling than Python - especially function value representation and dynamic dispatch, unlike Python, could not just make a callable object on the fly. Handling function/procedure calls in a stack VM is definitely a fun exercise, and there seems to be many ways to skin the cat. Shared vs. dedicated data stack across functions, adding registers (unlimited number if required) etc.
Hooks reminds me of tensorflow scopes a little bit, in python:
with tf.variable_scope("foo"):
with tf.variable_scope("bar"):
v = tf.get_variable("v", [1])
assert v.name == "foo/bar/v:0"
`v` tensor here will have a generated human readable unique name here: "foo/bar/v:0"
It seems with hooks, react uses call order to derive the unique "leaf" hook id for runtime resolving its implementations. However, it would be nice if react hooks can automatically provide a similar human readable "hook id" (even if only for dev/debug build).
Could something like this be used to move the "linting" that the react team recommends directly into react itself?
If you can abuse error stack traces to get the call stack, and some trickery to get the string representation of the component function that called the hook (following it through all intermediate custom hooks), you could then have the full text of the function body and know for sure that it's calling a Hook, and from there could run some linting on that internally and scream to the console if a hook is being used incorrectly.
It may have a pretty significant performance and possibly size overhead depending on how much code is needed to inspect the function body and actually do the parsing/linting, but removing the need for a linter ("need" might be too strong of a word?) would make it easier to get started with, and safer to use for developers who, like it or not, don't read docs fully, don't setup or use linters, or just want to throw something together with very little tooling. And obviously it would all be stripped from production builds.
Has the react team explored this idea? and are there reasons that I'm missing that it won't work or isn't ideal?
Sebastian’s comment (which I linked to throughout the post quite a few times) mentions we will probably do some DEV time validation with similar techniques. I really suggest to read it all — my post wasn’t intended to answer all questions.
My apologies! I was on mobile when I read it last night and the RFC links don't seem to go directly to the comment on my android device for some reason! (it loads the full list of comments, but never takes me to the correct one, and searching for sebastian didn't show any results, i guess because his username is the only thing that shows up)
In this case, I think Java's lack of tuples adds quite a bit of syntactic noise, a similar version in rust (another language with method chaining based iterators):
let generated: Vec<i32> =
itertools::iterate((0, 1), |&(a, b)| (b, a + b))
.map(|s| s.0)
.take(10)
.collect();
Arguably, this is closer to the matrix form of Fibonacci series[1]. In addition, the same code structure can generalize to any series with a recursive definition in the form of: a_n = f(a_{n-1}, a_{n-2}, ..., a_{n-k}) - which by some standard expresses intent better. Especially, for some k, the mental overhead of a loop version is too much to bare :)
Really impressed! Took a quick look at page source, a couple of observations on why it's fast:
1. Plain, small html - page size is 6.1 kb (request took 700ms for me, I guess the server side rendering is pretty fast too), css file 11kb; note html, css and js are all properly minified
2. Font-awesome and jquery at the bottom of page to not block page rendering, both loaded throught cdn (although a fallback jQuery exists)
3. Site's own js is only 5.6k
4. No large static assets, only image on page is an svg dlogo
5. Did not check with js off, but saw hints of decent fallbacks for no-script
* the table: a combination of `Array`, `Map` and `Map<Number, T>` can prettify much cover typical usecases of lua tables, so js is close in this regard
* Vararg expressions, check
* Lexical scoping, check
* Iterators, check
* Coroutines, with libraries and abstractions on top of generator functions
In addition, in js land, other paradigms of concurrency exists, such as CSP (goroutines), FRP (Rxjs and co). Of course, these can be implemented in Lua as well, but the libraries may not quite as battle-tested.
The author also mentions a sane coercion system; this still true, but ever since "use strict", unexpected coercions can mostly be avoided in js.
On the other hand, js has:
1. Typescript and static typing (a bit unfair to consider this js, but ts gets access to a large portion of high quality npm packages), flow is also great
2. Multiple mature echosystems of UI frameworks (React) - for instance if you need a date picker or an autocompleter, it's just `yarn add` away; I doubt enough such libraries exist for browser side lua yet
3. Tooling support - webpack, prettier, postcss and so on
I like lua, but I feel it does not offer much in addition to what modern js already provides. Of course bring more languages to the browser is always a good thing, on the other hand I do feel this is a tough sell to the larger community.
I think you misunderstand the aim of the article. It’s not a case and point against js but for Lua in the browser. When I list positive points of Lua, I’m not implying they don’t exist in JS.
Interesting mention of create-subscription[1], first time I have heard of such a library/api. Seems it's part of official react repo. Looks like a great piece of utility for interfacing rxjs/xstream etc. Observables. I guess this may replace recompose[2]'s Observable utilities as it's officially endorsed by react team.
Current react ecosystem broadly speakings splits on state management solutions in two styles:
1. Single Observable-like source of truth (redux store)
2. Multi-Observables (relay, appolo, mobx)
It will be interesting to see if `create-subscription` catches on, and whether library authors will start exporting subscriptions as public apis.
That's because it's a new addon library from the React team, intended to help handle several tricky bits of timing and behavior in how updates get passed to React.
Original Dartmouth BASIC had only 14 statement types, and it takes very little efforts to enumerate and implement all of them, even if you are just starting on a compiler journey and making things up suboptimally along the way.
The bonus upside for choosing BASIC as your first compiler project is that you get decades of vintage test programs to play with like this one [2].
[1] https://github.com/yiransheng/basic_rs/blob/ddd64e2eacfc2b36...
[2] Game of Life compiled to warm: http://subdued-afternoon.surge.sh/