"Walter" <walter digitalmars.com> escribiσ en el mensaje
news:bf1vgj$ql1$2 digitaldaemon.com...
|
| Everyone can help with this by simply talking about D here and in the
| regular internet newsgroups. Also, if you have some web space, put up a
web
| page on D!
|
I tried to do that for a while, but it seems to me like people aren't
interested in trying new things anymore. But I still do what I can: last
week I had an assignment about garbage collection in Java. Well, it kind of
went like this: "GC was first invented for Lisp... Other major languages
that use GC are Java, D, Prolog, Eiffel...".
Eventually this has to stop being a community, and start being something
bigger, something really big, so I agree that we all should contribute with
its growing.

Carlos Santander
"Walter" <walter digitalmars.com> escribiσ en el mensaje
news:bf1vgj$ql1$2 digitaldaemon.com...
|
| Everyone can help with this by simply talking about D here and in the
| regular internet newsgroups. Also, if you have some web space, put up a
web
| page on D!
|
I tried to do that for a while, but it seems to me like people aren't
interested in trying new things anymore. But I still do what I can: last
week I had an assignment about garbage collection in Java. Well, it kind of
went like this: "GC was first invented for Lisp... Other major languages
that use GC are Java, D, Prolog, Eiffel...".
Eventually this has to stop being a community, and start being something
bigger, something really big, so I agree that we all should contribute with
its growing.

Carlos Santander

- A cleaned-up syntax that has no baggage or special cases. No support
for double-syntaxes (C-style function pointers and arrays). Struct
constructors and destructors (with clearer rules than C++), and
consequently the removal of the RTTI hack. Support for struct
inheritance. No special case handling of constructors; removing the
"super ()" special case which should be "super.this ()"; their
inheritance should be the same as any other method; and "new Object;"
should not be valid. Bracketing with special methods should be
consistent; either you need parentheses "~this ()" or you don't
"unittest". None of this half-and-half.
- A useable template syntax that is integrated into the language as
full-blown genericism, rather than appearing, like C++, to be attached
on top of it. In particular, it must be better suited for generic
arguments to methods than either C++ or D are.
- A modern and platform-isomorphic link and installation system that has
no difference between static and shared binaries (either in writing, in
compiling, or in using them), doesn't penalise casual computer users,
and uses a single shared library format if possible, without affecting
integration with C.

- A useable template syntax that is integrated into the language as
full-blown genericism, rather than appearing, like C++, to be attached
on top of it. In particular, it must be better suited for generic
arguments to methods than either C++ or D are.

- A useable template syntax that is integrated into the language as
full-blown genericism, rather than appearing, like C++, to be attached
on top of it. In particular, it must be better suited for generic
arguments to methods than either C++ or D are.

I'm not sure what you mean here.

You stated once that one of the tests of a templating syntax is how it
implements min and max. In D this would be:
template Min (T)
{
T min (T a, T b)
{
return a > b ? b : a;
}
}
int c = instance Min (int).min (a, b);
I'm going to overspecify for the next two languages for the purpose of
fair comparison. In C++ this would be:
template <class T>
T min (T a, T b)
{
return a > b ? b : a;
}
int c = min <int> (a, b);
In both cases, templating is a separate syntax attached on the language
with as minimal mixing as possible to get the job done. An integrated
syntax makes it part of the language; one is my own:
$T min (TypeInfo $T, $T a, $T b)
{
return a > b ? b : a;
}
int c = min (int, a, b);
D is definitely the loser here; I have only used the feature a few
times (not for lack of wanting), but every time there's been this
identifier repetition symbolic of an unnecessary abstraction. C++ can
do implicit instantiation (by arbitrarily altering the syntax based on
usage), but still attaches templating on like the macro processing
syntax it was. An integrated syntax allows me to program with one
consistent methodology.
C++ template libraries are the most illegible things I've ever had the
misfortune of dealing with. D template libraries will be worse (at
least, when they finally come around) because of even more syntactual
baggage; so much so that it lessens the variety of applications they can
be pragmatically used with. Just take C++ templates, make them take
much more typing but be less capable in important ways, and you have D
templates.

- A useable template syntax that is integrated into the language as
full-blown genericism, rather than appearing, like C++, to be attached
on top of it. In particular, it must be better suited for generic
arguments to methods than either C++ or D are.

I'm not sure what you mean here.

You stated once that one of the tests of a templating syntax is how it
implements min and max. In D this would be:
template Min (T)
{
T min (T a, T b)
{
return a > b ? b : a;
}
}
int c = instance Min (int).min (a, b);
I'm going to overspecify for the next two languages for the purpose of
fair comparison. In C++ this would be:
template <class T>
T min (T a, T b)
{
return a > b ? b : a;
}
int c = min <int> (a, b);
In both cases, templating is a separate syntax attached on the language
with as minimal mixing as possible to get the job done. An integrated
syntax makes it part of the language; one is my own:
$T min (TypeInfo $T, $T a, $T b)
{
return a > b ? b : a;
}
int c = min (int, a, b);
D is definitely the loser here; I have only used the feature a few
times (not for lack of wanting), but every time there's been this
identifier repetition symbolic of an unnecessary abstraction. C++ can
do implicit instantiation (by arbitrarily altering the syntax based on
usage), but still attaches templating on like the macro processing
syntax it was. An integrated syntax allows me to program with one
consistent methodology.
C++ template libraries are the most illegible things I've ever had the
misfortune of dealing with. D template libraries will be worse (at
least, when they finally come around) because of even more syntactual
baggage; so much so that it lessens the variety of applications they can
be pragmatically used with. Just take C++ templates, make them take
much more typing but be less capable in important ways, and you have D
templates.

Just take C++ templates, make them take
much more typing but be less capable in important ways

How would they be less capable, and what do we want to do about it ? A
Petition maybe (only half joking :) ), walter what do you think ?
Charles

Just take C++ templates, make them take
much more typing but be less capable in important ways

How would they be less capable, and what do we want to do about it ? A
Petition maybe (only half joking :) ), walter what do you think ?

This is an old argument - my counter-proposal actually predates the
templates implementation (a year old next week) by a couple months.
Search for the subjects "Templates and matrices", "Serious deficiencies
in template mechanism", "C and/or C++ in D" (this one for my proposal),
and "Generics in D".
I'd make some tweaks to my proposal now; "$T" instead of "TypeInfo $T"
(Craig Black was right - "foo [int $T]" is redundant but better), and
C++-style specialisations don't work because no argument can be said to
be the owner so constraints should be separated.
Capability-wise there's no implicit instantiation in D templates,
default arguments, template methods, or a huge set of hard-to-comprehend
abilities. I don't want them; my proposal isn't as flexible in some
ways. I just want generics, not a template system.

In both cases, templating is a separate syntax attached on the language
with as minimal mixing as possible to get the job done. An integrated
syntax makes it part of the language; one is my own:
$T min (TypeInfo $T, $T a, $T b)
{
return a > b ? b : a;
}
int c = min (int, a, b);

It can't be a template -- its readable!
The mere mention of templates was enough to convince me
to not use D.
Karl Bochert

That's funny!
Yes, generics don't have to be a hideous boil on the face of the language.
;)
Sean
"Karl Bochert" <kbochert copper.net> wrote in message
news:1103_1059967426 bose...

On Fri, 01 Aug 2003 14:46:40 -0700, Burton Radons

Walter wrote:

In both cases, templating is a separate syntax attached on the language
with as minimal mixing as possible to get the job done. An integrated
syntax makes it part of the language; one is my own:
$T min (TypeInfo $T, $T a, $T b)
{
return a > b ? b : a;
}
int c = min (int, a, b);

It can't be a template -- its readable!
The mere mention of templates was enough to convince me
to not use D.
Karl Bochert

C++ template libraries are the most illegible things I've ever had the
misfortune of dealing with. D template libraries will be worse (at
least, when they finally come around) because of even more syntactual
baggage; so much so that it lessens the variety of applications they can
be pragmatically used with. Just take C++ templates, make them take
much more typing but be less capable in important ways, and you have D
templates.

While D templates do require more typing in the (trivial) example you
provided, if the templates have a mix of function and class templates
grouped together, the D template method is far less typing. It's also
possible to use the aliases to reduce the typing:
alias instance Min(int).min mymin;
int c = mymin(a,b);
The syntax you proposed is certainly intriguing, and works well for things
like min. I'm less sure it will work well for things like partial
specialization, etc.

Graduated in '86, been working ever since. Had some experience before.

3) What's your D knowledge?

Beginner

4) What programming language are you most familiar with?

C, C++, Java, assembly, Lisp, Scheme, Fortran, Basic, some others

5) What's your main operating system?

Unix (mostly Linux) and Windows.

6) Which type of application you want to develop in D?

It looks like the next language I switch to will be of the extendable variety
where new syntax and symantics can be added.

7) Top Three Wishes for D?

My needs are too specific to make it into D (or other non-extendable langauges),
which is why I need an extendable language. However, three of the most
important extensions for me are:
1) Dynamic class extension
2) Better support for relationships between classes, much like what can be found
in relational databases
3) Sather-like code reuse (the "include" construct)
Bill

Thanks for the link. I'm having some trouble getting good info on
Dynace, but at first look, it seems to be a non-extendable language
translator (like most C derived languages). The dynamic extensions are
useful for me, but the other features would be missing.
Bill

I'd really like to be able to treat an instance as a type:
alias instance List<Foo> FooList;
FooList.List myFooList;
FooList.Iterator i;
Also, it seems like the approach to implementing default template

efficient numeric computing. We could define algorithms in terms of
precision (template parameters) and be able to instantiate different
versions of the algorithm for different precisions, or compute the result
precision from the parameters and the algorithm used (as in dr. Kahan's
paper).
Other issue is how to deal with multiple template versions and code
sharing:
template TList(T) {
class List {
public void sort(int delegate(T, T) comparator) {
// code goes here
}
}
}
template TList(T : Comparable) {
/* how can we instantiate the previous definition to create the "Super"
alias?
*/
private alias instance TList(T).List Super;
class List : Super {
public void sort() {
// code goes here
}
}
}
With the class definition we can "cheat" and create subclasses of the
earlier definitions, but with plain templates it fails:
template TAssert(T) {
public void equals(T expected, T received) {
// code goes here
}
}
template TAssert(T : double) {
public void equals(T expected, T received, double precision) {
// code goes here
}
}
instance TAssert(double) check;
check.equals(1.001, 1.000, 0.001); // works as expected
check.equals(1.0, 1.0); // fails
The second "TAssert" definition is an extension/specialization of the
previous template, it should have all definitions from the earlier

definition, plus the new ones, overriding accordingly. Some kind of

inheritance is necessary, either explicit or implicit. Otherwise we'll

to duplicate the definitions for all specializations.

Ok, I understand that one!

I think that these two extensions are important and necessary to both
library writers and user programmers. Also the unification of the type
system, regarding delegates and function pointers, allowing templates with
function parameters.
Best regards,
Daniel Yokomiso.
"Time is the best teacher unfortunately it kills all its students."
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 14/8/2003

* we could also use the "this" keyword or whatever, as long as the
programmer
* doesn't need to write something like "A instance
A.TMul(B.columns()).mul(B)" to
* safely multiply the A and B matrices.
*/
alias instance TMatrix(T, COLUMNS, N).Matrix OtherMatrix;
alias instance TMatrix(T, ROWS, N).Matrix ResultMatrix;
public ResultMatrix mul(OtherMatrix other) {
// code goes here
}
}
}
}
In this case we have some kind of implicit instantiation, but this

of template mechanism will be available in the next versions of Java and

Also almost all statically-typed functional programming languages have

kind of type system.
The parameters for the "implicit" template should be always

determined from the operation's parameters, in this case the "other"

template instance.

I don't get it. Is the implicit template a new template within TMatrix?
Where does N come from again?

The implicit is just a way to say to the compiler: "the following
operation is a template inside the TMatrix, but with this parameter N, that
must come from the operation's parameters". So N is a the number of columns
of OtherMatrix which must have a number of rows equal to the TMatrix COLUMNS
parameter. It's just a way to define the matrix multiplication rule from
basic math.
In D we have templates with parameters that contain definitions inside,
they are like modules. Other languages don't use this form of templates,
instead relying on type parameters on the definition (e.g. classes or
function with an additional parameter). So in other languages we have:
class Matrix(T, int ROWS, int COLUMNS) {
// the parameters goes to the class
private T[] data = new T[ROWS * COLUWNS];
public Matrix add(Matrix other) {
// code goes here
}
public Matrix(T, ROWS, N) mul(N)(Matrix(T, COLUMNS, N) other) {
/* the parameter goes to the operation, but must be determinable from the
* parameters, in this case the "other" parameter.
*/
// code goes here
}
}
As you can see there are two levels of templates here, but in the
operations the instantiation is implicit (determinable from the parameters)
where in the classes must be explicit (so we need to declare Matrix(int, 2,
3) m). Also works the rule that in the result type all template parameters
must be defined in either the class or in the operation, and the template
parameters used in the parameters must be either new parameters (like N) or
constrained by the class parameters (T or COLUMNS). The mul operation only
works in matrices that has the element type T and COLUMNS row size, with the
N column size unconstrained.

* we could also use the "this" keyword or whatever, as long as the
programmer
* doesn't need to write something like "A instance
A.TMul(B.columns()).mul(B)" to
* safely multiply the A and B matrices.
*/
alias instance TMatrix(T, COLUMNS, N).Matrix OtherMatrix;
alias instance TMatrix(T, ROWS, N).Matrix ResultMatrix;
public ResultMatrix mul(OtherMatrix other) {
// code goes here
}
}
}
}
In this case we have some kind of implicit instantiation, but this

of template mechanism will be available in the next versions of Java

C#.

Also almost all statically-typed functional programming languages have

kind of type system.
The parameters for the "implicit" template should be always

determined from the operation's parameters, in this case the "other"

template instance.

I don't get it. Is the implicit template a new template within TMatrix?
Where does N come from again?

The implicit is just a way to say to the compiler: "the following
operation is a template inside the TMatrix, but with this parameter N,

must come from the operation's parameters". So N is a the number of

of OtherMatrix which must have a number of rows equal to the TMatrix

parameter. It's just a way to define the matrix multiplication rule from
basic math.

I'm totally lost with where N comes from. The parameters are ROWS and
COLUMNS, not N.

In D we have templates with parameters that contain definitions

they are like modules. Other languages don't use this form of templates,
instead relying on type parameters on the definition (e.g. classes or
function with an additional parameter). So in other languages we have:
class Matrix(T, int ROWS, int COLUMNS) {
// the parameters goes to the class
private T[] data = new T[ROWS * COLUWNS];
public Matrix add(Matrix other) {
// code goes here
}
public Matrix(T, ROWS, N) mul(N)(Matrix(T, COLUMNS, N) other) {
/* the parameter goes to the operation, but must be determinable from the
* parameters, in this case the "other" parameter.
*/
// code goes here
}
}
As you can see there are two levels of templates here, but in the
operations the instantiation is implicit (determinable from the

where in the classes must be explicit (so we need to declare Matrix(int,

3) m). Also works the rule that in the result type all template parameters
must be defined in either the class or in the operation, and the template
parameters used in the parameters must be either new parameters (like N)

constrained by the class parameters (T or COLUMNS). The mul operation only
works in matrices that has the element type T and COLUMNS row size, with

I do not know D, I know C++ a little. I think, I know what Daniel wants.
I try to explain in C++ nomenclature (I'll abreviate COLUMNS to COLS):
* class Matrix is like C++ template class:
template<typename T, int ROWS, int COLS> class Matrix;
* class method mull is like C++ member template method of a (templated) class;
in C++ it would look like this when defined within Matrix body:
template<int N> Matrix<T,ROWS,N> mul(Matrix<T,COLS,N> other);
or like this when defined outside of class Matrix:
template<typename T, int ROWS, int COLS>
template<int N>
Matrix<T,ROWS,N> Matrix<T,ROWS,COLS>::mul(Matrix<T,COLS,N> other);
* ie Matrix<T,ROWS,COLS> contains potentionally infinite number of methods mul
as part of its definition
* what is Daniel saying is that in this case explicit instatination of D
language is a pain,
because you do need not only to explicitly intantiate classes
Matrix<T,ROWS,COLS>,
Matrix<T,ROWS,N> and Matrix<T,COLS,N> (ie all the matrices used), but also
all the methods mul which are possible or better which are used, to multiply
these
matrices; so Daniel is proposing to introduce implicit instatiations for
member templates
and template argument deduction for them (he wants [inner] template argument
N to
be deducted from "other" argument of mul method ... probably the same way as
C++
would do it)
* as for as infinite recursion problem, I think that here you think too much in
a way how
you have template explicit instation implemented and Daniel is at a too high
level; imagine
that Daniel used in his examples keyword painstance instead of instatnce;
painstance
would not start the whole process of code generation (which would probably
result in
infinite recursion in your current implementation), but only prepare type to
which an
alias can be created; the point is that OtherMatrich and ResultMatrix are not
part of
Matrix template; they are only referenced there with "painstance" :) ... no
problem with
infinite recursion; there is still a problem with creating instances for all
the possible/used
mull method for each Matrix type
* I'm not sure whether D handles nested templates at all...
* the secon example is exactly the same idea, with only one exception and it is
that
it requires constat expresions to be possible for template arguments, I think
this is
not possible in C++ (please correct me if I'm wrong), but in C++ you can use
an
workaround with some enums
* the key to understand it is this C++ nomenclature: member template, implicit
instantiation,
template argument deduction (for [member] function templates)
hope this helps
"Walter" <walter digitalmars.com> wrote in message
news:bib45j$qos$1 digitaldaemon.com...

That does help clear it up. Thanks. BTW, D does support nested templates.
"Peter Hercek" <vvp no.post.spam.sk> wrote in message
news:bibpjk$1q6m$1 digitaldaemon.com...

I do not know D, I know C++ a little. I think, I know what Daniel wants.
I try to explain in C++ nomenclature (I'll abreviate COLUMNS to COLS):
* class Matrix is like C++ template class:
template<typename T, int ROWS, int COLS> class Matrix;
* class method mull is like C++ member template method of a (templated)

in C++ it would look like this when defined within Matrix body:
template<int N> Matrix<T,ROWS,N> mul(Matrix<T,COLS,N> other);
or like this when defined outside of class Matrix:
template<typename T, int ROWS, int COLS>
template<int N>
Matrix<T,ROWS,N> Matrix<T,ROWS,COLS>::mul(Matrix<T,COLS,N> other);
* ie Matrix<T,ROWS,COLS> contains potentionally infinite number of methods

as part of its definition
* what is Daniel saying is that in this case explicit instatination of D

because you do need not only to explicitly intantiate classes

Matrix<T,ROWS,N> and Matrix<T,COLS,N> (ie all the matrices used), but

all the methods mul which are possible or better which are used, to

matrices; so Daniel is proposing to introduce implicit instatiations for

and template argument deduction for them (he wants [inner] template

be deducted from "other" argument of mul method ... probably the same

would do it)
* as for as infinite recursion problem, I think that here you think too

you have template explicit instation implemented and Daniel is at a too

that Daniel used in his examples keyword painstance instead of

would not start the whole process of code generation (which would

infinite recursion in your current implementation), but only prepare typ

alias can be created; the point is that OtherMatrich and ResultMatrix

Matrix template; they are only referenced there with "painstance" :) ...

infinite recursion; there is still a problem with creating instances for

mull method for each Matrix type
* I'm not sure whether D handles nested templates at all...
* the secon example is exactly the same idea, with only one exception and

it requires constat expresions to be possible for template arguments, I

not possible in C++ (please correct me if I'm wrong), but in C++ you can

workaround with some enums
* the key to understand it is this C++ nomenclature: member template,

I'm also quite lost here as to why this would not instantiate TUnit with
infinite recursion.

It indeed would, and we don't want that. So make it so that it won't.
:-)
*ahem* Seriously. Would it possibly be feasible to allow template
instantiation to be lazy, so that the template would be instantiated
only when it used?
C++ does something like this. I think. But on the other hand, horror
stories are told about its instantiation rules, complexity, lack of
portability between subtly different incompatible compiler vendors etc.
etc. Well, everything Walter should be well aware of.
Certainly, as we can see from the example, lazy template instantiation
would make the type system more powerful as it would allow template
instances to depend on other templates in interesting ways.
By the way - is the "instance" keyword necessarily needed? I'd guess its
primary meaning is to make parsing easier, but as a human reader I don't
think it makes the code any more clearer. Without the instance keyword,
template instantiations would look the same as function calls, agreed,
but this could be remedied by using a convention where templates start
with a capital letter and functions with lowercase letter. Besides,
whether we're looking at a template instantiation is often clear from
the context.
Again, I'm thinking C++ -- blame me for homesickness -- where template
declaration/definition syntax can be complex but at least the
instantiation syntax is simple and legible: TUnit<1,2,3> unit;
-Antti

Beginner (haven't done much D programming, mostly just following its
developments)

4) What programming language are you most familiar with?

C, C++, Java, Perl

5) What's your main operating system?

30% Linux, 70% Windows 2000

6) Which type of application you want to develop in D?

image processing/robotics
GUI's

7) Top Three Wishes for D?

In summary, what ever is necessary to use D at work, replacing C++.
This means:
- A good, complete GUI library (must run on Windows and be at
least as complete as MFC).
- Tools (visual debuggers (IDE?)) and more libraries.
- A stable compiler that completely implements the D spec.

1. That it gets real. I don't mean this in a pejorative sense; I mean that
it moves out of its current hobbyist/research state, and there are some
real, and impressive, applications out there that are written in it. For my
part, I've been trying to put out the message, and have written a number of
articles that are due to be published in the coming months (WDN, CUJ, etc.)
that feature D.
2. That it does not suffer from heritage issues as C++ has from C and, MUCH
more importantly, that it does not get killed by having inadequate or
bloated libraries (in the way that Java and .NET - already! - have). Also, I
want to be able to create DLLs & executables in D that are no bigger than
the ones I can create in C/C++, and are (nearly) as fast.
3. That I can do at least as much useful template stuff in D as I can in
C++, without having to fight with arcane syntax, and without resorting to
mind expanding (or numbing, depending on your POV) Template Meta-Programming
tricks

1) DOS extender support (so I can actually use it at work).
2) Last few language issues: properties, bitfields, better syntax for
constructors /destructors / super.
3) A standard library, built "the D way" and meant to eliminate the need for
the C RTL.
Ric