>well, but that's secondary to the fact that C is like a compiled Java.

Typo... D is like a compiled Java, not C... ;-p

"Andrey Tarantsov" <andreyvit@nvkz.kuzbass.net> wrote in message news:agk0j6$1lml$1@digitaldaemon.com...
>
> > Have you actually used D, because it looks like C++ to me.
>
> No, I did not. I don't argue that D does not look like C++. The look can
be
> easily changed in a few days by rewriting compiler's syntax analyzer. I
say
> that the basic concepts of D are more like C++'s ones.
>
> >  You can even port (in a very round about way) C++ classes to D
> > and use very simular syntax methods to use them.
>
> That matters nothing. You can port C++ classes to Delphi very easily. In fact, you can even write a program that does it automatically. But there
are
> a lot of C++ applications (I don't mean "programs", just "ways to use
C++")
> that cannot be ported to D or Pascal.

> In fact, D is *very* similar to C#.
That is true. C# is simular too?

>
> They key features of C++ that make it feel like C++ are: templates,
macros,
> overloading of operators like ->, [], new, delete. Using this, you can
make
> anything look like anything else. That's the philosophy of C++, but not of Pascal, D, Java or C#. Among all these, I would prefer C# as the most balanced language. If I had much time (and wish) to spend on this, I would probably write a C++ environment that would suit me. But it's not an easy job.

I don't like that idea. Program languagues need to be standard. If you redeign the basic flow or look of the language you not only end up working against the grain, but you make it difficult for other users to understand your code. Macros also make compliation ineffecient because the compilier has extra processing steps.

> > Yes, but it also prevented effecient coding. Why does John Carmack use C/C++? Why are most OS written in C/C++?  Ada's a good learning language because the compiler holds your hand, but C/C++ is a power language.
>
> OK, all this is becoming a flame. I don't think we should discuss
languages
> as they are, but instead let's talk about concrete conceptions that can be utilitized in D. And, OSes are written in C/C++ because it allowes a very low-level code. Low-level does not mean only "very efficient", simply when writing OS kernel you do not need any of your language services (in particular, you wouldn't use dynamic arrays to store non-paged memory
pool).
> Also, C is used due to historical reasons.

It was not ment a a flame. But I think this type of talk is expected when discussing language design. There's alot of personal opinions out there. D also allows for low-level code. You don't have to use dynamic arrays. The GC can be turned off.

> Yes, C/C++ ("... OK, let's flame a bit...") is a powerful language when
you
> want to design a new environment. If you want simply to write programs,
any
> language whose ready-made environment suits your needs will do. Yes, I
some
> things (like lexical parsers) are always better expressed in C++ because
of
> it's pointer arithmetic. I think that's enough about the languages.
>
> > I prefer to spend more time designing a program before writing it. I
also
> > think it depends on what your using it for.
>
> By-the-by, what is D targetting for?

Effeciency and Simplicity. It's tring to not be like C# and Java which are a run-time language.

> > A good point about ada is that it is able to determine many errors
before
> > the program is even compiled. D is heading in that direction somewhat. Although it's keeping things more flexable.
>
> Unfortunately these aims might not be compatible. Either the language
limits
> you (limits not _what_ you can write, but only _how_ you can write it) and detects your errors, or the language allows you to write everything you
want
> how you want it, but then all mistakes are your responsibility.

There's always a toss-up between one thing and another. In rare cases you can have both.

> > D should support almost un-limited variable sizes. But I still want to
> know
> > the limit. For example on todays proccessors it would be infeasible to
> have
> > a variable 10GB integer.
>
> Show me a man that wants 10GB integers, I'll release a special compiler version for him (if he sends me an IA-64 processor and 10GB of RAM).

That's the idea. I simply ment I want the MAX value.

> > As I was saying dynamic arrays are extremely important and useful. I
don't
> > want to use a slow standard library to implement dynamic arrays.
>
> In what way shall std. library slow down dynamic arrays? Let's take C++.
>
> template <class T>
> class dyn_array {
> public
>     T &operator [] (int index);
> ...
> };
>
> When dyn_array::operator[] is called, it returns a reference to the array item. After you compile this and apply proper optimizations (inlining), I don't think there would be a way to implement dynamic arrays faster.

That's un-true. The more the complier knows about a program, the better it can optimise it. If it doesn't know that your writting a dynamic array lib, then how is it going to be-able to ie make it take advantage of parellel proccessing?

> Standard library does not slow your code! If the code written in D is inefficient, then fast dynamic arrays won't rescue your turtle app.
>
> The thing I was talking about: there should be a way to implement in D, if
I
> would like so, dynamic arrays, static interlocked lists or whatever. You
do
> understand it, so I don't think this question needs additional discussion.
> > What type of programs do you write?
>
> Just common Windows programs. (And, for fun, some libraries and small apps
> in languages like Ada.)
>
> And what sort of programs do YOU write? Are they real-time reactor control systems? Or probably a system software for winged missiles? I guess that
you
> simply love efficiency. And, for multimedia applications or other time-critical sections, even C# has sections marked with 'unsafe' where pointer arithmetic can be used. Maybe this is the right way of thinking:
the
> most of your app needs to be stable, and some critical parts should be as fast as possible (after a few days of debugging ;).

It was just out of interest (probably shouldn't have hadded that Guestimate). No need to start a flame.

3d programming is my hobby. 3D editors and engines. They need to be fast, and speed is 90% in the design.

> > The downside of this is flexibility.
>
> Have you seen ALGOL? I can tell you: you'll love it! There nothing more flexible in the whole world.

No I haven't. I said I aim for something in-between.

> ***
>
> And now my proposal.
>
> Languages cannot be invented and designed in the way D is. First,
everybody
> should say how do they see the language of their dreem (or, probably, just how do they think D should look like and what should it contain). Then,
all
> the proposals should be grouped, filtered and generalized. Then, you
choose
> what basic conceptions your language will be built on. And then, using
these
> conceptions, you try to produce a final language.
>
> D was designed in this way: you took C++, throw away everything you disliked, added everything you liked, submitted specification, throw away everything that is hard to implement, and wrote the alpha version of the compiler. That won't do. All the factors (ease of implementation, ease of understanding, ease of writing programs, ease of maintaining programs,
ease
> of writing correct code and finding bugs) must be considered from the very beginning, and all the features should make up a self-contained Language, not just a set of features under the common name.

Then we'd have to call it something else. As C was an extention of B and C++ of C we can't break that cycle. D is ment to be a new programming language based on C/C++. This is both for quick learning times and because C is the most popular language of all time.

> Here's a wrong list of study topics:
> WS1. Modules.
> WS2. Syncronization.
> WS3. Generics.
>
> As I can understand, current study topics are as follows.
>
> S1. Separate compilation. It is known that a program divided into modules
is
> easier to write, debug, understand and maintain. D should provide a
support
> for some kind of modules.

But D can be divided into modules?

> S2. Symultaneous execution capabilities (whether multitasking should be incorporated into the lang, how should tasks communicate, how will they access shared data).

D has support for this although I haven't used it.

> S3. Improve code reuse. This includes generics, probably macros (I don't

Generics are planned for 2.0.

> like them much, and you don't like them, so probably we can forget about them), nested modules like packages of Ada'95 (so that you can extend an existent library without altering it's source code).

That's what classes are for.

> Ada team said they
> considered "other types of type extension", that is, derivation of
> enumerations, extending ordinary records and so on. They gave up the idea
> because it's hard to implement. Should we?

> I think development of D should be a bit more organized. We should collect and keep all the ideas everybody has posted, we should add our ideas, then probably we should look at all the ideas and exchange our thought about revising the specification. Then we should revise it a few times until something very good is produced.
>
> 2Walter: probably it's time to give your comments about the overall discussion... What do you think about revising the lang?

Yes I'd be interested too.

>
> Regards!
>
> --
> Andrey Tarantsov.
>

Anyway enough said, because we are beginning to repeat ourselves.

Hello!

2Toyotomi:

> You sound like those Delphi people who think of C# as a Delphi ripoff and are completely ignorant of Java...

Well, I don't like Pascal at all (a year before I hated it). I think of C# because I like it & .NET Framework, and because I'm subscribed to MSDN Magazine that talks a lot about C#, so I can't forget it. C# is a C++ descendant. Java... well, I don't like it, but I did not have a chance to use it, so there's no serious opinion.

> D is designed to be a simple language - easy to write a compiler for and easy to learn.

This does not mean it would be easy to program with it. Standard Pascal is a very simple language, but it's very hard to write anything useful.

> That seems to be an argument in favour of a meta language - however the strength of a meta language is also its weekness,  where you are able to redefine the language and make it look like something else you also make
it
> more difficult to understand (and to parse).

Yes, I like the idea of metalanguages, but I'm also a bit tired of them, because there are no good class libraries, and I don't like writing everything myself.

FYI, do you know that C++ STL is originally borrowed from Ada Generics Library developed in early 1980s?

> Garbage collection,  although necessary for the language,  is implemented in a library not as part of the main language.
>
> D is not a descendant of C++, it is a descendant of C.  That idea being that D is what C++ should/could have been.

That's interesting. I like the idea to make a "good & easy to use C++". All right. Still, I don't like to move towards C# and Java then. In my opinion, they're too high-level anyway.

I can tell you that making a better C++ is a *very* serious... job. OK, going to think about the question.

By-the-by, what do you think about exceptions? As for me, I consider using classes for them usual, but nonneccessary. Anyway, I'm too lazy to define my own full-featured classes, so e.g. in Delphi I always write "ESmt = class (Exception);". Don't you think exceptions should not be classes?

1. Allowing to throw only descendents of a specific class (e.g. CException)
is a strange rule.
2. This would be ideal:

class EBadToken : exception {public: string file; int line, col;};

throw EBadToken ("My File", my_line, my_col);

Something like this: when a class has no constructors and has only public fields, it gets a constructor that can accepts arguments corresponding to all the fields and initializes them.

This is not a proposal, it's just an idea to discuss.

G/L!

Up front:  I agree with much of what you say.

"ôÁÒÁÎÃÏ× áÎÄÒÅÊ" <andreyvit@mail.ru> wrote in message news:agi9bb$240d$1@digitaldaemon.com...
> Hello everybody!
>
> I've recently read D language spec. I can't say I like D, but I like the fact that you're crazy enough to invent your own languages and technologies - just like me. (No, I have no languages of my own.)

I have only designed 2 languages (both script compilers)

> When I was a bit younger, I've tried to invent some languages too. Now I think that the language itself does not mean that much, am inventing new programming conception, use Delphi for my everyday programming and just
love
> Ada. ;-) I want to share with you some thoughts about D.

I once worked with an ex-marine on a Borland Pascal project.  He used to go on about ADA, but I never researched it much as it's not used much in day-to-day applications outside military circles.  Hard to find a compiler for.  ;)

> D needs much much much more designing. Currently it is like Object Pascal: you've just put together everything you like in all other languages. I
think
> it is really useful for everybody to learn Ada (by-the-by, a Pascal descendant), for that language has many samples of untraditional design.

I agree to some extent.  I think D's major shortcoming is its ancestry from
C.  That's also a perk, albeit one I personally don't need or want.  D
doesn't have many of the nice things about Pascal (ranges, sets) but it does
have many others (strings (darray of char), units (modules), module
init/deinit functions) and also some of the nice things about Java/C# (no
header files!!!, no forward declarations!!!, GC) while retaining some of C's
power (pointers, nice operators for basic types, and low-level programming)

All these languages have their good and bad points.  One could do much much worse than to just combine all the good points.  ;)

> There had been a language designed for everything at once: ease of programming, reading, typing, implementation, bug making. That's ALGOL. Do you want D to be a simple language (like Pascal) or a good language? I
think
> D needs a small-to-medium redesign. I propose a discussion about the concepts of D.
>
> First. You can't put everything into a language. Probably a language
should
> contain a basic, general set of... em, capabilities (not sure it's a right word), and everything else should be defined using the language itself.
Can
> you use a "naked" C++ for real development? No, you can't. You need some sort of programming environment. C standard library is the minimum environment. STL, MFC, C++ Builder's VCL add some useful features, but
still
> I think that there's no usable programming environment for C++. But the
best
> thing in C++ is that it allows you to create a very good one. Nobody did
it,
> however. :-) But is integrating a fixed programming environment into the language a best thing? That depends on the goal of the language:

I do agree that the language should attempt to make it possible to write your own "basic types" such as complex, quaternion, tensor, string, list, hashmap, whatever, all the way up through simple quick utility programs up through gigantic government database programs and missile guidance software and everything in between.  A programming language should be a toolset for building programs out of small parts.  The smaller the basic parts, the better... up to a point.  The dividing point is where the compiler can't figure out what it is that you're doing well enough to write optimal code. So a  few very low level features such as dynamic arrays are nice to have builtin to the language because (A) you don't have to write them yourself; you can always depend on them being available (B) you don't have to debug them, or step through or over them while debugging higher-level code, (C) the compiler knows what it is and can generate much better code than if it had to reverse-engineer the intent from your source code.  Also builtin types have a few advantages currently since there are no templates or operator overloading (yet!) it would not be possible to write a good darray at all in D yet.

I advocate putting the tools needed to build new low-level types into the language.  Those are:  generics, operator overloading, forced inlining, forced constant folding.  Introspection would help make generics easier. Unification of handling of builtin and user-defined types would also be a godsend.  This is something that really can't wait for version 2.0 because introducing generics will change the language enough to invalidate all code written to the D 1.0 spec.  Also I doubt it will gain major following until generics are supported.

> -> for small scripting languages for quick coding it is;
> -> for real system languages I think it's not.
>
> Specifically, I'm talking about dynamic arrays and garbage collection.
While
> GC is probably OK to be integrated into the language (as for GC to be implemented using D, D must be low-level enough), but things like dynamic arrays should be implemented using standard classes. Why? Because if
dynamic
> arrays can be implemented in D in a convenient and familiar way, then many other idioms (iterators, cursors, lists) can be implemented too.

I'd rather have alloca() and some kind of generic user-definable factory or allocator scheme than GC.  GC isn't a perfect solution for memory management any more than refcounting is.  At least it's safer than explicit malloc/free all over the place.

> Complex type. If you want to make every mathematical type a part of the language, I can tell you a lot of types that you've missed. :-) Complex
must
> be a standard class! With source code written in plain D. So that when I need Vector or Tensor type, I will be able to implement it as easily as Complex is. (Or, wouldn't you please add Tensors to D? ;)

And quaternions, and matrices, column/row vectors, geometric algebra, fixed point, big number, date, time, color, polygon, SIMD register types, etc, etc, etc.  Gotta draw the line somewhere.  I'd rather have language support for building my own basic types and enough tools and hints to the compiler that I can write a class that runs as efficiently as anything the compiler could generate.

> Why is D a descendant of C++, while it is much more like Pascal? The "spirit" of C++ is not a part of D, so I don't think it should look like C++. And, C++ is very self-contained language. I mean that adding
something
> new to it is not quite easy and seamless.

It's based off C, not C++.

> Well, at last, syntax does not matter. Here I want to describe some
concepts
> of my favourite language (Ada) that I think could be useful for D
> developers. Ada has two versions: Ada'83 and Ada'95 (the latter having OOP
> and a few other enhancements).

Syntax *does* matter.  A LOT.  Syntax is what I despised about Pascal the most.  Syntax is one of the major problems with C and C++.  Syntax is why I can't stand 99% of all the wierd little experimental languages you see being invented in universities.  Syntax will be a huge factor in influencing whether a language gains acceptance from the masses.

> 1. Types. In Ada, there exist types and *subtypes*. Types can derive from each other. Samples:
>
> type Foo_Integer is range 0 .. 2 ** 32 - 1;
> -- Foo_Integer is a completely new type. It is not compatible with
anything
> else.

This is typedef in D.  But D doesn't support ranges at all.  ;(

> type Bar_Integer is new Integer range -128 .. 127;
> -- This is a *derived* type. It inherites all "primitive operations" of
type
> Integer, is compatible with
> -- Integer if you use explicit conversion.
> -- To call it a "signed byte" we want to add an "attribute declaration
> clause":
> for Bar_Integer'Size use 8; -- use 8 bits for this type

Compiler should be able to figure this out for itself.

> subtype Boz_Integer is Integer range 0 .. 255;
> -- This is a subtype. It is like a synonim for other type, can be
implicitly
> converted back and forth.
>
> Int : Integer := 7;
> Foo : Foo_Integer;
> Bar : Bar_Integer;
> Boz : Boz_Integer;
>
> Foo := Int; -- this is invalid. Integer and Foo_Integer are not compatible Foo := Foo_Integer (Int); -- neither is this. They are really
*incompatible*
> ;)
> Bar := Int; -- Invalid! Thay are compatible, but they are different types.
> Bar := Bar_Integer (Int); -- Okay
> Boz := Int; -- Okay, as long as 0 <= Int <= 255. Else, Constraint_Error
> exception is raised.
> Int := Boz; -- Okay always.
>
> Ada's types are the most wonderful and logic things I've ever seen. They provide a lot of useful features not found in any other language. I think you should consider this approach.

That pascalesque syntax and whatever those apostrophe clauses are don't sit well with me.

> Somebody has asked for very long types here. They are made very easily:
>
> type Int_256 is range 0 .. 2 ** 256 - 1;
> type Float_Long is digits 20; -- 20 *decimal* digits precision at least

interesting (although it's going to get software emulation if you go past
precision of extended)

> type Fixed_Point_Dollars is range -10 ** 10 .. 10 ** 10 delta 0.01; --
Fixed
> point aka "Currency" type

Now this is really really cool.  ;)

> There is a "modulus" type like this:
>
> type Byte is mod 256; -- 255 + 1 = 0; 10 - 12 = 253, and so on

So you can declare bounded types and wrapping types.  But can you declare saturating types?

> type Wow is mod 7; -- useful for indexes: 6 + 1 = 0; 0 - 2 = 3.

Sounds really slow.  Could occasionally be useful.

> 2. Generics. Ada generics are the best! ;) But, they must be instanciated explicitly. Like this:
>
> generic
>     type Index is (<>); -- Index is any *discrete* type

What kind of wierd syntax is this?

>     type Elem is private; -- Elem is any fixed-size type supporting "="
and
> assignment

If you ask me (and you didn't) I'd want to be able to completely hide any private members from other code.  Other code shouldn't even know the private members exist.  Which means you need to be able to specify them from outside the externally visible declaration.

// visible interface

class Foo_public : private Foo_private
{
    void GoForIt();
}

// hidden somewhere

protected except(Foo_public)
class Foo_private
{
    int myprivateint; // nobody can see this but Foo_public
}

>     type Array is array (Index) of Elem; -- Array type
>     -- Also, we need a function for comparison. If it is not specified and
> Elem type
>     -- has overloaded "<" operation, it would be used by default.
>     with function "<" (A, B : in Elem) return Boolean is <>;
> procedure Generic_Sort (A : in out Array); -- body is somewhere else ;)
>
> ...

I can't follow that syntax.

> type Int_Array is array (Natural range 0 .. 20) of Integer;
> procedure Sort is new Generic_Sort (Int_Array'Domain, Integer, Int_Array);

What's with the apostophe operator?

> My_Array : Int_Array := (0 .. 5 => 1, 10 .. 15 => 2, 19 | 20 => 3, others
=>
> 0);
> -- look at array constant! Resulting array is (1, 1, 1, 1, 1, 1, 0, 0, 0,
0,
> 2, 2, 2, 2, 2, 2, 0 ... 0, 3, 3).
> Sort (My_Array);
>
> Of course, Ada is too conservative (though it really CAN be used in real development; I personally would like to use it very much, but there's no
GUI
> library, and I don't have time to develop it - but maybe some day I will), so for D a lot of restrictions must be revised. Still, how do you like the whole idea?

As long as ADA has been around, there must be something seriously wrong with it if nobody has developed a GUI library for it yet.

> 3. Packages. They are like this:
>
> -- in Foo.ads
> package Foo is
>     -- public part
> private
>     -- private part
> end Foo;

This is what I disagree with.  For one thing, the public and private sections can get to be HUGE.  I like D's attribute style.  And ideally you wouldn't "declare" anything that's supposed to be private.  Nobody outside needs to know it exists.

> -- in Foo.adb
> package body Foo is
>     -- body
> end Foo;
>
> While it looks so simple, Ada packages allow you to hide some details that C++ and Pascal does not allow to hide. Example: a linked list. In C++ it looks like:
>
> struct LinkedListItem { ... }; /* this is what SHOULD be hidden, but is
not!
> */
>
> class LinkedList {
> private:
>     LinkedListItem *m_pFirst;
> };
>
> In Ada, it looks like:
>
> generic
>     type Element_Type is private;
> package Linked_Lists is
>     type Linked_List is private; -- it's siply private!
>     Empty_List : constant Linked_List; -- private constant
>
>     -- here are *primitive operations* -- that is, operations with this
type
>     -- declared in the same package where the type is declared.
>     procedure Add (List : in out Linked_List; Elem : in Element_Type);
>     procedure Take_Out (List : in out Linked_List; Elem : out
Element_Type);
>     -- this can't be a function because functions can have only IN
> arguments - a
>     -- strange thing, but recently I've understood that it protects you
from
> wrong
>     -- design of your programs. Ada makes you use it's way of architecture
> design;
>     -- follow it or use another language, because non-Ada architecture
will
> never
>     -- compile, I know it myself.
>     function Empty (List : in List) return Boolean;
>
> private
>     type Linked_List_Item; -- forward declaration
>     type Linked_List_Access is access Linked_List; -- pointer type
>     type Linked_List_Item is
>         record
>             Data : Element_Type;
>             Next : Linked_List_Access;
>         end record;
>
>     type Linked_List is
>         record
>             First : Linked_List_Access; -- we could add initialization
like
> := null;
>         end;
>
>     Empty_List : constant Linked_List := (First => null);
>
> end Linked_Lists;
>
> package body Linked_Lists is
>     procedure Add (List : in out Linked_List; Elem : in Element_Type) is
>     begin
>         ...
>     end Add;
>     ...
> end Linked_Lists;

Linked lists are such a basic data type it should be builtin to the language.  Programmers hate having to reimplement list adding and list walking every time they need a list, and it's error prone.  Pointers (necessary to implement a linked list) are just too dangerous to leave laying around for some unsuspecting maintenance programmer to shoot themselves in the foot with.  But linked lists are FUNDAMENTAL and necessary and should be in the language.

> As you can see, Ada packages, like D modules, have one-to-one
correspondence
> with source files. But spec and body are contained in different files, and it's very useful for navigation purposes.

That's what an IDE is for.  I don't want D language spec to even have any clue that there are any such thing as .D files.

> In D docs, in several places you state that D compiler knows "all of the class heirarchy when generating code". It means that no separate
compilation
> was concerned during design. You must be aware that most users want to compile a part of their program, then develop another part and compile it without knowing the first part. You must clearly understand it. Of course, to assemble a final release version, one may put all the code together,
the
> your compiler really would know all the code. Probably this should be explained in the docs more clearly.

It has separate compilation;  haven't you tried it at all before making wild claims?  Of course you cannot declare a class in one module and put its implementation in a different module.  So when it compiles the class it does indeed know all that's necessary to generate code.  If it cannot know for some reason (templates or inline functions used in other modules) then it may have to generate code at link time.

> All right, I'm quite tired as it's now about 5:30 in the morning, and I'm going to sleep a bit. ;) Please, don't misunderstand me: I'm not
criticizing
> D, I want to to be a really good language, not just another one. If you
want
> D to be popular - make it better that widely used languages. It is NOT better now, it is just different. It is too simple and not-powerful. Explanation of C++ behaviour of exceptions raised during object
construction
> took a dozen articles in MSDN ("Deep C++"). Explanation of Delphi's behaviour takes a dozen paragraphs. It does not mean Delphi is simplier
and
> better - it means when an exception will raise in our constructor, you
will
> have much headache and thinking as Delphi was not thought over enough.
(Your
> destructors will get partially constructed objects! And you have to deal with it, instead of elegant solution of C++.)
>
> Good luck!

I also would beg to differ.  C++ isn't exactly what I'd call elegant.  It's nifty, sure.  But it's a behemoth.  The 900 pound gorilla of programming languages.

Sean

"ôÁÒÁÎÃÏ× áÎÄÒÅÊ" <andreyvit@mail.ru> wrote in message news:agj31a$tt$1@digitaldaemon.com...
> Hello, that's me again.
>
> Here's a small citation form Ada Rationale (part 2):
>
> --- cut here ---
>
> 1.1  Overall Approach
>
> Ada 95 is based on a building block approach.  Rather than providing a
> number of new language features to directly solve each identified
> application problem, the extra capability of Ada 95 is provided by a few
> primitive language building blocks.  In combination, these building
> blocks enable programmers to solve more application problems efficiently
> and productively.
>    Thus in the case of the object oriented area, much of the capability
> is provided by the interweaving of the properties of type extension, the
> child libraries and generic packages.  Great care has been taken to
> ensure that the additional building blocks work together in a cohesive
> and helpful manner.  Nevertheless implementation and understandability
> considerations have sometimes caused some restrictions to be imposed.  An
> example is that type extension of a formal generic parameter is not
> permitted in a generic body (which would either break the contract model
> or pose an intolerable pervasive implementation burden).

Like I said, I believe in the building block approach.  The language should allow you to build very fundamental types (such as a rangechecked replacement for int) without any additional overhead than the builtin type had.

Part of what you need to be able to do that is to be able to hide the fact that a class is user-defined.  That means, to not generate any debug info about the methods of the class, so that the debugger will not step into those methods (this is annoying for very basic classes such as string or vector or bignumber or date).  You need debug info when first making the class, or when debugging it.  Later when it's completely solid and bugfree, you should be able to disable debug info for any class or module.

> --- cut here ---
>
> I think that is what I've tried to tell you last time.
>
> By-the-by, look at Ada's tasking and synchronization approach. It uses two
> concepts: (1) a built-in multitasking support - an active object named
> 'task'; (2) a type with synchronized access - 'protected type'. (I can
post
> some information here, if you like, but I think you'd better download Rationale and read it yourself - in any case it's a very interesting document, that not simply describes what is included in Ada, but also explains why it is (and what for). IMO, should be read by all people that want to be language designers.)
>
> When calculating expressions and resolving overloads, Ada always considers the expected type. So, e.g., functions can be overloaded solely on the return value:
>
> function Create return Linked_List;
> function Create return My_Type;
> ...
> Foo : My_Type := Create;
>
> I like it, do you?

I'm ok with that.  I'd also want to be able to return tuples.

> About generics in Ada. I forgot to say that Ada do not have generic types
or
> classes (it does not have classes entirely). Instead, it has generic packages that may contain types or whatever. I think it's much better than generic types, because sometimes in C++ you write something like:
>
> template <typename T> class Foo {
>     // this is the nastiest: global operators must be template too
>     friend Foo operator* (int Left, const Foo &Right);
> public:
>     // some stuff that depends on the type T
>     struct Bar {T t};
>     ...
> };
>
> Ada does not have classes. You simply define procedures and functions that take your type as one of the arguments. OOP is implemented based on
Ada'83's
> type derivation. Record types marked with 'tagged' (i.e., they have a 'tag' - run-time information that is used to identify the type; usually
it's
> just a vTable pointer, but Ada standard do not specify what it is) can be extended.

I have thought that the OOP syntax sugar may be entirely unnecessary.  I guess the designers of ADA did too.  I think the main problem with using ADA today is that it does not have any concept of inheritance.

> type Base is tagged
>     record
>         A : Integer;
>     end;
>
> -- primitive operations (those defined in the same package)
> procedure Foo (Self : in out Base);
> function Bar (Self : in Base) return Integer;
> function Create return Base;

I find this distinction between procedure and function to be silly.  Unless you restrict functions so that they may not ever have side effects and are completely deterministic.  (i.e. if I call it twice with the same inputs, I'll definitely get the same outputs both times, so the compiler is safe to cache the first result and just use it twice)

> -- 'with record ... end record' is called a type extension;
> -- Derived is a new tagged
> type Derived is new Base with
>     record
>         B : Float;
>     end record;
>
> -- when you declare a derived type (not necessarily tagged), it inherites
> all
> -- primitive operations from it's base type. Some of them can be
overriden:
> procedure Foo (Self : in out Derived);
> -- note that function Create is inherited too. But it can't return a fully
> initialized
> -- Derived object, because it knows only about Base! So, it is inherited
as
> an
> -- *abstract* function, and must be overriden in Derived (or Derived will
be
> -- an abstract type):
> function Create return Derived;

Interesting.

> For now, Base and Derived are simply records. (They are compatible with
each
> other.) But you can declare a variable of a 'class-wide' that can hold any type derived from the given one:
>
> Var1 : Base;
> Var2 : Base'Class := Derived'(Create); -- we explicitly call Derived's
> Create
> -- if you wonder, Type'(Expr) is not a type cast - it simply indicates
that
> Expr
> -- should be of type Type. It is mainly used to specify array types in
array
> literals
> -- and so on.

I don't see the distinction between that and a typecast.

> Note that Var1 can hold only Base instances, and Var2 can hold both Base
and
> Derived (and anything else derived from Base). Ada *do not* use reference symantics, so Base'Class is an "unconstrained" type - it has variable
size.
> Once a variable of this type is initialized, variable becomes fixed. In
our
> example, Var2 requires explicit initialization, and after it can hold only Derived type instances. Usually pointers ('access types') are used with classes:
>
> type Base_Only_Access is access Base; -- can point ONLY to Base instances
> type Base_Access is access Base'Class; -- can point to everybody derived
> from Base
> Var3 : Base_Only_Access;
> Var4 : Base_Access;
>
> C++ syntax "Base Bar1" is like "Var1 : Base", and C++ "Base *Var4" is like "Var4 : Base_Access". Var2 and Var3 have no analogs in C++.

interesting.

> Using a class-wide type, calls to primitive operations become 'dispatched calls' (like C++/Pascal v-table calls):
>
> Foo (Var1);        -- statically bound to Base'(Var1)
> Foo (Var2);        -- dispatching call
> Foo (Var3.all);    -- statically bound to Base'(Var1)
> -- Pointer.all denotes the value pointed to by the pointer, like *Pointer
in
> C++
> Foo (Var4.all);    -- dispatching call
>
> Access types in Ada are very safe pointers. A lot of checks are made that you can't return a pointer to a local varaible or do something else that
is
> dangerous. Some checks are done at run-time, and as far as I know they are unique to Ada, no other language do them. And they're rather useful.
Before
> release, you remove all checks by inserting a pragma into your
configuration
> file:

If you remove all checks, your program might only fail once you release it. ;)  But performance is necessary.

> pragma Suppress (All_Checks);
>
> Or, you can suppress only several checks, or only checks applied to the given variable / type.
>
> Unconstrained types are very powerful in Ada. For example, array types of varying size can be declared:
>
> type Foo is array (Integer range <>) of Integer;
> -- <> is called 'box'
>
> When you declare a variable, you must provide a constraint either
explicitly
> or by initialization:
>
> A : Foo (1 .. 10); -- explicit constraining
> B : Foo := A; -- initialization
> C : Foo := (-10 .. 10 => 0); -- initialization using array literal
>
> You can declare a constrained subtype:
>
> subtype Foo10 is Foo (1 .. 10);
> D : Foo10; -- does not require additional care, as Foo10 is already
> constrained.
>
> Of course, unconstrained types are not dynamic, and array variables are of fixed size in Ada. But the syntax is quite suitable for dynamic arrays, isn't it? Just allow declaring uncounstrained variables and make them use reference symantics.
>
> Another example of unconstrained type is a variant record.
>
> type Device is (Printer, Disk);
> type Request (Dev : Device) is
>     record
>         Handle : Interfaces.C.DWORD;
>         case Dev is
>             when Printer =>
>                 LineNo : Integer := 0;
>                 OutOfParer : Boolean := False;
>             when Disk =>
>                 Head, Cyl, Track : Integer := 0;
>     end record;
>
> -- Request is unconstrained (it has a variable length!), so:
> A : Request (Printer); -- constrain explicitly
> B : Request := Get_Next_Req; -- by initialization
> C : Request := (Dev => Disk; Head | Cyl | Track => 0); -- either
> subtype Printer is Device (Printer);
> D : Printer;
>
> -- Analog of Pascal "variant record" would be:
> type Request_C (Dev : Device := Printer) is
>     record
>         ...
>     end record;
>
> An addition of a default value to all discriminants (by-the-by, Dev is called 'a discriminant' - that is, a parameter of a type; class-wide type have a hidden discrimintant - the Tag of the contained type) turns an unconstrained type into a constrained type. So now a variable can hold any Request variant:
>
> E : Request_C;
>
> A := (Dev => Disk; Head | Cyl | Track => 0);
> -- this is illegal, because A is constrained to Printer
> E := (Dev => Disk; Head | Cyl | Track => 0);
> -- this is legal, because Request_C is not an unconstrained type, so it's
> dicriminants may
> -- change their values
>
> Note that you can't assign to E.Dev. To change a discrimintant, you must re-assign the whole variable's value.
>
> That's the Ada's way of doing records. ;)

Still very interesting.

> While Ada may seem a very limited language (that is, limits free fantasies of a programmer), it really cathes almost all the bugs at compile time. (I've launched debugger only a few times, to catch a really obvious errors like accessing a freed memory. And - do you know how Ada's 'free' is
called?
> Unchecked_Deallocation. You always remember it's unsafe when you use it.
;)
> And when I required pointers-to-members like those in C++, I've
implemented
> them in an hour's work! I can bet one can't implement his own sort of pointers in D. Ada's building blocks are very safe and powerful, while D currently is simply a language with C++ look and Pascal feel, with a
strange
> mix of features.
>
> D is still under construction. Don't you think some ideas can be borrowed from Ada? In particular, Ada's multitasking and generic packages are very nice. Ada's style of function overloading is quite nice too. And, operator overloading is implemented like this:
>
> type My_Integer is new Integer;
> function "+" (A, B : My_Integer) return My_Integer is ...;

I prefer the pattern matching approach used in O'CaML.

> There's no function ":=", Ada rationale clearly explains why they decided
to
> implement assignment their own way. You define a 'controlled type':
>
> type Foo is new Ada.Finalization.Controlled with
>     record
>         ...
>     end record;
>
> And the override up to three procedures:
>
> -- initialize a newly created object of type Foo
> procedure Initialize (Self : in out Foo);
> -- adjust after assignment
> procedure Adjust (Self : in out Foo);
> -- clean-up Foo instance
> procedure Finalize (Self : in out Foo);
>
> A, B : Foo;
> ...
> A := B;
>
> This copies B to A bitwise, and then calls Adjust to adjust the new instance. It may seem strange and too simple, but in fact it's a very convenient way, and is enough for all applications.

I only tried a little, but was unable to think of a case where it wouldn't work.

> Ada cycles:
>
> while Smt loop
>     ...
> end loop;
>
> for I in 1 .. 10 loop
>     -- NOTE: unlike in many other languages, I is declared by the
>     -- for cycle header! I's type is determined from range type.
Assignments
>     -- to I are illegal.
>     ...
> end loop;
> -- I is no longer accessible here.
> -- Personally I hate declaring my loop counters explicitly and love Ada's
> way.

I like this style of foreach iteration.  Should work on ranges, enumerations, arrays, or other containers.

> loop -- infinite loop, much nicer then "While True" or smt else
>     ...
> end loop;

Yes.

> 'Break' look like this:
> 'exit' [loop_name] ['when' condition];
>
> Loops can have names:
>
> Calculate_Totals : for I in My_Array'Range loop
>     while Smt_Else loop
>         ...
>         exit Calculate_Totals when It_Is_Friday_The_13th;
>         ...
>     end loop;
> end loop;

It looks like a variable declaration.  Confusing.

> Ordinary labels look unusual:
>
> <<Label>> statement;
>
> (But, unlike labels in other languages, Ada labels are very easy to
> distinguish from code (that is, to find).)

That's not bad.  << and >> are used for shifts in D though.  May be a conflict.

> Returning to D, I can say: don't be afraid to add unusuals into the language! No good language was similar to it's ancestors.

Yeah but you want to keep it readable and sane.

> P.S. There are some people that regularily post to this newsgroup. Who are you? As far as I can understand, Walter is the "chief designer", am I
right?

I'm one.  Walter is the head honcho.

> --
> Andrey Tarantsov
> andreyvit@nvkz.kuzbass.net

I think what I want is a language with alot of D's design goals.  But it is not D because of lack of generics and operator overloading and so you can't make your own basic types.  I need my own basic types because I do alot of low level 3D math programming and I need vectors, quaternions, and matrices or I can't get anything done, and they read much better with overloaded operators than with function calls.  Fixed-size D arrays are very similar to SIMD register types already and have some good operations, but they don't support saturation or fixed point.  And they don't have dot product etc. Modern CPU's also have reciprocal square root instructions etc that are not currently exposed in D.

Games programming would be much better if it were not done in C and C++.  No other languages even come close to being usable for professional games development (yet).   Maybe I should make a language.  One of these days.... ;)

Sean

"Andrey Tarantsov" <andreyvit@nvkz.kuzbass.net> wrote in message news:aglpvi$qc0$1@digitaldaemon.com...
> Hello!
>
> 2Toyotomi:
>
> > You sound like those Delphi people who think of C# as a Delphi ripoff
and
> > are completely ignorant of Java...
>
> Well, I don't like Pascal at all (a year before I hated it). I think of C# because I like it & .NET Framework, and because I'm subscribed to MSDN Magazine that talks a lot about C#, so I can't forget it. C# is a C++ descendant. Java... well, I don't like it, but I did not have a chance to use it, so there's no serious opinion.

I programmed in Pascal for like 8 years before I got sick of it and switched to C++.

> > D is designed to be a simple language - easy to write a compiler for and easy to learn.
>
> This does not mean it would be easy to program with it. Standard Pascal is
a
> very simple language, but it's very hard to write anything useful.

D has enough power to be useful in real-world programming.  I've done a little OpenGL and Direct3D programming with it already.  ;)

> > That seems to be an argument in favour of a meta language - however the strength of a meta language is also its weekness,  where you are able to redefine the language and make it look like something else you also make
> it
> > more difficult to understand (and to parse).
>
> Yes, I like the idea of metalanguages, but I'm also a bit tired of them, because there are no good class libraries, and I don't like writing everything myself.
>
> FYI, do you know that C++ STL is originally borrowed from Ada Generics Library developed in early 1980s?
>
> > Garbage collection,  although necessary for the language,  is
implemented
> > in a library not as part of the main language.
> >
> > D is not a descendant of C++, it is a descendant of C.  That idea being that D is what C++ should/could have been.
>
> That's interesting. I like the idea to make a "good & easy to use C++".
All
> right. Still, I don't like to move towards C# and Java then. In my
opinion,
> they're too high-level anyway.
>
> I can tell you that making a better C++ is a *very* serious... job. OK, going to think about the question.
>
> By-the-by, what do you think about exceptions? As for me, I consider using classes for them usual, but nonneccessary. Anyway, I'm too lazy to define
my
> own full-featured classes, so e.g. in Delphi I always write "ESmt = class (Exception);". Don't you think exceptions should not be classes?

I never use exceptions because all the C++ implementations I've tried slow down alot when you turn them on.

> 1. Allowing to throw only descendents of a specific class (e.g.
CException)
> is a strange rule.
> 2. This would be ideal:
>
> class EBadToken : exception {public: string file; int line, col;};
>
> throw EBadToken ("My File", my_line, my_col);

file, line and col should be implicit, and if you're running under a debugger, are completely unnecessary.

> Something like this: when a class has no constructors and has only public fields, it gets a constructor that can accepts arguments corresponding to all the fields and initializes them.

I like that syntax sugar.

> This is not a proposal, it's just an idea to discuss.

Why not make it a proposal?  I propose that we propose to discuss your idea. ;)

Sean

> What's with the apostophe operator?
>
> Sean

It's simular to D's property syntax. ( ' instead of . )

"anderson" <anderson@firestar.com.au> wrote in message
news:agj38p$12r$1@digitaldaemon.com...
<SNIP>
>
> PS - This newsgroup is getting a "thoughts on D" type of email about once fortnight now. I'm not complaining, it's just a comment.
>
>

Yeah but that is a good sign!
It means many people are discovering D and are trying to
share their opinions on it. It is logical they want to
give their view on D when they first get here.

Andrey, welcome and thank you for your input.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Toyotomi" <kaishaku13@hotmail.com> wrote in message news:bekriu4v4rm3ki1k7ip1n8071b9dmrfsct@4ax.com...
> I use Delphi and C++, Borland and Microsoft's
>
> I do prefer Delphi for client applications. I do however think Java and C#
> are better languages than everything, however I had to dismiss using them
> for client applications long ago. Delphi Pascal is not the best language,
> but all in all it makes for the best development environment. I do have to
> use C++ for some things, such as those which might want to statically link
> ImageMagick or other large and fast moving excellent 3rd party C/C++ based
> libraries... The C interop capabilities of D would be useful there as
> well, but that's secondary to the fact that C is like a compiled Java.
> I also do some BCB .obj linking in Delphi, but some things, such as
> ImageMagick can not be compiled in BCB without a ton of work.
>
> D seems to fill an important niche, which I wanted filled years ago...
>
> You sound like those Delphi people who think of C# as a Delphi ripoff and are completely ignorant of Java... That makes it hard to pay attention... I am just a little tired of ignorant Delphi users. Remember, I am a Delphi user, just not an ignorant one.
>
> D has a chance to overthrow Delphi in a lot of applications, especially mine. It will need a well designed library and a RAD IDE. It's simple...
>
> -Toyotomi
>

Toyotomi, it sounds like you might *love* C#.
I had a look at it and it's pretty nice! The
language looks a lot like C/C++, but the
environment starts to look more and more like
Delphi. They have a great class library and
the visual development environment is good too,
some things that were seriously lacking in
MSVC. By the way, what about Borland C++ Builder?
Would that be something for you?

Also, C# can be interpreted-like (actually,
JIT-compiled), but you can also just compile
it straight to .dll's or .exes, so it is not
as much as Java as is often said on this
newsgroup. A collegea of mine is doing a
project in C# and he is very enthousiastic
about the possibilities. He likes it a lot.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message
news:aglttj$uan$1@digitaldaemon.com...
<SNIP>
>
> If you ask me (and you didn't) I'd want to be able to completely hide any private members from other code.  Other code shouldn't even know the
private
> members exist.  Which means you need to be able to specify them from
outside
> the externally visible declaration.
>
> // visible interface
>
> class Foo_public : private Foo_private
> {
>     void GoForIt();
> }
>
> // hidden somewhere
>
> protected except(Foo_public)
> class Foo_private
> {
>     int myprivateint; // nobody can see this but Foo_public
> }
>
<SNIP>
>
> Sean
>


So use interfaces:


interface IFoo
{
   void GoForIt();
}

class Foo: Object, IFoo
{
   int myprivateint;

   void GoForIt()
   {
      printf ("myprivateint==%d\n", myprivateint);
   }
}


Then you only need to publish the interface and
can keep everything else private.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail