null references redux + Looney Tunes

Jeremie Pelletier jeremiep at gmail.com
Sun Oct 4 08:36:52 PDT 2009


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.
> 
> 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.

I couldn't agree more, string mixins often feel like a hack in D and you 
lose all semantics informations an IDE can use to generate intellisense 
for example.

> 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.).

Aren't prototype based objects only possible with a VM? I mean the 
prototype can be extended at anytime throughout the execution. It also 
adds a level of indirection since the objects don't hold a direct 
reference to the vtable, they hold a reference to the prototype which 
contains the dynamic vtable and string identifiers are used to resolve 
calls to the proper method since vtable indices aren't known at compile 
time.

Prototype based OOP is a great model, but I don't think it can be 
implemented in compiled languages like D.



More information about the Digitalmars-d mailing list