Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

kaveh.shahbazian@gmail.com

kaveh.shahbazian@gmail.com kaveh.​shahbazian@​gmail.com

Niner since 2005

  • C# 4.0: Meet the Design Team

    I have wrote a comment on another post "Eric Gunnerson - How do you design new features for C#?"; That's a long one!
    So if the team is going to consider wish lists; mine is here!
    Thanks!
  • Eric Gunnerson - How do you design new features for C#?

    Hi there and thanks to the team!

    If "What features would you like to see the C# team add?" is really mean what it is saying then this is my wish list:
    (I have implemented some of these in a library named Foop which is an alpha version)

    1 - Define new operators; i.e. an operator named &&&.
    2 - Define Generic operators; currently we can just overload the existing operators and if the operands are going to be Generic, they can only be of type of one of the Type Parameters of the container class.
    3 - The pipe operator (|) as in F#; which can be there if we have feature number 2.
    4 - Tuples; I have implemented some tuple data structures; but without compiler support, it needs to be implemented for any number of them!
    5 - Better type inference; For example for lambdas I wrote a static method 'infer' for that I be able to define Extension Methods on delegates or use them in Anonymous Types:
    new
    {
        Target = "XPC 10",
        Vel = ExSyntax.infer ((int a) =>
        {
            return a * 22.8;
        })
    };
    or
    ExSyntax.infer (() =>
    {
        return DateTime.Now.Second > 10;
    }).do_while_true (() =>
    {
        Console.WriteLine ("Updating Report...");
    });
    6 -
    Anonymous Types everywhere; which in fact is "good Type Inference" every where. I think as the members of Anonymous Types are the static members of the container class; so we can apply synchronization and security facilities easily (I know you are the best and you are doing your best; so the "I think" part is just about the point of view from where that I am).
    7 - Dynamic proxies; we can emit runtime types and cache them: declaring a new class that implements the target interface and has members of another type which is going to be have the interface (ducked!).
    8 - Generic Generic Types; So I can define a typed linked list like this:
    TyLList<A> {
        public A Value;
        public
    TyLList<?> Next;
    }
    9 - Named parameter calling for functions; for void F(int a, string b) calling it like F(b = "OK", a = 10)
    10 - Default values for parameters
    11 - Calling function with an Anonymous Type with members which are named after function arguments:
    For void F(int a, string b) calling F like F(new { b="OK", a=100});
    (We already have 9, 10 and 11 for attributes!)
    12 - Metaprogramming; (not IL weaving) which already have proof of concept projects like F# (Active Patterns and Typed Quoting ...)
    13 - An even very simple form of syntax extending; with 12 we will have enough of this
    14 - A #light syntax for C#; as we have in F#, which can be some form of indentation-based code layout (like in F#) with possibility yet to enclose code blocks in {}s.
    15 - Tagging types; which will provides us Class Cases, I have implemented for example Either<A,B>, some people implement this by declaring additional types like Left<A> and Right<B>; that is wrong! GADT are distingushed from the way that the object is constructed and the cases of the class in fact are different constructors which tag the object with different tags.
    16 - 'this' refers to the current object; If there be somthing like this_type it is hand full (GetType is a runtime thing but this_type i.e. can be passed to Generics)
    17 - Passing lambdas to attributes as parameter
    18 - Defining Execution Contracts; like 'Ensure' and 'Requies' and with 14, even a new step in compiling a method or something.
    19 - Capturing the values in the current execution context as a Name-Value dictionary; we have already the clousures and with 6, this would be very easy (this will provide us continuations).
    20 - An attribute like [AloneExecutionPath] for methods; which grants that the methos just have access to it's parameters, and have not access to any public or internal thing in any assembly written by user (we can use .NET class library(is this good?) and to the Anonymous Types defined inside the function and we can pass objects of those types)
    22 - Curry is necessary;
    21 - OK! OK! ...
    I was just looking into my codes and comming back here and write things! I close Visual Studio for now!
    Maybe this is another language! Smiley Yet I do not think so!

    Thanks all!


  • Brian Beckman: Don't fear the Monad

    brianbec wrote:
    Very nice, indeed, Kaveh!

    Thankyou! I have been more than happy by your comment!
    Just I'v discovered a bad thing in my code: using Closures! I discovered this when using a LINQ query against a set of objects (a library for handling directory tree of my html templates for some work and extracting their content and publishing via a HttpHandler). I have changed one of objects that was placed inside the where clause somewhere (in another business class - ofcourse that was a bug; but what if it wasn't?), and the resault was not what expected!
    So I write another method for combining two monads and getting a third one; named Transform (I do not know this name is proper. I am a "thin client" of Haskell and Monads!).
    It seems now a better solution for composing two (or more monads). It seems to me closures are a bad thing in this context, because they pass the boundries whitout any footprints.
    (Code is here.)
    Cheers!
  • Brian Beckman: Don't fear the Monad

    I have write a Monad thing in C#. This Monad has a private field that I have not access to, but I can change it! :O And that's the interesting thing about it Tongue Out. Once I have pushed a data into it; There is no way out of it. But I can still modify the data in the Monad. Firts let's look at the stuff:

    public class Monad<T> : IMonad<T>
    {
       private Monad (T inner) { this.__InnerHolder = inner; }
       private Monad () { }

       private readonly T __InnerHolder;
       private T Inner { get { return __InnerHolder; } }
       public static IMonad<TInner> Unit<TInner> (TInner inner) 
       {
    return new Monad<TInner> (inner); }

       public
    static Func<A, IMonad<R>> Lift<A, R> (Func<A, R> fun)
       {
          if (fun.IsNull ()) 
             
    throw new ArgumentNullException 
                (
    "fun", "'fun' can not be null.");
          return (a => Unit<R> (fun Angel));
       }

       public
    static IMonad<B> Bind<A, B> (IMonad<A> a, 
          
    Func<A, IMonad<B>> fun)
       {
          if (fun.IsNull ()) throw new ArgumentNullException ("fun", "'fun' can not be null.");
       return Unit<B> (fun (a.Monad.Inner).Monad.Inner);
       }

       #region
    IMonad<T> Members
       Monad<T> IMonad<T>.Monad
       {
          get { return this; }
       }
       #endregion
    }

    public
    static partial class MonadExtra
    {
       public static IMonad<TInner> Unit<TInner> (this TInner inner) 
       {
    return Monad<object>.Unit<TInner> (inner); }

       public
    static Func<A, IMonad<R>> Lift<A, R> (this Func<A, R> fun)
       {
          return Monad<object>.Lift<A, R> (fun);
       }

       public
    static IMonad<B> Bind<A, B> (this IMonad<A> a, 
          
    Func<A, IMonad<B>> fun)
       {
          return Monad<object>.Bind<A, B> (a, fun);
       }
    }

    public
    interface IMonad<T>
    {
       Monad<T> Monad { get; }
    }

    Now back to work. First I push a string into my Monad and I want, at the end to have byte collection in my Monad that represents the charachters of my string. How about this:

    var var1 = "ABCD...MONAD!"
       .Unit ()
       .Bind ((
    string s) => s.ToCharArray ().Unit ())
       .Bind (ca => (
    from c in ca select Convert.ToByte (c)).Unit ());

    What is the type of var1? It is IMonad<IEnumerable<byte>>. And you see another interesting aspects of Monad here: Composability! Here we have 3 type for the type variable of our Monad. But as long as we are IN the Monad we can compose any kind of computations.

    Now assume we have two Monads and we want to apply a function to the inner value of both monads. How can I pull out the values from these Monads to perform my function application? I can not pull out the inner part of monads. But i can still use their values in my computation by using closures! For example I have to Monads that contains numbers and I want to have the multipluy value of them:

    var ma = 10.Unit ();
    var mb = 20.Unit ();

    var
    mr = mb
       .Bind (x => ma.Bind (y => (x * y).ToString ().Unit ()));


    As you can see (actually as I can see! Because writing this code make me feel a lot better about Monads - as an Imperative programmer - yet there are a lot of improvements possible to my Monad set of utilities) anything that we do in normal imperative code is possible by using this Monad. What is the good part? You can not change the Monad anywhere out of the Monad. So actually the state of you whole program that is out of the Monad is untouched. Another thing is that the Monad is immutable. Every action on a Monad produce a new Monad of that kind.
    Consider a data structure that has Monads as members. You can not modify these members! Even if the data structure itself is not a Monad! See this little bit of it:

    var
    nv = new { a = 10.Unit (), b = 20.Unit () };
    var mnv = nv.Unit ();
    mnv = mnv
       .Bind (j =>
    new
                a = j.a.Bind (k => (k * 2).Unit ()), 
                b = j.b.Bind (k => (k * 2).Unit ()) }.Unit ());

    It was very interesting to me that by putting a Monad of this type as a member of the root class of a hierarchy; that hierarchi of classes became immutable! (At least for changing that member!)