disconcision

llm hole filling ala the paper is actually live in the dev version right now (if you enter an openrouter API key in the second sidebar tab). it's slow and buggy at the moment though, it's only been running at all for the last few days

i'm not convinced takeover is a fair description. its true that functional languages are over-represented in the more theory-laden subfields, but this is in on small part because functional languages are easier to reason about. 'reason' here is not intended in any prescriptive sense, just in the sense that they are more mathematically circumscribed. proving anything in an imperative language is going to mean proving it in the purely functional fragment of that language first and then drawing the rest of the owl, so when someone wants to try something new they're probably going to try it in mice first.

> used to remark that the the Matrix is the kind of movie the matrix would make to think you've won. The Wachowskis who are very American did not understand S&S

to be fair this is explicitly a theme in the (imo unjustly maligned) sequels

this is not quite right. haskell and scheme have if expressions, not if statements. that's not the same as if being a function. if is not, and cannot be, a function in scheme, as it does not have scheme function semantics. specifically, it is not strict, as it does not evaluate all its subexpressions before executing. since haskell is non-strict, if can be implemented as a function, and iirc it is

Here's a similar example using lean widgets (in the live programming part of the talk): https://www.youtube.com/watch?v=c5LOYzZx-0c

i mean they say the policy is open for revision and it's also possible to make exceptions; if it's an excuse, they are going out of their way to let people down easy

as a minor clarification balenciaga slides in good condition would probably be more like $100-250 used, though your point still holds

earliest sci-fi antecedent i know off: https://en.wikipedia.org/wiki/The_Man_Who_Sold_the_Moon

> Virtually everybody who ever lost a job to technology ended up better off for it.

this feels like a much stronger claim than is typically made about the benefits of technological progress

i think it's both, and more. i didn't read the ending as particularly opinionated about how 'real' the depicted emulation was, though i do think it had a decidedly hopeful tinge. the idea that we might somehow, in some way get the opportunity to do it over, to do it right, even if weird/contingent/incomplete, has i think a mythic resonance that transcends strict bounds of realism. even in a fully fantastic utopian afterlife unmediated by technology there would still be the question of whether this is 'really real': ontological, psychologically, etc. nonetheless, there are levels of unreality many seem willing to accept, the ending of 'inception' being another paradigmatic film example. i guess my perspective is that many aspects of 'real life' also abut artifice and pantomime (a phenomena not unrelated to the feelings of regret inspiring desire for strictly-impossible second chances), and the decision to accept anything as 'real' is always contains an element of tenuousness, uncertainty, and faith.

a big part of the racket project has been about establishing robust tools for transforming syntax. focusing on this use case has resulted in a much more generalized notion of pattern matching and template reconstruction than is typical. these kind of pattern/template combinators, as developed for racket/match and syntax-parse, might appear special-casey at first glance but from use i can attest that they are clean and compositional... they have the appearance of something you'd write informally on a whiteboard, but they really do just work, and the rules are fairly simple and easy to internalize.

Here, the ... pattern combinator means 'match a list (segment) consisting of the pattern Posn(x,y) zero or more times, and because (free variables) x and y are under one ... combinator, bind x to a list of xs and y to a list of ys'. The template combinator ... means 'produce a list (segment) consisting of the template Posn(x, y) zero or more times, returning an error unless x and y are bound to lists. The reason I specified 'under one combinator' for the pattern part is that ellipses can be nested, resulting in contained pattern variables being bound to lists of lists etc. anyway, point is, this is all just compositional rules, with no spooky communication needed between pattern and template. I won't objectively argue that it's not magic, but it's at least not more magic than regexps.

the visceral realization that something feeling incredibly deep and meaningful doesn't necessarily mean it's actually incredibly deep and meaningful, can, itself, be incredibly deep and meaningful. an opportunity to reset and recalibrate what you feel you want out of life.

you can use scale as an attribute independently from transform. this is essentially a shorthand but you can write `<div style="width: 10px; height: 10px; scale: 20"></div>` and it works just fine

i think this is just typical natural language ambiguity:

"Inverse Square root" is used to mean "(Multiplicative) Inverse (of the) Square root" as opposed to "(Square root) Inverse"

you can, for now at least, still use reasonML with js_of_ocaml to compile to javascript if you like reason syntax but don't want to a more complicated relationship with the ocaml ecosystem (we use this for https://hazel.org)

OP said it's a win for meta because it creates more engagement, which is a proxy for $$

sure, but if companies find that llm performance on tests is less correlated with actual job performance that human test performance, then that means the test might not be not a useful metric to inform automation decisions

how can you tell? likely this is field-dependent but even if because reviewers dont tend to comment on writing quality it doesnt mean it doesnt play a factor in acceptance. if you annoy people, (sometimes even especially) in ways that dont feel substantive enough to merit mentioning in a review, it can make them more inclined to be critical about aspects they might otherwise gloss over.

(i acknowledge this is unsatisfyingly unfalsifiable, and that it can also go the other way, in that selectively bad writing can be used to attempt to paper over holes)

what is the relevance of the quoted passage here? its relation to parent seems unclear to me.

it looks like a group consisted largely of ex-academics using aspects of the academic form but they stop short of framing it as a research paper as-such. they call it a technical report, where it's generally more okay to be like 'here's a thing that we did', along with detailed reporting on the thing, without necessarily having definite research questions. this one does seem to be pretty diffuse though. the sections on Specialization and Cultural Transmission were both interesting, but lacked precise experimental design details to the point where i wish they had just focused on one or the other.

one disappointment for me was the lack of focus on external metrics in the multi-agent case. their single-agent benchmark focusses on an external metric (time to block type), but all the multi-agent analyses seems to be internal measures (role specialization, meme spread) without looking at (AFAICT?) whether or not the collective multi-agent systems could achieve more than the single agents on some measure of economic productivity/complexity. this is clearly related to the specialization section but without consideration of the whether said emergent role division had economic consequences/antecedents it makes me wonder to what degree the whole thing is a pantomime.

re: the first: this is in contrast to traditional structured editors which actively prevent you from doing edits that break the tree structure, even if the next edit would immediately restore them. users tend to do these often when refactoring; we looked at some examples versus a trad structured editor (MPS) here: https://hazel.org/papers/teen-tylr-vlhcc2023.pdf

in general though i have mixed feeling about making structured editing more text-like; the above is just about trying to patch a hole in existing structured editors, which doesn't in-itself improve on text. i think we can do better than that; we're exploring more radical directions in a separate project. but i do think it is interesting to see how close to regular text entry we can stay while always maintaining a well-formed (though incomplete) parse state which we can use to constantly run type-checking and evaluation.

the current model partially succeeds in the above, but at some significant usability cost, including the fact the the backpack obscures what the actual underlying parse state is. the ghost model i'm describing can basically be thought of a generalization of the vscode parentheses insertion you describe; it just works for every multi-delimiter form (eg when you insert 'let' you get ghosts '=' and 'in', with appropriate holes inserted). the utility is (A) the same as an incremental parser in a language server (you get semantic feedback in every state), but because of the ghost/hole insertions it's crystal clear what the parse state is that you're getting feedback from. but yeah the current version doesn't live up to that standard

its a bug. we should be clearer that we dont 'officially' support mobile yet (in that no-one regularly tests with it) but the no keyboard insertion thing is a chrome-specific issue (it works on firefox but there are other issues there)

good questions! both will be addressed soon with david moon's new tylr version (tylr being the underlying syntactic engine for hazel). the new tylr is designed to take a grammar as a parameter; we have a javascript grammar and a partial rust grammar, and are planning editor integrations. the new model also eschews the backpack (the yellow thing that contains matching delimiters) in lieu of inserting missing delimiters as 'ghosts' in a way that always shows the exact parse that the semantics engine is using, but also doesn't prevent typing normally. the current backpack solution is the result of trying to balance natural text editing with mandated syntactic correctness and it definitely has proved to have some rough edges... more on the new system soon

there's this hacky quick way of partially emulating typed holes sans library too: https://dev.to/gcanti/type-holes-in-typescript-2lck

we (team hazel) recently used that device in our typescript version of a hazel setup for typed-hole-contextualized code completion as described in https://dl.acm.org/doi/10.1145/3689728

yes. also keen on first class modules (coming soon to Hazel). syntax could have easily been more haskell-like, current team is pretty ecumenical wrt surface syntax, excepting that i have as yet been unable to convert anyone to the gospel of s-expressions.

biggest reason more haskelley syntax didnt/hasnt happen/ed is the current syntax engine does not support significant indentation. hazel concrete syntax isn't stable yet though we're also thinking seriously about semi-colons

happy to answer hazel questions; ive been working on hazel as cyrus' phd student for the last four years, and am currently working on moldable projectional interfaces for live programming in hazel. here are some of the things ive added to hazel: https://github.com/hazelgrove/hazel/pulls?q=is%3Apr+author%3...

and here's me speaking last week about using typed holes and the hazel language server to help provide code context for LLM code completion: https://www.youtube.com/watch?v=-DYe8Fi78sg&t=12707s

we have ~ another year of basic type system and editor features prior to the 'doing something' phase. there are early-stage feature branches with stuff for web GUI programming & data science applications, but parts are awkward without in-progress basics like implicit polymorphism, a module system, and more sophisticated type inference.

not obviously the case. natural language also has tree/dag structure yet transformers do okay with it. encoding higher order structure in linear sequences seems necessary for transformers to be able to do most anything

> (nobody ever writes: bug introduced)

it's usually written "feature: ...

how do you figure? people were making directly analogous arguments about compilers back in the day. (not trying to argue that they are 'the same', but their is definitely a spectrum of code generation methods, with widely varying genres of guarantees, suiting a widely varying range of use cases)