Comment by cxr

Comment by cxr 17 hours ago

16 replies

It wouldn't fix the issue of semantics, but "language skins"[1][2] are an underexplored area of programming language development.

People go through all this effort to separate parsing and lexing, but never exploit the ability to just plug in a different lexer that allows for e.g. "{" and "}" tokens instead of "then" and "end", or vice versa.

1. <https://hn.algolia.com/?type=comment&prefix=true&query=cxr%2...>

2. <https://old.reddit.com/r/Oberon/comments/1pcmw8n/is_this_sac...>

nine_k 17 hours ago

Not "never exploit"; Reason and BuckleScript are examples of different "language skins" for OCaml.

The problem with "skins" is that they create variety where people strive for uniformity to lower the cognitive load. OTOH transparent switching between skins (about as easy as changing the tab sizes) would alleviate that.

  • brabel 16 hours ago

    > OTOH transparent switching between skins (about as easy as changing the tab sizes) would alleviate that.

    That's one of my hopes for the future of the industry: people will be able to just choose the code style and even syntax family (which you're calling skin) they prefer when editing code, and it will be saved in whatever is the "default" for the language (or even something like the Unison Language: store the AST directly which allows cool stuff like de-duplicating definitions and content-addressable code - an idea I first found out on the amazing talk by Joe Armstrong, "The mess we're in" [1]).

    Rust, in particular, would perhaps benefit a lot given how a lot of people hate its syntax... but also Lua for people who just can't stand the Pascal-like syntax and really need their C-like braces to be happy.

    [1] https://www.youtube.com/watch?v=lKXe3HUG2l4

  • dualogy 4 hours ago

    > transparent switching between skins (about as easy as changing the tab sizes)

    One of my pet "not today but some day" project ideas. In my case, I wanted to give Python/Gdscript syntax to any & all the curly languages (a potential boon to all users of non-Anglo keyboard layouts), one by one, via VSCode extension that implements a virtual filesystem over the real one which translates back & forth the syntaxes during the load/edit/save cycle. Then the whole live LSP background running for the underlying real source files and resurfacing that in the same extension with line-number matchings etc.

    Anyone, please steal this idea and run with it, I'm too short on time for it for now =)

    • Orygin 37 minutes ago

      I want to do the opposite: Give curly braces to all the indentation based languages. Explicit is better than implicit, auto format is better than guessing why some block of code was executed outside my if statement.

  • cibyr 17 hours ago

    People fight about tab sizes all the time though.

    • dbdr 16 hours ago

      That's precisely the point of using tabs for indentation: you don't need to fight over it, because it's a local display preference that does not affect the source code at all, so everyone can just configure whatever they prefer locally without affecting other people.

      The idea of "skins" is apparently to push that even further by abstracting the concrete syntax.

      • lucketone 16 hours ago

        > you don't need to fight over it, because it's a local display preference

        This has limits.

        Files produced with tab=2 and others with tab=8, might have quite different result regarding nesting.

        (pain is still on the menu)

rao-v 15 hours ago

One day Brython (python with braces allowing copy paste code to autoindent) will be well supported by LSPs and world peace will ensure

kevin_thibedeau 15 hours ago

VB.Net is mostly a reskin of C# with a few extras to smooth the transition from VB.

procaryote 15 hours ago

Lowering the barrier to create your own syntax seems like a bad thing though. C.f. perl.