Interestingly, my background is close to that of Walter: I also developed video games for a living, I also worked on a commercial C++ implementation, and I also designed my own language, called LX. More information on LX can be found at http://mozart-dev.sf.net.

So I am going to start a big series of post to try to compare D and LX. To avoid polluting the newsgroup too much, I am going to try to post all of them under the same thread.

I am obviously biased. On the other hand, I believe there is much to be gained if we exchange ideas and compare designs. Please bear with me...


Christophe

1/ Macros

I do believe in the necessity of macros. Because it is simple technology
doesn't mean it is obsolete (unlike "register ;-) It is obsolete only for
modularization (#include). But there is still no better way for
environment-dependent compilation (#ifdef), or for textual replacements
(see my extensive use of '.tbl' files in the LX compiler). Back in the
1990's, I worked on the Alsys Ada compiler, which had a hidden preprocessor
for internal use (#ifdefs), disabled on customer versions since that was
not part of the Ada spec. I always
thought this was silly :-)

Your examples did not convince me either: you take seleted examples of
macro applications (for example dealing with different compilers), and then
say "it's useless in D". Well, then, you have to make sure that D
is absolutely perfectly portable. I hope you covered the various cases of
machine idioms that I documented in
http://home.earthlink.net/~descubes/C-- and in particular, that you have a
D-defined identifier for everything that has possibly ever been put in an
autoconf file :-)

Another point is that, if you don't have a standard preprocessor, then your customers will use another one. I have this very problem with LX, because one part of its syntax makes it incompatible with the C preprocessor (LX numbers like 16#FFFF), so I need to recommend another preprocessor like m4, which is quite complicated...


Christophe

2/ Why D?

When I was slashdotted on LX, I got one major feedback: you need to explain why people would need to use your language, what it does that C++ or Java can't do. Curiously, ease of use or implementation is a concern only to a microscopic minority. Even the '10% productivity increase' claim you make is probably difficult to sell. Hey, Perl is a successful language!

In the case of LX, the objective is to make a compiled, yet extensible programming language. There are many things you can write in LX easily that you can absolutely not write in C++ or any other existing language. See some examples below (in future posts), or on http://mozart-dev.sf.net/lx.html.

This doesn't mean that simplicity and ease of implementation / specification are not important. They were the starting point for LX initially. But they are now only secondary objective, and I "sell" LX differently than I used to.


Christophe

3/ C source code compatibility

If you decide to drop it, you may as well go the whole way. LX, for instance, has an indentation based syntax with a lot of optional punctuation that makes it much more concise than C or C++ in many common cases, even though it appears more verbose at first. My gut feeling there is that D is only a marginal, incremental improvement over C or Java, whereas LX is a radical change (for the best, I hope). But of course, I am very biased...

Maybe it's time to give an example:

 import IO = LX.Text_IO

 -- Validated "template" type: "integer" passes the test, "object" doesn't
 generic type ordered if
  with ordered A, B
  with boolean C := A < B

 -- This function is implicitly template because "ordered" is.
 function Min(ordered A) return ordered is
  return A

 -- This function takes a variable number of arguments
 function Min(ordered A, others) return ordered is
  with ordered B := Min(others)
  if A < B then return A; else return B

 procedure TestIt() is
  with integer X := Min(5, 4, 2, 3, 1, 5)
  with real Y := Min(1.4, 7.0, 2.9)
  IO.WriteLn "X=", X, Y format "Y=#5.9#"


Christophe

4/ Multiple inheritance:

I think you did almost the right thing: dumping implementation-side multiple inheritance, while keeping it at the interface side. But here too, I believe LX goes one step further, by also decoupling interface inheritance and implementation inheritance for the single-inheritance case:

 -- Interface inheritance
 type large_integer like integer
 function Foo(integer I) return integer
 function Bar(large_integer L) return integer is
  return Foo(L) -- OK

 -- Implementation inheritance. "record" is an empty base type
 type point_2D is record with
  coordinate X, Y
 type point_3D is point_2D with
  coordinate Z


What this gives you is more flexibility for future evolution of the software, because implementation and interface are no longer so tied together.


Christophe

5/ Templates

You say that you are looking for a solution. Look at the LX generic types, I'm sure they will give you interesting ideas, notably implicitly template types ("ordered" above). Any template type like array also makes functions that use it implicitly template, which reduces the code clutter in things like the STL dramatically. LX generics can be parameterized with any kind of object, not just integer/types (see the parameterization of array with a range argument below).

 generic [type value] type range written range of value is
 record with
  value low, high
 function range(range.value low, high) return range written low..high is
  result.low := low
  result.high := high

 generic [range index; type item] type array
  written array[index] of item

 function Min(array A of ordered, others) return ordered is
  result := Min(others)
  with array.item I
  for I in A loop
   result := Min(result, I)

Template validation (see ordered) and predicated template specialization
also simplify many things:

 -- C++ style full specialization
 generic type array for array[1..5, integer]

 -- C++ style partial specialization
 generic [range index; type item] type array for array [index,
pointer[item]]

 -- Predicate-based specialization
 generic type array when size(array.item) = size(integer)

Granted, some of this is a bit difficult to implement, and my LX compiler is only halfway through it... But I'm making good progress already.


Previous posts suggested the Ada or Eiffel generics model. There was one major difference between Ada and C++: implicit instantiation. In Ada or Eiffel, you have to explicitly instantiate everything. This basically makes the STL impossible to implement.



Christophe

6/ Creating objects on the stack

You say that in D, all objects are by reference. This makes "integer" different than objects, and that was a compromise I was not willing to make for LX. Instead, "integer" is not a built-in type any more than any user-defined object type. Also, for several types (notably simple template types), having them stack-based makes them much more efficient.

 -- I want this to live on the stack.
 type complex is record with
  real Re, Im

Using LX pragmas, it is possible to define on a per-type basis how the compiler accesses it. Among the default pragmas are the {dynamic} pragma that specifies that a type resides in garbage collected memory, and thus is always referenced to. At the root of the LX type hierarchy is "record" (and "module", which is just "constant record"). Right above it is "object", which is just "record" with the {dynamic} pragma. So anything that derives from "object" is dynamic.

 -- I want this to reside in garbage-collected memory
 type tree is object with
  tree left, right
 function tree(tree left, right) return tree is
  -- Implicit allocation occurs here.
  result.left := left
  result.right := right

 -- I want to do this with a stack based object as a root:
 {dynamic} type complex_tree is complex with
  complex_tree left, right



Christophe

7/ Trigraphs:

Full agreement here. The current LX specification says that an LX compiler must accept, in preferred order: Unicode source, ASCII source, proprietary character set, and that if the native charset is proprietary, then an import and export procedure to Unicode and ASCII must be provided.

However, I disagree with the runtime types. You are asking questions about ascii or unicode or char. Well, if these were not basic types, there would be no need to ask. So in LX, the LIBRARY will define the following:

    - A generic "character" type

    - A char type, which is a specialization of character for the most
common char representation on the machine

    - Modules for Unicode, ASCII and EBCDIC encodings that offer:

    - a basic type for representing the chars in memory (ascii, unicode,
etc), which is a specialization of character

    - conversion routines to generic char types, I/O, etc. They also
contain declarations for things like: ASCII.CR, ASCII.LF, etc.


Something I will repeat like a mantra in my posts: built-in types are EVIL. Yucky. Don't do that. Keep clear. _That_ is obsolete :-)


Christophe

8/ Operator overloading

Total disagreement here :-) Operator overloading is at the very core of the LX syntax, but it takes a completely different approach than C++ (the 'written' keyword that you may have seen in previous posts already). Written allows for N-ary operator overloading, and also the definition of new infix named operators and implicit conversions:

 function And(integer A, B) return integer written A and B
 function MultiplyAndAdd(matrix A, B, C) return matrix written A*B+C
 function real(integer N) return real written N

Without operator overloading, you miss big time on most scientific applications... What is necessary is a much simplified set of lookup and implicit conversion rules, which LX provides (it fits on a page, literally)

I also disagree that you can't use operator overloading to create libraries that work. Blitz++ is a good counter example.


Christophe

 9/ Object oriented gradualism

I just have no idea what you mean by that :-)


Christophe