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

C.


their way into D at some point. If properly planned for, they could probably fit


::->) 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/



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




queries that

 is similar to relational and hierarchical query languages such as SQL




and

 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




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


http://www.digitalmars.com/drn-bin/wwwnews?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.


 
 
 http://www.digitalmars.com/drn-bin/wwwnews?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 :)
 



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.




 http://www.digitalmars.com/drn-bin/wwwnews?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 :)


 

 would be:
 
 int square2(this int x) { return x*x; }



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


 
 

 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.


 
 
 http://www.digitalmars.com/drn-bin/wwwnews?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 :)
 


I agree! There will always be more new ideas to take on board, but I 
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 :)
 


I agree! There will always be more new ideas to take on board, but I 
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 



 
 •	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:



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 


library) for example slices, nested functions (that I can't live 
without) ...
Jan 06 2006