5 ms·
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 ef
by cxr 10mo ago
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%20language%20skin https://hn.algolia.com/?type=comment&prefix=true&query=cxr%2...>
2. <https://old.reddit.com/r/Oberon/comments/1pcmw8n/is_this_sacrilege/nt18w18/?context=3 https://old.reddit.com/r/Oberon/comments/1pcmw8n/is_this_sac...>
- nine_k 10mo agoNot "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.
- cibyr 10mo agoPeople fight about tab sizes all the time though.
- dbdr 10mo agoThat'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 10mo 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)
- philsnow 10mo agoDo you mean that files produced with "wide" tabs might have hard newlines embedded more readily in longer lines? Or that maybe people writing with "narrow" tabs might be comfortable writing 6-deep if/else trees that wrap when somebody with their tabs set to wider opens the same file?
- fc417fc802 10mo agoI don't see why? Your window width will presumably be tailored to accommodate common scenarios in your preferred tab width. More than that, in the general case for common C like languages things should almost never be nested more than a few levels deep. That's usually a sign of poorly designed and difficult to maintain code. Lisps are a notable exception here, but due to limitations (arguably poor design) with how the most common editors handle lines that contain a mix of tabs and spaces you're pretty much forced to use only spaces when writing in that family of languages. If anything that language family serves as case in point - code written with an indentation width that isn't to one's preference becomes much more tedious to adapt due to alternating levels of alignment and indentation all being encoded as spaces (ie loss of information which automated tools could otherwise use).
- somat 10mo agoI find it tends to be a structural thing, Tabs for indenting are fine, hell I prefer tabs for indenting. But use tabs for spacing and columnar layout and the format tends to break on tab width changes. Honestly not a huge deal but as such I tend to avoid tabs for layout work.
- fc417fc802 10mo agoI completely agree, hence my point about Lisps. In terms of the abstraction a tab communicates a layer of indentation, with blocks at different indentation levels being explicitly decoupled in terms of alignment. Unfortunately the discussion tends to be somewhat complicated by the occasional (usually automated) code formatting convention that (imo mistakenly) attempts to change the level of indentation in scenarios where you might reasonably want to align an element with the preceding line. For example, IDEs for C like languages that will add an additional tab when splitting function arguments across multiple lines. Fortunately such cases are easily resolved but their mere existence lends itself to objections.
- brabel 10mo 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 https://www.youtube.com/watch?v=lKXe3HUG2l4
- nine_k 10mo agoAlso consider translation to non-English languages, including different writing and syntax systems (e.g. Arabic or Japanese). Some languages have tools for more or less straightforward skinning. Clojure to Tamil: https://github.com/echeran/clj-thamil/blob/master/src/clj_thamil/%E0%AE%AE%E0%AF%8A%E0%AE%B4%E0%AE%BF%E0%AE%AF%E0%AE%BF%E0%AE%AF%E0%AE%B2%E0%AF%8D.cljc https://github.com/echeran/clj-thamil/blob/master/src/clj_th... C++ to distorted Russian: https://sizeof.livejournal.com/23169.html https://sizeof.livejournal.com/23169.html
- deleted 10mo ago[deleted]
- dualogy 10mo 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 10mo agoI 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.
- xigoi 10mo agoIndentation is just as explicit as braces.
- scns 10mo agoI wanted to give Python/Gdscript syntax to any & all the curly languages (a potential boon to all users of non-Anglo keyboard layouts) Neo makes it really easy to type those https://neo-layout.org https://neo-layout.org
- procaryote 10mo agoLowering the barrier to create your own syntax seems like a bad thing though. C.f. perl.
- rao-v 10mo agoOne day Brython (python with braces allowing copy paste code to autoindent) will be well supported by LSPs and world peace will ensure
- twic 10mo agoSyntaxError: not a chance
- xigoi 10mo agoWhat editor are you using that does not have a way to paste code with proper indentation?
- rao-v 10mo agoThere is not enough information in pasted code for a language server to indent pasted in python code. Try copy pasting a random stackoverflow snippet into deeply indented python code.
- xigoi 10mo agoWhy would you need a language server for that? You simply prepend the indentation of the current line to every line of the pasted text.
- kevin_thibedeau 10mo agoVB.Net is mostly a reskin of C# with a few extras to smooth the transition from VB.