Re: [Mono-dev] gmcs and The Future

This sounds like the macro system discussed here : http://cheddar.wik.is/Macro_system. Anyway, better to brainstorm on the wiki now than the mailing list imho ;-) . -- Jérémie Laval jeremie.la...@gmail.com http://garuma.wordpress.com 2009/2/17 Stefan Noack > Hi, > > > >> Anyway, am not complet

Re: [Mono-dev] gmcs and The Future

Hi, > Anyway, am not completely against the idea, I already wrote about how > I'd like to have a more extensible mcs, but in the current state of > affairs, again, I'd very cautious. > > Some time ago, I had the idea of an extensible compiler. One with kind of a plugin system. Or even better, a

Re: [Mono-dev] gmcs and The Future

Sounds to me like you should suggest that on the wiki ;) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] gmcs and The Future

Doesn't it make more sense to add something like a macro system (see Boo, Nemerle, Scheme, ...) ? That way you would only change the compiler once (for the macro resolution) and then you can extend the language at your wish in external libraries (as with Mono.Rocks). The three main advantages I se

Re: [Mono-dev] gmcs and The Future

This should get things started: http://cheddar.wik.is/ We can move hosts later it we want. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] gmcs and The Future

Scott Peterson wrote: > Any word on a wiki? If we don't use the mono-project one, on http://wik.is/ you can create one easily, and it turns out it's using Deki (powered by Mono) ;) Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@li

Re: [Mono-dev] gmcs and The Future

Any word on a wiki? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] gmcs and The Future

gt; Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz >> Subject: Re: [Mono-dev] gmcs and The Future >> >> On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain wrote: >> >> So I'm not expecting the C# compiler to output anything other than >> IL &

Re: [Mono-dev] gmcs and The Future

ent: 04 February 2009 16:14 > To: Jb Evain > Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz > Subject: Re: [Mono-dev] gmcs and The Future > > On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain wrote: > >> So I'm not expecting the C# compiler to output anyth

Re: [Mono-dev] gmcs and The Future

Whatever the format of the forum, I would like it to be easy for anyone to participate. A wiki fits the bill, but it might be best to keep this program separate from the primary Mono wiki so that account permissions don't become conflated. What does someone in charge of the Mono site/wiki think (Mi

Re: [Mono-dev] gmcs and The Future

> I admit I haven't tried it in a while - my workarounds date back to > mono 1.2.6 or so. Was it added recently? That is a few years old. You might want to upgrade. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximia

Re: [Mono-dev] gmcs and The Future

On Thu, Feb 5, 2009 at 6:49 PM, Miguel de Icaza wrote: >> And my own idea: add support for "# line" style preprocessor tags, as >> produced by cpp. I have a few programs that need to run through cpp >> before compiling, and the lack of "# line" support means that (unless >> I'm almost impossibly

Re: [Mono-dev] gmcs and The Future

> And my own idea: add support for "# line" style preprocessor tags, as > produced by cpp. I have a few programs that need to run through cpp > before compiling, and the lack of "# line" support means that (unless > I'm almost impossibly careful and do some strange tricks) the line > numbers repo

Re: [Mono-dev] gmcs and The Future

Might another language like Boo be a better place for the non-standard future features?   If in C#, a different flag from future should be used to diffentuate nonstandard from true future stuff (minor implmentation detail)   This is not a vote or even a suggestion, just some random thoughts.   D

Re: [Mono-dev] gmcs and The Future

On Thu, 2009-02-05 at 18:54 +, Marek Safar wrote: > Here is slightly simplified version > > [Conditional("DEBUG")] > static void Assert (Expression> e) > { > var d = e.Compile (); > if (!d ()) { > Console.WriteLine (((LambdaExpression)e).Body.ToString ()

Re: [Mono-dev] gmcs and The Future

Hi, > On Thu, 2009-02-05 at 12:10 -0500, Avery Pennarun wrote: > >> (The reason I use cpp, incidentally, is so I can implement C-style >> assert() and check() macros that actually print the condition being >> tested as part of the assertion message. There seems to be no other >> way to do this

Re: [Mono-dev] gmcs and The Future

On Thu, 2009-02-05 at 12:10 -0500, Avery Pennarun wrote: > (The reason I use cpp, incidentally, is so I can implement C-style > assert() and check() macros that actually print the condition being > tested as part of the assertion message. There seems to be no other > way to do this in C#, which is

Re: [Mono-dev] gmcs and The Future

On Thu, Feb 5, 2009 at 12:19 PM, Jonathan Pryor wrote: > On Thu, 2009-02-05 at 12:10 -0500, Avery Pennarun wrote: >> (The reason I use cpp, incidentally, is so I can implement C-style >> assert() and check() macros that actually print the condition being >> tested as part of the assertion message.

Re: [Mono-dev] gmcs and The Future

On Thu, Feb 5, 2009 at 8:54 AM, Scott Peterson wrote: > So what is (are) the killer feature(s)? I would be interested in > organizing a forum for proposing and discussing language features. If > for no other reason than as an excuse to talk about language design > with smart people. This forum cou

Re: [Mono-dev] gmcs and The Future

On Thu, Feb 5, 2009 at 2:54 PM, Scott Peterson wrote: > If other people are interested in geeking out over language features, > I suggest we get ourselves a little organized. We could hold forth > right here, on this list, or we could create our own Google Group. > Bugzilla is maybe another option

Re: [Mono-dev] gmcs and The Future

Scott Peterson wrote: > It sounds like the general reaction is cautiously favorable. New > language features would be nice, but they would require a commitment > to maintenance. As I see it, whether we are willing to invest ongoing > effort in a feature depends on the strength of the feature. A > s

Re: [Mono-dev] gmcs and The Future

It sounds like the general reaction is cautiously favorable. New language features would be nice, but they would require a commitment to maintenance. As I see it, whether we are willing to invest ongoing effort in a feature depends on the strength of the feature. A sufficiently "killer" feature wil

Re: [Mono-dev] gmcs and The Future

Hi, Thank you for tracking this down. Could you fill a bug report at http://www.mono-project.com/Bugs so we can address the issue. Marek > I try to use these voodoo keywords and have a small report: > > 1) gmcs currently supports only __arglist keyword, but sometimes > generates incorrect CIL.

Re: [Mono-dev] gmcs and The Future

I try to use these voodoo keywords and have a small report: 1) gmcs currently supports only __arglist keyword, but sometimes generates incorrect CIL. That code works while compiling with csc.exe, but leads to segmentation fault after gmsc (I try it on Mac OS 10.5, Mono 2.2 ): == CO

Re: [Mono-dev] gmcs and The Future

Hello, > > gmcs Compiler already not 100% compatible with csc - __arglist > > , > > __refvalue > > , > > __makeref > >

Re: [Mono-dev] gmcs and The Future

Hello, > 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. The problem is not only one of making the code conditional, but certain features come with a heavy ma

Re: [Mono-dev] gmcs and The Future

gt; To: Jb Evain > Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz > Subject: Re: [Mono-dev] gmcs and The Future > > On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain wrote: > >> So I'm not expecting the C# compiler to output anything other than > IL &g

Re: [Mono-dev] gmcs and The Future

February 2009 16:14 To: Jb Evain Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain wrote: >> So I'm not expecting the C# compiler to output anything other than IL >> but j

Re: [Mono-dev] gmcs and The Future

16:10 To: Russell Kay Cc: sc...@ssblack.co.nz; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] gmcs and The Future Hey, On 2/4/09, russell@realtimeworlds.com wrote: > So I'm not expecting the C# compiler to output anything other than IL > but just eliminate the calli

Re: [Mono-dev] gmcs and The Future

On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain wrote: >> So I'm not expecting the C# compiler to output anything other than IL >> but just eliminate the calling overhead and not relying on the JIT to do >> the inlining. > > That's just not possible for a large majority of the cases, as it > would cau

Re: [Mono-dev] gmcs and The Future

Hey, On 2/4/09, russell@realtimeworlds.com wrote: > So I'm not expecting the C# compiler to output anything other than IL > but just eliminate the calling overhead and not relying on the JIT to do > the inlining. That's just not possible for a large majority of the cases, as it would caus

Re: [Mono-dev] gmcs and The Future

ebruary 2009 15:49 To: Russell Kay Cc: sc...@ssblack.co.nz; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 3:35 PM, wrote: > Could we please get a __forceinline for the compiler allowing us to make > decisions at compile time to help

Re: [Mono-dev] gmcs and The Future

On Wed, Feb 4, 2009 at 3:35 PM, wrote: > 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 ple

Re: [Mono-dev] gmcs and The Future

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 t

Re: [Mono-dev] gmcs and The Future

On Wed, 2009-02-04 at 22:56 +1300, Scott Peterson wrote: > 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 MethodI

Re: [Mono-dev] gmcs and The Future

Hi, > > gmcs Compiler already not 100% compatible with csc - __arglist > , > __refvalue > , > __makeref >

Re: [Mono-dev] gmcs and The Future

Hi, gmcs Compiler already not 100% compatible with csc - __arglist, __refvalue , __makeref not supported ( it

Re: [Mono-dev] gmcs and The Future

Hey, On 2/4/09, Scott Peterson wrote: > 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. W

Re: [Mono-dev] gmcs and The Future

Hi, >> 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. > > Solut

Re: [Mono-dev] gmcs and The Future

Il giorno mer, 04/02/2009 alle 22.56 +1300, Scott Peterson ha scritto: >Da: > Scott Peterson > >Rispondi-a: > sc...@ssblack.co.nz > A: > mono-devel-list@lists.ximian.com > Oggetto: