Tech Off Thread

131 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Ideas for C# 5.0

Back to Forum: Tech Off
  • User profile image
    ramooon

    exoteric said:
    ramooon said:
    *snip*

    Interesting idea. It looks like a more complete/holistic/uniform approach to type extension, kudos. It is reminiscent of partial classes, except not exclusive for classes. Now I wonder: if you have a partial class A and another partial class B in two distinct namespaces and say you have a simple console program and the console program imports partial class A; will partial class B then also implicitly be used or only if you explicitly import that namespace? In the latter case the partial class construct looks pretty darned close to what you want, except partial to classes, so to speak. Hindsight is great.

     

    As for public/private, private is probably a sign of imperativeness because in an imperative setting you want to be careful about who's modifying your object using your special helper methods whereas when constructing new objects it's not really that big of an issue and this default looks wrong for a mostly-declarative world (or functional if you will). This will also save lots of code having to explicitly declare public all over. Well... too late for C#, that ship sailed long ago.

    Well, I'm not sure to understand what you said but the extensions would be available only if you import the right namespaces (ie. exactly the same behavior as the current syntax). The main benefit over partial classes is that it does not require  the 'partial' keyword at the declaration site and it is not limited to classes therefore basically everything is extensible by default Smiley What I didn't realize is that the partial keyword would become totally useless o_O ... right ?

     

    BTW Here's what I would like to see in future C# releases:

    - Contracts: Spec# contracts built-in the language (with the bang non-null operator)

    - Metaprogramming: a way to have user-defined keywords and syntax (ie.  a 'keyword' keyword and so on)

    - Immutablilty and Purity keywords

    - Some more declarative and lazy stuffs -- I absolutely love LINQ

     

    Another idea, but IDE specific:

    I wonder why although the IDE is now WPF based, it is still limited to classic characters ?

    For example if I type something like "-->" I would like the IDE to replace it with a real arrow.

    This would allow custom symbols to be used in modern languages...

     

  • User profile image
    exoteric

    ramooon said:
    exoteric said:
    *snip*

    Well, I'm not sure to understand what you said but the extensions would be available only if you import the right namespaces (ie. exactly the same behavior as the current syntax). The main benefit over partial classes is that it does not require  the 'partial' keyword at the declaration site and it is not limited to classes therefore basically everything is extensible by default Smiley What I didn't realize is that the partial keyword would become totally useless o_O ... right ?

     

    BTW Here's what I would like to see in future C# releases:

    - Contracts: Spec# contracts built-in the language (with the bang non-null operator)

    - Metaprogramming: a way to have user-defined keywords and syntax (ie.  a 'keyword' keyword and so on)

    - Immutablilty and Purity keywords

    - Some more declarative and lazy stuffs -- I absolutely love LINQ

     

    Another idea, but IDE specific:

    I wonder why although the IDE is now WPF based, it is still limited to classic characters ?

    For example if I type something like "-->" I would like the IDE to replace it with a real arrow.

    This would allow custom symbols to be used in modern languages...

     

    I'm not sure but on the face of it, it looks like your type extension idea would basically generalize and unite both partial classes and extension methods. Thumbs up. There may be gotchas but on the face of it, it looks very compelling.

  • User profile image
    GrantB

    exoteric said:
    GrantB said:
    *snip*

    There doesn't appear to be anything special about Go's notion of type equivalence beyond structural typing. C# has dynamic now, not sure the good folks want to go beyond that because dynamic allows you to apply the same programming pattern but in a less type-safe way. Another idea is to be able to coerce a type that structurally matches a different type into that type - a sort of structural cast.

     

    Love the idea behind persistent data structures.

    Would there be any value in this?

     

    void f(dynamic IFoo arg)
    {
    	arg.foo();
    }

     

    Where

    (1) arg is of type dynamic

    (2) the compiler warns when arg is used in a way not compatible with IFoo

    (3) the compiler warns when an actual parameter does not implement method signatures isomorphic with IFoo

    (4) the IDE provide arg with IFoo intellisense

  • User profile image
    Ion Todirel

    GrantB said:
    exoteric said:
    *snip*

    Would there be any value in this?

     

    void f(dynamic IFoo arg)
    {
    	arg.foo();
    }

     

    Where

    (1) arg is of type dynamic

    (2) the compiler warns when arg is used in a way not compatible with IFoo

    (3) the compiler warns when an actual parameter does not implement method signatures isomorphic with IFoo

    (4) the IDE provide arg with IFoo intellisense

    generics?

  • User profile image
    exoteric

    Ion Todirel said:
    GrantB said:
    *snip*

    generics?

    No because that requires explicit association to IFoo whereas here we just need arg to match IFoo.

  • User profile image
    exoteric

    Exceptions as part of type-signatures

     

    int Div(int n, int d) throws DivisionByZeroException { if (d == 0) throw new DivisionByZeroException(); else return n / d; }

     

    Now if a function of Div does not catch DivisionByZeroException, then it must declare that it throws it. Se we can always see in the function type if it is exception safe; that is, responsibility is clearly defined.

  • User profile image
    stevo_

    exoteric said:

    Exceptions as part of type-signatures

     

    int Div(int n, int d) throws DivisionByZeroException { if (d == 0) throw new DivisionByZeroException(); else return n / d; }

     

    Now if a function of Div does not catch DivisionByZeroException, then it must declare that it throws it. Se we can always see in the function type if it is exception safe; that is, responsibility is clearly defined.

    I would argue that the compiler should just infer the potential exceptions vs java style manual decl.. plus code contracts go some way towards this, it would be nice to have more static analysis (including more 'bug be here' than just 'this won't compile') I'm sure the c# team would agree but of course its a lot easier to say it than make it happen.

  • User profile image
    Sven Groot

    exoteric said:

    Exceptions as part of type-signatures

     

    int Div(int n, int d) throws DivisionByZeroException { if (d == 0) throw new DivisionByZeroException(); else return n / d; }

     

    Now if a function of Div does not catch DivisionByZeroException, then it must declare that it throws it. Se we can always see in the function type if it is exception safe; that is, responsibility is clearly defined.

    That is something they deliberately decided not to do when designing .Net.

     

    It's also impossible to add it now. Exception specifications only work if every single function uses them. If you allow interoperability with old code that doesn't have exception specifications, you'd need to have some way of dealing with situations where a method throws an exception which is not caught and not allowed by the specification of a method further up the chain. You'd get the same mess as in C++.

  • User profile image
    exoteric

    Sven Groot said:
    exoteric said:
    *snip*

    That is something they deliberately decided not to do when designing .Net.

     

    It's also impossible to add it now. Exception specifications only work if every single function uses them. If you allow interoperability with old code that doesn't have exception specifications, you'd need to have some way of dealing with situations where a method throws an exception which is not caught and not allowed by the specification of a method further up the chain. You'd get the same mess as in C++.

    Yes, there'd had to be a strict and non-strict mode. You'd have to have your programs opt-in to it.

  • User profile image
    exoteric

    stevo_ said:
    exoteric said:
    *snip*

    I would argue that the compiler should just infer the potential exceptions vs java style manual decl.. plus code contracts go some way towards this, it would be nice to have more static analysis (including more 'bug be here' than just 'this won't compile') I'm sure the c# team would agree but of course its a lot easier to say it than make it happen.

    I agree we should have more help from VS with this. There's really zero help here: at least it should be easy to say: these exceptions are not caught in the function you call, consider catching these, and of course refactoring in exception-safety by right-clicking on a function call and having it automatically catch every uncaught case; where static analysis proves what is not caught.

     

    On the other hand, there's probably also some benefits to expressing this explicitly. It may have been a deliberate choice to not have checked exceptions but maybe not the right choice.

  • User profile image
    exoteric

    // deleted, wrong thread

  • User profile image
    W3bbo

    exoteric said:

    // deleted, wrong thread

    It might have already been suggested, but I'd like to see base2 literals, which would be useful for writing Flags enums definitions without needing to think too much:

     

    I also want to see VC-style documentation inference. In VC it gets the comments on the same line as #defines and uses that, but in C# you have to use XML comments, which take up too much space and hamper visiblity.

     

    So this:

     

    [Flags]

    public enum Whatever {

        /// <summary>Foo Fighters</summary>

        Foo = 0x10,

        /// <summary>So a blonde walks into a bar...</summary>

        Bar = 0x11

    }

     

    Becomes:

     

    [Flags]

    public enum Whatever {

        Foo = 0b1010, // Foo fighters

        Bar = 0b1011 // So a blond walks into a bar...

    }

  • User profile image
    exoteric

    One might consider the Eiffel memoization support

     

    public once int Total
    {
        get { ... }
    }

     

    On the other hand, maybe its entirely possible to implement this with attributes

     

    [Memoize]
    public int Total
    {
        get { ... }
    }

     

    Also, towards a more immutable world, is the current object construction syntax/semantics adequate? If you recursively initialize an object by setting properties, you have nice syntax a la JSon but the object is left open in a mutable state when you are done (or?). In a more immutable world one would then have to use very messy constructors, essentially with one parameter for every readonly/const member of a class that needs initialization. Even with named parameters this is not that nice; or maybe its good enough.

     

    Also, how about auto-implemented properties and immutability. Is it good enough with private set and public get? Should you be able to set a hint that a property be readonly, i.e. that it is only settable at construction time? e.g.

     

    public int Total
    {
        get;
        set once;
    }

     

    Or should the compiler just infer this and apply any benefits yielded by analysis (e.g. class verifiably supports imutability post-construction, even if not explicitly so). Or should there be a keyword a la

     

    public readonly class Person
    {
        public string Name { get; set; } // settable, but only once, at construction time
        public uint Age { get; set; }
    }

     

    In some ways, just having readonly fields almost looks better

     

    public class Person
    {
        public static Person Parse(IEnumerable<byte> data)
        {
            return new Person()
            {
                Name = data.Take(20).ToAscii();
            }
        }
        public readonly string Name;
    }
    

     

    But that's not legal C#.

     

    Some food for thought.

  • User profile image
    kaveh.​shahbazian@​gmail.com

    I would like many features of Scala could be incorporated into C#. As that does not going to happen, I have my reduced wish list (with forgotten items, since I'm now somwhow dissapointed with C# road map - that's me).

     

    1 - Parameter-Level Interface Implementation; For example:

    class Person
    {
        public string Name { get; set; }
        public int Age { get; }
    }
    interface IPersonata
    {
        string Name { get; }
        int Age { get; }
    }
    class SomeTasks
    {
        // ...
        void Function(static IPersonata p) { /* ... */ }
        // ...
        void AnotherFunction(Person p)
        {
            // ...
            Function(p);
            // ...
        }
    }

    Should work; since Person satisfies IPersonata "statically". This is something like Google Go languages does. If we use dynamic instead of static; then it should generate necessary parts at runtime.

     

    2 - Mixins (like Scala's Mixins); which in turn could lead to some statically typed meta-programming (well; It "could"; yet I am not sure how viable are these things in C#'s type system *).

     

    3 - Templating generics themselves; at least as type parameters, in interfaces:

    interface ITemplateBuilder<T><a>
    {
         T<a> CreateInstance(a arg);
    }

     

    4 - Stronger type inferance (*).

     

    5 - XAML everywhere! Yes! XAML could be a perfect replacement for macros in C#; and it's legal even for macro-hater C# folks (and some designers which I have not their eagle-eye view for sure; yet I like statically syntatic extension tools)! XAML provides a proper blending of aspects, services and data manipulation facilities.

     

    I have successfully implemented a kd tree (in fact a 2d tree!) for solving a GIS nearest neighbor finding algorithm and enjoyed it a lot; and it is really performant.

     

    But; the point that language designers should have in calculation more and more (as our problems get more complex and need quicker reactions):

     

    A programming language for sure consums time to bend the programmer's mind to it's concept. At one point this "bending time" will be costy enough for being abandoned by industry.

     

    One good job that Microsoft did; is releasing F#. Because if they intend to keep C# the way it is; they should leverage abstraction levels as new languages. F# is a wonderful language; yet a Scala blend (Maybe G# since G has one more angle than C!) could help more; since this "syntax" thing - and { } - really matters.

  • User profile image
    exoteric

    kaveh.shahbazian@gmail.com said:

    I would like many features of Scala could be incorporated into C#. As that does not going to happen, I have my reduced wish list (with forgotten items, since I'm now somwhow dissapointed with C# road map - that's me).

     

    1 - Parameter-Level Interface Implementation; For example:

    class Person
    {
        public string Name { get; set; }
        public int Age { get; }
    }
    interface IPersonata
    {
        string Name { get; }
        int Age { get; }
    }
    class SomeTasks
    {
        // ...
        void Function(static IPersonata p) { /* ... */ }
        // ...
        void AnotherFunction(Person p)
        {
            // ...
            Function(p);
            // ...
        }
    }

    Should work; since Person satisfies IPersonata "statically". This is something like Google Go languages does. If we use dynamic instead of static; then it should generate necessary parts at runtime.

     

    2 - Mixins (like Scala's Mixins); which in turn could lead to some statically typed meta-programming (well; It "could"; yet I am not sure how viable are these things in C#'s type system *).

     

    3 - Templating generics themselves; at least as type parameters, in interfaces:

    interface ITemplateBuilder<T><a>
    {
         T<a> CreateInstance(a arg);
    }

     

    4 - Stronger type inferance (*).

     

    5 - XAML everywhere! Yes! XAML could be a perfect replacement for macros in C#; and it's legal even for macro-hater C# folks (and some designers which I have not their eagle-eye view for sure; yet I like statically syntatic extension tools)! XAML provides a proper blending of aspects, services and data manipulation facilities.

     

    I have successfully implemented a kd tree (in fact a 2d tree!) for solving a GIS nearest neighbor finding algorithm and enjoyed it a lot; and it is really performant.

     

    But; the point that language designers should have in calculation more and more (as our problems get more complex and need quicker reactions):

     

    A programming language for sure consums time to bend the programmer's mind to it's concept. At one point this "bending time" will be costy enough for being abandoned by industry.

     

    One good job that Microsoft did; is releasing F#. Because if they intend to keep C# the way it is; they should leverage abstraction levels as new languages. F# is a wonderful language; yet a Scala blend (Maybe G# since G has one more angle than C!) could help more; since this "syntax" thing - and { } - really matters.

    Scala was designed from the ground up with an object-functional theory in mind; C# is evolving towards functional style (with LINQ in particular) but even if we want C# to evolve I don't see C# ever becomming as smooth as Scala in this regard; it simply wasn't designed from the outset with this philosophy in mind.

     

    On the other hand it's probably not completely unreasonable to say that Microsoft wanted the equivalent of Java, fixing its inherent mistakes and improving it in various ways and then grew the idea further into an infrastructure for "poly-linguistic execution" although essentially founded on C# semantics (feel free to correct me.)

     

    This "Parameter-Level Interface Implementation" sounds to me like structural typing. That is indeed very desirable in some cases although you can emulate it with C# 4.0 dynamics - but I imagine loosing a lot of efficiency along the way.

     

    It would probably be more desirable to have a higher-kinded type system a la Haskell (higher-order generics or higher-order parametric polymorphism?)

     

    http://en.wikipedia.org/wiki/Type_polymorphism

     

    There has been some rumours that Microsoft is working on one more language. I believe Joe Duffy has been involved in this and maybe Erik Meijer as well. It's probably going to be pretty hard to beat Scala in generality and elegance but I remember a video with Joe Duffy and Erik Meijer discussing Linear Type Systems as a means to control effects within a concurrent world - or something to that effect. Maybe we can get an update some time on the current thinking within the company of what features are being thought of next.

     

    And of course we still have C# 5.0 on the horizon (and C# 4.0 is still not quite out of its eggshell yet.) I'm surprised you are disappointed at the C# roadmap because I haven't seen any roadmap so maybe you can point me to it - please!

     

    Still, functional programming has arrived in C# and its best realized in LINQ which is still evolving, at least on the library level. Rx is the latest and greatest example. So its power and impact is still unfolding.

     

    Smiley

  • User profile image
    kaveh.​shahbazian@​gmail.com

    exoteric said:
    kaveh.shahbazian@gmail.com said:
    *snip*

    Scala was designed from the ground up with an object-functional theory in mind; C# is evolving towards functional style (with LINQ in particular) but even if we want C# to evolve I don't see C# ever becomming as smooth as Scala in this regard; it simply wasn't designed from the outset with this philosophy in mind.

     

    On the other hand it's probably not completely unreasonable to say that Microsoft wanted the equivalent of Java, fixing its inherent mistakes and improving it in various ways and then grew the idea further into an infrastructure for "poly-linguistic execution" although essentially founded on C# semantics (feel free to correct me.)

     

    This "Parameter-Level Interface Implementation" sounds to me like structural typing. That is indeed very desirable in some cases although you can emulate it with C# 4.0 dynamics - but I imagine loosing a lot of efficiency along the way.

     

    It would probably be more desirable to have a higher-kinded type system a la Haskell (higher-order generics or higher-order parametric polymorphism?)

     

    http://en.wikipedia.org/wiki/Type_polymorphism

     

    There has been some rumours that Microsoft is working on one more language. I believe Joe Duffy has been involved in this and maybe Erik Meijer as well. It's probably going to be pretty hard to beat Scala in generality and elegance but I remember a video with Joe Duffy and Erik Meijer discussing Linear Type Systems as a means to control effects within a concurrent world - or something to that effect. Maybe we can get an update some time on the current thinking within the company of what features are being thought of next.

     

    And of course we still have C# 5.0 on the horizon (and C# 4.0 is still not quite out of its eggshell yet.) I'm surprised you are disappointed at the C# roadmap because I haven't seen any roadmap so maybe you can point me to it - please!

     

    Still, functional programming has arrived in C# and its best realized in LINQ which is still evolving, at least on the library level. Rx is the latest and greatest example. So its power and impact is still unfolding.

     

    Smiley

    @exoteric  
    Thanks for your time and your informative and precise reply.

    i.
    First on my disappointment about C# roadmap: I always look into ways not only to separate subsystems; but also abstracting bunch of aspects among all layers. First tool I like it here is syntactic extension mechanism and meta-programming and the second one - which I enjoy it's presence at XAML (especially WPF) - is a neat and clean (I am not sure if this name is descriptive enough) "aspect oriented" programming model. In XAML you can think of providers, services that are presented through providers, (I did not see this anywhere else, so maybe I am wrong) a very well tailored and tailor-able implementation of prototype-based OO model, templating every “thing/aspect” even up to the sky, binding/plumbing/validating state and much more; and why I think it should be more than handy in a programming language? An example could be a common task: Logging! A huge noise scattered all around our code just to serve at different conceptual level (can you turn it off and on easily, safely, or remove it easily?)! After these long years no one stood up to tackle this and see this problem at language level (for sure there a Lisper out there who does not share my point of view). This is my first of first (!) and very valuable (conceptually at least) to me: C# as an abstraction layer "on .NET"; C# as a XSLT for aspects "into .NET" (90:00':00"). I thought .NET team and C# team bring us more of it (and if anybody listens hear: we need more in-depth essays of WPF and the "reason/philosophy" behind each bit of it to learn it more deeply).
    Second (to be honest this second still has more deeply affected me than that first; maybe because it happens recently) reason of my disappointment is Scala. I melted down when I saw it: How is this possible? Even possible? I though these are elegant dreams! They should not exist in the real world! The second reason was: I "believed" something like Scala is "impossible"! Of-course your description of Scala way and "logical/rational" (political?) decisions about C#; are complete. Yet Scala provides a neat and clean statically typed meta-programming and even syntax manipulating environment.

    Again XAML is a source of well landed ideas! I like it! (OK, OK!)

    ii.
    A long time ago I thought about this "Parameter-Level Interface Implementation" thing in a different way. It was like some sort of "something mimics something" one-liner. Exactly as you mentioned, this idea changed in my mind when I was playing with C# 4.0 dynamic to this "Parameter-Level Interface Implementation". It's cool (and maybe exceptionally really immediately useful!).

    iii.
    I have played a little with Haskell and have a (maybe not so exact) clue of higher-kinded type-system; yet I think that's hard to achieve in C# semantics. But at interface level we can do more compiler tricks easily (correct me please if I am wrong).

    iv.
    It would be very nice to have some sources about that language you have spoke of. Thanks

    v.
    I have not looked into Rx so maybe I am wrong but it seems Rx should co-exists with some immutability facilities (like even an attribute, bundled with a compiler trick) in the language itself. Without that many problems (troubles) will still continue to exist in our code (is it possible for us to have uniqueness typing in C# or even in .NET?). And what about continuations? Does Rx provide a facility to use that seamlessly in our code? I have read some essays (maybe) which described that a language with exceptions can provide a richer model for dispatching that languages with continuations (in simple that idea is using different exceptions to reach different places in code - as I remember). So theorically we have a good bit of it. But do we have it built-in (not blotted-on) the language?

    Regards

  • User profile image
    Zyrthofar

    I don't know about you, but I'd like inline assembly for time-critical sections of code.

  • User profile image
    W3bbo

    Zyrthofar said:

    I don't know about you, but I'd like inline assembly for time-critical sections of code.

    Inline assembly defeats the point of C# as a cross-platform language. Whilst assemblies support mixed-mode with both CIL and Native instructions it makes it impossible to verify the correctness of the code, it's meant for interop and not performance.

     

    If you're doing time-critical programming do it in C/C++ without any CLR involvement.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.