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
    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.

Conversation locked

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