• Dan Liebgold (63/63) Apr 28 2003 Sorry if this is a dupe, but I'm accessing the group through the web int...
• Bill Cox (28/106) Apr 29 2003 Hi, Dan.
• Matthew Wilson (4/13) Apr 29 2003 Indeed. In the article it blathers on about how C++ template instantiati...

Dan Liebgold <Dan_member pathlink.com> writes:

Sorry if this is a dupe, but I'm accessing the group through the web interface,
which has no searching.  


at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbconCProgrammingLanguageFutureFeatures.asp.

Its pretty neat stuff.. their generics are an interesting way of implementing
generic data structures without using templates. They are also very simple and
syntactically pleasing.  You merely add <type-spec> to your class declaration
and you can genericize a type.  They also have constraints on the genericity of
types, a feature which C++ sorely lacks.  I remember advocated virtual types in
D at one point, and this feature will fully cover the cases I was concerned
about. The constraint feature is the lynchpin, as it will allow base class
method calls that can be properly checked by the compiler.

Their iterator implementation seems useful, but also kind of awkward. You
declare a function-like "foreach" construct in your class, and call a "yield"
primitive for each iteration.  It really seems like they've implemented a couple
of more general language features in getting to the iterator. The yield
primitive is a sort of continuation features, as the next call to your iterator
will continue where the yield left off, maintaining the environment. I can think
of uses for this feature that have little to do with iteration.   Also, the

code smacks of macros most strongly. In their first example of it, this code:

List list = ...;

foreach(object obj in list)
{
DoSomething(obj);
}


will get translated to this code:


Enumerator e = list.GetEnumerator();

while(e.MoveNext())
{
object obj = e.Current;
DoSomething(obj);


If that doesn't resemble a Lisp-style macro in use, I don't know what does.  If
they would generalize and expose the elements of this iterator construct for
other uses in the language, I'd certainly be much more excited about it. As it
is, though, it is still very useful syntactic sugar.


The anonymous methods they describe are full featured, with full lexical
closure, so I must say they are a welcome sight indeed.  The implementation
creates a new uniquely named function and associated class to hold the local
environment.  Walter, if you're reading this, please consider this approach, as
it isn't really that complex or unexpected, and you will soon have a powerful
ally in Microsoft making the lexical scoping understandable and expected to the
average programmer.


Partial types are a feature which I must wonder about, at least a little. The
motivations listed for adding this features are a bit weak, IMHO: 

"While it is good object-oriented programming practice to maintain all source
code for a type in a single file, sometimes performance constraints force types
to be large. Further, the cost of splitting the type into subtypes is not
acceptable for all situations. Moreover, programmers often create or use
applications that emit source code, modifying the resulting code. Unfortunately,
when source code is emitted again sometime in the future, all of the existing
source code modifications are overwritten."

At the very least, this feature will have one big advantage and one big
drawback. The advantage is that with a partial class, you will be able to add
methods to the class "outside" it quite easily; which is a desirable aspect of
full multimethods.  The disadvantage is that you will need a very good memory
(or clairvoyance) or excellent editor support to keep track of the full
definition of a partial class, which could be quite annoying while developing or
debugging.

Lastly, these features are not available yet, which makes them quite a bit less
cool... but I don't doubt we'll see them soon.

Dan L.

Bill Cox <bill viasic.com> writes:

Hi, Dan.

Thanks for the post.  Comments embedded.

Dan Liebgold wrote:
 Sorry if this is a dupe, but I'm accessing the group through the web interface,
 which has no searching.  
 

 at
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbconCProgrammingLanguageFutureFeatures.asp.
 
 Its pretty neat stuff.. their generics are an interesting way of implementing
 generic data structures without using templates. They are also very simple and
 syntactically pleasing.  You merely add <type-spec> to your class declaration
 and you can genericize a type.  They also have constraints on the genericity of
 types, a feature which C++ sorely lacks.  I remember advocated virtual types in
 D at one point, and this feature will fully cover the cases I was concerned
 about. The constraint feature is the lynchpin, as it will allow base class
 method calls that can be properly checked by the compiler.

 Their iterator implementation seems useful, but also kind of awkward. You
 declare a function-like "foreach" construct in your class, and call a "yield"
 primitive for each iteration.  It really seems like they've implemented a
couple
 of more general language features in getting to the iterator. The yield
 primitive is a sort of continuation features, as the next call to your iterator
 will continue where the yield left off, maintaining the environment. I can
think
 of uses for this feature that have little to do with iteration.   Also, the

 code smacks of macros most strongly. In their first example of it, this code:

So far as I can tell, their iterators are somewhat motivated from 
Sather's, which I think is a good thing.  Much more useful than wimpy 
additions for traversing array elements and such.

 List list = ...;
 
 foreach(object obj in list)
 {
 DoSomething(obj);
 }
 
 
 will get translated to this code:
 
 
 Enumerator e = list.GetEnumerator();
 
 while(e.MoveNext())
 {
 object obj = e.Current;
 DoSomething(obj);
 
 
 If that doesn't resemble a Lisp-style macro in use, I don't know what does.  If
 they would generalize and expose the elements of this iterator construct for
 other uses in the language, I'd certainly be much more excited about it. As it
 is, though, it is still very useful syntactic sugar.

They probably do the translation in their parser.  In that case, it's 
not a feature you can use.  I'm a big fan of extendable syntax, but you 
need an extendable way to represent and process the new constructs in 
the compiler.  That's pretty hard.

If they implement iterators this way, they may be throwing away a lot of 
performance.  The natural thing to do is to in-line the iterator 
function, and replace the 'yeild' statements with the loop body.  This 
optimization seems much easier on the original foreach form.

 The anonymous methods they describe are full featured, with full lexical
 closure, so I must say they are a welcome sight indeed.  The implementation
 creates a new uniquely named function and associated class to hold the local
 environment.  Walter, if you're reading this, please consider this approach, as
 it isn't really that complex or unexpected, and you will soon have a powerful
 ally in Microsoft making the lexical scoping understandable and expected to the
 average programmer.
 
 
 Partial types are a feature which I must wonder about, at least a little. The
 motivations listed for adding this features are a bit weak, IMHO: 
 
 "While it is good object-oriented programming practice to maintain all source
 code for a type in a single file, sometimes performance constraints force types
 to be large. Further, the cost of splitting the type into subtypes is not
 acceptable for all situations. Moreover, programmers often create or use
 applications that emit source code, modifying the resulting code.
Unfortunately,
 when source code is emitted again sometime in the future, all of the existing
 source code modifications are overwritten."
 
 At the very least, this feature will have one big advantage and one big
 drawback. The advantage is that with a partial class, you will be able to add
 methods to the class "outside" it quite easily; which is a desirable aspect of
 full multimethods.  The disadvantage is that you will need a very good memory
 (or clairvoyance) or excellent editor support to keep track of the full
 definition of a partial class, which could be quite annoying while developing
or
 debugging.

This is to help guys like me who like to have CASE tools generate a lot 
of code in separate files, rather than mucking up my hand-written files. 
  This is on my short-list of desirable features in a new language.

 Lastly, these features are not available yet, which makes them quite a bit less
 cool... but I don't doubt we'll see them soon.
 
 Dan L.

It's also quite a bit less cool that it comes from Microsoft.  Not that 
I have anything against them.  In fact I'm somewhat of a supporter, but 

or language.  I can't think of a single entity in the world I'd rather 
NOT have defining the next C derived language.


All praise to Microsoft, the source of light and wisdom!  Long live 
.Net!  The self-praise is thicker than any post I've read on this news 
group.

Thanks again for the link and analysis.

Bill

"Matthew Wilson" <matthew stlsoft.org> writes:

 It's also quite a bit less cool that it comes from Microsoft.  Not that
 I have anything against them.  In fact I'm somewhat of a supporter, but

 or language.  I can't think of a single entity in the world I'd rather
 NOT have defining the next C derived language.

Indeed. In the article it blathers on about how C++ template instantiation
leads to code bloat for t<int> and t<long>, which has been optimised by VC
since at least v6. Truth is a maleable concept, is it not?


 All praise to Microsoft, the source of light and wisdom!  Long live
 .Net!  The self-praise is thicker than any post I've read on this news
 group.

LOL. I wonder who you're talking about ...