www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C# 3.0 -- Ideas for D?

reply Glen Perkins <Glen_member pathlink.com> writes:
If I had to summarize the attractions of D in a sound bite, I might say it's
like having the conveniences of C# with the simple running on the metal power of
C.

With that in mind, I'm hoping that the next generation of C# features will find
their way into D at some point. If properly planned for, they could probably fit
right in without requiring any perling ( #$%#_[]!) or C++ing (*(foo)<<int>
::->) of the syntax.

I apologize if everyone has already seen these but here are some interesting links: http://msdn.microsoft.com/vcsharp/future/ http://channel9.msdn.com/showpost.aspx?postid=114680 (watch the video) The new features include (copied from their overview): Implicitly typed local variables, which permit the type of local variables to be inferred from the expressions used to initialize them. Extension methods, which make it possible to extend existing types and constructed types with additional methods. Lambda expressions, an evolution of anonymous methods that provides improved type inference and conversions to both delegate types and expression trees. Object initializers, which ease construction and initialization of objects. Anonymous types, which are tuple types automatically inferred and created from object initializers. Implicitly typed arrays, a form of array creation and initialization that infers the element type of the array from an array initializer. Query expressions, which provide a language integrated syntax for queries that is similar to relational and hierarchical query languages such as SQL and XQuery. Expression trees, which permit lambda expressions to be represented as data (expression trees) instead of as code (delegates). Many of these features were added to support their LINQ (Language Integrated Queries) technology that will be built right into the language. It allows you to query and write to a wide variety of data sources (array variables, complex in-memory structures, external files, relational databases, etc.) with a consistent syntax that is part of the language itself. Here's an example of querying an int array: ============= public void Linq1() { int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 }; var lowNums = from n in numbers where n < 5 select n; Console.WriteLine("Numbers < 5:"); foreach (var x in lowNums) { Console.WriteLine(x); } } =========== You could then easily evolve it to query an external data source--disk file, XML doc via HTTP, relational database, etc. without changing the query or any processing done with the results of the query. This works because the "var" is a new data type indicator that tells the compiler to figure out the type for itself (meaning therefore at compile time, not runtime). If you say var x = int[]{1,3,5}, x becomes an array of int for the rest of its life. If you say var x = customer.getField("Name"), x becomes a String. It's not dynamically typed, like a scripting language, where the type is inferred at runtime. It is still statically typed, like D, but the compiler infers the type at first initialization and enforces it thereafter. I also like the notion of "anonymous types": var hammer = new { name = "Hammer", price = 15.00 }; var saw = new { name = "Saw", price = 12.95 }; var tool = hammer; Then you could change the price of "tool" with "tool.price = 14.95". I think (not sure) that you could then also reassign "tool" to point at any object that had attributes "name" and "price", regardless of the other details about its type. It would only be aware of those two attributes/members as it would be a variable of type <anything containing a String member called "name" and a double member called "price">). These more dynamic, but still compile time, techniques allow you to let your code adjust itself to evolving data structures so you can have the easily evolvable code of a scripting language without sacrificing the type safety or performance obtainable with static typing. (OCaml does this and gets great performance. D could probably do it even faster.) Check out some other code snippets here: http://msdn.microsoft.com/vcsharp/future/linqsamples/ It is clear that Walter has been paying attention to C#, to the benefit of D, and I hope that he will continue with these new goodies in C# 3, even if they have to wait for a later version of D. (At least reserve room for them in D's syntax space.) I suspect that D would have an easier time including these features than most other languages, and I also suspect that these features would prove very popular. (I know they would with me.)
Nov 26 2005
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Glen Perkins wrote:
 
 The new features include (copied from their overview):
 
 	Implicitly typed local variables, which permit the type of local variables to
 be inferred from the expressions used to initialize them.

D allready has it and it is calles auto not var.
 	Extension methods, which make it possible to extend existing types and
 constructed types with additional methods.

D has it for array types, but could probbably be possible to extend to other types
 	Lambda expressions, an evolution of anonymous methods that provides improved
 type inference and conversions to both delegate types and expression trees.
 	Object initializers, which ease construction and initialization of objects.
 	Anonymous types, which are tuple types automatically inferred and created
from
 object initializers.
 	Implicitly typed arrays, a form of array creation and initialization that
 infers the element type of the array from an array initializer.

I don't see much difference between Implicitly typed local variables so D has it.
 	Query expressions, which provide a language integrated syntax for queries
that
 is similar to relational and hierarchical query languages such as SQL and
 XQuery.
 	Expression trees, which permit lambda expressions to be represented as data
 (expression trees) instead of as code (delegates).
 

As for other things I must agree that some of them would fiz nicely into D sytax.
Nov 27 2005
parent reply "Charles" <noone nowhere.com> writes:
 D has it for array types, but could probbably be possible to extend to
 other types

This would be awesome ! Maybe if we all ask Walter for it we can get him to include it for all types. Just for clarification the function: char [] strip_tags( char [] ) { ... } can currently be called like <code> char [] html; char [] buf = html.strip_tags(); -- or char [] buf = strip_tags(html ); </code> But only works for arrays ( of any type ).
  Query expressions, which provide a language integrated syntax for


 is similar to relational and hierarchical query languages such as SQL


 XQuery.


It'll be interesting to see how this comes out, and if they can really pull it off :). Some pretty radical ideas. Charlie "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message news:dmbtbf$2j92$1 digitaldaemon.com...
 Glen Perkins wrote:
 The new features include (copied from their overview):

  Implicitly typed local variables, which permit the type of local


 be inferred from the expressions used to initialize them.

D allready has it and it is calles auto not var.
  Extension methods, which make it possible to extend existing types and
 constructed types with additional methods.

D has it for array types, but could probbably be possible to extend to other types
  Lambda expressions, an evolution of anonymous methods that provides


 type inference and conversions to both delegate types and expression


  Object initializers, which ease construction and initialization of


  Anonymous types, which are tuple types automatically inferred and


 object initializers.
  Implicitly typed arrays, a form of array creation and initialization


 infers the element type of the array from an array initializer.

I don't see much difference between Implicitly typed local variables so D has it.
  Query expressions, which provide a language integrated syntax for


 is similar to relational and hierarchical query languages such as SQL


 XQuery.
  Expression trees, which permit lambda expressions to be represented as


 (expression trees) instead of as code (delegates).

As for other things I must agree that some of them would fiz nicely into D sytax.

Nov 27 2005
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Charles wrote:
D has it for array types, but could probbably be possible to extend to
other types

This would be awesome ! Maybe if we all ask Walter for it we can get him to include it for all types. Just for clarification the function: char [] strip_tags( char [] ) { ... } can currently be called like <code> char [] html; char [] buf = html.strip_tags(); -- or char [] buf = strip_tags(html ); </code> But only works for arrays ( of any type ).

I would like to here the official opinion on this feature because i don't think it is even documented, and that might mean this feature is not intended but only a bug in the current implementation. It would IMO be great if it really was a feature and extended to all types.
Nov 27 2005
parent reply John Reimer <terminal.node gmail.com> writes:
Ivan Senji wrote:
 Charles wrote:
 
 D has it for array types, but could probbably be possible to extend to
 other types

This would be awesome ! Maybe if we all ask Walter for it we can get him to include it for all types. Just for clarification the function: char [] strip_tags( char [] ) { ... } can currently be called like <code> char [] html; char [] buf = html.strip_tags(); -- or char [] buf = strip_tags(html ); </code> But only works for arrays ( of any type ).

I would like to here the official opinion on this feature because i don't think it is even documented, and that might mean this feature is not intended but only a bug in the current implementation. It would IMO be great if it really was a feature and extended to all types.

I believe it was an accidental feature that quickly became accepted as useful when it was discovered. It's been discussed in this group several times before. -JJR
Nov 27 2005
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
John Reimer wrote:
 Ivan Senji wrote:
 I would like to here the official opinion on this feature because i 
 don't think it is even documented, and that might mean this feature is 
 not intended but only a bug in the current implementation. It would 
 IMO be great if it really was a feature and extended to all types.

I believe it was an accidental feature that quickly became accepted as useful when it was discovered. It's been discussed in this group several times before.

Yes i know, but Walter never participated in any of those discussions.
Nov 27 2005
parent reply Nick <Nick_member pathlink.com> writes:
In article <dmd5hb$jk4$1 digitaldaemon.com>, Ivan Senji says...
John Reimer wrote:
 Ivan Senji wrote:
 I would like to here the official opinion on this feature because i 
 don't think it is even documented, and that might mean this feature is 
 not intended but only a bug in the current implementation. It would 
 IMO be great if it really was a feature and extended to all types.

I believe it was an accidental feature that quickly became accepted as useful when it was discovered. It's been discussed in this group several times before.

Yes i know, but Walter never participated in any of those discussions.

digitalmars.D/18038 FWIW, I think the feature is good, and should be extended to other types. BUT, it is a little "dodgy" the way it is (or rather isn't) defined at the moment. Perhaps, instead of allowing ANY function to be called this way (which could get confusing), we should have some special syntax, eg. int square1(int x) { return x*x; } auto int square2(int x) { return x*x; } int a = 10; a.square1(); // Doesn't work b.square2(); // Works. Ok, 'auto' is probably not a good keyword to use, but you get my drift :) Nick
Nov 29 2005
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Nick wrote:
 In article <dmd5hb$jk4$1 digitaldaemon.com>, Ivan Senji says...
 
John Reimer wrote:

Ivan Senji wrote:

Yes i know, but Walter never participated in any of those discussions.

digitalmars.D/18038

Wow, thanks Nick, i don't know how i missed that. Good to know.
 FWIW, I think the feature is good, and should be extended to other types. BUT,
 it is a little "dodgy" the way it is (or rather isn't) defined at the moment.
 Perhaps, instead of allowing ANY function to be called this way (which could
get
 confusing), we should have some special syntax, eg.
 
 int square1(int x) { return x*x; }
 auto int square2(int x) { return x*x; }
 
 int a = 10;
 a.square1(); // Doesn't work
 b.square2(); // Works.
 
 Ok, 'auto' is probably not a good keyword to use, but you get my drift :)
 

I get it. Since this was a C# 3.0 thread i think using that syntax that would be: int square2(this int x) { return x*x; } Althoug i wouldn't mind living without that special syntax, just hope that it gets implemented for other types. I don't think it should be that difficult to do it.
Nov 29 2005
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Ivan Senji wrote:
 Nick wrote:
 
 In article <dmd5hb$jk4$1 digitaldaemon.com>, Ivan Senji says...

 John Reimer wrote:

 Ivan Senji wrote:

Yes i know, but Walter never participated in any of those discussions.

digitalmars.D/18038

Wow, thanks Nick, i don't know how i missed that. Good to know.
 FWIW, I think the feature is good, and should be extended to other 
 types. BUT,
 it is a little "dodgy" the way it is (or rather isn't) defined at the 
 moment.
 Perhaps, instead of allowing ANY function to be called this way (which 
 could get
 confusing), we should have some special syntax, eg.

 int square1(int x) { return x*x; }
 auto int square2(int x) { return x*x; }

 int a = 10;
 a.square1(); // Doesn't work
 b.square2(); // Works.

 Ok, 'auto' is probably not a good keyword to use, but you get my drift :)

I get it. Since this was a C# 3.0 thread i think using that syntax that would be: int square2(this int x) { return x*x; }

This is a nice syntax. Does C# allow this function to be called as both square(5) and 5.square() or only 5.square()? This is the perfect way to allow a library define things such as c.conj /Oskar
Nov 30 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Oskar Linde wrote:
 Ivan Senji wrote:
 int square2(this int x) { return x*x; }

This is a nice syntax. Does C# allow this function to be called as both square(5) and 5.square() or only 5.square()?

I'm not sure, i didn't find any mention of it in the 3.0 spec.
 This is the perfect way to allow a library define things such as c.conj
 

I think so too. It would introduce endless possibilities.
Nov 30 2005
prev sibling parent Eugene Pelekhay <pelekhay gmail.com> writes:
Nick wrote:
 In article <dmd5hb$jk4$1 digitaldaemon.com>, Ivan Senji says...
 
John Reimer wrote:

Ivan Senji wrote:

I would like to here the official opinion on this feature because i 
don't think it is even documented, and that might mean this feature is 
not intended but only a bug in the current implementation. It would 
IMO be great if it really was a feature and extended to all types.

I believe it was an accidental feature that quickly became accepted as useful when it was discovered. It's been discussed in this group several times before.

Yes i know, but Walter never participated in any of those discussions.

digitalmars.D/18038 FWIW, I think the feature is good, and should be extended to other types. BUT, it is a little "dodgy" the way it is (or rather isn't) defined at the moment. Perhaps, instead of allowing ANY function to be called this way (which could get confusing), we should have some special syntax, eg. int square1(int x) { return x*x; } auto int square2(int x) { return x*x; } int a = 10; a.square1(); // Doesn't work b.square2(); // Works. Ok, 'auto' is probably not a good keyword to use, but you get my drift :) Nick

what about to use "this" as function argument name? int square(int this) {return this*this;} And to apply the same rules for other types including arrays.
Nov 30 2005
prev sibling parent BCS <BCS_member pathlink.com> writes:
I had a couple thoughts along this vain.

First, IIRC Walter has said the that array property trick is NOT a bug, just
un-documented.

Second, properties can be defined for classes, structs and to some extent
arrays, why not for typedefs? Besides the advantages that are present for
classes and structs, some other advantages come to mind. This would allow for
things like range checking.

Third, a delegate can be defined using a method call on a class or struct or a
nested function call. All of these amount to a pairing of a function pointer
with its first argument. Why not allow the same syntax to be used for a property
call with an array? Or for that matter, if properties are allowed on non arrays,
how about allow a delegate to be made from any property call? Thus the following
would be allowed:

char[] array = "this is a test\n\0junk";
int i, j;

i = array.fn();	// works

int delegate() dg = &array.fn;
j = dg();

..

int fn(char[] c)
{
for(int i=0;i<c.length;i++)
if(c[i] == '\0') return i;
}




In article <dmcrn4$b4f$1 digitaldaemon.com>, Charles says...
 D has it for array types, but could probbably be possible to extend to
 other types

This would be awesome ! Maybe if we all ask Walter for it we can get him to include it for all types. Just for clarification the function: char [] strip_tags( char [] ) { ... } can currently be called like <code> char [] html; char [] buf = html.strip_tags(); -- or char [] buf = strip_tags(html ); </code> But only works for arrays ( of any type ).

Nov 27 2005
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Glen Perkins wrote:
 http://channel9.msdn.com/showpost.aspx?postid=114680 (watch the video)

Ouch! Bill is invading my head, whadda ma gonna do? Nice video. Cool stuff, too. Damn, it almost made me want to move to Redmond, they seemed to have such a good time doing interesting stuff. At the end I was in a good mood, smiling, and felt that I'd actually been in the room with the guys. I feel like I've actually met Hejlsberg! Sigh.
Nov 27 2005
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
I just want to see D 1.0 :)
Nov 27 2005
parent reply Munchgreeble <"a" b.com \"munchgreeble xATx bigfoot xDOTx com\"> writes:
clayasaurus wrote:
 I just want to see D 1.0 :)
 

think finishing implementing the great list of features that D already has ironing out the issues with those has got to be more important, otherwise D just ends up being an experimental melting pot and never gets to a point where it's "finished". I think you need some stable definition of the language to get it widely used. Let's polish what we've got, rather than continually add bells and whistles. Just my tuppence Munch
Nov 28 2005
parent Glen Perkins <Glen_member pathlink.com> writes:
In article <dmeieu$1q0v$1 digitaldaemon.com>, Munchgreeble says...
clayasaurus wrote:
 I just want to see D 1.0 :)
 

think finishing implementing the great list of features that D already has ironing out the issues with those has got to be more important...

I definitely agree. I think the LINQ feature, though, would be particularly useful. Having a standard, built-in SQLish language syntax for querying data, whether it be located in an array, a container, a disk file, a remote Web service, a relational database, etc., would be a great feature in D. Being the only high-performance, natively compiled language with this feature could be a real attention getter for D. So all I'm hoping is that Walter will just reserve room for it in D's syntax space so that after D 1.0 ships, he won't have to choose between leaving it out or making a Perlish mess of D's syntax.
Nov 28 2005
prev sibling next sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Glen Perkins" <Glen_member pathlink.com> wrote in message 
news:dmbi58$2blo$1 digitaldaemon.com...
 . Query expressions, which provide a language integrated syntax for 
 queries that
 is similar to relational and hierarchical query languages such as SQL and
 XQuery.

That's a pretty neat idea! L.
Nov 28 2005
prev sibling next sibling parent "mK" <memsom interalpha.co.uk> writes:
 . Extension methods, which make it possible to extend existing types and
 constructed types with additional methods.

Which is stolen directly from Delphi.Net, which has the ability to "inject" new methods into .Net classes - and has since the field test, pre version 1.0 of Delphi.Net. Admittedly, Borland did it through compiler "hacks" (guessing) but still - it may be new to Microshaft "D-Flat", but it's not "new" to .Net at all.
Nov 28 2005
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Glen Perkins wrote:

Replying a little late to this but i have some more comments after 
playing around with C# 3.0 a little.

 
 	Implicitly typed local variables, which permit the type of local variables to
 be inferred from the expressions used to initialize them.
 	Extension methods, which make it possible to extend existing types and
 constructed types with additional methods.
 	Lambda expressions, an evolution of anonymous methods that provides improved
 type inference and conversions to both delegate types and expression trees.
 	Object initializers, which ease construction and initialization of objects.
 	Anonymous types, which are tuple types automatically inferred and created
from
 object initializers.

I dropped query expressions from this list as they are only syntax sugar for invoking query related extension methods. I would just like to comment a little on how near/far D is to these things. Implicitly typed local variables we have, extensions methods we could have (as we have them for arrays), lambda extensions we don't have but they are only syntax sugar for delegates, so not a real problem. The bigger problem is not having object initializers and anonymous types. As allways a little example: C# 3.0 code: var persons = new [] { new {Name = "ivan", Phone = "", Adress = ""}, new {Name = "ira", Phone = "", Adress = ""}, new {Name = "bla", Phone = "", Adress = ""} }; //a query to get names of persons that begin with 'i' var imena = d.Where(o => o.Name[0] == 'i').Select(o => o.Name); foreach(var name in imena) { Console.WriteLine(name); } Now that looks very simple an intuitive, what about doing this in D: The problem is the actual source is ~40 lines because you have to declare the type that stores persons, and have to declare a type that stores the projection result with their apropriate constructors, members and properties. The actual query in D (with a generic Select method doesn't look that bad): JustNames[] names = Where!(Person,JustNames) (d,delegate bool(Person src){return src.name[0]=='i';}); (It would be a little better with type inference but in this simple case this is not a big problem) Conslusion: anonymous types coupled with object initializers is what gives new power to C# 3.0 and could be an interesting (maybe D 1.1) addition to D as it has so many other advantages over C# 3.0 (except std library) for example slices, nested functions (that I can't live without) ...
Jan 06 2006