D - Some questions and suggestions, and the future of D
- =?koi8-r?B?9MHSwc7Dz9cg4c7E0sXK?= (201/201) Jul 10 2002 Hello everybody!
- =?koi8-r?B?9MHSwc7Dz9cg4c7E0sXK?= (249/249) Jul 10 2002 Hello, that's me again.
- C.R.Chafer (42/96) Jul 11 2002 And me replying again.
- Sean L. Palmer (79/328) Jul 12 2002 Like I said, I believe in the building block approach. The language sho...
- anderson (64/174) Jul 10 2002 love
- Andrey Tarantsov (105/142) Jul 11 2002 Hello.
- anderson (71/144) Jul 11 2002 Attributes are like the ' in ADA
- Andrey Tarantsov (105/123) Jul 11 2002 No, I did not. I don't argue that D does not look like C++. The look can...
- anderson (64/189) Jul 11 2002 be
- Walter (9/17) Jul 19 2002 the
- Sean L. Palmer (10/27) Jul 20 2002 Sets and ranges were both quite useful.
- Walter (3/5) Jul 20 2002 You know, I never thought of that. What do you think?
- Russ Lewis (9/14) Jul 21 2002 I would vote no, because I think that enums should be a different "idea
- Pavel Minayev (5/13) Jul 21 2002 Me, I like that feature of Pascal. Makes sense sometimes, when you
- Sandor Hojtsy (19/29) Jul 23 2002 Hmm..
- Jonathan Andrew (6/11) Jul 21 2002 It seems enums (anonymous especially) are used a lot for
- Jonathan Andrew (1/2) Jul 21 2002
-
OddesE
(14/16)
Jul 13 2002
"anderson"
wrote in message - C.R.Chafer (51/118) Jul 11 2002 hmm .. I have 4.
- andy (9/27) Jul 11 2002 To be fair to C++, although I am admittedly not an advocate of the
- Andrey Tarantsov (34/46) Jul 11 2002 Well, I don't like Pascal at all (a year before I hated it). I think of ...
- Sean L. Palmer (21/67) Jul 12 2002 and
- Walter (37/41) Jul 19 2002 a
- Sean L. Palmer (37/78) Jul 20 2002 and
- Walter (8/27) Jul 20 2002 container
- Toyotomi (19/19) Jul 11 2002 I use Delphi and C++, Borland and Microsoft's
- Toyotomi (1/2) Jul 11 2002 Typo... D is like a compiled Java, not C... ;-p
- OddesE (24/43) Jul 13 2002 Toyotomi, it sounds like you might *love* C#.
- Toyotomi (9/18) Jul 14 2002 I've written a C# ftp client for transferring and syncing ~50k real esta...
- OddesE (13/20) Jul 16 2002 Well, you certainly seem to have a lot more experience
- anderson (6/27) Jul 16 2002 estate
- Walter (6/11) Jul 19 2002 A crucial difference between D and C# is that D is meant to be compiled ...
- Steven Shaw (10/14) Jul 20 2002 into
- Walter (21/27) Jul 20 2002 Most of the operating system can be called a "system app". System apps
- Steven Shaw (36/63) Jul 21 2002 Just to clarify: .net doesn't have a VM. It's just got a runtime. Micros...
- Pavel Minayev (21/47) Jul 21 2002 You can write GUI applications in Java, but do they work fast? And how w...
- Walter (26/55) Jul 21 2002 Microsoft
- Steven Shaw (40/89) Jul 21 2002 I don't know how much memory the CLR takes up. I think the embedded vers...
- Walter (16/42) Jul 22 2002 ran
- Juan Carlos Arevalo Baeza (5/7) Jul 22 2002 But it will at some point, won't it? ;-)
- Walter (4/9) Jul 23 2002 loading.
- Juan Carlos Arevalo Baeza (15/18) Jul 24 2002 You'd need to provide a way to express the binary interface of the DL...
- anderson (36/45) Jul 24 2002 I'd like it to compile/load C style DLL's and simply have a handle attac...
- Sean L. Palmer (148/345) Jul 11 2002 Up front: I agree with much of what you say.
- anderson (1/3) Jul 12 2002 It's simular to D's property syntax. ( ' instead of . )
-
OddesE
(27/43)
Jul 13 2002
"Sean L. Palmer"
wrote in message - Sean L. Palmer (10/61) Jul 13 2002 That forces everything to be virtual.
- OddesE (18/25) Jul 14 2002 In D all method pointers are already virtual aren't they?
- anderson (6/10) Jul 13 2002 Yes, I never understood why C++ kept privates visible in the header. D
- Andrey Tarantsov (25/29) Jul 14 2002 I don't understand all of you. Private data *must* be visible to the wor...
- anderson (9/17) Jul 14 2002 from
- Sean L. Palmer (14/43) Jul 15 2002 from
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.) 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. 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. 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: -> 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. 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? ;) 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. 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). 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. 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 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. 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 type Fixed_Point_Dollars is range -10 ** 10 .. 10 ** 10 delta 0.01; -- Fixed point aka "Currency" type There is a "modulus" type like this: type Byte is mod 256; -- 255 + 1 = 0; 10 - 12 = 253, and so on type Wow is mod 7; -- useful for indexes: 6 + 1 = 0; 0 - 2 = 3. 2. Generics. Ada generics are the best! ;) But, they must be instanciated explicitly. Like this: generic type Index is (<>); -- Index is any *discrete* type type Elem is private; -- Elem is any fixed-size type supporting "=" and assignment 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 ;) ... type Int_Array is array (Natural range 0 .. 20) of Integer; procedure Sort is new Generic_Sort (Int_Array'Domain, Integer, Int_Array); 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? 3. Packages. They are like this: -- in Foo.ads package Foo is -- public part private -- private part end Foo; -- 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; 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. 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. 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! -- Andrey Tarantsov andreyvit nvkz.kuzbass.net P.S. From Russia with love. ;-)
Jul 10 2002
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). --- 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? 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. 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; -- '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; 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. 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++. 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: 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. ;) 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 ...; 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. 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. loop -- infinite loop, much nicer then "While True" or smt else ... end loop; '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; 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).) 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. 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? -- Andrey Tarantsov andreyvit nvkz.kuzbass.net
Jul 10 2002
???????? ?????? wrote:Hello, that's me again.And me replying again. [-snip-]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 think Ada is still the best language for inbuilt multitasking support, the synchronisation directive on D (in my opinion) is inadiquate and ill defined - however this is just an alpha versions and that should improve.(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.)I has been a while since I read that - so my memory may be a little patchy on the subject.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?It is useful, however I believe it may interfere with D's automatic type conversions (a feature I disagree with, but useful when converting C programmes). [-snip-]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: pragma Suppress (All_Checks);D's debug mode serves the same purpose (currently debug mode cannot be disabled however - this should change on later versions).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:[-snip-] D dynamic arrays serve a similar purpose - they are not quite as flexable as the Ada implementation however I suspect this additional flexibility can be done without.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.[unlike your spell checker - sorry could not resist that joke](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.In my opinion it is more a C look with object oriented features, dynamic arrays and properties. D is more for programmers who want to get the job done and while Ada may be safe sometimes you just do not want that safety.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:As these are things which are currently not fully defined in D they could be included using an Ada style implementation (though of course with D style syntax).Ada cycles:Looks just like BASIC in my opinion.'Break' look like this: 'exit' [loop_name] ['when' condition];Could do with D using <label> : while( <condition> ) { if( <condition> ) break <label>; }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.A departure from C is not a problem - only the features required for easy migration of C programmers should be kept (with the exception of the switch statement fall though - an endless source of bugs). Otherwise the D language should be internally consistant.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?Yes.
Jul 11 2002
"Таранцов Андрей" <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 canpostsome 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 typesorclasses (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 onAda'83'stype derivation. Record types marked with 'tagged' (i.e., they have a 'tag' - run-time information that is used to identify the type; usuallyit'sjust 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 beoverriden: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 inheritedasan -- *abstract* function, and must be overriden in Derived (or Derived willbe-- an abstract type): function Create return Derived;Interesting.For now, Base and Derived are simply records. (They are compatible witheachother.) 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 indicatesthatExpr -- should be of type Type. It is mainly used to specify array types inarrayliterals -- 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 BaseandDerived (and anything else derived from Base). Ada *do not* use reference symantics, so Base'Class is an "unconstrained" type - it has variablesize.Once a variable of this type is initialized, variable becomes fixed. Inourexample, 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 *PointerinC++ 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 thatisdangerous. 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.Beforerelease, you remove all checks by inserting a pragma into yourconfigurationfile: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 eitherexplicitlyor 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' iscalled?Unchecked_Deallocation. You always remember it's unsafe when you use it.;)And when I required pointers-to-members like those in C++, I'veimplementedthem 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 astrangemix 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 decidedtoimplement 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 Iright? I'm one. Walter is the head honcho.-- Andrey Tarantsov andreyvit nvkz.kuzbass.netI 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
Jul 12 2002
"Таранцов Андрей" <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.) 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 justloveAda. ;-) I want to share with you some thoughts about D. 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. Ithinkit is really useful for everybody to learn Ada (by-the-by, a Pascal descendant), for that language has many samples of untraditional design. 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? IthinkD 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 languageshouldcontain a basic, general set of... em, capabilities (not sure it's a right word), and everything else should be defined using the language itself.Canyou 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, butstillI think that there's no usable programming environment for C++. But thebestthing in C++ is that it allows you to create a very good one. Nobody didit,however. :-) But is integrating a fixed programming environment into the language a best thing?Not, that I believe D needs much of a redesign. I do believe that it should be define in such a way that allows the language great flexibility in evolving by itself. However things that are of frequent use should be part of the standard.That depends on the goal of the language: -> 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.WhileGC 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 ifdynamicarrays can be implemented in D in a convenient and familiar way, then many other idioms (iterators, cursors, lists) can be implemented too.C++ was designed that way, and did they come up with anything very neat? This is just my opinion, but STL vectors were ugly. Dynamic arrays are of frequent use. Infact in most programs memory management is 80%. I would however like the ability to write my own attributes for arrays.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. :-) Complexmustbe a standard class! With source code written in plain D.Complex does seem a step away from the ordinary. I can't see how frequently I'll use it. But that's just me. On the other hand, having a complex type helps drags the datatypes of D away from C/C++. Which is a good thing.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? ;)That's what classes are for. I agree, I'd be nice to have even further control to make classes more like datatypes. I think that a language should allow you the flexibilty to add what is missing without having to use workarounds, but it should also be effecient.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 addingsomethingnew to it is not quite easy and seamless.I'd have to strongly dissagree. It's much more like C++ the pascal syntactically and spiritily. Although Walters previous pascal compiler experiance my shine though the cracks.Well, at last, syntax does not matter. Here I want to describe someconceptsof 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).Ada, it's a bit to strongly typed for me. Code in ada always seemed to me be blotted with all this type checking stuff. However it did have some good points.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 withanythingelse.I liked that about ada (any sized data types), but then again in ada ranges lost much functionaly which became annoying.type Bar_Integer is new Integer range -128 .. 127; -- This is a *derived* type. It inherites all "primitive operations" oftype I like this, but i don't like all the type casting problems. This is likly to cause the need for much more casting which D tries to advoid.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 subtype Boz_Integer is Integer range 0 .. 255; -- This is a subtype. It is like a synonim for other type, can beimplicitlyconverted 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.All this strong typing blots code, which was one of the major turn downs of ada.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 type Fixed_Point_Dollars is range -10 ** 10 .. 10 ** 10 delta 0.01; --Fixedpoint aka "Currency" typeYes, but if I remember correctly there was a 128bit limit in Ada 95 (which is probably more then enough).2. Generics. Ada generics are the best! ;) But, they must be instanciated explicitly. Like this: generic type Index is (<>); -- Index is any *discrete* type type Elem is private; -- Elem is any fixed-size type supporting "="andassignment 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 ;) ... type Int_Array is array (Natural range 0 .. 20) of Integer; procedure Sort is new Generic_Sort (Int_Array'Domain, Integer, Int_Array); 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);I liked the ability in ada's generics to specify overload operators or simply use the default. It was extremly useful in searches/sorting. Also yo had the ability to overload any datatype operators which was useful for debuging purposes (ie counting comparsons). On the otherhand, ADA generics are very blotted.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 noGUIlibrary, 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?First of all you point out that D is tring to be everything to everyone and simply a mash of ideas. Then you give a few more ideas. Some of the ideas I like and some I don't. That's just my opinion. As you said "Ada is too conservative". 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.
Jul 10 2002
Hello. First, I beg your pardon for Outlook inserting my localized name into the "From" field. I hope that is corrected now.Not, that I believe D needs much of a redesign. I do believe that itshouldbe define in such a way that allows the language great flexibility in evolving by itself.Yes, definitely it should. ;)However things that are of frequent use should be part of the standard.Part of the standard - yes, obviously. But should they be a part of the language, or a part of the standard library? That matters much: Pascal, for example, had a lot of procedures that required "compiler magic" - writeln, copy, etc. You could not implement your own writeln if you didn't like the standard one. I don't think it's a right way. Standard environment should be implemented using the language itself. Talking about efficiency, nobody prevents you from doing compiler magic when compiling standard calls to optimize the usage of std. library. Still it's much better to get the same degree of efficiency by using inlining accross modules, advanced template techniques, optimizations during compilation.C++ was designed that way, and did they come up with anything very neat? This is just my opinion, but STL vectors were ugly.Yes, as I've said, C++ has no good standard environment. But that does not mean the whole idea is wrong. Simply too few people understand it.Dynamic arrays are of frequent use. Infact in most programs memorymanagement is 80%. I wouldhowever like the ability to write my own attributes for arrays.What are attributes?.. By-the-by, it has dynamic arrays. ;) Don't be late with D! In it's currentOn the other hand, having a complex type helps drags the datatypes of D away from C/C++. Which is a good thing.Why is complex a datatype rather than a standard class??? Don't talk about efficiancy. Even GNAT has a special pragma to treat the given record like a complex type and pass it in the FPU stack. It's a special case, because Complexes really should be treated specially. But the pragma affects only the way the record is stored, and the Complex type is contained in the standard library; if you don't like it, you are free implement your own Complex (together with your own versions of trigonometric functions ;).That's what classes are for. I agree, I'd be nice to have even further control to make classes more like datatypes. I think that a languageshouldallow you the flexibilty to add what is missing without having to use workarounds, but it should also be effecient.Yes, D must support templates and operator overloading. When used carefully, they do not bring in any extra overhead.I'd have to strongly dissagree. It's much more like C++ the pascal syntactically and spiritily.C++ is a kind of a "metalanguage" - a language to define your own languages (environments). C++ is a middle-level language, it can be used to implement nice data types like arrays, collections, iterators, references, and then use them in real programming. That's what STL is trying to do (but not too successfully ;). With C++ macros you can change the whole look of the language. And D is quite different - it has a predefined look & feel, with minor possibilities to extend the environment (NOT to write your own, but to extend the existing one). If you add generics and operator overloading, it would have good possibilities to extend the environment - but will never be like C++.Although Walters previous pascal compiler experiance my shine though thecracks. What did you mean?Ada, it's a bit to strongly typed for me. Code in ada always seemed to mebeblotted with all this type checking stuff.Well... If your program is designed right, there won't be much typecasting. If during development your code starts to contain a lot of typecasts, Elaboration_Check and Accesibility_Chech workarounds, it always means you have a poor design, and the whole code is to be thrown away and rewritten in another manner. I treat it as a feature of Ada: while C++ allows any nastiest architecture to be implemented, Ada prevents you from bad choices. The first 3 Ada projects I developed had to be completely rewritten, because the original version never compiled. (Or, it did compile, with a warning that Program_Error exception will be raised at run-time, meaning that binder could not find a suitable elaboration order.)However it did have some good points.Yes, it prevented most of the bugs in your programs.I liked that about ada (any sized data types), but then again in adarangeslost much functionaly which became annoying.? In fact, Ada do not allow any sized data types, there's a certain limit. But we're talking about D - and you can support anything, even 1Kbyte integers.I like this, but i don't like all the type casting problems. This is likly to cause the need for much more casting which D tries to advoid.Again: there's no need for much casting if everything is designed right. And the casting that is required is required to avoid bugs. I prefer to spend more time writing a program than debugging it. Ada's features can be compared to 8086 registers. As my old assembler book says, of course, you can store counters in ES and telephones in BP, but then you'll have problems accessing stack and managing strings. When you get used to Ada style, you start using it's features in a right way.All this strong typing blots code, which was one of the major turn downsofada.Strong typing helps you write corrent code. Still, there's no need for such a strong typing in D. But you can borrow type derivation idea, and other useful Ada idioms.Yes, but if I remember correctly there was a 128bit limit in Ada 95 (which is probably more then enough).I don't think there should be any limits (in D). Just say that any type size langer than 32 bits must be a multiplier of 32, and then implement long arithmetics. If some man requires it, why not add it?I liked the ability in ada's generics to specify overload operators or simply use the default. It was extremly useful in searches/sorting. Alsoyohad the ability to overload any datatype operators which was useful for debuging purposes (ie counting comparsons). On the otherhand, ADA generics are very blotted.Well... Compared to C++ templates, Ada generics are truly good. Unlike in C++, Ada generics are compiled at the time of declaration. If the generic package has successfully compiled, you know that any instanciation will be successful, because you specify the requirements for the generic paraments. C++ templates are more like extended macros. And the idea of generic packages instead of generic types is practically useful. Why not incorporate it? Taking into consideration that D has very poor modules, packages are a suitable replacement. By-the-by, Ada packages can be nested. That allows you to extend existent packages without modifying their code (child packages "see" the private section of their parent package). "Separate compilation" and "minimal recompilation" topics are to be studied more carefully during D design.First of all you point out that D is tring to be everything to everyoneandsimply a mash of ideas.I point out that D does not have a powerful, logical base. The basic of any language is: types, data abstraction possibilities (classes, hiding of implementation, packages), code reuse possibilities (inheritence, child packages, "programming by extension", as it's called in Ada), compatibility (interfacing to other languages and using preexistent libraries/code), portability. Complex types and dynamic arrays just don't matter. Everybody can say that in an ideal language, he wants a standard implementation of data structures and memory management (GC). That's obvious. And when you'll finish developering the basics of your language, it'll be clear how complexes and dynamic arrays should look like.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.Well, many people understand that D is steel far for ideal language... -- Andrey Tarantsov andreyvit nvkz.kuzbass.net
Jul 11 2002
"Andrey Tarantsov" <andreyvit nvkz.kuzbass.net> wrote in message news:agjaae$14i4$1 digitaldaemon.com...Hello.Attributes are like the ' in ADAlanguagesI'd have to strongly dissagree. It's much more like C++ the pascal syntactically and spiritily.C++ is a kind of a "metalanguage" - a language to define your own(environments). C++ is a middle-level language, it can be used toimplementnice data types like arrays, collections, iterators, references, and then use them in real programming. That's what STL is trying to do (but not too successfully ;). With C++ macros you can change the whole look of the language. And D is quite different - it has a predefined look & feel, with minor possibilities to extend the environment (NOT to write your own, but to extend the existing one). If you add generics and operator overloading, it would have good possibilities to extend the environment - but will neverbelike C++.Are you kidding? Walter has plans to implement templates in D 2.0. Have you actually used D, because it looks like C++ to me. You can even port (in a very round about way) C++ classes to D and use very simular syntax methods to use them. --I wonder what Walter opinion on D looking like pascal more then C++ is?Although Walters previous pascal compiler experiance may shine though the cracks.Although Walters previous pascal compiler experiance my shine though thecracks.What did you mean?I simply mean (Walter correct me if I'm wrong) is that Walters written a pascal compiler before and elements of that may show in D.meAda, it's a bit to strongly typed for me. Code in ada always seemed tobetypecasting.blotted with all this type checking stuff.Well... If your program is designed right, there won't be muchIf during development your code starts to contain a lot of typecasts, Elaboration_Check and Accesibility_Chech workarounds, it always means you have a poor design, and the whole code is to be thrown away and rewritteninanother manner. I treat it as a feature of Ada: while C++ allows any nastiest architecture to be implemented, Ada prevents you from badchoices.The first 3 Ada projects I developed had to be completely rewritten,becausethe original version never compiled. (Or, it did compile, with a warning that Program_Error exception will be raised at run-time, meaning thatbindercould not find a suitable elaboration order.)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.However it did have some good points.Yes, it prevented most of the bugs in your programs.ButI liked that about ada (any sized data types), but then again in adarangeslost much functionaly which became annoying.? In fact, Ada do not allow any sized data types, there's a certain limit.we're talking about D - and you can support anything, even 1Kbyteintegers. Sorry that's not what I ment there. I simply ment that you'd have to program your own operators for new types that weren't derived from variables with those operators. I was annoying when you were, say using someone elses currency type and they forgot to include a muliplication operator.liklyI like this, but i don't like all the type casting problems. This isAndto cause the need for much more casting which D tries to advoid.Again: there's no need for much casting if everything is designed right.the casting that is required is required to avoid bugs. I prefer to spend more time writing a program than debugging it.We that's the theory anyway. In practice things turn out differn't. ADA is dying, although there has been an increase in use as a introductory language. Of coarse I don't know of any rockets that have crashed because of C mistakes. Then again ADA more of a military/machinical languange anyway. But that's beside the point. I prefer to spend more time designing a program before writing it. I also think it depends on what your using it for. Ada is a structured programming language with OO abilities added later. C++ on the other hand is object based. Industry is swing away from structured (although it's still useful) and towards OO. 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.Ada's features can be compared to 8086 registers. As my old assembler book says, of course, you can store counters in ES and telephones in BP, butthenyou'll have problems accessing stack and managing strings. When you getusedto Ada style, you start using it's features in a right way.suchAll this strong typing blots code, which was one of the major turn downs of ada.Strong typing helps you write corrent code. Still, there's no need fora strong typing in D. But you can borrow type derivation idea, and other useful Ada idioms.(whichYes, but if I remember correctly there was a 128bit limit in Ada 95sizeis probably more then enough).I don't think there should be any limits (in D). Just say that any typelanger than 32 bits must be a multiplier of 32, and then implement long arithmetics. If some man requires it, why not add it?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. These things should be able to be quared at compile time like ADA allows (parhaps not using the same syntax though).anyFirst of all you point out that D is tring to be everything to everyoneandsimply a mash of ideas.I point out that D does not have a powerful, logical base. The basic oflanguage is: types, data abstraction possibilities (classes, hiding of implementation, packages), code reuse possibilities (inheritence, child packages, "programming by extension", as it's called in Ada),compatibility(interfacing to other languages and using preexistent libraries/code), portability. Complex types and dynamic arrays just don't matter. EverybodyAs I was saying dynamic arrays are extremely important and useful. I don't want to use a slow standard library to implement dynamic arrays. What type of programs do you write? (I get the idea that your into writting applications such as bussiness apps, that arn't performance depended.)can say that in an ideal language, he wants a standard implementation of data structures and memory management (GC). That's obvious. And whenyou'llfinish developering the basics of your language, it'll be clear how complexes and dynamic arrays should look like.oncePS - This newsgroup is getting a "thoughts on D" type of email aboutActually I haven't seen anyone make the same suggestions you have. I don't believe it's in a complete form either. After all that's why it's only alpha and what this newsgroup is for. I believe that the D should aim for a middle ground. Ada is a good learning language because it forces the programmer to do program in a particular way. The downside of this is flexibility. I think of ADA on one side of a fence and C++ on another. D remains on C++'s side of the fence and tries to be an improvement to C++.fortnight now. I'm not complaining, it's just a comment.Well, many people understand that D is steel far for ideal language...
Jul 11 2002
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++") 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 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.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. 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?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.D should support almost un-limited variable sizes. But I still want toknowthe limit. For example on todays proccessors it would be infeasible tohavea 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).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. 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 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 ;).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. *** 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. 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. S2. Symultaneous execution capabilities (whether multitasking should be incorporated into the lang, how should tasks communicate, how will they access shared data). S3. Improve code reuse. This includes generics, probably macros (I don't 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). 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? Regards! -- Andrey Tarantsov.
Jul 11 2002
"Andrey Tarantsov" <andreyvit nvkz.kuzbass.net> wrote in message news:agk0j6$1lml$1 digitaldaemon.com...beHave 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 caneasily changed in a few days by rewriting compiler's syntax analyzer. Isaythat the basic concepts of D are more like C++'s ones.areYou 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 therea lot of C++ applications (I don't mean "programs", just "ways to useC++")that cannot be ported to D or Pascal.They key features of C++ that make it feel like C++ are: templates,macros,overloading of operators like ->, [], new, delete. Using this, you canmakeanything look like anything else. That's the philosophy of C++, but not of 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.languagesYes, 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 discussas 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 memorypool).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 whenyouwant to design a new environment. If you want simply to write programs,anylanguage whose ready-made environment suits your needs will do. Yes, Isomethings (like lexical parsers) are always better expressed in C++ becauseofit's pointer arithmetic. I think that's enough about the languages.alsoI prefer to spend more time designing a program before writing it. Irun-time language.think it depends on what your using it for.By-the-by, what is D targetting for?beforeA good point about ada is that it is able to determine many errorslimitsthe 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 languageyou (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 youwanthow 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.That's the idea. I simply ment I want the MAX value.D should support almost un-limited variable sizes. But I still want toknowthe limit. For example on todays proccessors it would be infeasible tohavea 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).don'tAs I was saying dynamic arrays are extremely important and useful. IThat'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?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.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, ifIwould like so, dynamic arrays, static interlocked lists or whatever. Youdounderstand it, so I don't think this question needs additional discussion.youWhat 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 thatsimply love efficiency. And, for multimedia applications or other pointer arithmetic can be used. Maybe this is the right way of thinking:themost 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.No I haven't. I said I aim for something in-between.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.*** And now my proposal. Languages cannot be invented and designed in the way D is. First,everybodyshould 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,allthe proposals should be grouped, filtered and generalized. Then, youchoosewhat basic conceptions your language will be built on. And then, usingtheseconceptions, 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,easeof 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 modulesiseasier to write, debug, understand and maintain. D should provide asupportfor 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'tGenerics 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.
Jul 11 2002
"anderson" <anderson firestar.com.au> wrote in message news:agjp40$195r$1 digitaldaemon.com...--I wonder what Walter opinion on D looking like pascal more then C++ is?theAlthough Walters previous pascal compiler experiance my shine thoughIt's true that the first compiler I wrote was for a Pascal subset, way back in 1980 or so. While Pascal is not my favorite language, it does have a nice feature I tried to carry into D - that of being able to separate the lexical, syntactic, and semantic phases of compilation. This is a crucial feature for reducing a complicated language into managable pieces, for easy understanding and implementation.cracks.Although Walters previous pascal compiler experiance may shine though the cracks.What did you mean?I simply mean (Walter correct me if I'm wrong) is that Walters written a pascal compiler before and elements of that may show in D.
Jul 19 2002
Sets and ranges were both quite useful. You can't use ++ and -- on enum variables in C++... can you in D? Sean "Walter" <walter digitalmars.com> wrote in message news:ahah9f$m73$1 digitaldaemon.com..."anderson" <anderson firestar.com.au> wrote in message news:agjp40$195r$1 digitaldaemon.com...is?--I wonder what Walter opinion on D looking like pascal more then C++thetheAlthough Walters previous pascal compiler experiance my shine thoughcracks.Although Walters previous pascal compiler experiance may shine thoughbackcracks.It's true that the first compiler I wrote was for a Pascal subset, wayWhat did you mean?I simply mean (Walter correct me if I'm wrong) is that Walters written a pascal compiler before and elements of that may show in D.in 1980 or so. While Pascal is not my favorite language, it does have anicefeature I tried to carry into D - that of being able to separate the lexical, syntactic, and semantic phases of compilation. This is a crucial feature for reducing a complicated language into managable pieces, foreasyunderstanding and implementation.
Jul 20 2002
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message news:ahci0h$47g$1 digitaldaemon.com...Sets and ranges were both quite useful.You can't use ++ and -- on enum variables in C++... can you in D?You know, I never thought of that. What do you think?
Jul 20 2002
Walter wrote:"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message news:ahci0h$47g$1 digitaldaemon.com...I would vote no, because I think that enums should be a different "idea space" than integers. I'm likely to get outvoted, though, and that's ok. -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]Sets and ranges were both quite useful.You can't use ++ and -- on enum variables in C++... can you in D?You know, I never thought of that. What do you think?
Jul 21 2002
On Sun, 21 Jul 2002 22:32:14 -0700 Russ Lewis <spamhole-2001-07-16 deming-os.org> wrote:Me, I like that feature of Pascal. Makes sense sometimes, when you have a set of sequential elements, and want to traverse back and forth. At least it doesn't hurt in other cases. =)I would vote no, because I think that enums should be a different "idea space" than integers. I'm likely to get outvoted, though, and that's ok.You can't use ++ and -- on enum variables in C++... can you in D?You know, I never thought of that. What do you think?
Jul 21 2002
charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Enums with integer properties (++, --) would be nice. I sometimes like = to mix integers and enums together. For example I may use the last 8 = places for a byte storage and the first part for enable/disable bit = flags. Although now D has bits included, it's still useful in things = such as file saving. ++, -- and any other integer maths would be useful = on enums, although I suppose it's possible to cast an enum to a int.=20 Also how about a specific structure or extention to enums for enable = disable bits. I know that D's bits data type goses some way, but it = doesn't provide a labling system enable/disable bits. And before you = point it out, you could use: enum EnableBit //You may reconise this from GL (Although it's missing a = few) { ALPHA_TEST =3D 1, AUTO_NORMAL =3D 2, BLEND =3D 4, COLOR_MATERIAL =3D 8, CULL_FACE =3D 16, DEPTH_TEST =3D 32, DITHER =3D 64, FOG =3D 128, LIGHTING =3D256, LINE_SMOOTH =3D 1024, LINE_STIPPLE =3D 2048, LOGIC_OP =3D 4096, NORMALIZE =3D 8192, POINT_SMOOTH =3D 16384, POLYGON_SMOOTH =3D 32768, POLYGON_STIPPLE =3D 65536, SCISSOR_TEST =3D 131072, STENCIL_TEST =3D 262144, TEXTURE_1D =3D 524288, TEXTURE_2D =3D 1048576 }; EnableBit CurrentEnable; CurrentEnable &=3D ALPHA_TEST; ect... -------------------------------------------------------------------------= ------- But how about enable EnableBit { ALPHA_TEST, //Auto generates the numbers ... }; EnableBit CurrentEnable; CurrentEnable &=3D ALPHA_TEST; And even syntax sugur, CurrentEnable.enable(ALPHA_TEST); CurrentEnable.disable(ALPHA_TEST); ect... "Pavel Minayev" <evilone omen.ru> wrote in message = news:CFN37459427319294 news.digitalmars.com...On Sun, 21 Jul 2002 22:32:14 -0700 Russ Lewis=20 <spamhole-2001-07-16 deming-os.org> wrote: =20"idea=20 I would vote no, because I think that enums should be a different =You can't use ++ and -- on enum variables in C++... can you in D?You know, I never thought of that. What do you think?space" than integers. =20 I'm likely to get outvoted, though, and that's ok.=20 Me, I like that feature of Pascal. Makes sense sometimes, when you have a set of sequential elements, and want to traverse back and forth. At least it doesn't hurt in other cases. =3D) =20
Jul 22 2002
charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "anderson" <anderson firestar.com.au> wrote in message = news:ahglim$12gp$1 digitaldaemon.com... Enums with integer properties (++, --) would be nice. I sometimes like = to mix integers and enums together. For example I may use the last 8 = places for a byte storage and the first part for enable/disable bit = flags. Although now D has bits included, it's still useful in things = such as file saving. ++, -- and any other integer maths would be useful = on enums, although I suppose it's possible to cast an enum to a int.=20 Also how about a specific structure or extention to enums for enable = disable bits. I know that D's bits data type goses some way, but it = doesn't provide a labling system enable/disable bits. And before you = point it out, you could use: enum EnableBit //You may reconise this from GL (Although it's missing = a few) { ALPHA_TEST =3D 1, AUTO_NORMAL =3D 2, BLEND =3D 4, COLOR_MATERIAL =3D 8, CULL_FACE =3D 16, DEPTH_TEST =3D 32, DITHER =3D 64, FOG =3D 128, LIGHTING =3D256, LINE_SMOOTH =3D 1024, LINE_STIPPLE =3D 2048, LOGIC_OP =3D 4096, NORMALIZE =3D 8192, POINT_SMOOTH =3D 16384, POLYGON_SMOOTH =3D 32768, POLYGON_STIPPLE =3D 65536, SCISSOR_TEST =3D 131072, STENCIL_TEST =3D 262144, TEXTURE_1D =3D 524288, TEXTURE_2D =3D 1048576 }; EnableBit CurrentEnable; Should be... CurrentEnable |=3D ALPHA_TEST; //Enable bit ect... -------------------------------------------------------------------------= ----- But how about enable EnableBit { ALPHA_TEST, //Auto generates the numbers ... }; EnableBit CurrentEnable; Should be... CurrentEnable |=3D ALPHA_TEST; //Enable bit And even syntax sugur, CurrentEnable.enable(ALPHA_TEST); CurrentEnable.disable(ALPHA_TEST); ect... "Pavel Minayev" <evilone omen.ru> wrote in message = news:CFN37459427319294 news.digitalmars.com... > On Sun, 21 Jul 2002 22:32:14 -0700 Russ Lewis=20 > <spamhole-2001-07-16 deming-os.org> wrote: >=20 > >> > You can't use ++ and -- on enum variables in C++... can you in = D? > >> > >> You know, I never thought of that. What do you think? > >=20 > > I would vote no, because I think that enums should be a different = "idea > > space" than integers. > >=20 > > I'm likely to get outvoted, though, and that's ok. >=20 > Me, I like that feature of Pascal. Makes sense sometimes, when you > have a set of sequential elements, and want to traverse back and > forth. At least it doesn't hurt in other cases. =3D) >=20
Jul 22 2002
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3D3B98DE.CDF15BC deming-os.org...Walter wrote:Hmm.. Sometimes I use enum for naming the states of a process. In this idea space it seems logical to read ++ as "step into the next state". So please implement it. I admit, there are some problems with the analogy: steping to the next state, does not necessarily mean "increment the underlying integer value with 1". Especially when the last state is reached. OTOH, there are cases when I use enums as a collection of unique values with names, but the particular value is not important. In these cases I would be really happy if the compiler would check that I do no integer operations on these values. Summary: The best would be two enum types! One with all integer operations (enum alias), and one without any (enum typedef). Yours, Sandor"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message news:ahci0h$47g$1 digitaldaemon.com...I would vote no, because I think that enums should be a different "idea space" than integers.Sets and ranges were both quite useful.You can't use ++ and -- on enum variables in C++... can you in D?You know, I never thought of that. What do you think?
Jul 23 2002
Walter wrote:You know, I never thought of that. What do you think?It seems enums (anonymous especially) are used a lot for constants, so it doesn't seem appropriate to modify them like that. Just my opinion, Jon
Jul 21 2002
that got posted in the wrong place, Sorry!
Jul 21 2002
"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
Jul 13 2002
???????? ?????? wrote: Some good points - however I disagree with a number of them.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.)hmm .. I have 4.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.Ada has may ideas which make a good language - however it also has problems primarily it is for too verbose. (I tend to use VHDL more than Ada myself which also has the problem that there are too many ways to do the same operation - in my opinion there should be a minimum of ways to achieve the same result otherwise you simply have to remember too much (or constantly use a reference) to read another persons code.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 think Ada has been examined and features added - I personally would have liked to used an Ada style switch (case) statement, though that idea was rejected.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.D is designed to be a simple language - easy to write a compiler for and easy to learn.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),[I would have used 'features' however 'capabilities' still gets your intent]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: -> for small scripting languages for quick coding it is; -> for real system languages I think it's not.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).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.Garbage collection, although necessary for the language, is implemented in a library not as part of the main language.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? ;) 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.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. The idea being to step away from the complexity of C++ which is underused, poorly implemented and often leads to bugs.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).(some of the following features would be useful - however there syntax would need a complete overhaul to be used in D).1. Types. In Ada, there exist types and *subtypes*. Types can derive from each other. Samples:[-snip-] Most of this can be achieved with 'define' and 'alias' - a range check would be useful though.2. Generics. Ada generics are the best! ;) But, they must be instanciated explicitly. Like this:[-snip-] D generics (templates) have been left out till version 2 - their implementation is still under discussion.3. Packages. They are like this:[-snip-] The trouble with this is that when a procedure is redefined the package header also has to be modified. While this is not a major problem it is very annoying. I believe D can achieve the same as Ada here despite the difference in syntax.Explanation of C++ behaviour of exceptions raised during object construction took a dozen articles in MSDN ("Deep C++").The idea of D is to simplify problems such as this, therefore making the language easier to implement properly. I do not believe there is a single implementation of C++ which fully conforms to the standard, this should not be the case in D.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++.)I can not comment on Delphi, however 'elegant' is not a word I would use to describe C++. C 2002/7/11
Jul 11 2002
The idea of D is to simplify problems such as this, therefore making the language easier to implement properly. I do not believe there is a single implementation of C++ which fully conforms to the standard, this should not be the case in D.To be fair to C++, although I am admittedly not an advocate of the language, Doctor Dobbs did a "benchmark" for compliance of sorts and the major compilers are very largely compliant. (of course its the little things that kill). GCC did *remarkably* well with standards compliance for C++ (I expected it to fair horribly) as did Borland and some others that I don't really know anything about. Can you guess which compiler was *least* compliant with the standards....? hummm? (take a wild guess) ;-) -AndyExplanation 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++.)I can not comment on Delphi, however 'elegant' is not a word I would use to describe C++. C 2002/7/11
Jul 11 2002
Hello! 2Toyotomi:are completely ignorant of Java...because I like it & .NET Framework, and because I'm subscribed to MSDN 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 makeitmore 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 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!
Jul 11 2002
"Andrey Tarantsov" <andreyvit nvkz.kuzbass.net> wrote in message news:aglpvi$qc0$1 digitaldaemon.com...Hello! 2Toyotomi:andI programmed in Pascal for like 8 years before I got sick of it and switched to C++.are completely ignorant of Java...because I like it & .NET Framework, and because I'm subscribed to MSDN descendant. Java... well, I don't like it, but I did not have a chance to use it, so there's no serious opinion.aD 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 isvery 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. ;)implementedThat 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 makeitmore 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, isAllin 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++".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 definemyown 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
Jul 12 2002
"Andrey Tarantsov" <andreyvit nvkz.kuzbass.net> wrote in message news:aglpvi$qc0$1 digitaldaemon.com...aD 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 isvery simple language, but it's very hard to write anything useful.Very true. Pascal is a good language to learn how to write compilers. I can't say it's useful for much else. I am trying to bring my experience to bear on the problem of finding a fairly minimal set of features that cover most of the programming needs. I remember when Ada first appeared, it was considered unimplementable for years. Eventually, people did figure out how to implement it as compiler technology advanced. C++ also suffered for years being unimplementable. I wish to avoid that fate with D by at least providing source to a reference implementation. I read your comments with interest. Can I sum them up by saying that you wish for D to be more of a meta-language, such as providing the building blocks for dynamic arrays rather than implementing them directly? That's a valid point of view, and certainly the one C++ takes with STL. So why does D have dynamic arrays built in? 1) They are so darned useful. I use them everywhere in my own code - and find them to be a more than suitable replacement for most singly linked lists, doubly linked lists, stacks, queues, etc. Having to learn only dynamic arrays instead of vectors, lists, stacks, queues, etc., makes programming easier and less buggy. 2) By integrating them into the language, D can achieve tight and nearly seamless integration with static C style arrays - important for interfacing with external C functions. 3) Since the compiler knows about dynamic arrays, sensible and to the point error diagnostics can be issued, rather than the notoriously inscrutable messages coming from metalanguage constructs. 4) Good code can be generated for a builtin construct by a less sophisticated compiler. Constructs built up from meta-primitives usually need a very advanced compiler to generate comparably good code. 5) Designing the syntax into the language enables the use of special syntax where useful, such as the array slicing syntax. 6) In a garbage collected language, dynamic arrays should be a fundamental type, not something built up from metalanguage constructs. Metalanguage constructs are needed for special types, and should not be necessary for basic types.
Jul 19 2002
"Walter" <walter digitalmars.com> wrote in message news:ahaldu$ptj$1 digitaldaemon.com..."Andrey Tarantsov" <andreyvit nvkz.kuzbass.net> wrote in message news:aglpvi$qc0$1 digitaldaemon.com...andD is designed to be a simple language - easy to write a compiler foriseasy to learn.This does not mean it would be easy to program with it. Standard PascalaNo object support, and no means to really control the display. No decent standard library. Yeah that makes it hard. There's also a bunch of practical extensions needed (Borland provided most of these later and became the de-facto standard).very simple language, but it's very hard to write anything useful.Very true. Pascal is a good language to learn how to write compilers. I can't say it's useful for much else. I am trying to bring my experience to bear on the problem of finding a fairly minimal set of features that cover most of the programming needs.This is good, so long as we can extend the language later. If it will let us write really low level stuff that looks and acts like the things the language provides built-in.I remember when Ada first appeared, it was considered unimplementable for years. Eventually, people did figure out how to implement it as compiler technology advanced. C++ also suffered for years being unimplementable. I wish to avoid that fate with D by at least providing source to a reference implementation. I read your comments with interest. Can I sum them up by saying that you wish for D to be more of a meta-language, such as providing the building blocks for dynamic arrays rather than implementing them directly? That's a valid point of view, and certainly the one C++ takes with STL. So why doesDhave dynamic arrays built in? 1) They are so darned useful. I use them everywhere in my own code - and find them to be a more than suitable replacement for most singly linked lists, doubly linked lists, stacks, queues, etc. Having to learn only dynamic arrays instead of vectors, lists, stacks, queues, etc., makes programming easier and less buggy.But the performance characteristics of dynamic arrays don't match those of lists. Yeah, you *can* build any container type out of some other container type, but the fundamental containers (vector, list) have vastly different performance characteristics and can't easily emulate one another without being very inefficient. Lists are for fast arbitrary insertion and removal and linear traversal. Arrays are for fast random access or linear traversal and are easier to copy since the whole thing can be copied as a contiguous block. Insertion at the end isn't too bad but can cause reallocations, insertion or removal at the beginning are very slow.2) By integrating them into the language, D can achieve tight and nearly seamless integration with static C style arrays - important forinterfacingwith external C functions.This is nice.3) Since the compiler knows about dynamic arrays, sensible and to thepointerror diagnostics can be issued, rather than the notoriously inscrutable messages coming from metalanguage constructs.Heh. Good point. ;)4) Good code can be generated for a builtin construct by a less sophisticated compiler. Constructs built up from meta-primitives usually need a very advanced compiler to generate comparably good code.Agreed.5) Designing the syntax into the language enables the use of specialsyntaxwhere useful, such as the array slicing syntax.Yes.6) In a garbage collected language, dynamic arrays should be a fundamental type, not something built up from metalanguage constructs. Metalanguage constructs are needed for special types, and should not be necessary for basic types.Agreed, the most basic of basic types should be part of the language. They're so basic that everyone will have to implement them anyway or that they'll need to be part of the standard library. I think we should take another look at the possibility of adding linked lists directly to the language and formalizing the concept of iterator as a basic language feature. Can this be done? If so, how? I'm going to split this off into a new thread. Sean
Jul 20 2002
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message news:ahcipd$4tg$1 digitaldaemon.com..."Walter" <walter digitalmars.com> wrote in message news:ahaldu$ptj$1 digitaldaemon.com...containerSo why does D have dynamic arrays built in? 1) They are so darned useful. I use them everywhere in my own code - and find them to be a more than suitable replacement for most singly linked lists, doubly linked lists, stacks, queues, etc. Having to learn only dynamic arrays instead of vectors, lists, stacks, queues, etc., makes programming easier and less buggy.But the performance characteristics of dynamic arrays don't match those of lists. Yeah, you *can* build any container type out of some othertype, but the fundamental containers (vector, list) have vastly different performance characteristics and can't easily emulate one another without being very inefficient.Yes, they are very different for long lists and long arrays. 99% of the time, however, I find that I have just a handful of members, and the performance difference just doesn't come up on the radar screen.I think we should take another look at the possibility of adding linked lists directly to the language and formalizing the concept of iterator asabasic language feature. Can this be done? If so, how? I'm going to split this off into a new thread.Ok, see ya there.
Jul 20 2002
I use Delphi and C++, Borland and Microsoft's 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... 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
Jul 11 2002
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
Jul 11 2002
"Toyotomi" <kaishaku13 hotmail.com> wrote in message news:bekriu4v4rm3ki1k7ip1n8071b9dmrfsct 4ax.com...I use Delphi and C++, Borland and Microsoft's 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... 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... -ToyotomiI 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? 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 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
Jul 13 2002
On Sat, 13 Jul 2002 22:36:45 +0200, "OddesE" <OddesE_XYZ hotmail.com> wrote: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?it is like Java, and it is not like a self sufficient C/C++/Delphi app. The runtime and memory use is insanely larger, and it will never be the same thing. In order of frequency I use Delphi, C++ Builder & Visual Studio... However, after that are a slew of other languages and tools.
Jul 14 2002
"Toyotomi" <kaishaku13 hotmail.com> wrote in message news:e7j4ju49poihi6br27eqsgi4hv7vdl256s 4ax.com...it is like Java, and it is not like a self sufficient C/C++/Delphi app. The runtime and memory use is insanely larger, and it will never be the same thing. In order of frequency I use Delphi, C++ Builder & Visual Studio... However, after that are a slew of other languages and tools.Well, you certainly seem to have a lot more experience with it than me. I guess I was misinformed. Sorry about that. So there really *is* a gap in the market for D. I thought you could straight compile your programs too. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jul 16 2002
"OddesE" <OddesE_XYZ hotmail.com> wrote in message news:ah1b24$1iko$1 digitaldaemon.com..."Toyotomi" <kaishaku13 hotmail.com> wrote in message news:e7j4ju49poihi6br27eqsgi4hv7vdl256s 4ax.com...estatebutYou can "straight compile your programs", but I'm told that COM makes it slow. I'll b't there's still a JITC still working on some of the compoents.it is like Java, and it is not like a self sufficient C/C++/Delphi app. The runtime and memory use is insanely larger, and it will never be the same thing. In order of frequency I use Delphi, C++ Builder & Visual Studio... However, after that are a slew of other languages and tools.Well, you certainly seem to have a lot more experience with it than me. I guess I was misinformed. Sorry about that. So there really *is* a gap in the market for D. I thought you could straight compile your programs too.-- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jul 16 2002
"OddesE" <OddesE_XYZ hotmail.com> wrote in message news:ah1b24$1iko$1 digitaldaemon.com...Well, you certainly seem to have a lot more experience with it than me. I guess I was misinformed. Sorry about that. So there really *is* a gap in the market for D. I thought you could straight compile your programs too.machine code. This has a lot of interesting ramifications, from subtleties of the language design to how a resulting app looks. For example, you can
Jul 19 2002
"Walter" <walter digitalmars.com> wrote in message news:ahahse$mn4$1 digitaldaemon.com...intomachine code. This has a lot of interesting ramifications, from subtleties of the language design to how a resulting app looks. For example, you can"system apps". I'm thinking device drivers. Could anyone provide me with other examples? Are there aspects of D other than it's ability to do inline assembly that lends D to systems programming? Apologies - I don't know much about systems programming. Why is it that device drivers need to be written in assembler? -- Regards, Steve.
Jul 20 2002
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message news:ahcv9a$hhg$1 digitaldaemon.com..."system apps". I'm thinking device drivers. Could anyone provide me with other examples?Most of the operating system can be called a "system app". System apps include compilers, editors, utilities, networking infrastructure code, the Java VM, the .net VM, etc.Are there aspects of D other than it's ability to do inline assembly that lends D to systems programming?Yes: 1) it can be compiled to machine code and stored as an executable binary 2) it doesn't require an abstraction layer or virtual machine between it and the actual hardware 3) it can interface directly to the raw operating system entry points 4) type checking, semantic analysis, etc., is done at compile time, not run time, so the executable code runs at maximal speed with minimal overhead 5) the semantics of the language are flexible enough to conform to the actual peculiarities of real CPUs, so no costly and slow emulations are necessaryApologies - I don't know much about systems programming. Why is it that device drivers need to be written in assembler?They don't always need to be written in assembler - but frequently there are special instructions that need to be executed, I/O ports that need accessing, interrupt handlers that need hooking, etc., and those usually get done with a bit of assembler. Inline assembler can also get you out of a hole when the compiler is not generating good enough code for a particular performance bottleneck.
Jul 20 2002
"Walter" <walter digitalmars.com> wrote in message news:ahd42a$lt8$1 digitaldaemon.com..."Steven Shaw" <steven_shaw iprimus.com.au> wrote in message news:ahcv9a$hhg$1 digitaldaemon.com...Just to clarify: .net doesn't have a VM. It's just got a runtime. Microsoft calls it CLR for .net and CLI in the ecma spec Common Language Runtime (or Infrastructure I think). I get what you mean. Modula-3 was a language, too that was design to be used for systems programming but still had modules, class-based objects and gc."system apps". I'm thinking device drivers. Could anyone provide me with other examples?Most of the operating system can be called a "system app". System apps include compilers, editors, utilities, networking infrastructure code, the Java VM, the .net VM, etc.thatAre there aspects of D other than it's ability to do inline assemblyFor some embedded work this is probably mandatory. I get the feeling, though, that many system apps do not require this feature. Though it doesn't hurt to have it. newsgroup. You can write compilers, editors, jvm's in Java (can't say I know *how* they did it), so I'm sure that it would be pretty hard to come up with a task that just flat can't be done.lends D to systems programming?Yes: 1) it can be compiled to machine code and stored as an executable binary2) it doesn't require an abstraction layer or virtual machine between itandthe actual hardwareDoes this mean that D doesn't have a runtime? Or more likely that you can optionally leave out the runtime at link time?3) it can interface directly to the raw operating system entry pointsIs this the C interoperability at work?4) type checking, semantic analysis, etc., is done at compile time, notruntime, so the executable code runs at maximal speed with minimal overheadI also get the feeling from other posts that the D implementation uses whole program optimisation techniques to decide when methods need not be dynamically dispatched. yes?5) the semantics of the language are flexible enough to conform to the actual peculiarities of real CPUs, so no costly and slow emulations are necessaryUnderstood. More like C (than Java) in this respect.areApologies - I don't know much about systems programming. Why is it that device drivers need to be written in assembler?They don't always need to be written in assembler - but frequently therespecial instructions that need to be executed, I/O ports that need accessing, interrupt handlers that need hooking, etc., and those usuallygetdone with a bit of assembler. Inline assembler can also get you out of a hole when the compiler is not generating good enough code for a particular performance bottleneck.Thanks. This is starting to ring some old bells from school days. In a C project I once saw inline assembler used to access the host cpu's test-and-set operation(s) for implementing locks. Until then I didn't think you could embed asm in C (maybe just a gcc enhancement). --Cheers, Steve.
Jul 21 2002
On Sun, 21 Jul 2002 18:27:08 +1000 "Steven Shaw" <steven_shaw iprimus.com.au> wrote:For some embedded work this is probably mandatory. I get the feeling, though, that many system apps do not require this feature. Though it doesn't hurt to have it. newsgroup. You can write compilers, editors, jvm's in Java (can't say I know *how* they did it), so I'm sure that it would be pretty hard to come up with a task that just flat can't be done.You can write GUI applications in Java, but do they work fast? And how would they work if entire graphics output, down to the lowest-level primitives, would be written in Java? VM... not sure how fast VM written in Java would be, but I'd bet it is slower than any VM written in some non-interpreted language.It does, but it is embedded into your executable. You don't need any external applications or DLLs or components to run the D program. For Java, you need2) it doesn't require an abstraction layer or virtual machine between itandthe actual hardwareDoes this mean that D doesn't have a runtime?Or more likely that you can optionally leave out the runtime at link time?I doubt. GC, dynamic arrays, hashes, class Object, ClassInfo - are all in RTL.Not only C, but also stdcall.3) it can interface directly to the raw operating system entry pointsIs this the C interoperability at work?I also get the feeling from other posts that the D implementation uses whole program optimisation techniques to decide when methods need not be dynamically dispatched. yes?It is stated. But I'm not sure whether current alpha supports this.Thanks. This is starting to ring some old bells from school days. In a C project I once saw inline assembler used to access the host cpu's test-and-set operation(s) for implementing locks. Until then I didn't think you could embed asm in C (maybe just a gcc enhancement).It isn't ANSI C (nor C++), but I haven't yet seen any C/C++ compiler which doesn't support some form of inline asm. At least MS, Intel, Borland, GNU, and DM compilers support it.
Jul 21 2002
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message news:ahdqvg$1cru$1 digitaldaemon.com..."Walter" <walter digitalmars.com> wrote in message news:ahd42a$lt8$1 digitaldaemon.com... Just to clarify: .net doesn't have a VM. It's just got a runtime.Microsoftcalls it CLR for .net and CLI in the ecma spec Common Language Runtime (or Infrastructure I think).ready to run app), I need the VM, CLR, or CLI which is (correct me if I'm wrong) over 10 megabytes of memory. That may not be so important in the future, but it is now.For some embedded work this is probably mandatory. I get the feeling, though, that many system apps do not require this feature. Though it doesn't hurt tohaveit.Correct, you can write systems apps that don't use inline assembler, but the more sophisticated and commercially successful ones generally do.newsgroup. You can write compilers, editors, jvm's in Java (can't say I know *how*theydid it), soI took the Java compiler written in Java and translated it to C++. It ran ten times faster.I'm sure that it would be pretty hard to come up with a task that justflatcan't be done.Sure, it's less of an issue of can/cannot be done, but how practical it is.D does have a runtime, but it is pretty minimal at 40k rather than multiple megabytes. The runtime can also be bypassed for special apps. One other conceptual difference is that D apps do not run under the control of the app. D apps do not run in a sandbox created by the runtime, and D apps can do every down and dirty programming trick if you really want to use them.2) it doesn't require an abstraction layer or virtual machine between itandthe actual hardwareDoes this mean that D doesn't have a runtime? Or more likely that you can optionally leave out the runtime at link time?need to create a DLL with wrappers, and you need to do considerable translation for passing other than the most basic types.3) it can interface directly to the raw operating system entry pointsIs this the C interoperability at work?whole4) type checking, semantic analysis, etc., is done at compile time, notruntime, so the executable code runs at maximal speed with minimal overheadI also get the feeling from other posts that the D implementation usesprogram optimisation techniques to decide when methods need not be dynamically dispatched. yes?D can do this, although the current implementation does not.
Jul 21 2002
"Walter" <walter digitalmars.com> wrote in message news:ahf57o$2j1a$1 digitaldaemon.com..."Steven Shaw" <steven_shaw iprimus.com.au> wrote in message news:ahdqvg$1cru$1 digitaldaemon.com...I don't know how much memory the CLR takes up. I think the embedded version is being worked on."Walter" <walter digitalmars.com> wrote in message news:ahd42a$lt8$1 digitaldaemon.com... Just to clarify: .net doesn't have a VM. It's just got a runtime.Microsoftcalls it CLR for .net and CLI in the ecma spec Common Language Runtime (or Infrastructure I think).ready to run app), I need the VM, CLR, or CLI which is (correct me if I'm wrong) over 10 megabytes of memory. That may not be so important in the future, but it is now.*snip*Typical jvms has this lazy compilation of methods which I think is not such a great idea. This could have been a large part of the time taken. To see what a difference it makes you could use something like beanshell, run the compiler once to ensure it is compiled and then again to measure. It would be interesting to see how the results differ when using gcj. I can see, though, that with D, you don't have to worry about startup speed. as it is with Java/JVM.newsgroup. You can write compilers, editors, jvm's in Java (can't say I know *how*theydid it), soI took the Java compiler written in Java and translated it to C++. It ran ten times faster.is. Sure.I'm sure that it would be pretty hard to come up with a task that justflatcan't be done.Sure, it's less of an issue of can/cannot be done, but how practical itit2) it doesn't require an abstraction layer or virtual machine betweentime?andthe actual hardwareDoes this mean that D doesn't have a runtime? Or more likely that you can optionally leave out the runtime at linkD does have a runtime, but it is pretty minimal at 40k rather thanmultiplemegabytes. The runtime can also be bypassed for special apps. One other conceptual difference is that D apps do not run under the control of the app. D apps do not run in a sandbox created by the runtime, and D apps can do every down and dirty programming trick if you really want to use them.I'm not sure what you're getting at here. Could you please provide an example?you3) it can interface directly to the raw operating system entry pointsIs this the C interoperability at work?need to create a DLL with wrappers, and you need to do considerable translation for passing other than the most basic types.This is something that really makes D different. I really hate JNI wrappers. CLR has platform invoke but I don't know enough to comment on it.not4) type checking, semantic analysis, etc., is done at compile time,overheadruntime, so the executable code runs at maximal speed with minimalThis could be hard/impossible to achieve in the face of dynamic loading. Java implementations can handle this at runtime, purging native code when dynamic loading causes invalidation of a this optimisation. purged when assemblies are loaded at runtime, too but I don't think the current implementations do it that way. I like D. A smallish, fast to compile, fast to execute, modular, java-style oo, gc'ed language. like them all. --Cheers, Steve.I also get the feeling from other posts that the D implementation useswholeprogram optimisation techniques to decide when methods need not be dynamically dispatched. yes?D can do this, although the current implementation does not.
Jul 21 2002
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message news:ahg4lr$g45$1 digitaldaemon.com..."Walter" <walter digitalmars.com> wrote in message news:ahf57o$2j1a$1 digitaldaemon.com...ranI took the Java compiler written in Java and translated it to C++. Itsuchten times faster.Typical jvms has this lazy compilation of methods which I think is nota great idea. This could have been a large part of the time taken. To see what a difference it makes you could use something like beanshell, run the compiler once to ensure it is compiled and then again to measure. It would be interesting to seehowthe results differ when using gcj.Why it was faster in C++ is a complicated matter, it's more than just startup time. And no, it wasn't the garbage collector <g>.canD does have a runtime, but it is pretty minimal at 40k rather thanmultiplemegabytes. The runtime can also be bypassed for special apps. One other conceptual difference is that D apps do not run under the control of the app. D apps do not run in a sandbox created by the runtime, and D appsthem.do every down and dirty programming trick if you really want to useI'm not sure what you're getting at here. Could you please provide an example?For example, you can write a garbage collector in D. There is no way to do it in Java - the type checking and the sandbox will prevent it.This could be hard/impossible to achieve in the face of dynamic loading.Yes, but currently D is not defined to deal with dynamic loading. <g>I like D. A smallish, fast to compile, fast to execute, modular,java-styleoo, gc'ed language. like them all.They each have their place. D is not targetted at what Java is, so the design tradeoffs are different. Using D for what Java is best at is inappropriate, and vice versa.
Jul 22 2002
"Walter" <walter digitalmars.com> wrote in message news:ahgfa7$sgf$1 digitaldaemon.com...But it will at some point, won't it? ;-) Salutaciones, JCABThis could be hard/impossible to achieve in the face of dynamic loading.Yes, but currently D is not defined to deal with dynamic loading. <g>
Jul 22 2002
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message news:ahk5pu$2ao$1 digitaldaemon.com..."Walter" <walter digitalmars.com> wrote in message news:ahgfa7$sgf$1 digitaldaemon.com...loading.This could be hard/impossible to achieve in the face of dynamicI'm not sure how that would work out.Yes, but currently D is not defined to deal with dynamic loading. <g>But it will at some point, won't it? ;-)
Jul 23 2002
"Walter" <walter digitalmars.com> wrote in message news:ahk9fv$1b1h$1 digitaldaemon.com...You'd need to provide a way to express the binary interface of the DLL. For example, inhibiting inheritance from specific classes outside of the DLL where they reside would get you a large portion of the way there. In general, the interface would somehow be: - List of classes that are abstract from outside the DLL. Useful for handle-style APIs. - List of classes, variables and functions that are publicly accessible from outside the DLL. - List of classes that are also inheritable from outside the DLL. Now, you can optimize the hell out of everything in the DLL, except those classes you can inherit from. Salutaciones, JCABI'm not sure how that would work out.Yes, but currently D is not defined to deal with dynamic loading. <g>But it will at some point, won't it? ;-)
Jul 24 2002
"Walter" <walter digitalmars.com> wrote in message news:ahk9fv$1b1h$1 digitaldaemon.com..."Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message news:ahk5pu$2ao$1 digitaldaemon.com...I'd like it to compile/load C style DLL's and simply have a handle attached to each method (or as a state machine) for classes. That way you could DLL write code in C (or C++ interfaced by C) and use it in D dynamicly. Also you could write a DLL in D and use it dynamicly in C. Parhaps exceptions could be used to test if functions exist. It's annoying having to type the same code over and over in C to simply test and extract all the functions from a DLL in C. Parhaps D could also complie a sample dynamic loading code with all the funcion/methods defintions included or one better, create a .d file that does it for that file. Parhaps for classes it may look something like: class eatMe : mouth; loadDLibrary(Filename, eatME); eatME Object; //But that'll need more work. And a for a function list (called functionList) DLL with a pre-produced .d file (functionlist.d). import functionlist; loadFunctionList(Filename); //Of course that would only allow one set of functionList, but classes should generaly be used for more the one anyway. Besides parhaps they could be indexed using a state machine type structure. setFunctionList(int Index); //Index to the current set of functions Of course there's the other side to look at: Parhaps for classes... dll class eatME : mouth { ... } and functions dll void func() { ... } These are just a starting point, and probably need alot of work."Walter" <walter digitalmars.com> wrote in message news:ahgfa7$sgf$1 digitaldaemon.com...loading.This could be hard/impossible to achieve in the face of dynamicI'm not sure how that would work out.Yes, but currently D is not defined to deal with dynamic loading. <g>But it will at some point, won't it? ;-)
Jul 24 2002
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 justloveAda. ;-) 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. Ithinkit 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 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? IthinkD 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 languageshouldcontain a basic, general set of... em, capabilities (not sure it's a right word), and everything else should be defined using the language itself.Canyou 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, butstillI think that there's no usable programming environment for C++. But thebestthing in C++ is that it allows you to create a very good one. Nobody didit,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.WhileGC 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 ifdynamicarrays 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. :-) Complexmustbe 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 addingsomethingnew 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 someconceptsof 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 withanythingelse.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" oftypeInteger, 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 typeCompiler 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 beimplicitlyconverted 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 leastinteresting (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; --Fixedpoint aka "Currency" typeNow 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 onSo 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* typeWhat kind of wierd syntax is this?type Elem is private; -- Elem is any fixed-size type supporting "="andassignmentIf 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 noGUIlibrary, 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 isnot!*/ 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 thistype-- 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 : outElement_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 youfromwrong -- design of your programs. Ada makes you use it's way of architecture design; -- follow it or use another language, because non-Ada architecturewillnever -- 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 initializationlike:= 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-onecorrespondencewith 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 separatecompilationwas 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,theyour 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 notcriticizingD, I want to to be a really good language, not just another one. If youwantD 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 objectconstructiontook a dozen articles in MSDN ("Deep C++"). Explanation of Delphi's behaviour takes a dozen paragraphs. It does not mean Delphi is simplierandbetter - it means when an exception will raise in our constructor, youwillhave much headache and thinking as Delphi was not thought over enough.(Yourdestructors 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
Jul 11 2002
What's with the apostophe operator? SeanIt's simular to D's property syntax. ( ' instead of . )
Jul 12 2002
"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 theprivatemembers exist. Which means you need to be able to specify them fromoutsidethe 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>SeanSo 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
Jul 13 2002
That forces everything to be virtual. But yeah it would work unless you wanted to have data in the public interface. What I want really is to be able to avoid having to use pImpl pattern as is necessary to really hide the guts of a class in C++. This may already be mostly possible in D; probably is. Sean "OddesE" <OddesE_XYZ hotmail.com> wrote in message news:agq3mj$b41$1 digitaldaemon.com..."Sean L. Palmer" <seanpalmer earthlink.net> wrote in message news:aglttj$uan$1 digitaldaemon.com... <SNIP>anyIf you ask me (and you didn't) I'd want to be able to completely hideprivate members from other code. Other code shouldn't even know theprivatemembers exist. Which means you need to be able to specify them fromoutsidethe 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>SeanSo 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
Jul 13 2002
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message news:agq42d$bb6$1 digitaldaemon.com...That forces everything to be virtual.In D all method pointers are already virtual aren't they?But yeah it would work unless you wanted to have data in the public interface. What I want really is to be able to avoid having to use pImpl pattern asisnecessary to really hide the guts of a class in C++. This may already be mostly possible in D; probably is. SeanYeah, when I first learned that private fields need to be in the .h file in C++ I thought it really sucked too! They should have something like int CMyClass::myfield; in the .cpp files, where CMyClass would be a class declared in a header file included by the .cpp file. This should also go for methods. If they only exist in the .cpp file, they are automatically private. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jul 14 2002
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 theprivatemembers exist. Which means you need to be able to specify them fromoutsidethe externally visible declaration.Yes, I never understood why C++ kept privates visible in the header. D automatically generates a header file, perhaps they could be removed from that. If it is useful to have a private member listing, they could be placed in another file.
Jul 13 2002
Hello.Yes, I never understood why C++ kept privates visible in the header. D automatically generates a header file, perhaps they could be removed from that. If it is useful to have a private member listing, they could be placed in another file.I don't understand all of you. Private data *must* be visible to the world, because compilers must know how much memory to allocate for your classes. C++ does not use reference symantics, neither does Ada. But Ada allows you to define everything you want to be private in the private section of the package (and in C++, like I've shown, something that should be private has to be public, and that is not good). Of course, nonvirtual private procedures can (and should) be declared in the body of the package, i.e., the world wan't know anything. Virtual procedures must be in the spec to know how many slots does your type occupy in the v-table. About exceptions: my example was not good. I did not meant that you should pass line & column no of exception. The exception was named EBadToken, and it was a part of some hypotetical lexical parser. LineNo and ColNo were just information that could be called FooData and BarData. The names do not matter. I said that was not a proposal because that was not a complete exception model. A proposal is something I think is suitable for the language, or at least one of the ways something might be implemented. And my code was just an example, to start a subject of exceptions. I think the idea of having numerous allocation methods is rather good. Again, first, look thru Ada Rationale - Ada has a convinient model of storage pools. I don't say D's "allocation methods" should look like Ada storage pools, but before creating something yourself, it's better to look through the existent implementations, determine what you like and what you don't like.
Jul 14 2002
"Andrey Tarantsov" <andreyvit nvkz.kuzbass.net> wrote in message news:agschk$2idc$1 digitaldaemon.com...Hello.fromYes, I never understood why C++ kept privates visible in the header. D automatically generates a header file, perhaps they could be removedworld,that. If it is useful to have a private member listing, they could be placed in another file.I don't understand all of you. Private data *must* be visible to thebecause compilers must know how much memory to allocate for your classes.An intelligent compiler can append the private members from the body file before compliation. Java does this. From a users point of view, private's is just space junk because they can't use it. Ada had the same problem.Of course, nonvirtual private procedures can (and should) be declared inthe body of the package. When would you ever get a virtual private?
Jul 14 2002
"Andrey Tarantsov" <andreyvit nvkz.kuzbass.net> wrote in message news:agschk$2idc$1 digitaldaemon.com...Hello.fromYes, I never understood why C++ kept privates visible in the header. D automatically generates a header file, perhaps they could be removedworld,that. If it is useful to have a private member listing, they could be placed in another file.I don't understand all of you. Private data *must* be visible to thebecause compilers must know how much memory to allocate for your classes. C++ does not use reference symantics, neither does Ada. But Ada allows you to define everything you want to be private in the private section of the package (and in C++, like I've shown, something that should be private has to be public, and that is not good). Of course, nonvirtual private procedures can (and should) be declared in the body of the package, i.e., the world wan't know anything. Virtual procedures must be in the spec to know how many slots does your type occupy in the v-table.They should get such information from the linker. Code generation should go after link step. Or the compiler and linker could be otherwise integrated. You need this for templates anyway.About exceptions: my example was not good. I did not meant that you should pass line & column no of exception. The exception was named EBadToken, and it was a part of some hypotetical lexical parser. LineNo and ColNo werejustinformation that could be called FooData and BarData. The names do not matter. I said that was not a proposal because that was not a complete exception model. A proposal is something I think is suitable for the language, or at least one of the ways something might be implemented. And my code was just an example, to start a subject of exceptions. I think the idea of having numerous allocation methods is rather good. Again, first, look thru Ada Rationale - Ada has a convinient model of storage pools. I don't say D's "allocation methods" should look like Ada storage pools, but before creating something yourself, it's better to look through the existent implementations, determine what you like and what you don't like.If to allocate an object you had to call some kind of per-class allocator instead of just requesting memory from wherever you want, this would be solved nicely. Is the extra flexibility really worth it? Perhaps a class could have multiple potential allocator pools (system memory, fast memory, or fixed sized preallocated buffer slot) Sean
Jul 15 2002