Tech Off Thread

131 posts

Ideas for C# 5.0

Back to Forum: Tech Off
  • User profile image
    exoteric

    Design by Contract syntax also comes with some very useful keywords such as old; in Eiffel the return value always has a name, called Result (this, by the way, encourages structured programming where control flow is expressed with if-then-else, making control flow visually clear via scoping), so there it is easy to refer to it when forming a post-condition; e.g.

     

        ensures

            positive: result > 0

     

    One simple function I've found extremely blissful for contract programming is implies, defined as

     

        implies a b = not a or b

     

    As an example, transitivity expressed with implication/entailment:

     

        (a > b and b > c) implies (a > c)

     

    It's a bit of a shame we can use neither the natural words for logical operators, nor their symbolic representatives.

     

    I may sound like a broken record, always praising Eiffel but there's also much to be loved about C#. Iterators, lamda expressions and extension methods for example. It doesn't hurt to look around though. Contracts are a way to specify, constrain and verify the state machines we are surrounded with.

  • User profile image
    Ion Todirel

    exoteric said:

    Design by Contract syntax also comes with some very useful keywords such as old; in Eiffel the return value always has a name, called Result (this, by the way, encourages structured programming where control flow is expressed with if-then-else, making control flow visually clear via scoping), so there it is easy to refer to it when forming a post-condition; e.g.

     

        ensures

            positive: result > 0

     

    One simple function I've found extremely blissful for contract programming is implies, defined as

     

        implies a b = not a or b

     

    As an example, transitivity expressed with implication/entailment:

     

        (a > b and b > c) implies (a > c)

     

    It's a bit of a shame we can use neither the natural words for logical operators, nor their symbolic representatives.

     

    I may sound like a broken record, always praising Eiffel but there's also much to be loved about C#. Iterators, lamda expressions and extension methods for example. It doesn't hurt to look around though. Contracts are a way to specify, constrain and verify the state machines we are surrounded with.

    I like the idea! But that doesn't fit with C# 's style, you want this:

     

    ensures (result > 0); // The result is within spec limits

    ensures immutable someLocalOrClassLevelMemebr; // The state doesn't change during method execution, this may be useful in multithreaded scenarios

     

    require (arg1 > 0 && arg2 < 10);

    require (arg1 /*string*/); // The compiler will emit code depending on the inputs, e.g. for string it would emit !String.IsNullOrWhitespace(arg1)

     

    Just dreaming. This probably never will get into C#.

  • User profile image
    exoteric

    Ion Todirel said:
    exoteric said:
    *snip*

    I like the idea! But that doesn't fit with C# 's style, you want this:

     

    ensures (result > 0); // The result is within spec limits

    ensures immutable someLocalOrClassLevelMemebr; // The state doesn't change during method execution, this may be useful in multithreaded scenarios

     

    require (arg1 > 0 && arg2 < 10);

    require (arg1 /*string*/); // The compiler will emit code depending on the inputs, e.g. for string it would emit !String.IsNullOrWhitespace(arg1)

     

    Just dreaming. This probably never will get into C#.

    Agreed; I just wrote it like that to show how nicely readable it is. I would prefer non-nullness at the type level (string! arg1) and stronger conditions in the contract (requires !arg1.IsWhitespace()).

  • User profile image
    exoteric

    The new Rx video made me think about deferred execution in LINQ.

     

    Bart mentions the Sum method which exits from the IEnumerable monad. As when you evaluate this expression

     

    Enumerable.Range(0, 10).Sum()

     

    the result is 45 but you have left the monad.

     

    Staying alive, in the monad, one might imagine this simple code

     

    Enumerable.Range(0, 10).Sum2()

     

    driven by these extension methods

     

    public static IEnumerable<T> Reduce<S, T>(this IEnumerable<S> source, Func<IEnumerable<S>, T> transform)
    {
        yield return transform(source);
    }
    public static IEnumerable<int> Sum2(this IEnumerable<int> source)
    {
        return source.Reduce(xs => xs.Sum());
    }
    

     

    Now looking at this code I cannot help but wonder whether the Sum2 method should not be implementable as

     

    public static IEnumerable<int> Sum2(this IEnumerable<int> source)
    {
        return source.Reduce(Sum);
    }
    

     

    or if that's too much magic. It should know the type of source and therefore also know about the extension methods available. See that one matches and resolve to use that.

  • User profile image
    Masoud

    Compile to native code.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.