Whole-known-network
<p><span class="h-card" translate="no"><a href="https://infosec.exchange/@adamshostack" class="u-url mention">@<span>adamshostack</span></a></span> Sssh, we do not speak of these things on non-covert channels!</p>
<p><span class="h-card" translate="no"><a href="https://hachyderm.io/@jschuster" class="u-url mention">@<span>jschuster</span></a></span> <span class="h-card" translate="no"><a href="https://mathstodon.xyz/@mudri" class="u-url mention">@<span>mudri</span></a></span> <br />This is a very reasonable question. It is hard to answer because there isn't a canonical answer for what the output of the parser is.</p><p>For instance, a typical parser does not type-check (which is clearly context-sensitive). But not everything may be context-free. E.g.: the AST may not just have "names", but may have bound instances referring to binding locations. If so, the parser needs to keep track of them as it goes along, which is context-sensitive.</p><p>Make sense?</p>
<p><span class="h-card" translate="no"><a href="https://scholar.social/@khinsen" class="u-url mention">@<span>khinsen</span></a></span> <span class="h-card" translate="no"><a href="https://fosstodon.org/@nilesh" class="u-url mention">@<span>nilesh</span></a></span> <br />The simpler answer is, macro expansion happens before parsing. It requires trees, hence it follows the reader; but it has constructs the parser may not know about and, more to the point, *does not need to* know about. So you can have all these extensions without having to change the core AST.</p><p>In practice, some Lisps have sufficiently complex macro systems that you have to interleave expansion and parsing: e.g., if a macro can ask questions like "is this variable bound".</p>
<p><span class="h-card" translate="no"><a href="https://types.pl/@disconcision" class="u-url mention">@<span>disconcision</span></a></span> <span class="h-card" translate="no"><a href="https://mathstodon.xyz/@zhxsdm" class="u-url mention">@<span>zhxsdm</span></a></span> <span class="h-card" translate="no"><a href="https://mathstodon.xyz/@j2kun" class="u-url mention">@<span>j2kun</span></a></span> <br />So they renamed it away from Luna to Enso to avoid collisions, thereby creating a new (admittedly very obscure) collision? It's particularly confusing because there are so many potential similarities between the two Enso's! (And funnily, I don't know any other tool called Luna, though they must be several.)</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@shriramk" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>shriramk</span></a></span> Your love of that ancient religion hasn’t helped you conjure up the stolen data tapes!</p>
<p><span class="h-card" translate="no"><a href="https://mathstodon.xyz/@juli" class="u-url mention">@<span>juli</span></a></span> Yes indeed! That is in fact exactly why the article says "blocks—the ultimate bicameral syntax".</p>
<p>Weapons from a more civilized age.</p><p>In the late 80s, PL and DB really embraced at Brown: both Zdonik and Kanellakis chaired DBPL. Plus on the OO side: Zdonik ⭢ OODBs, Wegner ⭢ Cardelli-Wegner, William Cook ⭢ modern OO theory! Will was always influenced by that DBPL vision.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Missed a bracket.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> I love it going to share that at work</p>
