[Mono-dev] gmcs and The Future

[russell.kay at realtimeworlds.com]

Could we please get a __forceinline for the compiler allowing us to make
decisions at compile time to help us with optimisation.

I know that the long term and "correct" answer is to put this sort of
thing in the Jit but in the short term can we please be treated like
grownups and get some way of telling the compiler that this property or
method really really should be inlined.

I would even go for adding an attribute to functions where I want
everything to be inlined inside i.e.

[InlineEverything(MyNamespace)]
Void Foo()
{
	MyClass a = new MyClass();
	MyClass b = new MyClass();
	MyClass c = a + b;
	Console.WriteLine( "C = {0}", c.ToString() );
}

This would inline the constructor for MyClass, the operator+ for MyClass
and the ToString, but leave intact the call to Console.WriteLine.

And to go one step further, control over the level of inlining would be
good to, i.e. default level is 1 so only the immediate function would be
inlined, 2 would inline up to 2 calls deep, -1 would inline everything.

This would greatly enhance optimising of things like Maths intensive
operations

Regards

Russell

-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Scott
Peterson
Sent: 04 February 2009 09:57
To: mono-devel-list at lists.ximian.com
Subject: [Mono-dev] gmcs and The Future

Generic type variance has landed in gmcs SVN [1]. This is a C# 4
feature. It can be enabled by passing -langversion:future. While type
variance is cool, I want to talk about -langversion:future. I see this
as being a sentinel langversion for features as yet unreleased by
Microsoft. Those features could be announced additions to the language
(as with generic type variance, or the "dynamic" keyword) but they
need not be. Mcs has done an excellent job of tracking the official C#
language, and it will continue to do so, but the Mono project has a
world-class compiler entirely at its disposal. We need not confine
ourselves to the blessed specs of Microsoft or Ecma. We could "trick
out" C#, indulging in sugars of our own device, so long as we keep our
creations in -langversion:future. Those projects which are willing to
sacrifice compatibility with csc in order to partake of our forbidden
fruit can write code in this New C#. This C#++. This
-langversion:future.

To be clear, I am not advocating VM changes. Anything to come out of
this compiler would remain binary-compatible with the .NET runtime.
Language features and APIs only. I have loads of ideas - I actually
keep a list where I jot down every language feature idea I come up
with - but I want to hear from the list. Do you like the idea? Do you
have concerns? Do you have a language feature you've always wanted?

I will start the ball rolling with a simple feature:

Problem: While the 'typeof' keyword is very convenient for getting
Type objects, it is much more difficult to get any other kind of
reflection data. For example, to get a MethodInfo object, one usually
does:

> static readonly MethodInfo methodInfo = typeof(Foo).GetMethod("Bar",
new Type [] { typeof(string), typeof(int) });

Not only is this an eyesore, but we have a method name in a string. If
I refactor that method, I will have to remember to update this code as
well.

Solution: The "reflect" keyword. This is like the typeof keyword, but
you can use it to reflect upon anything.

Examples:

> Type fooType = reflect(Foo);
> MethodInfo barMethod1 = reflect(Foo.Bar(string));
> MethodInfo barMethod2 = reflect(Foo.Bar(string,int));
> FieldInfo batField = reflect(Foo.bat);
> PropertyInfo bazProperty = reflect(Foo.Baz);
> ConstructorInfo fooCtor1 = reflect(new Foo());
> ConstructorInfo fooCtor2 = reflect(new Foo(string));
> ConstructorInfo staticFooCtor = reflect(static Foo());
> EventInfo fooEvent = reflect(Foo.Changed);

And if I refactor any of these members or types, my IDE will update
this code as well.

Your turn.

- scottp

[1] http://themonkeysgrinder.blogspot.com/2009/02/c-4-is-now.html
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

____________________________________________________________________
This email has been scanned by the MessageLabs Email Security System

____________________________________________________________________
DISCLAIMER

This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd.

 

Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ.