Possible themes for C# 4.0

[Luke Breuer]

I had a relatively short, but quite insightful conversation with Eric
Lippert, one of the C# designers who actually
blogs<http://blogs.msdn.com/ericlippert/>about C#. He said the
following (yes, in purple):

Rather, we have a large number of customers, internal and external, and each

has their own ideas about how the language should evolve. There are a
million and one possible new language features we could do; the trick is
finding the few of them that give the biggest bang for the buck to the
greatest number of customers. We therefore try to identify a *theme* and
then choose features, large and small, which work together to support that
theme.

I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ. Yes, there are no trivial left
joins, but on the whole, I like it. Frans would have something to say about
how Expression<T> is implemented, Ayende and others would denigrate partial
methods, but I think most of us, on average, really like C# 3.0.

What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme would be
better type safety/type inference. A few examples:

- non-nullable reference types
- inter-method type inference, so I can pass anonymous types around
- var quote = s => "'" + s + "'";
- named parameters (dunno about default parameter values)
- the infoof operator (info of), for no/fewer magic strings or lambdas
when using reflection
- [more] covariance/contravariance

There is plenty else to discuss, but I don't want to steal all the thunder
or anything. :-D

Luke

[Peter Ritchie]

I think non-nullable reference types are better handled through
invariant guarantees. Pulling in some stuff from Spec# would improve
C# greatly, and you'd get to be able to specify a reference cannot be
null and have it "guaranteed".

"public" anonymous types would simply be a nightmare. "var" is just
sugar, C# generates the real type. You'd have the same issues as
private "var", you'd have to ensure you assign and declare at the
same time. For example, in C# 3, this is not valid:

var x;
x = 10;

This would be difficult for properties, but would force member fields
to always be initialized like:
class MyClass{
public var field = 10;
}

This would not be valid:

class MyClass{
public var field;
MyClass(){
field = 10;
}
}

So, I don't think it's all that useful.

infoof/variance, top of my list. I think that was dropped because
LINQ took too much time in C# 3...

Immutability and parallelization are also very important and I think
they should get recognition sooner rather than later.

Post by Luke Breuer
I had a relatively short, but quite insightful conversation with Eric
Lippert, one of the C# designers who actually
blogs<http://blogs.msdn.com/ericlippert/>about C#. He said the
Rather, we have a large number of customers, internal and external, and each

has their own ideas about how the language should evolve. There are a
million and one possible new language features we could do; the trick is
finding the few of them that give the biggest bang for the buck to the
greatest number of customers. We therefore try to identify a

*theme* and

Post by Luke Breuer

then choose features, large and small, which work together to support that
theme.

I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ. Yes, there are no

trivial left

Post by Luke Breuer
joins, but on the whole, I like it. Frans would have something to say about
how Expression<T> is implemented, Ayende and others would denigrate partial
methods, but I think most of us, on average, really like C# 3.0.
What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme would be
- non-nullable reference types
- inter-method type inference, so I can pass anonymous types around
- var quote = s => "'" + s + "'";
- named parameters (dunno about default parameter values)
- the infoof operator (info of), for no/fewer magic strings or lambdas
when using reflection
- [more] covariance/contravariance
There is plenty else to discuss, but I don't want to steal all the thunder
or anything. :-D
Luke

[Luke Breuer]

Post by Peter Ritchie
I think non-nullable reference types are better handled through
invariant guarantees. Pulling in some stuff from Spec# would improve
C# greatly, and you'd get to be able to specify a reference cannot be
null and have it "guaranteed".

Yeah, I should have just mentioned
Spec#<http://research.microsoft.com/specsharp/>
.

Post by Peter Ritchie
"public" anonymous types would simply be a nightmare. "var" is just
sugar, C# generates the real type. You'd have the same issues as
private "var", you'd have to ensure you assign and declare at the
same time.

Not necessarily. We're just talking about a lot more type inference than C#
3.0 provides -- perhaps it would be [somewhat] accurate to say that we'd be
going into Haskell land. I could elaborate on how [I think] this would
work, if you're interested. The idea would be to reduce the amount of
explicit typing (spelling is intended) required, with the option for
refactoring to more/less explicit typing.

Immutability and parallelization are also very important and I think

Post by Peter Ritchie
they should get recognition sooner rather than later.

Are you thinking in terms of making it easier to write parallelizable code?
That is definitely becoming more important in certain areas.

[Ayende Rahien]

Post by Luke Breuer
Not necessarily. We're just talking about a lot more type inference than
C# 3.0 provides -- perhaps it would be [somewhat] accurate to say that
we'd be going into Haskell land. I could elaborate on how [I think] this
would work, if you're interested. The idea would be to reduce the amount of
explicit typing (spelling is intended) required, with the option for
refactoring to more/less explicit typing.

I would be interested in that, yes.

[Peter Ritchie]

"var" in JS is a variant, completely different from "var" in C#.
You shouldn't compare the two. The "ease" of variant is far from
what is needed in a modern language.

Inferred types on a public interface couples the interface to
implementation details and makes interfaces with potentially
unobvious types.

For example:

private int someValue;
public var MyProperty {get { return someValue;}}

If I change my private implementation, I now affect my public
interface:

private float someValue;
public var MyProperty { get { return someValue;}}

...breaking any clients to that interface.

Here's an example of unobvious types:
private UInt32 unsignedNumber;
private Int32 signedNumber;
public var MyProperty { get { return unsignedNumber &
signedNumber; }}

...what do you expect the type of MyProperty to be? I'll answer in
another message if no one has answered correctly.

Implicitly typed local variables were only added for anonymous
types. Without that, implicitly typed local variables would never
have made the bar, IMO.

Parallelization; the language needs first class support for writing
code for multiple processors/cores. Immutability is part of that,
if the CLR supported truly immutable types, programmers could write
safer concurrent code.

Post by Luke Breuer

Post by Peter Ritchie
I think non-nullable reference types are better handled through
invariant guarantees. Pulling in some stuff from Spec# would improve
C# greatly, and you'd get to be able to specify a reference

cannot be

Post by Luke Breuer

Post by Peter Ritchie
null and have it "guaranteed".

Yeah, I should have just mentioned
Spec#<http://research.microsoft.com/specsharp/>
.

Post by Peter Ritchie
"public" anonymous types would simply be a nightmare. "var" is just
sugar, C# generates the real type. You'd have the same issues as
private "var", you'd have to ensure you assign and declare at the
same time.

Not necessarily. We're just talking about a lot more type

inference than C#

Post by Luke Breuer
3.0 provides -- perhaps it would be [somewhat] accurate to say

that we'd be

Post by Luke Breuer
going into Haskell land. I could elaborate on how [I think] this would
work, if you're interested. The idea would be to reduce the

amount of

Post by Luke Breuer
explicit typing (spelling is intended) required, with the option for
refactoring to more/less explicit typing.
Immutability and parallelization are also very important and I

think

Post by Luke Breuer

Post by Peter Ritchie
they should get recognition sooner rather than later.

Are you thinking in terms of making it easier to write

parallelizable code?

Post by Luke Breuer
That is definitely becoming more important in certain areas.

[Luke Breuer]

Post by Peter Ritchie
Inferred types on a public interface couples the interface to
implementation details and makes interfaces with potentially
unobvious types.

I wouldn't use inference for public interfaces. I just think it'd be useful
for prototype work and communication between internal methods. One would
always be able to "make explicit".

[Peter Ritchie]

Post by Luke Breuer
I wouldn't use inference for public interfaces. I just think it'd be useful
for prototype work and communication between internal methods.

One would

Post by Luke Breuer
always be able to "make explicit".

So, you're only asking for it for private members? I should have
said "publicly visible". Private and protected members are publicly
visible via reflection, which is part of a class's interface.
Changing implementation details means my interface changes and
therefore is no longer compatible with the previous interface.

But, still, what do you expect the type of "value" to be here:
class MyClass {
private static UInt32 ui = 10;
private static Int32 i = 20;
private var value = i * ui;
//...
}

[Luke Breuer]

Post by Peter Ritchie
So, you're only asking for it for private members?

That, or people would have to be careful to not leave it in for public
members after the library is released/etc. I guess this would be a very
misusable feature...

Post by Peter Ritchie
class MyClass {
private static UInt32 ui = 10;
private static Int32 i = 20;
private var value = i * ui;
//...
}

It's what the compiler would generate from that expression: Int64.

[Ayende Rahien]

Peter.
If you care about the public interface, you can make it explicit. Most
times, you don't care.
If it change and it breaks stuff, you fix it. If you are building a library,
using var would probably not be a good idea, but that is a choice we should
have.

There is no confusion about the result of i * ui, so I don't see what the
problem.

Post by Luke Breuer

Post by Luke Breuer

i as int = 20

20

Post by Luke Breuer

Post by Luke Breuer

ui as UInt32 = 10

10

Post by Luke Breuer

Post by Luke Breuer

value = i * ui

200

Post by Luke Breuer

Post by Luke Breuer

value.GetType()

System.Int64

Post by Luke Breuer

Post by Luke Breuer
I wouldn't use inference for public interfaces. I just think it'd

be useful

Post by Luke Breuer
for prototype work and communication between internal methods.

One would

Post by Luke Breuer
always be able to "make explicit".

So, you're only asking for it for private members? I should have
said "publicly visible". Private and protected members are publicly
visible via reflection, which is part of a class's interface.
Changing implementation details means my interface changes and
therefore is no longer compatible with the previous interface.
class MyClass {
private static UInt32 ui = 10;
private static Int32 i = 20;
private var value = i * ui;
//...
}
Yahoo! Groups Links

[Peter Ritchie]

The type of a implicitly typed member would be a side-effect of
implementation, and in some circumstances a side-effect of compiler rules.
In the case of Int32 * Uint32 the result isn't a 32-bit intrinsic, but a
64-bit non-atomic intrinsic. Not only is that type not technically
thread-safe on 32-bit systems but you get an unintuitive slower type.
Unless you know these compiler rules (I won't get into what would happen if
someone decided that an operator to multiply Int32 by UInt32 would be
useful) the type isn't intuitive (the fact that you wrote code to find out
what it was exemplifies that) and if you changed your implementation and
inadvertently changed the type of that member it's not intuitive what it
*was* so it's not intuitive what you need to do to mitigate the change.



You're fine with this?



Without var you would get a compile error, so you're also hiding what would
otherwise have been an error unless you used a 64-bit type for the variable
(intuitively you'd type "uint x = ui * i" not "long x = ui * i")



With implicitly typed locals, these are less of an issue because
implementation details don't leak out, the body of a method is just that, an
implementation detail.



__

Microsoft <https://mvp.support.microsoft.com/profile/Peter.Ritchie> MVP
Visual Developer - C#

http://www.peterRitchie.com/



From: altnetconf-***@public.gmane.org [mailto:altnetconf-***@public.gmane.org] On
Behalf Of Ayende Rahien
Sent: December 22, 2007 2:44 AM
To: altnetconf-***@public.gmane.org
Subject: Re: [altnetconf] Re: Possible themes for C# 4.0



Peter.
If you care about the public interface, you can make it explicit. Most
times, you don't care.
If it change and it breaks stuff, you fix it. If you are building a library,
using var would probably not be a good idea, but that is a choice we should
have.

There is no confusion about the result of i * ui, so I don't see what the
problem.

Post by Luke Breuer

i as int = 20

20

Post by Luke Breuer

ui as UInt32 = 10

10

Post by Luke Breuer

value = i * ui

200

Post by Luke Breuer

value.GetType()

System.Int64

Post by Luke Breuer
I wouldn't use inference for public interfaces. I just think it'd be useful
for prototype work and communication between internal methods.

One would

Post by Luke Breuer
always be able to "make explicit".

So, you're only asking for it for private members? I should have
said "publicly visible". Private and protected members are publicly
visible via reflection, which is part of a class's interface.
Changing implementation details means my interface changes and
therefore is no longer compatible with the previous interface.

But, still, what do you expect the type of "value" to be here:
class MyClass {
private static UInt32 ui = 10;
private static Int32 i = 20;
private var value = i * ui;
//...
}





Yahoo! Groups Links


mailto:altnetconf-fullfeatured-***@public.gmane.org





__________ NOD32 2741 (20071221) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

[Ayende Rahien]

Yes, I am fine by that, because what you are trying to present is a very
edge casey and use that to rule out the entire feature.

Post by Peter Ritchie
The type of a implicitly typed member would be a side-effect of
implementation, and in some circumstances a side-effect of compiler rules.
In the case of Int32 * Uint32 the result isn't a 32-bit intrinsic, but a
64-bit non-atomic intrinsic. Not only is that type not technically
thread-safe on 32-bit systems but you get an unintuitive slower type.
Unless you know these compiler rules (I won't get into what would happen if
someone decided that an operator to multiply Int32 by UInt32 would be
useful) the type isn't intuitive (the fact that you wrote code to find out
what it was exemplifies that) and if you changed your implementation and
inadvertently changed the type of that member it's not intuitive what it *
*was** so it's not intuitive what you need to do to mitigate the change.
You're fine with this?
Without var you would get a compile error, so you're also hiding what
would otherwise have been an error unless you used a 64-bit type for the
variable (intuitively you'd type "uint x = ui * i" not "long x = ui * i")
With implicitly typed locals, these are less of an issue because
implementation details don't leak out, the body of a method is just that, an
implementation detail.
__
Microsoft MVP Visual Developer - C#<https://mvp.support.microsoft.com/profile/Peter.Ritchie>
http://www.peterRitchie.com/
Behalf Of *Ayende Rahien
*Sent:* December 22, 2007 2:44 AM
*Subject:* Re: [altnetconf] Re: Possible themes for C# 4.0
Peter.
If you care about the public interface, you can make it explicit. Most
times, you don't care.
If it change and it breaks stuff, you fix it. If you are building a
library, using var would probably not be a good idea, but that is a choice
we should have.
There is no confusion about the result of i * ui, so I don't see what the
problem.

Post by Luke Breuer

i as int = 20

20

Post by Luke Breuer

ui as UInt32 = 10

10

Post by Luke Breuer

value = i * ui

200

Post by Luke Breuer

value.GetType()

System.Int64

Post by Luke Breuer
I wouldn't use inference for public interfaces. I just think it'd

be useful

Post by Luke Breuer
for prototype work and communication between internal methods.

One would

Post by Luke Breuer
always be able to "make explicit".

So, you're only asking for it for private members? I should have
said "publicly visible". Private and protected members are publicly
visible via reflection, which is part of a class's interface.
Changing implementation details means my interface changes and
therefore is no longer compatible with the previous interface.
class MyClass {
private static UInt32 ui = 10;
private static Int32 i = 20;
private var value = i * ui;
//...
}
Yahoo! Groups Links
__________ NOD32 2741 (20071221) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com

[Peter Ritchie]

I don't think the issues raised with implicitly-typed members are edge
cases. There may be some edge cases in there.



Var raised above the bar for language additions as soon as anonymous types
were needed. Anonymous types, IMO, are the only reason to use var.



With implicitly-typed members, the ability of anonymous types to become
public is introduced. Since the name of anonymous types is basically random
there's no conceivable way to maintain a public API with anonymous types
from compile to compile, let alone from release to release.



__

Microsoft <https://mvp.support.microsoft.com/profile/Peter.Ritchie> MVP
Visual Developer - C#

http://www.peterRitchie.com/



From: altnetconf-***@public.gmane.org [mailto:altnetconf-***@public.gmane.org] On
Behalf Of Ayende Rahien
Sent: December 22, 2007 1:39 PM
To: altnetconf-***@public.gmane.org
Subject: Re: [altnetconf] Re: Possible themes for C# 4.0



Yes, I am fine by that, because what you are trying to present is a very
edge casey and use that to rule out the entire feature.

On 12/22/07, Peter Ritchie <yahoo.ritchiep1-C0Vd6GC7rd3pemSwkR/***@public.gmane.org> wrote:

The type of a implicitly typed member would be a side-effect of
implementation, and in some circumstances a side-effect of compiler rules.
In the case of Int32 * Uint32 the result isn't a 32-bit intrinsic, but a
64-bit non-atomic intrinsic. Not only is that type not technically
thread-safe on 32-bit systems but you get an unintuitive slower type.
Unless you know these compiler rules (I won't get into what would happen if
someone decided that an operator to multiply Int32 by UInt32 would be
useful) the type isn't intuitive (the fact that you wrote code to find out
what it was exemplifies that) and if you changed your implementation and
inadvertently changed the type of that member it's not intuitive what it
*was* so it's not intuitive what you need to do to mitigate the change.



You're fine with this?



Without var you would get a compile error, so you're also hiding what would
otherwise have been an error unless you used a 64-bit type for the variable
(intuitively you'd type "uint x = ui * i" not "long x = ui * i")



With implicitly typed locals, these are less of an issue because
implementation details don't leak out, the body of a method is just that, an
implementation detail.



__

Microsoft <https://mvp.support.microsoft.com/profile/Peter.Ritchie> MVP
Visual Developer - C#

http://www.peterRitchie.com/



From: altnetconf-***@public.gmane.org [mailto:altnetconf-***@public.gmane.org] On
Behalf Of Ayende Rahien
Sent: December 22, 2007 2:44 AM
To: altnetconf-***@public.gmane.org
Subject: Re: [altnetconf] Re: Possible themes for C# 4.0



Peter.
If you care about the public interface, you can make it explicit. Most
times, you don't care.
If it change and it breaks stuff, you fix it. If you are building a library,
using var would probably not be a good idea, but that is a choice we should
have.

There is no confusion about the result of i * ui, so I don't see what the
problem.

Post by Luke Breuer

i as int = 20

20

Post by Luke Breuer

ui as UInt32 = 10

10

Post by Luke Breuer

value = i * ui

200

Post by Luke Breuer

value.GetType()

System.Int64

Post by Luke Breuer
I wouldn't use inference for public interfaces. I just think it'd be useful
for prototype work and communication between internal methods.

One would

Post by Luke Breuer
always be able to "make explicit".

So, you're only asking for it for private members? I should have
said "publicly visible". Private and protected members are publicly
visible via reflection, which is part of a class's interface.
Changing implementation details means my interface changes and
therefore is no longer compatible with the previous interface.

But, still, what do you expect the type of "value" to be here:
class MyClass {
private static UInt32 ui = 10;
private static Int32 i = 20;
private var value = i * ui;
//...
}





Yahoo! Groups Links


mailto:altnetconf-fullfeatured-***@public.gmane.org





__________ NOD32 2741 (20071221) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com








__________ NOD32 2742 (20071222) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

[Luke Breuer]

As implicit typing is now, it encourages one to stuff more in a method or be
forced to make all passed types explicit. Moreover, breaks in the API
should be detected via changes in "API signatures," obtained by checking out
various versions from source control and running reflection against them;
unit/regression tests would also be good. I have a hard time seeing why
this isn't a good practice *without* inter-method type inference!

[Ayende Rahien]

There is the libchecker.exe tool from MS, which already does just that.

Post by Luke Breuer
As implicit typing is now, it encourages one to stuff more in a method or
be forced to make all passed types explicit. Moreover, breaks in the API
should be detected via changes in "API signatures," obtained by checking out
various versions from source control and running reflection against them;
unit/regression tests would also be good. I have a hard time seeing why
this isn't a good practice *without* inter-method type inference!

[Luke Breuer]

Post by Ayende Rahien
There is the libchecker.exe tool from MS, which already does just that.

Damn, why does everyone have to steal my good ideas? :-p

[Peter Ritchie]

I don't think things like libchecker really have any bearing on
this. It's a good practice now, that doesn't make implicitly typed
members any more valid.

API changes with explicitly-typed members would be detected with
source control, which isn't something that would be detected with
implicitly-typed members.

MyClass.cs:
using System;

public partial class Program
{
public var field = MyMethod();
}

MyClass1.partial.cs
using System;

public partial class Program
{
private static int MyMethod()
{
return 10;
}
}

Changes in the return type of Program.MyMethod in
MyClass1.partial.cs causes an API change to Program.field in
MyClass1.cs; but the source file never changes. As a lead, I can
detect changes to APIs with explicitly-typed members simply by being
informed a file changed; if the API can change without the source
file containing that API changing, I must rely on libchecker either
during the check-in process or at some later review time.

If there weren't issues with implicitly-typed members that aren't
present with implicitly-typed locals, it would have been added in C#
3.

Post by Luke Breuer
As implicit typing is now, it encourages one to stuff more in a method or be
forced to make all passed types explicit. Moreover, breaks in the API
should be detected via changes in "API signatures," obtained by checking out
various versions from source control and running reflection

against them;

Post by Luke Breuer
unit/regression tests would also be good. I have a hard time

seeing why

Post by Luke Breuer
this isn't a good practice *without* inter-method type inference!

[Ayende Rahien]

Post by Luke Breuer
I had a relatively short, but quite insightful conversation with Eric
Rather, we have a large number of customers, internal and external, and

each has their own ideas about how the language should evolve. There are a
million and one possible new language features we could do; the trick is
finding the few of them that give the biggest bang for the buck to the
greatest number of customers. We therefore try to identify a *theme* and
then choose features, large and small, which work together to support that
theme.

I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ. Yes, there are no trivial left
joins, but on the whole, I like it. Frans would have something to say about
how Expression<T> is implemented, Ayende and others would denigrate partial
methods, but I think most of us, on average, really like C# 3.0.
What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme would be
- non-nullable reference types
- inter-method type inference, so I can pass anonymous types around
Not really useful, I am afraid. I really don't like the idea of anonymous

types, they are a hack, plain and simple.
public var Foo()
{
return 43;
}

Now that would be nice.

Post by Luke Breuer
- var quote = s => "'" + s + "'";
This is a problem because you may want a delegate or an expression tree.

You can default to the delegate, however, I am not sure why this is not so
already.

Post by Luke Breuer
- named parameters (dunno about default parameter values)
- the infoof operator (info of), for no/fewer magic strings or
lambdas when using reflection
- [more] covariance/contravariance
There is plenty else to discuss, but I don't want to steal all the thunder
or anything. :-D

public interface IDynamicObject
{
IDynamicObject DynamicInvoke(string name, params object[] args);
}

I really want this supported

[Luke Breuer]

Post by Luke Breuer
Not really useful, I am afraid. I really don't like the idea of anonymous
types, they are a hack, plain and simple.

This is shocking, coming from you. Have you never written Javascript and
come to admire the syntactically elegant object literal syntax (think
JSON)? I've found incredible uses for anonymous types, uses that enabled
very, very elegant code. Perhaps this
example<http://luke.breuer.com/time/item/C_Example_of_anoymous_types_and_LINQ/206.aspx>would
be better re-written without anonymous types? (It's a bit of a hack,
but it was just for doing one-time processing of data.)

Post by Luke Breuer

Post by Luke Breuer
- var quote = s => "'" + s + "'";
This is a problem because you may want a delegate or an expression tree.

You can default to the delegate, however, I am not sure why this is not so
already.

Or the compiler can look to see how *quote* is used.

Post by Luke Breuer
public interface IDynamicObject
{
IDynamicObject DynamicInvoke(string name, params object[] args);
}
I really want this supported

method_missing, I see. :-p You should have linked to your blog post on how
Boo implements method_missing<http://ayende.com/Blog/archive/2007/12/21/If-it-walks-like-a-duck-and-it-quacks.aspx>.
By the way, Eric gave me the smallest of hints that C# 4.0 might do
something like this, at least he said that "interoperability between C# and
other programming systems" was a possible theme.

[Ayende Rahien]

Post by Luke Breuer

Post by Luke Breuer
Not really useful, I am afraid. I really don't like the idea of
anonymous types, they are a hack, plain and simple.

This is shocking, coming from you. Have you never written Javascript and
come to admire the syntactically elegant object literal syntax (think
JSON)? I've found incredible uses for anonymous types, uses that enabled
very, very elegant code. Perhaps this example<http://luke.breuer.com/time/item/C_Example_of_anoymous_types_and_LINQ/206.aspx>would be better re-written without anonymous types? (It's a bit of a hack,
but it was just for doing one-time processing of data.)

Javascript has two types of objects, hashes and functions.
I am not too sure about functions, however.

Stuff that make sense there doesn't make sense here.

The example that you gave is a hack, sorry. It is a hack because I now have
to both define and use the definition in the same methods.
God methods, anyone?

A good syntax for hashes as well as a good syntax to get stuff out of hashes
would elevate a lot of the pain, I think.

For the rest, just write a DTO, it is shorter, more maintainable and more
understandable.

Post by Luke Breuer

Post by Luke Breuer

Post by Luke Breuer
- var quote = s => "'" + s + "'";
This is a problem because you may want a delegate or an expression

tree. You can default to the delegate, however, I am not sure why this is
not so already.

Or the compiler can look to see how *quote* is used.

No, you _really_ don't want that in a general purpose language.
I am purposefully not including lazy methods information in the book,
because I think that the chance to abuse that is simply too great.

[Eric Hauser]

I assume for 4.0 (like 3.0) they are not planning on changing the
CLR? Named parameters would require a change to IL.

Post by Luke Breuer
I had a relatively short, but quite insightful conversation with Eric
Lippert, one of the C# designers who actually
blogs<http://blogs.msdn.com/ericlippert/>about C#. He said the
Rather, we have a large number of customers, internal and external, and each

has their own ideas about how the language should evolve. There are a
million and one possible new language features we could do; the trick is
finding the few of them that give the biggest bang for the buck to the
greatest number of customers. We therefore try to identify a

*theme* and

Post by Luke Breuer

then choose features, large and small, which work together to support that
theme.

I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ. Yes, there are no

trivial left

Post by Luke Breuer
joins, but on the whole, I like it. Frans would have something to say about
how Expression<T> is implemented, Ayende and others would denigrate partial
methods, but I think most of us, on average, really like C# 3.0.
What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme would be
- non-nullable reference types
- inter-method type inference, so I can pass anonymous types around
- var quote = s => "'" + s + "'";
- named parameters (dunno about default parameter values)
- the infoof operator (info of), for no/fewer magic strings or lambdas
when using reflection
- [more] covariance/contravariance
There is plenty else to discuss, but I don't want to steal all the thunder
or anything. :-D
Luke

[Ayende Rahien]

Not really. You can do them in VB.Net

Post by Eric Hauser
I assume for 4.0 (like 3.0) they are not planning on changing the
CLR? Named parameters would require a change to IL.

Post by Luke Breuer
I had a relatively short, but quite insightful conversation with

Eric

Post by Luke Breuer
Lippert, one of the C# designers who actually
blogs<http://blogs.msdn.com/ericlippert/>about C#. He said the
Rather, we have a large number of customers, internal and external,

and each

Post by Luke Breuer

has their own ideas about how the language should evolve. There

are a

Post by Luke Breuer

million and one possible new language features we could do; the

trick is

Post by Luke Breuer

finding the few of them that give the biggest bang for the buck

to the

Post by Luke Breuer

greatest number of customers. We therefore try to identify a

*theme* and

Post by Luke Breuer

then choose features, large and small, which work together to

support that

Post by Luke Breuer

theme.

I think it was really cool that a lot of good features got pulled

in for a

Post by Luke Breuer
mostly non-hackish implementation of LINQ. Yes, there are no

trivial left

Post by Luke Breuer
joins, but on the whole, I like it. Frans would have something to

say about

Post by Luke Breuer
how Expression<T> is implemented, Ayende and others would denigrate

partial

Post by Luke Breuer
methods, but I think most of us, on average, really like C# 3.0.
What I want to know is what you would like for C# 4.0. As noted by

Eric,

Post by Luke Breuer
"narrow" improvements are more likely to happen if they contribute

to a

Post by Luke Breuer
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme

would be

Post by Luke Breuer
- non-nullable reference types
- inter-method type inference, so I can pass anonymous types

around

Post by Luke Breuer
- var quote = s => "'" + s + "'";
- named parameters (dunno about default parameter values)
- the infoof operator (info of), for no/fewer magic strings or

lambdas

Post by Luke Breuer
when using reflection
- [more] covariance/contravariance
There is plenty else to discuss, but I don't want to steal all the

thunder

Post by Luke Breuer
or anything. :-D
Luke

Yahoo! Groups Links

[Eric Hauser]

I misunderstood named parameters. I was thinking access to the
actual parameter names at runtime.

Post by Ayende Rahien
Not really. You can do them in VB.Net

Post by Eric Hauser
I assume for 4.0 (like 3.0) they are not planning on changing the
CLR? Named parameters would require a change to IL.

Post by Luke Breuer
I had a relatively short, but quite insightful conversation with

Eric

Post by Luke Breuer
Lippert, one of the C# designers who actually
blogs<http://blogs.msdn.com/ericlippert/>about C#. He said the
Rather, we have a large number of customers, internal and

external,

Post by Ayende Rahien

Post by Eric Hauser
and each

Post by Luke Breuer

has their own ideas about how the language should evolve. There

are a

Post by Luke Breuer

million and one possible new language features we could do; the

trick is

Post by Luke Breuer

finding the few of them that give the biggest bang for the buck

to the

Post by Luke Breuer

greatest number of customers. We therefore try to identify a

*theme* and

Post by Luke Breuer

then choose features, large and small, which work together to

support that

Post by Luke Breuer

theme.

I think it was really cool that a lot of good features got

pulled

Post by Ayende Rahien

Post by Eric Hauser
in for a

Post by Luke Breuer
mostly non-hackish implementation of LINQ. Yes, there are no

trivial left

Post by Luke Breuer
joins, but on the whole, I like it. Frans would have something to

say about

Post by Luke Breuer
how Expression<T> is implemented, Ayende and others would

denigrate

Post by Ayende Rahien

Post by Eric Hauser
partial

Post by Luke Breuer
methods, but I think most of us, on average, really like C# 3.0.
What I want to know is what you would like for C# 4.0. As

noted by

Post by Ayende Rahien

Post by Eric Hauser
Eric,

Post by Luke Breuer
"narrow" improvements are more likely to happen if they

contribute

Post by Ayende Rahien

Post by Eric Hauser
to a

Post by Luke Breuer
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme

would be

Post by Luke Breuer
- non-nullable reference types
- inter-method type inference, so I can pass anonymous types

around

Post by Luke Breuer
- var quote = s => "'" + s + "'";
- named parameters (dunno about default parameter values)
- the infoof operator (info of), for no/fewer magic strings or

lambdas

Post by Luke Breuer
when using reflection
- [more] covariance/contravariance
There is plenty else to discuss, but I don't want to steal all the

thunder

Post by Luke Breuer
or anything. :-D
Luke

Yahoo! Groups Links

[Jeff Brown]

A million and one ideas, indeed.

My own list would be biased towards enabling the language to be more
expressive to cut back on error-prone boilerplate.

* infoof(). Unfortunately this gets a little tricky with specifying the
signature of overloaded members.
* Hygienic macros. Or decorator annotations a la Python. Or bolt-on
compiler extensions.
* Combine the above with efficient runtime method interception in the CLR
and we could build some very interesting AOP systems.
* More powerful custom attributes: allow Expression<T> to appear in
attributes or allow attributes to be composed as in Java. (I'm not holding
my breath.)
* Design by Contract. Way better than non-nullable types.
* Library enhancements: more collections, more concurrency primitives,
lock-free data structures.
* Extension properties and extension events to round out extension methods.
* Variance.
* Regex syntax. eg. /arr+ ye mateys/g
* A barrel of monkeys.

---

Now ultimately to get any new features into C# 4.0, it needs to be shown to
be required by some other highly visible and marketable feature that is of
interest to Microsoft's primary customer base. Just like LINQ. Personally
I have no use for the LINQ syntax, but the extra features that came along
for the ride are pretty good.

For example, we should consider how we might slip in some cool
general-purpose features under the guise of enhancing C#'s support for
parallel / asynchronous computation. Spawning and reaping threads or
setting up and chaining asynchronous callbacks is very tedious right now.
One way to simplify that would be to add new control structures to the
language.

But I can think of quite a few new interesting control structures I might
want to add to do this. And I can think of quite a few other interesting
things besides if we start looking at Software Transactional Memory and
mechanisms for composing computations and controlling side-effects like
Monads do.

Surely we could only expose a few such new high-level features as C#
keywords. But there may be too many of them so we'll have to do something
else. Maybe we can introduce macros or user-defined control structures into
the language somehow to confine the complexity to specific problem domains.
I can imagine some kind of "extension syntax" based features that you only
get when you import some special namespace into your file.

That way you can define "Fork", "Join", and "Future" as extension syntax
features in the library to help with concurrent programming. These are
ordinary methods like extension methods but they are decorated with a custom
attribute that tells the compiler how to map expressions and code blocks
into its parameters as Expression<T> or delegate values.

See where this is going?

When we get down to it, my pet list of feature requests is not really any
better than anyone else's. There are lots of cool things we can think of.
They need to be put in context.

So what interesting high-level features can we come up with that Microsoft
can SELL and that incidentally bring in new low-level features that are also
of value to us?

Jeff.

_____

From: altnetconf-***@public.gmane.org [mailto:altnetconf-***@public.gmane.org] On
Behalf Of Luke Breuer
Sent: Friday, December 21, 2007 12:46 PM
To: altnetconf-***@public.gmane.org
Subject: [altnetconf] Possible themes for C# 4.0


I had a relatively short, but quite insightful conversation with Eric
Lippert, one of the C# designers who actually blogs
<http://blogs.msdn.com/ericlippert/> about C#. He said the following (yes,
in purple):



Rather, we have a large number of customers, internal and external, and each
has their own ideas about how the language should evolve. There are a
million and one possible new language features we could do; the trick is
finding the few of them that give the biggest bang for the buck to the
greatest number of customers. We therefore try to identify a theme and then
choose features, large and small, which work together to support that theme.



I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ. Yes, there are no trivial left
joins, but on the whole, I like it. Frans would have something to say about
how Expression<T> is implemented, Ayende and others would denigrate partial
methods, but I think most of us, on average, really like C# 3.0.

What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme would be
better type safety/type inference. A few examples:


* non-nullable reference types


* inter-method type inference, so I can pass anonymous types around

* var quote = s => "'" + s + "'";

* named parameters (dunno about default parameter values)


* the infoof operator (info of), for no/fewer magic strings or lambdas
when using reflection

* [more] covariance/contravariance


There is plenty else to discuss, but I don't want to steal all the thunder
or anything. :-D

Luke

[Ayende Rahien]

Also, a few concurrency primitives backed by the CLR would be great. Things
like being able to release control on a thread and let another handle it,
Erlang style processes.

Post by Luke Breuer
I had a relatively short, but quite insightful conversation with Eric
Rather, we have a large number of customers, internal and external, and

each has their own ideas about how the language should evolve. There are a
million and one possible new language features we could do; the trick is
finding the few of them that give the biggest bang for the buck to the
greatest number of customers. We therefore try to identify a *theme* and
then choose features, large and small, which work together to support that
theme.

I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ. Yes, there are no trivial left
joins, but on the whole, I like it. Frans would have something to say about
how Expression<T> is implemented, Ayende and others would denigrate partial
methods, but I think most of us, on average, really like C# 3.0.
What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme would be
- non-nullable reference types
- inter-method type inference, so I can pass anonymous types around
- var quote = s => "'" + s + "'";
- named parameters (dunno about default parameter values)
- the infoof operator (info of), for no/fewer magic strings or
lambdas when using reflection
- [more] covariance/contravariance
There is plenty else to discuss, but I don't want to steal all the thunder
or anything. :-D
Luke

[Sergio Pereira]

I share a lot of the requests made here, but I'd also be happy with
some little things:
- literal notations for regex, dates, timespans, hashes
- better integration of nullable types in the rest of the framework
(ado.net comes to mind)

I guess my theme is "finish what you've sarted"

- sp

Post by Luke Breuer
I had a relatively short, but quite insightful conversation with Eric
Lippert, one of the C# designers who actually blogs about C#. He said the

Post by Luke Breuer
Rather, we have a large number of customers, internal and external, and

each has their own ideas about how the language should evolve. There are a
million and one possible new language features we could do; the trick is
finding the few of them that give the biggest bang for the buck to the
greatest number of customers. We therefore try to identify a theme and then
choose features, large and small, which work together to support that theme.
I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ. Yes, there are no trivial left
joins, but on the whole, I like it. Frans would have something to say about
how Expression<T> is implemented, Ayende and others would denigrate partial
methods, but I think most of us, on average, really like C# 3.0.
What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme would be
non-nullable reference types
inter-method type inference, so I can pass anonymous types around
var quote = s => "'" + s + "'";
named parameters (dunno about default parameter values)
the infoof operator (info of), for no/fewer magic strings or lambdas when
using reflection
[more] covariance/contravariance
There is plenty else to discuss, but I don't want to steal all the thunder
or anything. :-D
Luke

[Scott Bellware]

Post by Sergio Pereira
- literal notations for regex, dates, timespans, hashes

And string formats!

[Sergio Pereira]

Post by Scott Bellware
And string formats!

Good catch. +1 on that.

Post by Scott Bellware

Post by Sergio Pereira
- literal notations for regex, dates, timespans, hashes

And string formats!
Yahoo! Groups Links

[Ayende Rahien]

String interpolation, I assume you mean.

Post by Sergio Pereira

Post by Scott Bellware
And string formats!

Good catch. +1 on that.

Post by Scott Bellware

Post by Sergio Pereira
- literal notations for regex, dates, timespans, hashes

And string formats!
Yahoo! Groups Links

--
______________________________________
Sergio Pereira
Yahoo! Groups Links

[Scott Bellware]

Post by Ayende Rahien
String interpolation, I assume you mean.

Yes indeed.

[Chris Brandsma]

OK, I had to look that one up (string interpolation).

I am guessing you are talking about changing this:

string person = "sucker";
string s = string.format("Hi there {0}", person);

with this

string person = "sucker"
string s = "Hi there {=person}";

Or something there abouts. (actual syntax might vary).

Post by Scott Bellware

Post by Ayende Rahien
String interpolation, I assume you mean.

Yes indeed.

[silky]

Post by Chris Brandsma
OK, I had to look that one up (string interpolation).
string person = "sucker";
string s = string.format("Hi there {0}", person);
with this
string person = "sucker"
string s = "Hi there {=person}";
Or something there abouts. (actual syntax might vary).

god that would be a truly horrible idea ...

to me it seems obvious that the 'theme' for c# 4 will be parallelism
(plinq, immutability) and distributed deployment (volta). i have
several doubts, at this time, as to the 'amazing' value of
language-detectable immutability and immutable lists and so on, as
discussed by eric lippert. still, it'll be interesting to see what
happens. but damn it would suck if c# became more "script" like. i
know "var" is really quite limited at the moment (local variables,
this is good) but if it got further out then that it'd create a
horrible programming experience. like what extensions methods will do.

[Bill Barry]

2 things (other than non-nullable reference types):
make it easy to attach events before and after method calls (perhaps at
compile time).
allow more in attribute parameters (expressions for example)

I think most of the additions in spec# could be done with these (the
non-nullable reference type included).

Post by Luke Breuer
I had a relatively short, but quite insightful conversation with Eric
Lippert, one of the C# designers who actually blogs
<http://blogs.msdn.com/ericlippert/> about C#. He said the following
Rather, we have a large number of customers, internal and
external, and each has their own ideas about how the language
should evolve. There are a million and one possible new language
features we could do; the trick is finding the few of them that
give the biggest bang for the buck to the greatest number of
customers. We therefore try to identify a /theme/ and then choose
features, large and small, which work together to support that theme.
I think it was really cool that a lot of good features got pulled in
for a mostly non-hackish implementation of LINQ. Yes, there are no
trivial left joins, but on the whole, I like it. Frans would have
something to say about how Expression<T> is implemented, Ayende and
others would denigrate partial methods, but I think most of us, on
average, really like C# 3.0.
What I want to know is what you would like for C# 4.0. As noted by
Eric, "narrow" improvements are more likely to happen if they
contribute to a [decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme
* non-nullable reference types
* inter-method type inference, so I can pass anonymous types around
* var quote = s => "'" + s + "'";
* named parameters (dunno about default parameter values)
* the infoof operator (info of), for no/fewer magic strings or
lambdas when using reflection
* [more] covariance/contravariance
There is plenty else to discuss, but I don't want to steal all the
thunder or anything. :-D
Luke

[Jon Davis]

I vote for theme:



"If it ain't broke ."





- Jon





From: altnetconf-***@public.gmane.org [mailto:altnetconf-***@public.gmane.org] On
Behalf Of Luke Breuer
Sent: Friday, December 21, 2007 1:46 PM
To: altnetconf-***@public.gmane.org
Subject: [altnetconf] Possible themes for C# 4.0



I had a relatively short, but quite insightful conversation with Eric
Lippert, one of the C# designers who actually blogs
<http://blogs.msdn.com/ericlippert/> about C#. He said the following (yes,
in purple):

Rather, we have a large number of customers, internal and external, and each
has their own ideas about how the language should evolve. There are a
million and one possible new language features we could do; the trick is
finding the few of them that give the biggest bang for the buck to the
greatest number of customers. We therefore try to identify a theme and then
choose features, large and small, which work together to support that theme.


I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ. Yes, there are no trivial left
joins, but on the whole, I like it. Frans would have something to say about
how Expression<T> is implemented, Ayende and others would denigrate partial
methods, but I think most of us, on average, really like C# 3.0.

What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for
improvements/features, linked to a pretty solid theme. My #1 theme would be
better type safety/type inference. A few examples:

* non-nullable reference types
* inter-method type inference, so I can pass anonymous types around
* var quote = s => "'" + s + "'";
* named parameters (dunno about default parameter values)
* the infoof operator (info of), for no/fewer magic strings or lambdas
when using reflection
* [more] covariance/contravariance

There is plenty else to discuss, but I don't want to steal all the thunder
or anything. :-D

Luke

[Luke Breuer]

"If it ain't broke …"
Was it broken before C# 3.0?

[Jon Davis]

No. I voted the same theme then. Apparently I got out-voted.



Jon





From: altnetconf-***@public.gmane.org [mailto:altnetconf-***@public.gmane.org] On
Behalf Of Luke Breuer
Sent: Friday, December 21, 2007 10:25 PM
To: altnetconf-***@public.gmane.org
Subject: Re: [altnetconf] Possible themes for C# 4.0



On Dec 22, 2007 12:22 AM, Jon Davis <jon-***@public.gmane.org> wrote:

I vote for theme:



"If it ain't broke ."

Was it broken before C# 3.0?

[Luke Breuer]

Post by Jon Davis
No. I voted the same theme then. Apparently I got out-voted.

Use C++ if you don't want anything to change. :-p

[Jon Davis]

Use C++ if you don't want anything to change. :-P

:P I was just kidding, but I love C#, it's just that with LINQ and var it
feels like it's become a different language. I feel like C# is transitioning
after an identity crisis. I can't say the same thing about generics (we
begged for this before v1 went gold), anonymous delegates, partial classes,
partial methods, or extension methods (all of these are minor but
significant language enhancements), but LINQ and var really ticked me off.
Don't get me wrong, I was running around doing cartwheels when C-Omega was
put on Channel 9. I loved LINQ, when it was not "C# 3" and it was a
thoughtful optional compiler extension. I just didn't expect C# itself to
become a new language. I feel the same about XML in VB.



I do agree with some of the enhancements such as those proposed (i.e. the
non-nullable reference types).



But I don't like inferential typing and I'm annoyed that C# has gone down
that path.



That said, I'm here to embrace C# through thick (really thick .. fat ..) and
thin, till death do us part. I'll just have to be picky about who I team up
with. :P



Jon

[Casey Charlton]

Have to agree here - LINQ and var to me shifted C# from what it was as a
language, into a bit of a utlity language ...

To me it was an elegant higher level version of C/C++ useful for similar
level things, and it just happened to work quite well for application stuff
too. LINQ and var have shifted it into a VB/JS type language, more aimed at
just 'throwing shit together quick'

var I think has the most amazing potential to be abused in c# and I am
dreading the day in a year or twos time when I go to a client where some
budding genius has abused var to the point where I can no longer figure out
wtf his code is meant to do. Extension methods for all their potential
benefits have an even more stunning capability to be abused. LINQ is going
to encourage data access from the UI layer.

Until now at least any potential nightmare scenario a wannabe could create
in c#, I could pretty much unravel with relative ease, but in MS' efforts to
make C# a higher level language all the time, I think they are making it
easier to write poor code.

I don't think anything in C#3 was to me a 'great' feature - a few things are
'nice to haves' - but I would honestloy have prefered none of them to them
as a whole. Ruby showed a long time ago that you can make a solid language
at a pretty high level, without needing to make it so fragile ... VB(
pre-.NET) showed the opposite, unfortunately I think C# is taking too many
ideas from the wrong camp.

Post by Jon Davis

Use C++ if you don't want anything to change. :-P

:P I was just kidding, but I love C#, it's just that with LINQ and var it
feels like it's become a different language. I feel like C# is transitioning
after an identity crisis. I can't say the same thing about generics (we
begged for this before v1 went gold), anonymous delegates, partial classes,
partial methods, or extension methods (all of these are minor but
significant language enhancements), but LINQ and var really ticked me off.
Don't get me wrong, I was running around doing cartwheels when C-Omega was
put on Channel 9. I loved LINQ, when it was not "C# 3" and it was a
thoughtful optional compiler extension. I just didn't expect C# itself to
become a new language. I feel the same about XML in VB.
I do agree with some of the enhancements such as those proposed (i.e. the
non-nullable reference types).
But I don't like inferential typing and I'm annoyed that C# has gone down
that path.
That said, I'm here to embrace C# through thick (really thick .. fat ..)
and thin, till death do us part. I'll just have to be picky about who I team
up with. :P
Jon

[Ayende Rahien]

Did you _see_ what was going on in C++ 0x?

I _want_ traits, I want them badly.

Post by Luke Breuer

Post by Jon Davis
No. I voted the same theme then. Apparently I got out-voted.

Use C++ if you don't want anything to change. :-p

[Bil Simser]

Professor Stephane Ducasse[1], president of the European Smalltalk User
Group[2] says they're working on a traits for C#, but not sure how that's
going to manifest itself.



[1] http://www.iam.unibe.ch/~ducasse/

[2] http://www.esug.org/?



From: altnetconf-***@public.gmane.org [mailto:altnetconf-***@public.gmane.org] On
Behalf Of Ayende Rahien
Sent: Saturday, December 22, 2007 12:45 AM
To: altnetconf-***@public.gmane.org
Subject: Re: [altnetconf] Possible themes for C# 4.0



Did you _see_ what was going on in C++ 0x?

I _want_ traits, I want them badly.

On 12/22/07, Luke Breuer <labreuer-***@public.gmane.org <mailto:labreuer-***@public.gmane.org> >
wrote:

On Dec 22, 2007 12:25 AM, Jon Davis <jon-***@public.gmane.org> wrote:

No. I voted the same theme then. Apparently I got out-voted.

Use C++ if you don't want anything to change. :-p

[Frans Bouma]

Post by Luke Breuer
I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ.

I'd argue that the LINQ implementation IS hacky. The main reason is
that it is a DSL, and therefore they should have implemented a way to embed a
DSL inside C# with scope awareness. With that they could have made Linq but
they also would allow others with other DSLs to embed their DSL into C#.

Post by Luke Breuer
What I want to know is what you would like for C# 4.0. As noted by Eric,
"narrow" improvements are more likely to happen if they contribute to a
[decently] large theme. Therefore, I'm asking you for improvements/fea

tures,

Post by Luke Breuer
linked to a pretty solid theme. My #1 theme would be better type

safety/type

Post by Luke Breuer
inference.

Meyer has solved many things decades ago in Eiffel, and I think the C#
team should just look at Eiffel and use the stuff that makes Eiffel great,
like pre/post conditions, design by contract, multiple inheritance which DOES
work, etc.

Added to that, they should add the possibility to embed your DSL
inside C# with scope awareness.

Anything else is IMHO minor or irrelevant to these two.

FB

[Ayende Rahien]

Post by Frans Bouma

Post by Luke Breuer
I think it was really cool that a lot of good features got pulled in for

a

Post by Luke Breuer
mostly non-hackish implementation of LINQ.

I'd argue that the LINQ implementation IS hacky. The main reason is
that it is a DSL, and therefore they should have implemented a way to embed a
DSL inside C# with scope awareness. With that they could have made Linq but
they also would allow others with other DSLs to embed their DSL into C#.

Agreed. On the boo list we are toying with the idea of macro operators, and
then building the linq implementation on top of that.

A macro operator is something like this:

bool result = a contains b;

Where the compiler takes that and translate it to:

public static class MyOperators
{
[MacroOperator]
public static boool contains(ICollection a, object b)
{
return c.Contains(b);
}
}

(well, the Boo implementation would be more interesting, but that is how I
would build this for C#)

[Frans Bouma]

Post by Frans Bouma

Post by Luke Breuer
I think it was really cool that a lot of good features got pulled in for a
mostly non-hackish implementation of LINQ.

I'd argue that the LINQ implementation IS hacky. The main reason is
that it is a DSL, and therefore they should have implemented a way to embed a
DSL inside C# with scope awareness. With that they could have made Linq but
they also would allow others with other DSLs to embed their DSL into C#.
Agreed. On the boo list we are toying with the idea of macro operators, and
then building the linq implementation on top of that.
bool result = a contains b;
public static class MyOperators
{
[MacroOperator]
public static boool contains(ICollection a, object b)
{
&nb sp; return c.Contains (b);
}
}
(well, the Boo implementation would be more interesting, but that is how I
would build this for C#)

Isn't that too limited? it's not really offering a complete embedded
foreign language. Take for example SQL/J, which is compile-time checked SQL
statements inside Java code.

so what I'm arguing is something like:

public List<Customer> GetCustomers(string country)
{
var query =
language(SQL)
{
SELECT * FROM Customer WHERE COUNTRY = country
}
return someORMapperSession.GetList<Customer>(query);
}

I used SQL as an example here. The main idea is that what's defined in
the language block between {} is handed to a DIFFERENT compiler, namely the
SQL compiler. It receives the symbol table valid at the point of the
'language' statement, and the variables in-scope at that time. The mechanism
build into C# then takes care of scope updates back and forth between the two
languages.

FB

[Jay Chapman]

Frans,

In this example you gave how would the complier know the schema of the
database which you are querying? Would this really gain you anything
without knowledge of the schema?

John Chapman

Post by Frans Bouma

Post by Frans Bouma

Post by Luke Breuer
I think it was really cool that a lot of good features got pulled in

for a

Post by Frans Bouma

Post by Luke Breuer
mostly non-hackish implementation of LINQ.

I'd argue that the LINQ implementation IS hacky. The main

reason is

Post by Frans Bouma
that it is a DSL, and therefore they should have implemented a way to

embed a

Post by Frans Bouma
DSL inside C# with scope awareness. With that they could have made

Linq but

Post by Frans Bouma
they also would allow others with other DSLs to embed their DSL into

C#.

Post by Frans Bouma
Agreed. On the boo list we are toying with the idea of macro operators,

and

Post by Frans Bouma
then building the linq implementation on top of that.
bool result = a contains b;
public static class MyOperators
{
[MacroOperator]
public static boool contains(ICollection a, object b)
{
&nb sp; return c.Contains (b);
}
}
(well, the Boo implementation would be more interesting, but that is how

I

Post by Frans Bouma
would build this for C#)

Isn't that too limited? it's not really offering a complete embedded
foreign language. Take for example SQL/J, which is compile-time checked SQL
statements inside Java code.
public List<Customer> GetCustomers(string country)
{
var query =
language(SQL)
{
SELECT * FROM Customer WHERE COUNTRY = country
}
return someORMapperSession.GetList<Customer>(query);
}
I used SQL as an example here. The main idea is that what's defined in
the language block between {} is handed to a DIFFERENT compiler, namely the
SQL compiler. It receives the symbol table valid at the point of the
'language' statement, and the variables in-scope at that time. The mechanism
build into C# then takes care of scope updates back and forth between the two
languages.
FB

[Frans Bouma]

Post by Jay Chapman
Frans,
In this example you gave how would the complier know the schema of the
database which you are querying? Would this really gain you anything

without

Post by Jay Chapman
knowledge of the schema?

It's the responsibility of the SQL compiler (or more in general: the
DSL compiler of the DSL used in the language block) to produce code at that
spot which is syntactically correct. So if the SQL compiler needs schema info
to do its job, it has to access that schema info. How, that's up to the SQL
compiler.

FB

Post by Jay Chapman
John Chapman

Post by Frans Bouma

Post by Luke Breuer
I think it was really cool that a lot of good features got pulled

in
for a

Post by Frans Bouma

Post by Luke Breuer
mostly non-hackish implementation of LINQ.

I'd argue that the LINQ implementation IS hacky. The main

reason is

Post by Frans Bouma
that it is a DSL, and therefore they should have implemented a way to

embed a

Post by Frans Bouma
DSL inside C# with scope awareness. With that they could have made

Linq but

Post by Frans Bouma
they also would allow others with other DSLs to embed their DSL into

C#.

Post by Frans Bouma
Agreed. On the boo list we are toying with the idea of macro

operators, and

Post by Frans Bouma
then building the linq implementation on top of that.
bool result = a contains b;
public static class MyOperators
{
[MacroOperator]
public static boool contains(ICollection a, object b)
{
&nb sp; return c.Contains (b);
}
}
(well, the Boo implementation would be more interesting, but that is

how I

Post by Frans Bouma
would build this for C#)

Isn't that too limited? it's not really offering a complete embedded
foreign language. Take for example SQL/J, which is compile-time

checked

Post by Jay Chapman
SQL
statements inside Java code.
public List<Customer> GetCustomers(string country)
{
var query =
language(SQL)
{
SELECT * FROM Customer WHERE COUNTRY = country
}
return someORMapperSession.GetList<Customer>(query);
}
I used SQL as an example here. The main idea is that what's defined in
the language block between {} is handed to a DIFFERENT compiler,

namely

Post by Jay Chapman
the
SQL compiler. It receives the symbol table valid at the point of the
'language' statement, and the variables in-scope at that time. The mechanism
build into C# then takes care of scope updates back and forth between the two
languages.
FB

[Ayende Rahien]

Frans,
While this is an option, I don't really like this.
It is mixing too much in the same file. Even if this is compiler checked,
you still have the problem of dealing with two syntaxes at the same time.
It is confusing.
Keeping the same syntax for everything seems more natural to me.

Post by Frans Bouma
Isn't that too limited? it's not really offering a complete embedded
foreign language. Take for example SQL/J, which is compile-time checked SQL
statements inside Java code.
public List<Customer> GetCustomers(string country)
{
var query =
language(SQL)
{
SELECT * FROM Customer WHERE COUNTRY = country
}
return someORMapperSession.GetList<Customer>(query);
}
I used SQL as an example here. The main idea is that what's defined in
the language block between {} is handed to a DIFFERENT compiler, namely the
SQL compiler. It receives the symbol table valid at the point of the
'language' statement, and the variables in-scope at that time. The mechanism
build into C# then takes care of scope updates back and forth between the two
languages.
FB
Yahoo! Groups Links

[Andrew Davey]

Composability is key here.
You need to have have one syntax that utilizes composition to create
structured complexity.

Post by Jay Chapman
Frans,
While this is an option, I don't really like this.
It is mixing too much in the same file. Even if this is compiler checked,
you still have the problem of dealing with two syntaxes at the same time.
It is confusing.
Keeping the same syntax for everything seems more natural to me.

[Frans Bouma]

Post by Andrew Davey
Composability is key here.
You need to have have one syntax that utilizes composition to create
structured complexity.

Why? All you do is utilize another DSL to specify some of the intent
you want to describe in the method because that other DSL is allowing you
express your intent way better than C# can do, in _THAT_ context.

So the reader of the method can see in 1 method, all code is there,
what the intent of the method is, and how the method works. Seems to me way
better than to cram a DSL into C# in such a way that THAT code is suddenly not
OO oriented but set/sequence oriented or functional oriented. Or worse, that
you have to learn the transition rules from C# statements to extension methods
:X

FB

Post by Andrew Davey

Post by Jay Chapman
Frans,
While this is an option, I don't really like this.
It is mixing too much in the same file. Even if this is compiler

checked,

Post by Jay Chapman
you still have the problem of dealing with two syntaxes at the same

time.

Post by Jay Chapman
It is confusing.
Keeping the same syntax for everything seems more natural to me.

Yahoo! Groups Links