null references redux + Looney Tunes

[Andrei Alexandrescu]

language_fan wrote:
> On Sun, 04 Oct 2009 04:28:35 -0500, Andrei Alexandrescu wrote:
> 
>> language_fan wrote:
>>> On Sat, 03 Oct 2009 16:39:29 -0400, Justin Johansson wrote:
>>>
>>>> People might remember that when I picked up D and joined this forum
>>>> just some 3 or so weeks ago I made mention of being a Scala
>>>> refugee.***  When asked what I didn't like about Scala I commented
>>>> about there being too many language constructs.
>>> Compared to D that is not even true. The Scala language spec lists 40
>>> keywords + 10 additional reserved tokens. D 2.0 spec lists 106 keywords
>>> + a bit over 60 reserved tokens. In general there are no features in
>>> Scala that are not built around those keywords and tokens. The keywords
>>> and token are not more heavily overloaded than in D, on the contrary in
>>> my subjective opinion.
>>>
>>> So how I see things is that the language core in Scala is about 75%
>>> smaller, faster to learn, and easier to reason about. I have to admit
>>> that the features often are more powerful than in D. You need to
>>> recognize concepts like contra/co/invariance, higher order functions
>>> and kinds, and algebra that is based on terms discussed in lambda
>>> calculus books.
>> I agree that a hemorrhage of keywords is of dubious value, and Walter
>> has been much more generous with keywords than I would have ever liked.
>>
>> Assuming you're not hanging out in this group just to feel smug: what
>> steps do you think we could take to make D a better language than it
>> currently is?
> 
> I would concentrate on combining and generalizing the core constructs and 
> types to cut down language complexity. Starting from basic algebraic 
> facts, D lacks built-in first class sum and product types. Higher order 
> type operators also feel like a hack. The level of orthogonality is often 
> very poor -- this is the result of the uncontrolled language evolution. D 
> was not designed to be very orthogonal in these respects. Practical 
> languages are rarely built with types in mind. Same applies to rationale 
> behind built-in meta-properties of types and free function like 
> constructs.

Well this is a bit vague to act on. So, you say D lacks built-in 
first-class sum and product types. Yet Tuple is a product type. In spite 
of appearances, it's a built-in type, just that it has no literal. I 
don't see that a deal breaker. Then I fail to find fault for Algebraic 
(in std.variant) as a sum type. I need to add visitation to it, but 
other than that I don't think Algebraic is worse than a built-in type.

I agree that the language is unorthogonal but realistically there isn't 
a lot we can do about that now.

> Even though templates and string mixins provide some kind of macro 
> facility, I would like to offer something more Scheme like, with Template 
> Haskell like flavor. String mixins are powerful, but unfortunately they 
> do not provide any kind of meta-level type system. As a result the 
> compile errors on the wrong abstraction level. It also fails at capturing 
> symbol references in a nicely scoped manner. Andrei, I remember you also 
> suggested all kinds of macro systems, but the discussion died ages ago.

It hasn't died. We just concluded that it would take many months to 
define and implement a decent macro system. We also had a ton of other 
things to do, so we decided macros have to wait.

> In OOP I have found Scala and some prototype based OOP languages to 
> behave in the most elegant way. You should read the OOP articles by 
> Odersky. For instance, try to find a solution to the Node-Edge subtyping 
> problem in D. Experiment with traits to see how powerful they are. Try to 
> find justifications for the lack of genuine new features of Scala (self 
> types, etc.).

I am very familiar with much of Odersky's work and have a lot of respect 
for it. But then Walter created D and has brought his world view in D, 
not someone else's. We can't go like, hey, let's wheelbarrow whatever's 
good in language X into D. That's why I specifically asked "what steps 
we need to take" hoping for much more detail and aim at integration than 
"Scala is good".

Regarding the Node-Edge subtyping problem, I'd appreciate a link. The 
first relevant result returned by Google is your own post :o). Is this 
relevant?

http://www.jot.fm/issues/issue_2008_06/article3.pdf

> I cannot foretell how changing the low level abstractions changes the 
> overall look and feel. Probably some constructs become unnecessary, 
> others will remain. I do not have the skills to build a full language 
> that works optimally in all possible ways.

I guess you're in good company - nobody quite does.

> The keyword comparison was a bit unfair. I find it acceptable for a lower 
> level language to have a bit more keywords since there are many hardware 
> capabilities that need to have a mapping on the language level.

I don't know. I agree that D's relative abundance of keywords doesn't 
seem to be a huge problem in practice, but I also think we shouldn't add 
many more lest a phase shift of sorts occurs. And then just like you I 
prefer orthogonality, and abundance of keywords is abundance of magic 
and exceptions. I'd prefer "classinfo" to be an identifier like any 
other and obey the same rules that every symbol in its scope does. I'm 
very happy that Tomasz Stachowiak revealed to me that in-situ class 
allocation can be elegantly defined as a library facility. I don't care 
for foreach_reverse because foreach (e; retro(r)) actually does better. 
The popping of "length" in scope inside slice bounds is about the most 
distasteful hack there is, which gives the "length" keyword an 
almost-keyword status. And so on...


Andrei