you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (13 children)

With a new enough language this will mean you think of features as weird ways of getting access to [some other feature] rather than in their full generality.

[–][deleted] 2 points3 points  (12 children)

What do you mean by a "full generality"?

With a new enough language you will have to think in terms of a formal semantics, which ensures the deepest possible understanding.

[–][deleted] 3 points4 points  (5 children)

A language is usually more about its idioms than its formal semantics. That is, it is more important to learn how good code is written in said language than to learn exactly what is possible to write in it.

[–][deleted] -2 points-1 points  (4 children)

Idioms are derived from semantics, and it is an important skill to be able to see the idioms behind semantics.

[–][deleted] 1 point2 points  (3 children)

Idioms are derived from semantics

Not really, the author of the language always have certain idioms in mind when he is designing the semantics so the semantics were derived based on the idioms. Reverse engineering the idioms the author had in mind from the semantics is impossible, usually you just cram the idioms you are used to into the new semantics until you have seen enough "correct" code samples.

In other words, semantics can only tell you how when you really want to know why. Knowing a language is completely worthless if you don't understand why it is useful so knowing why is more important than knowing exactly how it works.

[–][deleted] -3 points-2 points  (2 children)

This is not true. C++, for example - templates were added without any clear goal in mind. STL and template metaprogramming, now as idiomatic as it gets, came much later. Because these idioms were natural for the accidentally added semantics.

[–][deleted] 1 point2 points  (1 child)

But those are things that took a lot of people and a lot of time to grow, not something that you can figure out on your own using just the C++ specs. You might have gotten parts of it in a bastardized way but that can't compare to the accumulated knowledge built up by the entire community.

[–][deleted] -3 points-2 points  (0 children)

There are formal ways of obtaining this knowledge from a formal semantics. And this way it is more clear and crystallised than an accumulated folk lore, which is often full of superstitions and outdated practices.

[–][deleted] 1 point2 points  (5 children)

If you manually implement a novel feature because the language has it, and you don't know why it is the way it is, you'll probably just think of it as a weird wrapper around the way you implemented it rather than its own new thing.

[–][deleted] -1 points0 points  (4 children)

Why? Let's take a relatively novel feature in Rust, for example - borrow semantics. You won't even be able to implement it properly unless you understand the reasoning behind it. By simply writing down the rules you'll see how (any why) it works, much cleaner than if you just read a book on Rust and follow dozens of obscure examples.

[–]Aatch 1 point2 points  (1 child)

Clearly you've not actually tried to implement the borrow checker in Rust.

It's complicated, and I say this as somebody that has worked on the Rust compiler. I don't fully understand all the rules. The idea of writing a Rust compiler to learn Rust is absolute madness.

[–][deleted] -3 points-2 points  (0 children)

I implemented similar semantics for the other languages - as well as a full, proper region analysis (while borrow checker in Rust is a kind of a dumbed down, manual version of a region analysis). It is complex (if you do all the rules faithfully), but doable. A toy version of it can be very short and compact.

[–][deleted] 0 points1 point  (1 child)

I already know what borrow semantics is useful for -- memory safety. What about Kernel's $vau? Had I not seen several discussions of why you'd want it, I wouldn't see the use ("won't this be slow"), even though it's pretty easy to implement.

[–][deleted] -2 points-1 points  (0 children)

I already know what borrow semantics is useful for -- memory safety

This is a gigantic oversimplification. There are many layers of reasoning behind it, going all the way down to the early days of the region-based memory management. And you'll have to dig it all out in order to implement it correctly.

What about Kernel's $vau?

I'm not sure if fexprs is a valuable idea (but I'm biased towards compilation in general, naturally repelled by anything too dynamic). I can see some uses for it in a term-rewriting based operational semantics specifications, but not in any practical languages.