www.digitalmars.com         C & C++   DMDScript  

D - D User Poll

reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
1) What's your name?

2) What's your programming experience?

3) What's your D knowledge?

    Beginner

    Intermediate

    Advanced

4) What programming language are you most familiar with?

5) What's your main operating system?

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

7) Top Three Wishes for D?
Jul 04 2003
next sibling parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
 1) What's your name?


Andrew Edwards


 2) What's your programming experience?


 0-1 years


 3) What's your D knowledge?


 Beginner


 4) What programming language are you most familiar with?


D


 5) What's your main operating system?


Windows XP


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


Realtime Military Databases
Maintenance Management Systems (military)
Platform independent Operating System (distant dream)


 7) Top Three Wishes for D?


Complete Documentation
Programming Tutorials
Jul 04 2003
parent "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
 7) Top Three Wishes for D?


 Complete Documentation
 Programming Tutorials


and Success
Jul 04 2003
prev sibling next sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
Andrew Edwards wrote:

 
 1) What's your name?


     Helmut Leitner
 

 2) What's your programming experience?


     28 years, 20 years C
 

 3) What's your D knowledge?


 
     Beginner


 4) What programming language are you most familiar with?


     C(Pascal,Fortran), Basic, Perl, Java
 

 5) What's your main operating system?


     80% Windows
     20% Linux
 

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


     client based GUI / database applications 
     server based CGI
 

 7) Top Three Wishes for D?


     an abstract object interface
     an abstract array interface
     a good garbage collector

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Jul 04 2003
prev sibling next sibling parent Simon J Mackenzie <project.d smackoz.fastmail.fm> writes:
Andrew Edwards wrote:

 1) What's your name?


Simon J Mackenzie (alias SMack)

 
 2) What's your programming experience?


Way, way out of date. Recently some C. Last seriously coded in '94.

 
 3) What's your D knowledge?
 

     Beginner










 
     Intermediate
 
     Advanced
 
 4) What programming language are you most familiar with?


C/C++

 
 5) What's your main operating system?


Linux +98% / Windows 2%- (havn't been game to ditch windows yet)

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


D Application/Class set to intergrate LCDProc, Lirc with Ogg Vorbis 
playback for a portable music player on mini-itx motherboard system 
running Linux.

 
 7) Top Three Wishes for D?
 
 


D intergration of KDevelop
Improved/updated documentation
DOSX Support
Jul 04 2003
prev sibling next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Andrew Edwards" <edwardsac spamfreeusa.com> escribiσ en el mensaje
news:be3pk6$22d6$1 digitaldaemon.com...
| 1) What's your name?
|
Carlos Santander

| 2) What's your programming experience?
|
about 10 years

| 3) What's your D knowledge?
|
|     Beginner
|

|
| 4) What programming language are you most familiar with?
|
Basic, Delphi, C/C++, Java, D

| 5) What's your main operating system?
|
Windows, sometimes Linux

| 6) Which type of application you want to develop in D?
|
Not sure about that... haven't thought too much about it

| 7) Top Three Wishes for D?
|
More acceptance
A real and complete IDE
More compilers (that'd mean competition, which is always good...)

—————————————————————————
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 2003-06-30
Jul 04 2003
next sibling parent Stephan Wienczny <wienczny web.de> writes:
Carlos Santander B. wrote:


 | 7) Top Three Wishes for D?
 |
 More acceptance
 A real and complete IDE
 More compilers (that'd mean competition, which is always good...)


One integrated into GCC would be nice.

Stephan
Jul 04 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:be4ceh$2kja$1 digitaldaemon.com...

 | 7) Top Three Wishes for D?
 More acceptance


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!
Jul 15 2003
parent "Carlos Santander B." <carlos8294 msn.com> writes:
"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
Jul 19 2003
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Andrew Edwards wrote:

 7) Top Three Wishes for D?


- 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.
Jul 04 2003
next sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 3) What's your D knowledge?


    Beginner


 7) Top Three Wishes for D?


    - fixing "bool is bit"

    - fixing "string is array"

    - fixing the property namespace "fun":

        struct C {
         // int size;
        }

        void main(char[][] arg) {
         C c;
         c.size = 99;
         printf ("%d", c.size);
        }

Cheers,
Sz.
Jul 04 2003
parent Erick <Erick_member pathlink.com> writes:
 7) Top Three Wishes for D?




1.- Serilization of objects
2.- True Properties, like Delphi
3.- Better Garbage Colection
Jul 04 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:be4ctn$2l48$1 digitaldaemon.com...

 - 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.
Jul 15 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:


 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:be4ctn$2l48$1 digitaldaemon.com...
 

- 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.
Aug 01 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgemr5$19q5$1 digitaldaemon.com...

 Walter wrote:


 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:be4ctn$2l48$1 digitaldaemon.com...


- 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
Aug 01 2003
parent Burton Radons <loth users.sourceforge.net> writes:
Charles Sanders wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgemr5$19q5$1 digitaldaemon.com...
 

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.
Aug 01 2003
prev sibling next sibling parent reply Karl Bochert <kbochert copper.net> writes:
On Fri, 01 Aug 2003 14:46:40 -0700, Burton Radons <loth users.sourceforge.net>
wrote:

 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
Aug 03 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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


<loth users.sourceforge.net> wrote:

 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
Aug 04 2003
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bgm2vi$23gg$1 digitaldaemon.com...

 Yes, generics don't have to be a hideous boil on the face of the language.
 ;)


LOL!
Aug 13 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgemr5$19q5$1 digitaldaemon.com...

 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.
Aug 13 2003
prev sibling next sibling parent Patrick Down <pat codemoon.com> writes:
"Andrew Edwards" <edwardsac spamfreeusa.com> wrote in news:be3pk6$22d6$1
 digitaldaemon.com:


 1) What's your name?


Patrick Down
 

 2) What's your programming experience?


23 Years

4 Teenage Apple II hacker*
6 University CS BS/MS student
13 Professional programmer

*Back in the days when hacker wasn't
a negative term.
 

 3) What's your D knowledge?


Intermediate


 4) What programming language are you most familiar with?


C++,Python


 5) What's your main operating system?


Windows


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


I don't really have a definite agenda.
Lots of projects started few finished. 


 7) Top Three Wishes for D?


1. Continued expansion of it's generics capability
2. Interator/Generator support
3. A good garbage collector

And of course wide spread acceptance
Jul 04 2003
prev sibling next sibling parent reply Bill Cox <Bill_member pathlink.com> writes:
In article <be3pk6$22d6$1 digitaldaemon.com>, Andrew Edwards says...

1) What's your name?


Bill Cox


2) What's your programming experience?


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
Jul 04 2003
parent reply Mark T <Mark_member pathlink.com> writes:
In article <be4lqs$1r4$1 digitaldaemon.com>, Bill Cox says...

which is why I need an extendable language.  However, three of the most
important extensions for me are:

1) Dynamic class extension


how about Dynace
http://groups.yahoo.com/group/Dynace/
Jul 05 2003
next sibling parent reply Stephan Wienczny <wienczny web.de> writes:
Mark T wrote:

 In article <be4lqs$1r4$1 digitaldaemon.com>, Bill Cox says...
 

which is why I need an extendable language.  However, three of the most
important extensions for me are:

1) Dynamic class extension


 
 
 how about Dynace
 http://groups.yahoo.com/group/Dynace/
 
 


Then we would have an preprozessor again. Do we want something like that ?

Stephan
Jul 06 2003
parent Mark T <Mark_member pathlink.com> writes:
In article <be9q2e$1hiu$1 digitaldaemon.com>, Stephan Wienczny says...

Mark T wrote:

 In article <be4lqs$1r4$1 digitaldaemon.com>, Bill Cox says...
 

which is why I need an extendable language.  However, three of the most
important extensions for me are:

1) Dynamic class extension


 
 
 how about Dynace
 http://groups.yahoo.com/group/Dynace/
 
 


Then we would have an preprozessor again. Do we want something like that ?


It is actually more like a translator, like converting Eiffel to C like
SmartEffiel.
The OT is "off topic" it was meant as reply to Bill Cox for him to possibly
check out this language.
Jul 08 2003
prev sibling parent Bill Cox <bill viasic.com> writes:
Mark T wrote:

 In article <be4lqs$1r4$1 digitaldaemon.com>, Bill Cox says...
 

which is why I need an extendable language.  However, three of the most
important extensions for me are:

1) Dynamic class extension


 
 
 how about Dynace
 http://groups.yahoo.com/group/Dynace/
 
 


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
Jul 08 2003
prev sibling next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Andrew Edwards" <edwardsac spamfreeusa.com> escreveu na mensagem
news:be3pk6$22d6$1 digitaldaemon.com...

 1) What's your name?


    Daniel Yukio Yokomiso


 2) What's your programming experience?


    10 years, 5 professional.


 3) What's your D knowledge?


    That's hard to answer, I would say intermediate.


 4) What programming language are you most familiar with?


    Probably Java.


 5) What's your main operating system?


    win2k


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


    Libraries and development tools (IDEs, code repositories, etc.)


 7) Top Three Wishes for D?


    More powerful template syntax ;)
    Stable, working compiler (with all features)
    More libraries


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30/6/2003
Jul 06 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:be9gje$19cp$1 digitaldaemon.com...

     More powerful template syntax ;)


Any specific ideas?
Aug 11 2003
next sibling parent reply Chris Sokol <chris echosproject.org> writes:
In article <bh92nq$2403$1 digitaldaemon.com>, Walter says...

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:be9gje$19cp$1 digitaldaemon.com...

     More powerful template syntax ;)


Any specific ideas?


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 parameters is:

template List(T, SomeOtherType) {
class List {
..
}
}

template List(T) {
alias List instance List(T, DefaultOtherType) List;
}

But what if the first template defined a dozen classes?  Do they all need to be
aliased in the single argument template?

Being able to pass a template instance as a template parameter would be fly as
well:

template Comparator(T) {
int compare(T i, T j) {
return i.compare(j);
}
}

template List(T, Cmp) {
class List {
void insertSorted(T a) {
for (T p = head ; p && Cmp.compare(p, t) <= 0 ; p = p.next)
you_get_the_idea(p);
}
}
}

instance List(Foo, instance Comparator(Foo)) fooList; // doesn't work
Aug 11 2003
parent "Walter" <walter digitalmars.com> writes:
I think I can work with that. -Walter

"Chris Sokol" <chris echosproject.org> wrote in message
news:bh97gp$29e3$1 digitaldaemon.com...

 In article <bh92nq$2403$1 digitaldaemon.com>, Walter says...

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:be9gje$19cp$1 digitaldaemon.com...

     More powerful template syntax ;)


Any specific ideas?


 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


parameters is:

 template List(T, SomeOtherType) {
 class List {
 ..
 }
 }

 template List(T) {
 alias List instance List(T, DefaultOtherType) List;
 }

 But what if the first template defined a dozen classes?  Do they all need


to be

 aliased in the single argument template?

 Being able to pass a template instance as a template parameter would be


fly as

 well:

 template Comparator(T) {
 int compare(T i, T j) {
 return i.compare(j);
 }
 }

 template List(T, Cmp) {
 class List {
 void insertSorted(T a) {
 for (T p = head ; p && Cmp.compare(p, t) <= 0 ; p = p.next)
 you_get_the_idea(p);
 }
 }
 }

 instance List(Foo, instance Comparator(Foo)) fooList; // doesn't work
Aug 11 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Walter" <walter digitalmars.com> escreveu na mensagem
news:bh92nq$2403$1 digitaldaemon.com...

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:be9gje$19cp$1 digitaldaemon.com...

     More powerful template syntax ;)


 Any specific ideas?


Hi,

    Here we go again ;)
    There are a few things that are impossible to do currently:


template TMatrix(T, int ROWS, int COLUMNS) {
    class Matrix {
        private T[] data = new T[ROWS * COLUWNS];
        public Matrix add(Matrix other) {
            // code goes here
        }
        public Matrix mul(Matrix other) {
            // code goes here
        }
    }
}


    The mul operation can be specified. Our template defines the matrix
component's type (T) and its dimensions (M, N). It's ok for add, but mul
must use different values for M and N, something in the lines of:

template TMatrix(T, int ROWS, int COLUMNS) {
    class Matrix {
        private T[] data = new T[ROWS * COLUWNS];
        public Matrix add(Matrix other) {
            // code goes here
        }
        public instance TMatrix(T, COLUMNS, N).Matrix mul(instance
TMatrix(T, COLUMNS, N).Matrix other) {
            // code goes here
        }
    }
}

    In this way (I'm not arguing about the syntax, just the semantics) we
can say to the compiler: "a matrix can multiply only matrix with a row size
equal to its column size.". Perhaps a better syntax would be:

template TMatrix(T, int ROWS, int COLUMNS) {
    class Matrix {
        private T[] data = new T[ROWS * COLUWNS];
        public Matrix add(Matrix other) {
            // code goes here
        }
        template implicit (N) {
/* "implicit" is a keyword to make a template with implicit instantiation.
 * 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 kind

Also almost all statically-typed functional programming languages have this
kind of type system.
    The parameters for the "implicit" template should be always statically
determined from the operation's parameters, in this case the "other" Matrix
template instance.
    My other example involving statically-typed units would become:


template TUnit(T, int C, int G, int S) {
    struct Unit {
        private T value;
        public Unit add(Unit other) {
            // code goes here
        }
        template implicit (C1, G1, S1) {
            alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;
            alias instance TUnit(T, C + C1, G + G1, S + S1).Unit ResultUnit;
            public ResultUnit mul(OtherUnit other) {
                // code goes here
            }
        }
        // other methods here
    }
}
template TUnits(T) {
    alias instance TUnit(T, 1, 0, 0).Unit Length;
    alias instance TUnit(T, 0, 1, 0).Unit Mass;
    alias instance TUnit(T, 0, 0, 1).Unit Time;
    alias instance TUnit(T, 1, 0, -1).Unit Speed;
    alias instance TUnit(T, 1, 0, -2).Unit Acceleration;
    const Length meter = {100};
    const Time second = {1};
}
// all operations below should be statically verified
instance TUnits(double).Acceleration a = 2 * meter / (second * second);
instance TUnits(double).Length l = 10 * meter;
instance TUnits(double).Speed s = a * l;


    This kind of expressiveness will make D very suitable to reliable, safe,
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 template
definition, plus the new ones, overriding accordingly. Some kind of template
inheritance is necessary, either explicit or implicit. Otherwise we'll have
to duplicate the definitions for all specializations.
    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
Aug 22 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bi6iu9$2u47$1 digitaldaemon.com...

 template TMatrix(T, int ROWS, int COLUMNS) {
     class Matrix {
         private T[] data = new T[ROWS * COLUWNS];
         public Matrix add(Matrix other) {
             // code goes here
         }
         public Matrix mul(Matrix other) {
             // code goes here
         }
     }
 }


     The mul operation can be specified. Our template defines the matrix
 component's type (T) and its dimensions (M, N). It's ok for add, but mul
 must use different values for M and N, something in the lines of:

 template TMatrix(T, int ROWS, int COLUMNS) {
     class Matrix {
         private T[] data = new T[ROWS * COLUWNS];
         public Matrix add(Matrix other) {
             // code goes here
         }
         public instance TMatrix(T, COLUMNS, N).Matrix mul(instance
 TMatrix(T, COLUMNS, N).Matrix other) {
             // code goes here
         }
     }
 }

     In this way (I'm not arguing about the syntax, just the semantics) we
 can say to the compiler: "a matrix can multiply only matrix with a row


size

 equal to its column size.". Perhaps a better syntax would be:

 template TMatrix(T, int ROWS, int COLUMNS) {
     class Matrix {
         private T[] data = new T[ROWS * COLUWNS];
         public Matrix add(Matrix other) {
             // code goes here
         }
         template implicit (N) {
 /* "implicit" is a keyword to make a template with implicit instantiation.
  * 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


kind

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




 Also almost all statically-typed functional programming languages have


this

 kind of type system.
     The parameters for the "implicit" template should be always statically
 determined from the operation's parameters, in this case the "other"


Matrix

 template instance.


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



     My other example involving statically-typed units would become:

 template TUnit(T, int C, int G, int S) {
     struct Unit {
         private T value;
         public Unit add(Unit other) {
             // code goes here
         }
         template implicit (C1, G1, S1) {
             alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;
             alias instance TUnit(T, C + C1, G + G1, S + S1).Unit


ResultUnit;

             public ResultUnit mul(OtherUnit other) {
                 // code goes here
             }
         }
         // other methods here
     }
 }
 template TUnits(T) {
     alias instance TUnit(T, 1, 0, 0).Unit Length;
     alias instance TUnit(T, 0, 1, 0).Unit Mass;
     alias instance TUnit(T, 0, 0, 1).Unit Time;
     alias instance TUnit(T, 1, 0, -1).Unit Speed;
     alias instance TUnit(T, 1, 0, -2).Unit Acceleration;
     const Length meter = {100};
     const Time second = {1};
 }
 // all operations below should be statically verified
 instance TUnits(double).Acceleration a = 2 * meter / (second * second);
 instance TUnits(double).Length l = 10 * meter;
 instance TUnits(double).Speed s = a * l;


I just don't get where the arguments for implicit come from?


     This kind of expressiveness will make D very suitable to reliable,


safe,

 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


template

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


template

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


have

 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
Aug 22 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    Comments embedded:
"Walter" <walter digitalmars.com> escreveu na mensagem
news:bi6qcm$8qf$1 digitaldaemon.com...

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bi6iu9$2u47$1 digitaldaemon.com...


[snip]


     In this way (I'm not arguing about the syntax, just the semantics)




we

 can say to the compiler: "a matrix can multiply only matrix with a row


 size

 equal to its column size.". Perhaps a better syntax would be:

 template TMatrix(T, int ROWS, int COLUMNS) {
     class Matrix {
         private T[] data = new T[ROWS * COLUWNS];
         public Matrix add(Matrix other) {
             // code goes here
         }
         template implicit (N) {
 /* "implicit" is a keyword to make a template with implicit




instantiation.

  * 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


 kind

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




 Also almost all statically-typed functional programming languages have


 this

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




statically

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


 Matrix

 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.


     My other example involving statically-typed units would become:

 template TUnit(T, int C, int G, int S) {
     struct Unit {
         private T value;
         public Unit add(Unit other) {
             // code goes here
         }
         template implicit (C1, G1, S1) {
             alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;
             alias instance TUnit(T, C + C1, G + G1, S + S1).Unit


 ResultUnit;

             public ResultUnit mul(OtherUnit other) {
                 // code goes here
             }
         }
         // other methods here
     }
 }
 template TUnits(T) {
     alias instance TUnit(T, 1, 0, 0).Unit Length;
     alias instance TUnit(T, 0, 1, 0).Unit Mass;
     alias instance TUnit(T, 0, 0, 1).Unit Time;
     alias instance TUnit(T, 1, 0, -1).Unit Speed;
     alias instance TUnit(T, 1, 0, -2).Unit Acceleration;
     const Length meter = {100};
     const Time second = {1};
 }
 // all operations below should be statically verified
 instance TUnits(double).Acceleration a = 2 * meter / (second * second);
 instance TUnits(double).Length l = 10 * meter;
 instance TUnits(double).Speed s = a * l;


 I just don't get where the arguments for implicit come from?


    As I said before, they are determinable from the operation's parameters.
In this case OtherUnit constrain the parameters.

[snip]


 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


 template

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


 template

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


 have

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




    Best regards,
    Daniel Yokomiso.

"You laugh at me because I'm different. I laugh because you are all the
same."
 - Daniel Knode


---
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
Aug 23 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bi7lqj$1mfi$1 digitaldaemon.com...

 Hi,

     Comments embedded:
 "Walter" <walter digitalmars.com> escreveu na mensagem
 news:bi6qcm$8qf$1 digitaldaemon.com...

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bi6iu9$2u47$1 digitaldaemon.com...


 [snip]


     In this way (I'm not arguing about the syntax, just the semantics)




 we

 can say to the compiler: "a matrix can multiply only matrix with a row


 size

 equal to its column size.". Perhaps a better syntax would be:

 template TMatrix(T, int ROWS, int COLUMNS) {
     class Matrix {
         private T[] data = new T[ROWS * COLUWNS];
         public Matrix add(Matrix other) {
             // code goes here
         }
         template implicit (N) {
 /* "implicit" is a keyword to make a template with implicit




 instantiation.

  * 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


 kind

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






and



 Also almost all statically-typed functional programming languages have


 this

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




 statically

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


 Matrix

 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.


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


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.


     My other example involving statically-typed units would become:

 template TUnit(T, int C, int G, int S) {
     struct Unit {
         private T value;
         public Unit add(Unit other) {
             // code goes here
         }
         template implicit (C1, G1, S1) {
             alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;
             alias instance TUnit(T, C + C1, G + G1, S + S1).Unit


 ResultUnit;

             public ResultUnit mul(OtherUnit other) {
                 // code goes here
             }
         }
         // other methods here
     }
 }
 template TUnits(T) {
     alias instance TUnit(T, 1, 0, 0).Unit Length;
     alias instance TUnit(T, 0, 1, 0).Unit Mass;
     alias instance TUnit(T, 0, 0, 1).Unit Time;
     alias instance TUnit(T, 1, 0, -1).Unit Speed;
     alias instance TUnit(T, 1, 0, -2).Unit Acceleration;
     const Length meter = {100};
     const Time second = {1};
 }
 // all operations below should be statically verified
 instance TUnits(double).Acceleration a = 2 * meter / (second *






second);

 instance TUnits(double).Length l = 10 * meter;
 instance TUnits(double).Speed s = a * l;


 I just don't get where the arguments for implicit come from?


     As I said before, they are determinable from the operation's


parameters.

 In this case OtherUnit constrain the parameters.


I'm also quite lost here as to why this would not instantiate TUnit with
infinite recursion.
Aug 24 2003
next sibling parent reply "Peter Hercek" <vvp no.post.spam.sk> writes:
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...


[snip]

 template TMatrix(T, int ROWS, int COLUMNS) {
     class Matrix {
         private T[] data = new T[ROWS * COLUWNS];
         public Matrix add(Matrix other) {
             // code goes here
         }
         template implicit (N) {
 /* "implicit" is a keyword to make a template with implicit instantiation.
  * 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;








here should be painstance :)


             alias instance TMatrix(T, ROWS, N).Matrix ResultMatrix;








here should be painstance


             public ResultMatrix mul(OtherMatrix other) {
                 // code goes here
             }
         }
     }
 }








[snip]

 template TUnit(T, int C, int G, int S) {
     struct Unit {
         private T value;
         public Unit add(Unit other) {
             // code goes here
         }
         template implicit (C1, G1, S1) {
             alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;








here should be painstance


             alias instance TUnit(T, C + C1, G + G1, S + S1).Unit ResultUnit;








here should be painstance


             public ResultUnit mul(OtherUnit other) {
                 // code goes here
             }
         }
         // other methods here
     }
 }
 template TUnits(T) {
     alias instance TUnit(T, 1, 0, 0).Unit Length;
     alias instance TUnit(T, 0, 1, 0).Unit Mass;
     alias instance TUnit(T, 0, 0, 1).Unit Time;
     alias instance TUnit(T, 1, 0, -1).Unit Speed;
     alias instance TUnit(T, 1, 0, -2).Unit Acceleration;
     const Length meter = {100};
     const Time second = {1};
 }
 // all operations below should be statically verified
 instance TUnits(double).Acceleration a = 2 * meter / (second * second);
 instance TUnits(double).Length l = 10 * meter;
 instance TUnits(double).Speed s = a * l;








[snip]



 Aug 24 2003



 next sibling parent reply "Walter" <walter digitalmars.com>  writes:


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)


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 typ


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


 [snip]

 template TMatrix(T, int ROWS, int COLUMNS) {
     class Matrix {
         private T[] data = new T[ROWS * COLUWNS];
         public Matrix add(Matrix other) {
             // code goes here
         }
         template implicit (N) {
 /* "implicit" is a keyword to make a template with implicit










instantiation.

  * 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;

 here should be painstance :)


             alias instance TMatrix(T, ROWS, N).Matrix










ResultMatrix;

 here should be painstance


             public ResultMatrix mul(OtherMatrix other) {
                 // code goes here
             }
         }
     }
 }








 [snip]

 template TUnit(T, int C, int G, int S) {
     struct Unit {
         private T value;
         public Unit add(Unit other) {
             // code goes here
         }
         template implicit (C1, G1, S1) {
             alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;








 here should be painstance


             alias instance TUnit(T, C + C1, G + G1, S + S1).Unit










ResultUnit;

 here should be painstance


             public ResultUnit mul(OtherUnit other) {
                 // code goes here
             }
         }
         // other methods here
     }
 }
 template TUnits(T) {
     alias instance TUnit(T, 1, 0, 0).Unit Length;
     alias instance TUnit(T, 0, 1, 0).Unit Mass;
     alias instance TUnit(T, 0, 0, 1).Unit Time;
     alias instance TUnit(T, 1, 0, -1).Unit Speed;
     alias instance TUnit(T, 1, 0, -2).Unit Acceleration;
     const Length meter = {100};
     const Time second = {1};
 }
 // all operations below should be statically verified
 instance TUnits(double).Acceleration a = 2 * meter / (second *










second);

 instance TUnits(double).Length l = 10 * meter;
 instance TUnits(double).Speed s = a * l;








 [snip]





 Aug 25 2003



  parent  "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br>  writes:


"Walter" <walter digitalmars.com> escreveu na mensagem
news:bicdat$2q0f$1 digitaldaemon.com...

 That does help clear it up. Thanks. BTW, D does support nested templates.


So I guess everything is clear from now on.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003



 Aug 25 2003



prev sibling  parent  "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br>  writes:


"Peter Hercek" <vvp no.post.spam.sk> escreveu na mensagem
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):


[snip]


 hope this helps


Yes, that's exactly what I was arguing for, but I lacked the practical
approach you used, relying on theoretical POV instead. Thanks.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003



 Aug 25 2003



prev sibling  parent  Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi>  writes:


     My other example involving statically-typed units would become:

 template TUnit(T, int C, int G, int S) {
     struct Unit {
         private T value;
         public Unit add(Unit other) {
             // code goes here
         }
         template implicit (C1, G1, S1) {
             alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;
             alias instance TUnit(T, C + C1, G + G1, S + S1).Unit


 ResultUnit;

             public ResultUnit mul(OtherUnit other) {
                 // code goes here
             }
         }
         // other methods here
     }
 }




[...two levels of quoting snipped]

In article <bib45j$qos$1 digitaldaemon.com>, Walter wrote:

 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



 Aug 25 2003



prev sibling next sibling parent  Jason Mills <jmills cs.mun.ca>  writes:


Andrew Edwards wrote:

 1) What's your name?


   Jason Mills


 2) What's your programming experience?


   5+ years


 3) What's your D knowledge?


   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.



 Jul 06 2003



prev sibling next sibling parent  "Nic Tiger" <tiger7 progtech.ru>  writes:


 1) What's your name?


Nic Tiger


 2) What's your programming experience?


14 years


 3) What's your D knowledge?


Intermediate (now, after ICFP)


 4) What programming language are you most familiar with?


C/C++, Pascal/Delphi, ASM, D, Perl


 5) What's your main operating system?


60% - DOS (MS DOS 7.10, PTSDOS-32)
30% - Win2000
10% - Linux (Mandrake 9)


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


As usual, ground based flight data processing systems.
Realtime modelling environment for missile guidance systems.
Maybe 3D games also.


 7) Top Three Wishes for D?


1. Overloading of [] or some other way to create full-featured arrays on top
of dynamic arrays.
2. DOSX support




 Jul 08 2003



prev sibling next sibling parent  "Matthew Wilson" <matthew stlsoft.org>  writes:


"Andrew Edwards" <edwardsac spamfreeusa.com> wrote in message
news:be3pk6$22d6$1 digitaldaemon.com...

 1) What's your name?


Matthew Wilson (or "The Dr" if you're a friend, or "Bigboy" if you're a
real-close friend ...)


 2) What's your programming experience?




 3) What's your D knowledge?

     Beginner

     Intermediate


Keep getting distracted with other things to be advanced. I've created some
small libraries at http://synsoft.org/d.html and will be creating a D
version of ATL before the end of the year.


     Advanced

 4) What programming language are you most familiar with?


C++


 5) What's your main operating system?


Win32, with Linux sprinkled in when I get mouse-weary. ("set -o vi" ;)


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


Libraries. I'm a library kinda-guy. (Am also the author of STLSoft -
http://stlsoft.org/)


 7) Top Three Wishes for D?


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



 Jul 08 2003



prev sibling next sibling parent  "DeadCow" <deadcow-remove-this free.fr>  writes:


"Andrew Edwards" <edwardsac spamfreeusa.com> a ιcrit dans le message news:
be3pk6$22d6$1 digitaldaemon.com...

 1) What's your name?


Nicolas Repiquet


 2) What's your programming experience?


five years


 3) What's your D knowledge?


Beginner


 4) What programming language are you most familiar with?


Java


 5) What's your main operating system?


Win2000


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


Not planned yet. Probably libraries first.


 7) Top Three Wishes for D?


- An official library repository, like Perl's CPAN.
- Tulpes, handy for multiple return values and so on.
- Sucess of course. D rulez.

-- Nicolas Repiquet



 Jul 14 2003



prev sibling next sibling parent  "Riccardo De Agostini" <riccardo.de.agostini email.it>  writes:


"Andrew Edwards" <edwardsac spamfreeusa.com> ha scritto nel messaggio
news:be3pk6$22d6$1 digitaldaemon.com...

 1) What's your name?


Riccardo De Agostini


 2) What's your programming experience?


12 years as a professional; 19 since I first put together some lines of
Basic on a Commodore 64 (have rarely played games on it since :-) ).


 3) What's your D knowledge?


Beginner


 4) What programming language are you most familiar with?


Delphi, Borland Pascal, Visual Basic, C, C++ excluding templates/STL/RTTI,
JavaScript, some assembler (mostly Motorola 68k, some Intel too).


 5) What's your main operating system?


WinXP as development host; DOS, Win98, WinXP as targets.


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


Industrial and home automation with embedded systems.


 7) Top Three Wishes for D?


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



 Aug 04 2003



prev sibling  parent reply John Boucher <John_member pathlink.com>  writes:


1) What's your name?

John Boucher

2) What's your programming experience?

14 years; BASIC (VAX), Pascal (Turbo), C/C++ (Turbo, Borland), SQL (Oracle, RDB,

All of it backend/console stuff, not Windows.

3) What's your D knowledge?

Beginner -- Just read the docs through once and wrote a "Hello World" program.
First saw it mentioned in the September 2003 issue of windows::developer (From
the Editor)

4) What programming language are you most familiar with?

C

5) What's your main operating system?

Win32 now that I'm not using OpenVMS (my first love <sniff>)

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

Killer, duh

7) Top Three Wishes for D?

Include timezone and DST info in the d_time type. And get Congress to ban DST
while you're at it.

Don't allow declarations mixed in with executable code, it's poor style.

Dump the HTML support. The D compiler should only accept D source code and
therefore not require the source file to have an extension of D, in fact how
about supporting piping in the source code? well, that should be up to the
compiler implementer, not the language anyway.

Should assert() really be built in? Shouldn't its implementation be up to the
programmer? Maybe I can override it? Aw, heck I won't use it either.

Hmm, maybe I should specify a language called D-.

John Boucher
PIEBALDconsult aol.com



 Aug 24 2003



  parent  Bill Cox <bill viasic.com>  writes:


 Hmm, maybe I should specify a language called D-.


I feel the same way.  D has too many features.  However, the success of 
languages like Perl indicate that having lots and lots of features draws 
supporters.

The longer I code, the more I find I can mimic advanced features in any 
language.  Just give me a FORTRAN compiler, and I'll write some nice 
structured, object oriented, efficient clean code for you.  Give me more 
control over generated code, and I'll create more efficient programs. 
No language I know of has ever beaten C in this regard.

Bill

P.S.  I missed VMS for years.  I recommend switching to Linux.  Windows 
will never be quite so satisfying.



 Aug 25 2003