Esse é um post “just for fun”. A ideia principal é explorar a utilização de MongoDB em aplicações C#.

O que é MongoDB?!

Usando a definição do site oficial:

MongoDB (from "humongous") is a scalable, high-performance, open source NoSQL database. Written in C++!

Como aprender MongoDB?

MongoDB oferece um shell online para aprendizado básico de seus conceitos. Recomendo fortemente que você faça o tutorial antes de continuar. Isso vai ajudar você a entender alguns dos principais conceitos desse banco. Combinado?!

O mais bacana no tutorial on-line é que não é necessário instalar nada em seu computador.

Instalando MongoDB em seu computador

Agora que você já aprendeu a utilizar o MongoDB, é hora de ter o banco instalado e funcionando em seu computador.

Faça o download da versão mais adequada para seu sistema (disponível em http://www.mongodb.org/downloads) e execute o tutorial oficial (http://www.mongodb.org/display/DOCS/Quickstart).

Preparando um projeto para consultar o Mongo

Agora que você tem o Mongo instalado em seu sistema, é hora de aprender a operar o banco a partir de um projeto em C#.

IMPORTANTE: Mantenha o Mongo em execução enquanto estiver brincando no C#.

No seu projeto em C# (para brincar, recomendo uma aplicação console), adicione uma referência Nuget usando a opção Add Library Package Reference (Se você não conhece NuGet, é mais do que hora de aprender acessando http://nuget.org/) para o pacote MongoCSharpDriver.

Esse procedimento irá adicionar referência para duas DLLs em seu projeto. Observe:

Criando um “documento” (a forma mais simples)

Se você seguiu meu conselho e fez o tutorial on-line, já sabe que um banco mongo tem coleções de documentos.

A forma mais direta de criar um documento é assim:

private static BsonDocument CreateDummyDocument()
{
           
    var result = new BsonDocument
        {
            {"name", "Joca 123 da Silva 4" },
            {"address", new BsonDocument
                {
                    {"street", "Rua dos Loucos"},
                    {"city", "MongoDBlandia"},
                    {"state", "TS"}
                }
            }
        };
    return result;
}

BsonDocument é definido nas referências que adicionamos. Observe a sensibilidade do desenvolvedor da API em permitr a definição do documento de forma fluída (bem parecida com JSON, não acha?!).

Obviamente, o tipo fornece uma interface altertiva. Veja:

private static BsonDocument CreateDummyDocument2()
{
    var result = new BsonDocument();
    result.Add("name", "Joca 123 da Silva 4");

    var address = new BsonDocument();
    address.Add("street", "Rua dos Loucos");
    address.Add("city", "MongoDBlandia");
    address.Add("state", "TS");

    result.Add("address", address);
    return result;
}

Para mim, significativamente mais pesada. Entretanto, mais convencional.

Adicionando o documento no Mongo

Já sabemos como definir um documento. Agora, vamos ver como realizar a persistência dele no Mongo. É tão simples quanto isso:

private static void AddDocument(
    BsonDocument document,
    string databaseName = "myDatabase",
    string collectionName = "contacts"
    )
{
    var server = MongoServer.Create("mongodb://localhost");
    server.Connect();

    var db = server.GetDatabase(databaseName);
    var collection = db.GetCollection(collectionName);

    collection.Insert(document);

    server.Disconnect();
}

Bonito, não?!

Próximos passos…

Obviamente, o driver do MongoDB oferece alternativas para persistência direta de objetos(sem criação manual de objetos BsonDocument). Além disso, todas as operações que podemos executar no Shell, também podem ser executadas através do C#.

Para entender tudo isso, recomendo fortemente a leitura de:

• CSharp Driver Serialization Tutorial – mostra, detalhadamente, com muitos exemplos, boas formas de persistir seus objetos diretamente nas coleções do Mongo.
• CSharp Driver Tutorial – mostra como executar todas as operações suportadas pelo driver (muito além do que mostrei aqui). Além disso, é uma excelente “porta de entrada” para o caso de você desejar colaborar com a evolução do driver.

Por hoje, era isso.

No último post falei sobre como a Microsoft planejou a experiência do usuário para o Windows Phone 7. Nesse post, começo a falar sobre o desenvolvimento de aplicações para a plataforma.

Antes de começar

Uma das características mais interessantes do Windows Phone 7 é a facilidade relacionada ao desenvolvimento de aplicações para ele.

Para desenvolver para o Windows Phone 7, aproveitamos todo o conhecimento relacionado a Silverlight/WPF e XNA. Além disso, contamos com o Visual Studio como IDE (o que é um grande benefício comparado a outras plataformas).

Se você já tem o Visual Studio instalado, instale também o SDK (pode ser obitdo em http://create.msdn.com).

Começando uma aplicação para o Windows Phone 7

Com o Visual Studio e o SDK devidamente instalados, podemos iniciar um projeto para o Windows Phone. Observe:

Como você pode ver, há diversos templates disponíveis. Para o post de hoje utilizaremos o mais simples deles (Windows Phone Application).

Antes de iniciar o projeto, o Visual Studio ainda solicita qual é a plataforma target. Observe:

Há duas opções:

• 7.0 – Para a primeira geração do sistema operacional
• 7.1 – Para aplicações com suporte a Mango.

Escolho uma opcão e estamos prontos para iniciar o desenvolvimento.

Se você conhece Silverlight (não, ele não morreu!) se sentirá em casa.

Como já é habitual, podemos executar a aplicação a partir do código gerado até aqui com o template. O Visual Studio carregará um emulador para que você possa experimentar.

Composição de um projeto básico para WP7

Observando os arquivos que formam o projeto, encontramos algumas coisas bem interessantes:

Temos:

• Application Manifest
• Algumas imagens
• XAML (MainPage.xaml e App.xaml)
• Código C# (MainPage.xaml.cs, App.xaml.cs e AssemblyInfo.cs)

Arquivos .XAP

Quando você compila uma aplicação para WP7, seja usando Silverlight ou XNA, ocorre a geração um arquivo com extensão .xap.

Arquivos XAP são, simplesmente, Zip. Se renomearmos o arquivo XAP dando a ele a extensão .zip, podemos inspecionar facilmente seu conteúdo.

O arquivo XAP possui diversos arquivos:

• DLLs geradas no processo de compilação
• manifestos
• imagens
• outros “assets” utilizados no projeto (como vídeos e outros arquivos de dado) que não tenham sido “embedded” na DLL.

Application Manifest

O arquivo chamado WPAppManifest.xml é o manifesto da aplicação (WM é uma abreviatura para “Windows Mobile”).

Ele descreve a aplicação para o sistema operacional. Ou seja:

• nome;
• como aplicação se parece;
• o que ela “pode fazer”

Veja o conteúdo do manifesto gerado com o template padrão.

<Deployment xmlns="http://schemas.microsoft.com/windowsphone/2009/deployment" AppPlatformVersion="7.1">
  <App xmlns="" ProductID="{b281e38e-e1cb-46e6-b955-7dd1f2849e52}" 
       Title="PhoneApp1" 
       RuntimeType="Silverlight" Version="1.0.0.0" 
       Genre="apps.normal"  Author="PhoneApp1 author" 
       Description="Sample description" 
       Publisher="PhoneApp1">
    <IconPath IsRelative="true" IsResource="false">ApplicationIcon.png</IconPath>
    <Capabilities>
      <Capability Name="ID_CAP_GAMERSERVICES"/>
      <Capability Name="ID_CAP_IDENTITY_DEVICE"/>
      <Capability Name="ID_CAP_IDENTITY_USER"/>
      <Capability Name="ID_CAP_LOCATION"/>
      <Capability Name="ID_CAP_MEDIALIB"/>
      <Capability Name="ID_CAP_MICROPHONE"/>
      <Capability Name="ID_CAP_NETWORKING"/>
      <Capability Name="ID_CAP_PHONEDIALER"/>
      <Capability Name="ID_CAP_PUSH_NOTIFICATION"/>
      <Capability Name="ID_CAP_SENSORS"/>
      <Capability Name="ID_CAP_WEBBROWSERCOMPONENT"/>
      <Capability Name="ID_CAP_ISV_CAMERA"/>
      <Capability Name="ID_CAP_CONTACTS"/>
      <Capability Name="ID_CAP_APPOINTMENTS"/>
    </Capabilities>
    <Tasks>
      <DefaultTask  Name ="_default" NavigationPage="MainPage.xaml"/>
    </Tasks>
    <Tokens>
      <PrimaryToken TokenID="PhoneApp1Token" TaskName="_default">
        <TemplateType5>
          <BackgroundImageURI IsRelative="true" IsResource="false">Background.png</BackgroundImageURI>
          <Count>0</Count>
          <Title>PhoneApp1</Title>
        </TemplateType5>
      </PrimaryToken>
    </Tokens>
  </App>
</Deployment>

Entenda que quase toda a informação mantida nesse arquivo será “considerada” e sobrescrita no processo de certificação para o MarketPlace.

Perceba que a aplicação possui um atributo ProductID (é um GUID) que identifica a aplicação. Além disso, há um RuntimeType indicando que a aplicação é “Silverlight” (atualmente, poderia ser XNA também).

O atributo Genre influencia onde a aplicação será instalada no telefone:

• app.normal – indica que a aplicação deverá ser instalada na lista convencional
• app.games – indica que a aplicação deverá ser instalada no “Games Hub” (Também é válido para aplicações Silverlight)

O elemento IconPath indica o nome do ícone.

Application Capabilities

A parte mais interessante do Application manifest é a lista de “capabilities”. São as permissões que a aplicação demanda para funcionar.

O template padrão do Visual Studio requisita todas as “capacidades” disponíveis.

Em um post futuro, falo mais sobre esse tópico.

Imagens

O projeto que geramos possui três imagens. São elas:

1. applicationicon.png – O ícone da aplicação exibido onde quer que a aplicação tenha sido instalada.
1. Para aplicações no App List, a imagem deverá ter 62×62 pixels
2. Para aplicações no Game Hub, a imagem deverá ter 173×173 pixels
2. Background.png – O ícone a ser utilizado como Tile na tela inicial. Deve ter 173×173 pixels. Para mim, foi pobremente nomeado.
3. SplashScreenImage.jpg – Imagem a ser exibida quando a aplicação estiver sendo carregada. Deve ter 480×800 pixels.

Podemos mudar o nome e a localização dessas imagens. Também podemos utilizar arquivos PNG ou JPEG. Entretanto, devemos lembrar de atualizar o manifesto.

Ícones com 62×62 pixels devem respeitar uma margem de 12 pixel. Ou seja, deve ser um ícone de 38×38 centralizado.

Ícones com 173×173 pixels devem ter, na prática, 73×73 pixels com margem superior de 47 pixels e 50 nas margens laterais.

applicationicon.png e splashscreenimage.jpg devem ter build action Content!

MainPage.xaml e MainPage.xaml.cs

Toda aplicação tem uma ou mais “pages”. Novos projetos começam com uma única página chamada “MainPage”.

O .xaml devide a interface, o .cs define a “lógica” (frequentemente chamada de code-behind).

<phone:PhoneApplicationPage 
    x:Class="PhoneApp1.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"
    FontFamily="{StaticResource PhoneFontFamilyNormal}"
    FontSize="{StaticResource PhoneFontSizeNormal}"
    Foreground="{StaticResource PhoneForegroundBrush}"
    SupportedOrientations="Portrait" Orientation="Portrait"
    shell:SystemTray.IsVisible="True">

    <!--LayoutRoot is the root grid where all page content is placed-->
    <Grid x:Name="LayoutRoot" Background="Transparent">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>

        <!--TitlePanel contains the name of the application and page title-->
        <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
            <TextBlock x:Name="ApplicationTitle" Text="MY APPLICATION" 
                       Style="{StaticResource PhoneTextNormalStyle}"/>
            <TextBlock x:Name="PageTitle" Text="page name" 
                       Margin="9,-7,0,0" 
                       Style="{StaticResource PhoneTextTitle1Style}"/>
        </StackPanel>

        <!--ContentPanel - place additional content here-->
        <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0"></Grid>
    </Grid>

</phone:PhoneApplicationPage>

O aspecto mais importante a observar, se você já entende de XAML, é que não são definidas cores e fontes explicitamente. Em lugar disso, são especificados recursos que são fornecidos pelo sistema operacional (padrões do sistema).

App.xaml e App.xaml.cs

App.xaml é um arquivo especial que não define elementos visuais. Em lugar disso, define elementos que serão usados na aplicação como um todo. A única razão para mexer nesse arquivo é definir recursos globais ou novos estilos para serem usados em toda a aplicação.

App.xaml.cs define eventos que serão executados durante todo o ciclo de vida da aplicação. Com destaque para:

• Lauching
• Activated
• Deactivated
• Closing

Observe:

using System.Diagnostics;
using System.Windows;
using System.Windows.Navigation;
using Microsoft.Phone.Controls;
using Microsoft.Phone.Shell;

namespace PhoneApp1
{
    public partial class App : Application
    {
        /// <summary>
        /// Constructor for the Application object.
        /// </summary>
        public App()
        {
            // Global handler for uncaught exceptions. 
            UnhandledException += Application_UnhandledException;

            // Standard Silverlight initialization
            InitializeComponent();

            // Phone-specific initialization
            InitializePhoneApplication();

            // Show graphics profiling information while debugging.
            if (Debugger.IsAttached)
            {
                // Display the current frame rate counters.
                Current.Host.Settings.EnableFrameRateCounter = true;

                // Show the areas of the app that are being redrawn in each frame.
                //Application.Current.Host.Settings.EnableRedrawRegions = true;

                // Enable non-production analysis visualization mode, 
                // which shows areas of a page that are handed off to GPU with a colored overlay.
                //Application.Current.Host.Settings.EnableCacheVisualization = true;

                // Disable the application idle detection by setting the UserIdleDetectionMode property of the
                // application's PhoneApplicationService object to Disabled.
                // Caution:- Use this under debug mode only. Application that disables user idle detection will continue to run
                // and consume battery power when the user is not using the phone.
                PhoneApplicationService.Current.UserIdleDetectionMode = IdleDetectionMode.Disabled;
            }
        }

        /// <summary>
        /// Provides easy access to the root frame of the Phone Application.
        /// </summary>
        /// <returns>The root frame of the Phone Application.</returns>
        public PhoneApplicationFrame RootFrame { get; private set; }

        // Code to execute when the application is launching (eg, from Start)
        // This code will not execute when the application is reactivated
        private void Application_Launching(object sender, LaunchingEventArgs e)
        {
        }

        // Code to execute when the application is activated (brought to foreground)
        // This code will not execute when the application is first launched
        private void Application_Activated(object sender, ActivatedEventArgs e)
        {
        }

        // Code to execute when the application is deactivated (sent to background)
        // This code will not execute when the application is closing
        private void Application_Deactivated(object sender, DeactivatedEventArgs e)
        {
        }

        // Code to execute when the application is closing (eg, user hit Back)
        // This code will not execute when the application is deactivated
        private void Application_Closing(object sender, ClosingEventArgs e)
        {
        }

        // Code to execute if a navigation fails
        private void RootFrame_NavigationFailed(object sender, NavigationFailedEventArgs e)
        {
            if (Debugger.IsAttached)
            {
                // A navigation has failed; break into the debugger
                Debugger.Break();
            }
        }

        // Code to execute on Unhandled Exceptions
        private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
        {
            if (Debugger.IsAttached)
            {
                // An unhandled exception has occurred; break into the debugger
                Debugger.Break();
            }
        }

        #region Phone application initialization

        // Avoid double-initialization
        private bool phoneApplicationInitialized;

        // Do not add any additional code to this method
        private void InitializePhoneApplication()
        {
            if (phoneApplicationInitialized)
                return;

            // Create the frame but don't set it as RootVisual yet; this allows the splash
            // screen to remain active until the application is ready to render.
            RootFrame = new PhoneApplicationFrame();
            RootFrame.Navigated += CompleteInitializePhoneApplication;

            // Handle navigation failures
            RootFrame.NavigationFailed += RootFrame_NavigationFailed;

            // Ensure we don't initialize again
            phoneApplicationInitialized = true;
        }

        // Do not add any additional code to this method
        private void CompleteInitializePhoneApplication(object sender, NavigationEventArgs e)
        {
            // Set the root visual to allow the application to render
            if (RootVisual != RootFrame)
                RootVisual = RootFrame;

            // Remove this handler since it is no longer needed
            RootFrame.Navigated -= CompleteInitializePhoneApplication;
        }

        #endregion
    }
}

Era isso.

Este é meu primeiro post (de muitos) falando especificamente sobre o desenvolvimento de aplicações e aprimoramento da experiência do usuário no Windows Phone 7.

Nesse primeiro post, pretendo “apresentar” as duas personas, idealizadas pela Microsoft, para orientar o desenvolvimento de toda a experiência do usuário no Windows Phone. Também falo sobre os princípios que orientaram o desenvolvimento do METRO (para atender Anna e Miles).

Life Maximizers

Windows Phone 7 foi projetado para um grupo particular de usuários identificados, pela Microsoft, como “Life Maximizers”.

Segundo a empresa, são pessoas, maduras, comprometidas, que precisam de devices para comunicação que suporte “Life in Motion”.

Para facilitar a compreensão desse “conceito”, foram idealizadas duas personas: Anna e Miles.

Settled, rather than seeking

Com o Windows Phone 7, a Microsoft deseja atender pessoas mais maduras e sérias. Pessoas que usam mais que Office e Outlook, mas que não “lotam” computadores e dispositivos com aplicações usadas apenas uma vez.

Anna

Anna tem 37 anos e acumula as funções de relações púbicas e mãe presente. Morando nos Estados Unidos, possui familiares na Europa com quem deseja manter contato.

Em seu tempo livre, Anna costuma escutar música e verificar seus e-mails.

My life is a balancing act between work, family, friends, and my own personal needs. – Anna

Miles

Miles tem 38 anos, é arquiteto e, há pouco tempo, começou seu próprio negócio. Miles é casado com Anna.

Miles é uma pessoa “conectada” que usa diversas soluções da Microsoft (Exchange, Excel, OneNote, etc) e de outros fornecedores (Miles adora o GMail).

Miles trabalha em casa mas visita clientes com grande frequência. Por isso, dá grande importância para o seu calendário.

I love running my life real-time so I can take advantage of whatever is inspiring me…whether it’s a new project, a pick up game or a stolen moment with Anna. – Miles

METRO – uma nova linguagem visual

Para atender as necessidades de Anna e Miles, a Microsoft desenvolveu uma nova linguagem visual. Chamou-a de METRO. Agora, está usando essa mesma linguagem visual em todos os seus aplicativos.

Segundo a própria Microsoft:

METRO is our design language. We call it METRO because it is MODERN and clean. It is fast and in motion. It is about content and typography. And it is entirely authentic.

Princípios de Design para atender Miles e Anna

Com Miles e Anna (personas) em mente, a equipe de design do WP7 consolidou os seguintes princípios para a linguagem de interface – Metro:

• Clean, Light, Open, Fast
• Aplicação veloz e responsiva;
• Foco nas atividades mais importantes;
• Fazer muito, com muito pouco;
• Redução de elementos desnecessários;
• Uso “tranquílo” de espaço em branco;
• Aplicação em “tela-cheia” todo o tempo (sem barra de status)
• Celebrate Typography
• Fontes bonitas, não apenas legíveis;
• Informação clara
• Uso equilibrado de peso e escala;
• Alive in motion
• Interface responsiva e adaptada as ações do usuário’;
• Entrega um contexto beneficiando usabilidade;
• Atenção especial para as transições de estado da interface;
• Senso de dimensão e profundidade;
• Content, Not Chrome
• Janelas sem bordas e sem barras de título – ênfase no conteúdo;
• Redução de qualquer elemento visual que não esteja relacionado com o conteúdo;
• Content is the UI
• Interação direta com o conteúdo;
• Authentically Digital
• Projeto de interface adequado ao tamanho dos dispositivos (sem reduzir a interface de um desktop para o device)
• Minimização das “analogias” da interface para artifícios mais ricos.

Red Threads – Personal. Relevant. Connected.

Microsoft especializou o desenvolvimento de aplicações para Windows Phone em três “Red Threads”:

1. Personal – Your day, your way
2. Relevant – Your people, your location
3. Connected – Your stuff, your peace of mind

Vejamos o que eles querem dizer…

Personal

Toda a interface desenvolvida conforme Metro deverá focar os interesses do usuário e, preferencialmente, apenas isso. Embora isso pareça óbvio, não ocorre sempre assim.

A chave para fazer uma aplicação “Personal” é prover apenas informação diretamente relacionada ao usuário de alguma forma.

Uma ótima consequência de fazer a interface “pessoal” é a redução do volume de dados que precisa ser transmitida.

Relevant

Outro aspecto aparentemente óbvio. Sempre pensamos que nossas interfaces contém informações relevantes para o usuário. Entretanto a questão central é:

Quanto relevante para o usuário você projeta suas interfaces atualmente versus quanto relevante essa interface poderia ser?!

Algumas aplicações óbvias desse conceito:

• Se você está desenvolvendo uma aplicação que é geo-sensível, deveria considerar a localização do usuário fornecida pelo hardware;
• Sua interface pode utilizar o acelerômetro para determinar se o usuário está em movimento;
• Sua interface pode utilizar data e hora como filtro primário de informações.

Connected

No lugar de desenvolver aplicações “stand-alone”, devemos considerar o desenvolvimento de cenários onde um usuário possa colaborar com outros usuários, compartilhando informação e conhecimento entre dispositivos. Para isso, precisamos “conectar” nossas aplicações a serviços on-line, armazenando informações na Cloud.

A estratégia é não confiar em ambientes 100% conectados. No lugar disso, desenvolver funções que funcionem independente de uma conexão com rede, sincronizando e atualizando dados, em background, sempre que uma conexão estiver disponível.

A combinação dos três Red Threads e dos princípios da linguagem METRO, entregam para Anna e Miles aquilo que eles buscam.

Você talvez não saiba. Pelo menos, não falei aqui no blog (embora você talvez tenha visto no vídeo). Mas, Anna e Miles têm um filho, Luca, 11 anos. A Microsoft também concebeu o seu perfil. Não sei até onde ele influenciou as decisões de interface, mas …

Era isso!

Monad é uma abstração poderosa que facilita a escrita de soluções elegantes para problemas complexos. É um conceito matemático amplamente utilizado em linguagens funcionais (com destaque para Haskell). Além disso, foi amplamente considerado no design do LINQ.

Nesse post, mostro como utilizar essa poderosa abstração em C#.

O que é Monad?

Esse termo acumula dois significados:

1. É uma abstração, ou pattern de implementação, utilizada para combinar funções utilizando “valores ampliados”;
2. São classes implementadas seguindo o pattern que recebe este mesmo nome.

Benefícios de adoção

Monads permitem a redução de “boilerplate code”. Ou seja, códigos repetidos, não relacionados com o objetivo principal do domínio, como, por exemplo:

• validação de estado (para verificar se uma variável está com conteúdo nulo, por exemplo),
• logging
• tratamento de exceptions

Removendo boilerplate code, temos códigos mais simples de escrever, ler e, consequentemente, manutenir.

Valores simples e valores “ampliados”

Para poder entender corretamente o Pattern Monad, precisamos saber diferenciar valores simples e valores “ampliados”

Comecemos por valores simples. Considere:

private static void Main(string[] args)
{
    Func<int, int> fiveTimes = v => v*5;
    Func<int, int> halfOf = v => v/2;
    Console.WriteLine(halfOf(fiveTimes(6)));
}

Nesse código, definimos duas funções simples que retornam apenas o “resultado principal” do processamento, sem nenhuma informação adicional.

Métodos assim são fáceis de combinar. Veja:

private static void Main(string[] args)
{
    Func<int, int> fiveTimes = v => v*5;
    Func<int, int> halfOf = v => v/2;
    Func<int, int> halfOfFiveTimes = v => halfOf(fiveTimes(v));
    
    Console.WriteLine(halfOfFiveTimes(6));
}

Entretanto, por só retornarem o valor principal, transferem uma série de responsabilidades para códigos clientes (verificação de retorno nulo, exceptions, etc).

Por outro lado, valores ampliados conseguem descrever mais do que o seu resultado principal.

class Envelope<T>
{
    public T Value { get; private set; }

    public Envelope(T value)
    {
        Value = value;
    }
}

Nossa implementação, ilustrativa, não faz uso do benefício que esse tipo poderia prover.

Vamos mudar nosso código para retornar esse valor ampliado.

private static void Main(string[] args)
{
    Func<int, Envelope<int>> fiveTimes = v => new Envelope<int>(v*5);
    Func<int, Envelope<int>> halfOf = v => new Envelope<int>(v/2);
    
    Console.WriteLine(halfOf(fiveTimes(6).Value).Value);
}

Naturalmente, como os valores de entrada (parâmetro) e saída (retorno) das funções não são do mesmo tipo, a combinação é um pouco mais trabalhosa. Para facilitar essa combinação, adicionamos um helper a classe Envelope.

class Envelope<T>
{
    public T Value { get; private set; }

    public Envelope(T value)
    {
        Value = value;
    }

    public Envelope<TResult> Bind<TResult>(Func<T, Envelope<TResult>> func)
    {
        return func(Value);
    }
}

O que nos habilita a escrever o código de forma mais elegante.

private static void Main(string[] args)
{
    Func<int, Envelope<int>> fiveTimes = v => new Envelope<int>(v * 5);
    Func<int, Envelope<int>> halfOf = v => new Envelope<int>(v / 2);
    Func<int, Envelope<int>> halfOfFiveTimes = v => halfOf(v).Bind(fiveTimes);

    Console.WriteLine(halfOfFiveTimes(6).Value);
}

Implementação do Monad pattern

Monad consiste de classes “envelope” com suporte para:

1. criação de instâncias a partir do valor principal (no nosso exemplo, com o construtor);
2. combinação facilitada com outros objetos que implementem o pattern.

O Envelope que escrevemos acima atende a essas duas condições. Logo, é um monad (Inútil, mas é um monad).

Uma prática comum, na implementação de Monads em C# é escrever Extensions Methods para criação do “primeiro monad”. Continuando no exemplo do envelope:

static class EnvelopeExtensions
{
    public static Envelope<T> ToEnvelope<T>(T value)
    {
        return new Envelope<T>(value);
    }
}

O que possibilita a simplificação no uso de monads. Veja:

private static void Main(string[] args)
{
    Func<int, Envelope<int>> fiveTimes = v => (v * 5).ToEnvelope();
    Func<int, Envelope<int>> halfOf = v => (v / 2).ToEnvelope();
    Func<int, Envelope<int>> print = v =>
                                         {
                                             Console.WriteLine(v);
                                             return v.ToEnvelope();
                                         };
    6.ToEnvelope()
        .Bind(fiveTimes)
        .Bind(halfOf)
        .Bind(print);
}

Maybe – Um Monad útil, em C#

Considere o seguinte código:

private static string GetThirdChildName(Dummy d)
{
    return d.Child.Child.Child.Name;
}

Qual é o problema com esse código?! Qualquer um dos “três níveis” de propriedades poderá estar nulo (resultando em exception).

Para evitar problemas, devemos adicionar algum código de verificação. Entretanto, dependendo da complexidade da expressão, podemos incorrer em falhas. O ideal é fazer com que a validação esteja diretamente associada a execução. Assim, surge os Monads. Veja:

public class Maybe<T>
{
    public static readonly Maybe<T> Empty = new Maybe<T>();

    public Maybe(T value)
    {
        Value = value;
        IsEmpty = false;
    }

    private Maybe()
    {
        IsEmpty = true;
    }

    public T Value { get; private set; }
    public bool IsEmpty { get; private set; }

    public bool HasValue
    {
        get { return !IsEmpty; }
    }

    public Maybe<TResult> Bind<TResult>(Func<T, Maybe<TResult>> f)
    {
        return IsEmpty ? Maybe<TResult>.Empty : f(Value);
    }
}

Esse monad pode ter ou não um valor atribuido. Caso não tenha, qualquer “bind” resultará em um Monad “vazio”.

Para completar a funcionalidade do Monad, definimos também alguns extension methods.

public static class MaybeExtensions
{
    public static Maybe<T> ToMaybe<T>(this T value)
    {
        return new Maybe<T>(value);
    }

    public static Maybe<T> ToNotNullMaybe<T>(this T value)
        where T : class
    {
        return value != null ? value.ToMaybe() : Maybe<T>.Empty;
    }
}

Considere:

• Criei um “conversor” imediato de qualquer valor para o Monad;
• Criei um “converso especialista” que define qualquer nulo como Monad vazio.

Nosso código, agora, pode ser escrito assim:

private static string GetThirdChildNameOrNull(Dummy d)
{
    return d.ToNotNullMaybe()
        .Bind(t => t.Child.ToNotNullMaybe())
        .Bind(t => t.Child.ToNotNullMaybe())
        .Bind(t => t.Child.ToNotNullMaybe())
        .Bind(t => t.Name.ToNotNullMaybe())
        .Value;
}

A principal vantagem desse código é que tornamos a validação dispensável. O lado negativo é a quantidade de lambda expressions.

Apenas como provocação, IEnumerable<T> é um monad. Graças a ele, podemos criar implementações bem mais limpas, mas esse é tema para outro dia.

Era isso.

No paradigma funcional, há três funções, muito comuns, aplicadas a listas e sequências. São elas:

1. Map – uma mesma operação aplicada a todos os elementos de uma lista e/ou sequência;
2. Filter – seleção de elementos de uma lista/sequência, conforme um critério especificado;
3. Fold – “acumulo” de todos os valores de uma lista/sequência em um único resultado.

Este post mostra alguns exemplos de aplicação destas funções em C#, considerando as implementações disponíveis no LINQ. No final, mostro como potencializar o uso dessas funções através de uma técnica chamada Currying (descrita em um post anterior).

Select, Where e Aggregate

O LINQ possui uma implementação completa das funções descritas. Veja alguns exemplos de uso:

var squaresOf1To100 = Enumerable.Range(1, 100)
    .Select(x => x * x);

var evenOf1To100 = Enumerable.Range(1, 100)
    .Where(x => x % 2 == 0);

var sumOfEvenOf1To100 = Enumerable.Range(1, 100)
    .Where(x => x % 2 == 0)
    .Aggregate((l, r) => l + r);

Na verdade, Select (Map), Where (Filter) e Aggregate (Fold) são extension methods definidos na classe estática Enumerable. Logo, podem também ser utilizados em uma notação mais convencional. Considere:

var squaresOf1To100 = Enumerable.Select(
    Enumerable.Range(1, 100),
    x => x * x
    );

var evenOf1To100 = Enumerable.Where(
    Enumerable.Range(1, 100),
    x => x % 2 == 0
    );

var sumOfEvenOf1To100 = Enumerable.Aggregate(
    Enumerable.Where(
        Enumerable.Range(1, 100),
        x => x % 2 == 0
        ),
    (l, r) => l + r
    );

Perceba como a Microsoft deixou nossos códigos mais elegantes pela definição dos extension methods (há um post sobre como melhorar códigos usando extension methods).

Como você sabe, há métodos de agregação (operadores) pré-definidos que dimunem a necessidade da função Aggregate (No código de exemplo, poderíamos usar o agregador Sum no lugar do “genérico” Aggregate). Entretanto, o uso criativo desse operador permite que levantemos muito mais informações. Veja:

var ages = people
    .Select(p => DateTime.Now - p.Birthday)
    .Select(elapsedTime => elapsedTime.TotalDays)
    .Select(days => Convert.ToInt32(days / 365));

var summary = ages
    .Aggregate(Tuple.Create(0, 0), (l, r) => Tuple.Create(l.Item1 + r, l.Item2 + 1));

No exemplo, percorro uma coleção de pessoas calculando a idade de cada uma delas. Depois, usando Aggregate, crio uma tupla com a soma dessas idades e com o número de elementos da lista. Também é possível definir um tipo anônimo para deixar a sintaxe mais clara. Perceba:

var summary2 = ages
    .Aggregate(
        new { SumOfAges = 0, Count = 0 },
        (l, r) => new { SumOfAges = l.SumOfAges + r, Count = l.Count + 1 }
    );

Obviamente, podemos também escrever esse código usando a notação “livre” de extension methods, mas veja como o prejuízo de leitura fica mais evidente:

var ages = Enumerable.Select(
    Enumerable.Select(
        Enumerable.Select(
            people,
            p => DateTime.Now - p.Birthday
            ),
        elapsedTime => elapsedTime.TotalDays
        ),
    days => Convert.ToInt32(days / 365)
    );

var summary = Enumerable.Aggregate(
    ages,
    Tuple.Create(0, 0),
    (l, r) => Tuple.Create(l.Item1 + r, l.Item2 + 1)
    );

var summary2 = Enumerable.Aggregate(
    ages,
    new { SumOfAges = 0, Count = 0 },
    (l, r) => new { SumOfAges = l.SumOfAges + r, Count = l.Count + 1 }
    );

Currying Map, Filter e Fold

Como expliquei em um post anterior, currying é uma técnica onde começamos com uma função com múltiplos parâmetros e a convertemos em uma sequência de funções, em cadeia, com apenas um parâmetro cada. Utilizando essa técnica, podemos, facilmente, criar novas funções especializadas, a partir de funções genéricas.

O problema com os métodos Select, Where e Aggregate é que eles têm, como primeiro parâmetro, a lista/sequência que será processada. Isso torna currying pouco usual para elas. Então, vamos mudar as coisas. Observe:

static IEnumerable<TResult> Map<TInput, TResult>(Func<TInput, TResult> func, IEnumerable<TInput> input)
{
    return input.Select(func);
}

static IEnumerable<TInput> Filter<TInput>(Func<TInput, bool> func, IEnumerable<TInput> input)
{
    return input.Where(func);
}


static TAggregate Fold<TAggregate, TInput>(
    Func<TAggregate, TInput, TAggregate> func,
    TAggregate seed, 
    IEnumerable<TInput> input
    )
{
    return input.Aggregate(seed, func);
}

static TInput Fold<TInput>(
    Func<TInput, TInput, TInput> func,
    IEnumerable<TInput> input
    )
{
    return input.Aggregate(func);
}

O que fizemos?! Simplesmente mudamos a sequência dos parâmetros. Para fins de simplificação, vou repetir aqui as funções que escrevi para Currying em um post anterior.

public static class FunctionalExtensions
{
    public static Func<T1, Func<T2, TResult>>
        Curry<T1, T2, TResult>(this Func<T1, T2, TResult> func)
    {
        return a => b => func(a, b);
    }

    public static Func<T1, Func<T2, Func<T3, TResult>>>
        Curry<T1, T2, T3, TResult>(this Func<T1, T2, T3, TResult> func)
    {
        return a => b => c => func(a, b, c);
    }

    public static Func<T1, Func<T2, Func<T3, Func<T4, TResult>>>>
        Curry<T1, T2, T3, T4, TResult>(this Func<T1, T2, T3, T4, TResult> func)
    {
        return a => b => c => d => func(a, b, c, d);
    }

    public static Func<T1, Func<T2, Func<T3, Func<T4, Func<T5, TResult>>>>>
        Curry<T1, T2, T3, T4, T5, TResult>(this Func<T1, T2, T3, T4, T5, TResult> func)
    {
        return a => b => c => d => e => func(a, b, c, d, e);
    }
}

Perfeito! Agora, vamos ver o que podemos fazer com isso.

var curriedMap =  FunctionalExtensions.Curry<Func<int, int>, IEnumerable<int>, IEnumerable<int>>(Map);
var curriedFilter = FunctionalExtensions.Curry<Func<int, bool>, IEnumerable<int>, IEnumerable<int>>(Filter);
var curriedFold = FunctionalExtensions.Curry<Func<int, int, int>, IEnumerable<int>, int>(Fold);

var squares = curriedMap(x => x*x);
var squaresOf1To100 = squares(Enumerable.Range(1, 100));

var evens = curriedFilter(x => x%2 == 0);

var evenOf1To100 = evens(
    Enumerable.Range(1, 100)
    );

var sum = curriedFold((l, r) => l + r);
var sumOfEvenOf1To100 = sum(evens(Enumerable.Range(1, 100)));

Bacana, não?

Era isso.

Uma discussão com o Juan Lopes (@juanplopes) me motivou a escrever este post. Pretendo explicar como Closures são entregues pelo compilador do C#.

Uma questão intrigante…

Para entender como closures funcionam é melhor examinar um código de exemplo. Observe:

using System;

namespace HowClosureWorks
{
    internal class Program
    {
        public static Func<int, int> GetFunc()
        {
            int seed = 10;
            Func<int, int> f = (v) => v + seed;
            Console.WriteLine(f(10));

            seed = 20;
            Console.WriteLine(f(15));
            return f;
        }

        static void Main()
        {
            Console.Title = "How Closure Works";
            Console.WriteLine(GetFunc()(20));
            Console.ReadLine();
        }
    }
}

Seguindo o caminho de execução:

1.  Main chama a função GetFunc que retorna uma função;
2. Na GetFunc, há uma variável chamada seed (iniciada com 10) e outra chamada f;
3. f é uma expressão lambda que soma o valor de seed com o parâmetro v;
4. f é evocada com parâmetro 10 – o retorno é 20 (valor do parâmetro + o valor de seed);
5. seed é alterado para 20;
6. f é acionado com parâmetro 15 – o retorno é 35;
7. f é retornado de GetFunc e é chamado novamente com parâmetro 20 – o retorno agora é 40 (parâmetro + o último valor de seed).

Vendo a execução:

A questão é: A variável seed não deveria ter “saído” do escopo assim que a função GetFunc retorna?!

Surgem os Closures…

Closures garantem que valores não saiam do escopo quando o compilador “percebe” que isso cause algum prejuízo ao sistema.

Veja a definição da wikipedia:

In computer science, a closure (also lexical closure, function closure, function value or functional value) is a function together with a referencing environment for the non-local variables of that function.^[1] A closure allows a function to access variables outside its typical scope. Such a function is said to be "closed over" its free variables. The referencing environment binds the nonlocal names to the corresponding variables in scope at the time the closure is created, additionally extending their lifetime to at least as long as the lifetime of the closure itself. When the closure is entered at a later time, possibly from a different scope, the function is executed with its non-local variables referring to the ones captured by the closure.

De forma simplificada:

• O compilador identifica que uma função anônima (variável f) utiliza uma variável definida fora de seu escopo (variável seed);
• Como essa função anônima será retornada e usada em outra posição do código (fora do escopo da variável seed), o compilador armazena os dados que são necessários em um lugar seguro (fora do stack);
• Compilador gera uma classe anônima para armazenar com a implementação da função anônima (variável f) e com o dado que utiliza (variável seed);
• Compilador modifica o código do método GetFunc para instanciar essa classe anônima usando os valores de seed e o método dessa classe.

Ou seja, o IL gerado é totalmente compatível com aqueles das primeiras versões do Framework.

Observando o IL

Observe a estrutura do IL gerado (usando o IL Disassembler)

Perceba a classe aninhada e privada c__DisplayClass1. É a classe, privada e aninhada, gerada pelo compilador para armazenar o valor da variável seed (veja como o nome foi preservado) e do método anônimo <GetFunc>b_0.

Inspecionando do método anônimo temos o seguinte IL:

.method public hidebysig instance int32  '<GetFunc>b__0'(int32 v) cil managed
{
  // Code size       9 (0x9)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldarg.0
  IL_0002:  ldfld      int32 HowClosureWorks.Program/'<>c__DisplayClass1'::seed
  IL_0007:  add
  IL_0008:  ret
} // end of method '<>c__DisplayClass1'::'<GetFunc>b__0'

Se você não entende muito de IL, veja a série que escrevi sobre o tema.

Agora, vejamos como o compilador resolveu o método GetFunc

.method public hidebysig static class [mscorlib]System.Func`2<int32,int32> 
        GetFunc() cil managed
{
  // Code size       63 (0x3f)
  .maxstack  3
  .locals init ([0] class [mscorlib]System.Func`2<int32,int32> f,
           [1] class HowClosureWorks.Program/'<>c__DisplayClass1' 'CS$<>8__locals2')
  IL_0000:  newobj     instance void HowClosureWorks.Program/'<>c__DisplayClass1'::.ctor()
  IL_0005:  stloc.1
  IL_0006:  ldloc.1
  IL_0007:  ldc.i4.s   10
  IL_0009:  stfld      int32 HowClosureWorks.Program/'<>c__DisplayClass1'::seed
  IL_000e:  ldloc.1
  IL_000f:  ldftn      instance int32 HowClosureWorks.Program/'<>c__DisplayClass1'::'<GetFunc>b__0'(int32)
  IL_0015:  newobj     instance void class [mscorlib]System.Func`2<int32,int32>::.ctor(object, native int)
  IL_001a:  stloc.0
  IL_001b:  ldloc.0
  IL_001c:  ldc.i4.s   10
  IL_001e:  callvirt   instance !1 class [mscorlib]System.Func`2<int32,int32>::Invoke(!0)
  IL_0023:  call       void [mscorlib]System.Console::WriteLine(int32)
  IL_0028:  ldloc.1
  IL_0029:  ldc.i4.s   20
  IL_002b:  stfld      int32 HowClosureWorks.Program/'<>c__DisplayClass1'::seed
  IL_0030:  ldloc.0
  IL_0031:  ldc.i4.s   15
  IL_0033:  callvirt   instance !1 class [mscorlib]System.Func`2<int32,int32>::Invoke(!0)
  IL_0038:  call       void [mscorlib]System.Console::WriteLine(int32)
  IL_003d:  ldloc.0
  IL_003e:  ret
} // end of method Program::GetFunc

Para facilitar, poderíamos dizer que GetFunc, em C#, como foi gerado pelo compilador parece com o que segue:

public static Func<int, int> GetFunc()
{
    var d = new c__DisplayClass1();
    d.seed = 10;
    Func<int, int> f = d.b__0;
    Console.WriteLine(f(10));

    d.seed = 20;
    Console.WriteLine(f(15));
    return f;
}

Era isso!

Nesse post, mostro como implementar “Tail Recursions” em C#.

Embora o compilador do C# quase não forneça suporte para “Tail Recursion Optimizations”, o JIT em 64 bits fornece. Logo, utilizar técnicas de codificação para “Tail Recursion” pode representar um incremento significativo de performance.

Nesse post, além de C#, usaremos um pouco de F# e um pouco de Intermediate Language.

Se você está com vontade de aprender F#, recomendo seguir @rodrigovidal e ler tudo o que ele  escreve (o cara é MVP em F# [linguagem pure-functional wanna-be], da Microsoft).

Se você quiser aprender Intermediate Language (acho que todo desenvolvedor .NET deveria saber pelo menos o básico), recomendo dar uma olhada na série IL 101 (aqui mesmo no blog).

O que é Tail Recursion?!

Pegando a definição da Wikipedia:

In computer science, a tail call is a subroutine call that happens inside another procedure and that produces a return value, which is then immediately returned by the calling procedure. The call site is then said to be in tail position, i.e. at the end of the calling procedure. If a subroutine performs a tail call to itself, it is called tail-recursive. This is a special case of recursion.

Tentado explicar: Se você escreve um método recursivo, onde a última operação do método é a chamada para a recursão. Então, a recursão implemetada tem um tipo especial chamado Tail Recursion. Veja:

public static void CountDown(int seed)
{
    if (seed == 0) return;
    CountDown(seed - 1);
}

Por outro lado,

public static int ComputeFactorial(int value)
{
    if (value == 0) return 1;
    return value*ComputeFactorial(value - 1);
}

Esse método não tem “Tail Recursion” já que executa operações depois da chamada para recursão.

Por que Tail Recursion é importante!?

Funções que implementam “Tail Recursion” suportam um tipo especial de otimização (Tail Recursion Optimization).

Como o “estado” (variáveis internas e call stack) da função evocadora não é relevante para a continuidade do programa, o compilador pode “descartar” essa informação e evitar o “terrível” StackOverflowException.

Além disso, como o sistema fica “aliviado” da responsabilidade de manter o call stack e estado das funções, há um evidente ganho de performance (tanto em memória quanto em tempo de processamento).

Tail Recursion Optimization depende do compilador

Quando implementamos uma “Tail Recursion” fazemos a nossa parte para que não ocorram “Stack Overflow Exceptions” e para que tenhamos uma performance superior. Entretanto, o compilador precisa fazer a parte dele. Infelizmente, esse nem sempre é o caso do C#.

Observe a seguinte implementação em F# (Olha só, @rodrigovidal):

let n = 1000000

let rec countdown n =
    match n with
    | 0 -> ()
    | _ -> countdown (n-1)

countdown n
printfn "Done"

A função countdown, em Intermediate Language, gerada pelo compilador do F# ficou assim (Não sabe IL? Que tal dar uma olhada nessa série):

.method public static void  countdown(int32 n) cil managed
{
  // Code size       21 (0x15)
  .maxstack  4
  IL_0000:  nop
  IL_0001:  ldarg.0
  IL_0002:  switch     ( 
                        IL_000d)
  IL_000b:  br.s       IL_000e
  IL_000d:  ret
  IL_000e:  ldarg.0
  IL_000f:  ldc.i4.1
  IL_0010:  sub
  IL_0011:  starg.s    n
  IL_0013:  br.s       IL_0000
} // end of method Program::countdown

O que, em C#, ficaria assim:

public static void countdown(int n)
{
    while (true)
    {
        switch (n)
        {
            case 0:
                goto label_1;
            default:
                --n;
                continue;
        }
    }
label_1: ;
}

Ou seja, o compilador do F# reconheceu a “tail recursion” e a eliminou do IL integralmente. Esse código tem performance superior e nunca dispara “Stack Overflow Exception”.

Agora, a versão em C#:

using System;

namespace TailRecursion
{
    internal class Program
    {

        public static void CountDown(int seed)
        {
            if (seed == 0) return;
            CountDown(seed - 1);
        }

        private static void Main()
        {
            CountDown(1.Million());
            Console.WriteLine("done!");
        }
    }

    internal static class IntExtensions
    {
        public static int Million(this int value)
        {
            return value * 1000 * 1000;
        }
    }
}

Perceba que também temos um “Tail Recursion” aqui. Entretanto, o IL gerado para a função CountDown fica assim (mais uma vez, considere aprender IL):

.method public hidebysig static void  CountDown(int32 seed) cil managed
{
  // Code size       13 (0xd)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  brtrue.s   IL_0004
  IL_0003:  ret
  IL_0004:  ldarg.0
  IL_0005:  ldc.i4.1
  IL_0006:  sub
  IL_0007:  call       void TailRecursion.Program::CountDown(int32)
  IL_000c:  ret
} // end of method Program::CountDown

Como pode ver, o compilador não “removeu” a recursão. Isso quer dizer que esse código PODE resultar “Stack Overflow Exception” e ter performance inferior.

Não há certeza do resultado porque o JIT (que converte IL para código nativo) PODE implementar a otimização.

Atualmente o JIT (Just-in-time compiler), em sua versão 64 bits, implementa a “Tail Recursion Optimization”. Entretanto, a versão 32 bits não implementa. Ou seja, Stack Overflow Exception ocorrerá apenas em programas que sejam processados pela versão 32 bits do JIT.

Essa condição, espero eu, deverá mudar nas futuras implementações do C# e/ou JIT.

Importante destacar que Intermediate Language possui um opcode especial para tratar tail recursion (curiosamente, Tail). Infelizmente, esse opcode só é “emitido” pelo compilador do F#. O compilador do C# não faz uso desse recurso.

De qualquer forma, sempre que possível, devemos implementar “Tail Recursion”. Quando houver otimização, os resultados serão muito bons.

Implementando “Accumulator Passing Style” Tail Recursion

Considere a seguinte implementação para calcular o fatorial de um número (Lembrando 5! = 5 * 4 * 3 * 2 * 1 = 120).

public static int ComputeFactorial(int value)
{
    if (value == 0) return 1;
    return value*ComputeFactorial(value - 1);
}

Essa implementação não é “Tail Recursion”, pois a última operação não é a chamada para recursão.

Uma forma de modificar isso é implementando um acumulador. Veja:

public static int ComputeFactorial(int value, int accumulator = 1)
{
    if (value == 0) return accumulator;
    return ComputeFactorial(value - 1, value * accumulator);
}

Essa implementação é “Tail Recursion” pois a chamada para a recursão é a última operação realizada.

Perceba:

• a assinatura da função foi modificada para incluir um parametro adicional (accumulator);
• esse parâmetro, de certa forma, subsitui o valor de retorno. Em cada iteração, o acumulador contém o fatorial calculado até aquele ponto;
• enquanto o contador não chega a zero, o acumulador é atualizado e uma nova chamada a recursão é executada;
• em determinado momento, o contador chega a zero, e o valor do acumulador é retornado como resultado.

Podemos remover o inconveniente da mudança da assinatura usando lambda expressions. Perceba:

public static int ComputeFactorial(int value)
{
    Func<int, int, int> @worker = null;
    @worker = (v, a) => v == 0 ? a : @worker(v - 1, v * a);
    return @worker(value, 1);
}

Basicamente, mudamos a recursão de lugar. A lambda @worker é “tail recursive”.

O segredo para criar expressões lambdas recursivas está na atribuição inicial para null

Implementando “Continuation Passing Style” Tail Recursion

Continuation Passing Style é mais uma estratégia para implantação de algoritmos com “Tail Recursion”.

Como não é tão “fácil de pegar”, vamos tentar construir alguma fundamentação. Observe:

using System;

namespace TailRecursion.CPS
{
    internal class Program
    {
        public static int Add(int a, int b)
        {
            return a + b;
        }

        public static int Mult(int a, int b)
        {
            return a*b;
        }

        static void Main()
        {
            Console.WriteLine(Mult(3, Add(5,2)));
            Console.ReadLine();
        }
    }
}

Nessa sequência ingênua de código temos algo plenamente intuitivo sob a perspectiva matemática. Mas, pouco intuitiva para linguagens imperativas sequênciais. Os trechos mais internos (innermost) da linha que imprime o resultado são calculados antes dos trechos mais externos (outermost). Ou seja:

1. Add é chamado com parâmetros 5 e 2;
2. Mult é chamado com 3 e o resultado da adição;
3. WriteLine é chamado com resultado da multiplicação.

Continuation Passing Style habilita que façamos um código “sequencialmente” mais intuitivo. Veja:

using System;

namespace TailRecursion.CPS
{
    internal class Program
    {
        public static void Add(int a, int b, Action<int> continuation)
        {
            continuation( a + b );
        }

        public static void Mult(int a, int b, Action<int> continuation)
        {
            continuation( a * b );
        }

        static void Main()
        {
            Add(5, 2, (x)
                      => Mult(x, 3, Console.WriteLine)
                );
 
            Console.ReadLine();
        }
    }
}

Repare como “invertemos” o código.

Agora, voltando ao exemplo do cálculo do fatorial, usando CPS.

using System;

namespace TailRecursion.CPS
{
    internal class Program
    {
        public static void ComputeFactorial(int value, Action<int> continuation)
        {
            if (value == 0)
                continuation(1);
            else
                ComputeFactorial(value - 1, x => continuation(value * x));
        }

        static void Main()
        {
            ComputeFactorial(5, Console.WriteLine);
            Console.ReadLine();
        }
    }
}

O que fizemos?

• Alteramos a assinatura do nosso método para que ele aceitasse um continuation;
• Inicialmente, passamos um “WriteLine”;
• Nossa função verifica se o contador chegou a zero.
  • Em caso positivo, executa o continuation;
  • Em caso negativo, ativa uma “Tail call” com o contador decrementado e uma versão diferente do continuation.

E temos mais uma versão com Tail Recursion.

Agora, vamos implementar uma versão modificada, mais conveniente, onde nossa função retorna um valor no lugar de simplesmente processar um continuation. Veja:

using System;

namespace TailRecursion.CPS
{
    internal class Program
    {
        public static int ComputeFactorial(int value, Func<int, int> continuation)
        {
            return (value == 0) ? continuation(1) : 
                ComputeFactorial(value - 1, x => continuation(value * x));
        }

        static void Main()
        {
            Console.WriteLine(ComputeFactorial(5, x => x));
            Console.ReadLine();
        }
    }
}

O inconveniente dessa implementação é a obrigatoriedade da passagem de uma função de continuation burra. Vamos eliminar isso?!

using System;

namespace TailRecursion.CPS
{
    internal class Program
    {
        public static int ComputeFactorial(int value)
        {
            Func<int, Func<int, int>, int> @worker = null;
            
            @worker = (v, c) => (v == 0) ? c(1) : 
                @worker(v - 1, x => c(v * x));

            return @worker(value, x => x);
        }

        static void Main()
        {
            Console.WriteLine(ComputeFactorial(5));
            Console.ReadLine();
        }
    }
}

Lindo, não?!

Era isso!

Fundamentalmente, programação funcional trata da aplicação de funções e suas combinações para algoritmos mais complexos.

Outro dia, mostrei como “combinar” funções usando uma técnica chamada “Combinators” (veja o post). Hoje, mostro como decompor funções complexas usando uma ténica chamada “Currying” para, depois disso, criar composições mais inteligentes através de uma técnica chamada “Partial Application”.

Este é um post com bastante código (ao gosto do meu amigo @juanplopes)

Você sabe, C# não é (nem pretende ser) uma linguagem puramente funcional (Aliás, F# também não é [desculpa aí, @rodrigovidal]!). Mesmo assim, algumas técnicas desse paradigma conseguem deixar nosso código bem mais elegante.

Currying 101

Currying é uma técnica onde começamos com uma função com múltiplos parâmetros e a convertemos em uma sequência de funções, em cadeia, com apenas um parâmetro cada.

Observe esse exemplo convencional:

using System;

namespace FunctionalProgramming
{
    internal class Program
    {
        private static void Main()
        {
            Func<int, int, int> add = (a, b) => a + b;
            Console.WriteLine(add(2, 5));
        }
    }
}

Como você pode ver, definimos uma função de soma simples que aceita dois parâmetros. Aplicar currying  nesse cenário implica em definir uma função que aceite apenas um parâmetro, retorne outra função que espere o segundo parâmetro, para, enfim, retornar o resultado da adição. Observe:

using System;

namespace FunctionalProgramming
{
    internal class Program
    {
        private static void Main()
        {
            Func<int, Func<int, int>> add = a => b => a + b;
            Console.WriteLine(add(2)(5));
        }
    }
}

Perceba como o tipo da função mudou de Func<int, int, int> para Func<int, Func<int, int>>. Como a função interna (inner) utiliza o parâmetro a que é uma variável da função externa (outer), c compilador cria uma closure para essa variável.

Perceba que essa técnica pode ser aplicada independente da quantidade de parâmetros.

using System;

namespace FunctionalProgramming
{
    internal class Program
    {
        private static void Main()
        {
            Func<int, Func<int, Func<int, int>>> add = a => b => c => a + b + c;
            Console.WriteLine(add(2)(5)(7));
        }
    }
}

Facilitando as coisas…

Embora o conceito seja bastante simples, pode ser tedioso (e fácil de errar) escrever funções com currying. Além disso, podemos querer aplicar a técnica em funções já implementadas. Por isso, é bom pensar em escrever algum código de ajuda. Observe:

using System;

namespace FunctionalProgramming
{
    internal class Program
    {
        private static void Main()
        {
            Func<int, int, int> add = (a, b) => a + b;
            var curriedAdd = add.Curry();

            Console.WriteLine("Add result for 2, 2 is: {0}", add(2,2));
            Console.WriteLine("Curried Add result for 2, 2 is: {0}", curriedAdd(2)(2));

        }
    }

    public static class FunctionalExtensions
    {
        public static Func<T1, Func<T2, TResult>> 
            Curry<T1, T2, TResult>(this Func<T1, T2, TResult> func)
        {
            return a => b => func(a, b);
        }

        public static Func<T1, Func<T2, Func<T3, TResult>>>
            Curry<T1, T2, T3, TResult>(this Func<T1, T2, T3, TResult> func)
        {
            return a => b => c => func(a, b, c);
        }

        public static Func<T1, Func<T2, Func<T3, Func<T4, TResult>>>>
            Curry<T1, T2, T3, T4, TResult>(this Func<T1, T2, T3, T4, TResult> func)
        {
            return a => b => c => d => func(a, b, c, d);
        }

        public static Func<T1, Func<T2, Func<T3, Func<T4, Func<T5, TResult>>>>>
            Curry<T1, T2, T3, T4, T5, TResult>(this Func<T1, T2, T3, T4, T5, TResult> func)
        {
            return a => b => c => d => e => func(a, b, c, d, e);
        }
    }
}

Usando Currying em classes

Até aqui, utilizamos Currying apenas em algumas expressões lambdas dentro de um escopo de função. Entretanto, nada nos impede de que façamos uso destas em classes. Veja:

using System;

namespace FunctionalProgramming
{
    internal class Program
    {
        private static void Main()
        {
            Console.WriteLine("Add result for 2, 2 is: {0}", 
                Calculator.Add(2,2));
            Console.WriteLine("Curried Add result for 2, 2 is: {0}", 
                Calculator.AddC(2)(2));
        }
    }

    public static class Calculator
    {
        public static readonly Func<int, int, int>
            Add = (a, b) => a + b;

        public static readonly Func<int, Func<int, int>>
            AddC = Add.Curry();

        public static readonly Func<int, int, int>
            Mult = (a, b) => a * b;

        public static readonly Func<int, Func<int, int>>
            MultC = Mult.Curry();
    }

    public static class FunctionalExtensions
    {
        /* .. */
    }
}

Mas, afinal, por que usar Currying?

A principal razão para utilização de currying é tornar possível chamar uma função com apenas alguns (e não todos) parâmetros que esta precisa para funcionar. Em outras palavras, Currying autoriza a utilização de uma ténica chamada “Partial Application”

Observe:

private static void Main()
{
    Func<int, int, int> add = (a, b) => a + b;
    var addC = add.Curry();
    var add5 = addC(5);
    Console.WriteLine("The result of 5 + 17 is {0}", add5(17));
}

Perceba:

1. construímos uma função de soma simples (variável add);
2. usando os helpers que já definimos, criamos uma “curried version” dessa função (variável addC);
3. chamamos a “curried version” de nossa versão passando apenas o valor (5) de um parâmetro (variável add5);
4. o “retorno” armazenado da “curried version” é uma função que poderá ser chamada quantas vezes desejarmos;

Entendendo Partial Application

Utilizar “Partial Application” permite que criemos uma nova função com base em uma existente. Geralmente, partimos de uma função mais genérica para criar uma função com aplicação mais expecífica.

No exemplo que mostrei acima, tinhamos uma função “genérica” de soma que aceitava dois inteiros. Toda vez que ela fosse chamada aceitaria um novo par de parâmetros e devolveria o resultado. Criamos uma função mais específica para restringir a aplicação a um domínio bem mais restrito de entradas.

Currying Actions

Da mesma forma que “generalizamos” currying para Func, podemos generalizar Actions. Veja:

public static class FunctionalExtensions
{
    /* .. */

    public static Func<T1, Action<T2>>
        Curry<T1, T2>(this Action<T1, T2> action)
    {
        return a => b => action(a, b);
    }

    public static Func<T1, Func<T2, Action<T3>>>
        Curry<T1, T2, T3>(this Action<T1, T2, T3> action)
    {
        return a => b => c => action(a, b, c);
    }

    public static Func<T1, Func<T2, Func<T3, Action<T4>>>>
        Curry<T1, T2, T3, T4>(this Action<T1, T2, T3, T4> action)
    {
        return a => b => c => d => action(a, b, c, d);
    }

    public static Func<T1, Func<T2, Func<T3, Func<T4, Action<T5>>>>>
        Curry<T1, T2, T3, T4, T5>(this Action<T1, T2, T3, T4, T5> action)
    {
        return a => b => c => d => e => action(a, b, c, d, e);
    }
}

Assim, podemos escrever código assim:

using System;

namespace FunctionalProgramming
{
    internal class Program
    {
        private static void Main()
        {
            Console.Title = "Having fun with Currying";

            Action<string, string> print = Console.WriteLine;
            var printC = print.Curry();
            var printAlert = printC("ALERT: {0}");

            printAlert("Hello World");
            printAlert("This is the second alert");
            printAlert("This is the third alert");
            Console.ReadLine();
        }
    }
}

Executando …

Era isso.

Nessa série, mostro os fundamentos do projeto Roslyn. Se está chegando agora, considere visitar o primeiro post (acho que vale a pena).

Aqui, mostro como gerar e inspecionar uma árvore sintática de códigos em C#.

O código que desejamos analisar

Para demonstrar as funcionalidades do Roslyn, escrevi um arquivo com um código de exemplo. Observe:

using System;
using System.Linq;

namespace Demo
{
	class demo
	{
		static void Main(string[] args)
		{
			Console.WriteLine(GetMessage());
		}
		
		static string GetMessage()
		{
			return "Hello World!";
		}		
	}
}

Percorrendo a árvore sintática

Roslyn permite que “interpretemos” um código facilmente. Veja:

using System;
using System.IO;

using Roslyn.Compilers.CSharp;

namespace RoslynSyntaxTree
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            Console.Title = "Roslyn SyntaxTree Demo";

            var source = File.ReadAllText("demo.txt");
            var tree = SyntaxTree.ParseCompilationUnit(source);

            var root = (CompilationUnitSyntax) tree.Root;

            foreach (var @using in root.Usings)
            {
                  Console.WriteLine("Using: {0}", @using.Name.GetText());
            }

            Console.WriteLine("\n");

            var @namespace = (NamespaceDeclarationSyntax) root.Members[0];
            Console.WriteLine("Namespace is {0}", @namespace.Name.GetText());

            var @type = (TypeDeclarationSyntax) @namespace.Members[0];
            Console.WriteLine("Type keyword is {0}; identifier {1}", 
                @type.Keyword.ToString().Trim(),
                @type.Identifier.GetText()
                );

            var @method = (MethodDeclarationSyntax) @type.Members[0];
            Console.WriteLine("First Method identifier is {0}", @method.Identifier);

            var @argument = @method.ParameterList.Parameters[0];
            Console.WriteLine("Argument identifier is {0}",
                @argument.TypeOpt.GetText());

            Console.WriteLine("Argument name is {0}",
                @argument.Identifier.GetText());
            
            Console.ReadLine();
        }
    }
}

Como pode ver, submetemos um código-fonte para o Roslyn. Como resultado, recebemos a árvore sintática correspondente. O código que seguiu, apresenta alguns dados do código conforme essa árvore sintática.

Perceba como os diversos elementos (nodos) da árvore sintática possuem tipos apropriados. Com o cast, conseguimos “especializar” a consulta.

Linq To Code

A árvore sintática gerada pelo Roslyn permite consultas feitas com Linq. Veja:

using System;
using System.IO;
using System.Linq;
using Roslyn.Compilers.CSharp;

namespace RoslynSyntaxTree
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            Console.Title = "Roslyn SyntaxTree Demo";

            var source = File.ReadAllText("demo.txt");
            var tree = SyntaxTree.ParseCompilationUnit(source);
            var root = (CompilationUnitSyntax) tree.Root;

            Action print = Console.WriteLine;
            Action nl = () => print("\n");

            var methods = root.DescendentNodes()
                .OfType();
                          

            foreach (var method in methods)
                print(method.Identifier.GetText());

            nl();

            var methodsStartingWithM = from m in methods
                                       where m.Identifier.GetText().StartsWith("M")
                                       select m;

            foreach (var method in methodsStartingWithM)
                print(method.Identifier.GetText());

            Console.ReadLine();
        }
    }
}

Executando,

Gostou?!

Era isso.

Em um post anterior, mostrei como podemos usar o suporte de caching dos browsers para melhorar o desempenho de nossas aplicações. Naquele momento, mostrei como fazer a implementação “na unha”.

Nesse post, mostro como implementar esse benefício utilizando ASP.net MVC 3. As coisas ficam um pouco mais fáceis.

Caching simples

Considere o seguinte controller:

using System;
using System.Globalization;
using System.Web.Mvc;

namespace ConditionalMVC.Controllers
{
    public class HomeController : Controller
    {
        public string Index()
        {
            return string.Format("Hello from ASP.net MVC {0}", 
                DateTime.Now.ToString(CultureInfo.InvariantCulture));
        }
    }
}

Basicamente, estamos gerando um retorno dinâmico. Executando a aplicação e atualizando o Browser, percebemos que um request é feito a cada atualização.

Vejamos como é o retorno HTTP provido pela infraestrutura do ASP.net.

Nada de especial. Agora, vamos solicitar algum caching. Observe:

using System;
using System.Globalization;
using System.Web.Mvc;

namespace ConditionalMVC.Controllers
{
    [OutputCache(Duration = 10)]
    public class HomeController : Controller
    {
        public string Index()
        {
            return string.Format("Hello from ASP.net MVC {0}", 
                DateTime.Now.ToString(CultureInfo.InvariantCulture));
        }
    }
}

O atributo OutputCache indica que clientes não devem nos “importunar” em intervalos inferiores ao especificado na duração (em segundos). Vejamos o que isso muda na resposta para o browser.

Veja a adição dos atributos Expires e Last-Modified ! São os heróis que vimos no post anterior.

Bacana!

Evitando processamento desnecessário com Last-Modified field

Digamos que você saiba, exatamente, quando seu conteúdo dinâmico resultará algo diferente do que já foi “enviado” ao browser! Pois bem, nesses cenários, você pode evitar o “reprocessamento” devolvendo o status 304 para o cliente (assim, ele entenderá que o conteúdo em Cache continua válido). Observe:

using System;
using System.Globalization;
using System.Web.Mvc;

namespace ConditionalMVC.Controllers
{
    public class HomeController : Controller
    {
        private static int _dummyCounter = 0;
        private static DateTime _lastModified;

        static void Update()
        {
            _dummyCounter++;
            if ((_dummyCounter % 5) == 0)
            {
                _lastModified = DateTime.Now;
                _lastModified = new DateTime(
                    _lastModified.Year, _lastModified.Month, _lastModified.Day,
                    _lastModified.Hour, _lastModified.Minute, _lastModified.Second
                    );
            }
        }

        static HomeController()
        {
            _lastModified = DateTime.Now;
        }

        public string Index()
        {
            Update();
            var response = HttpContext.Response;
            var request = HttpContext.Request;

            var incomingDate = request.Headers["If-Modified-Since"];

            response.Cache.SetLastModified(_lastModified);

            DateTime testDate;
            if (
                DateTime.TryParse(incomingDate, out testDate) && 
                testDate == _lastModified
                )
            {
                response.ClearContent();
                response.StatusCode = 304;
                response.SuppressContent = true;
                return null;
            }

            return string.Format("Hello from ASP.net MVC {0}", 
                DateTime.Now.ToString(CultureInfo.InvariantCulture));
        }
    }
}

Pegou a idéia?! Apenas para fins de ilustração, assumo que “meu conteúdo” deve mudar a cada 5 requests. Obviamente, a lógica que você aplicaria em seu sistema poderia ser outro (envolvendo consulta a última data de modificação de uma tabela em um banco de dados, por exemplo).

Evitando processamento desnecessário com ETag field

Algumas vezes, fica mais fácil determinar modificações através de um hash do conteúdo, em lugar de uma “data de validade”. Observe:

using System;
using System.Globalization;
using System.Web.Mvc;

namespace ConditionalMVC.Controllers
{
    public class HomeController : Controller
    {
        static int _dummyCounter = 0;
        static string _lastHash;
        static string _content;

        static void Update()
        {
            if ((_dummyCounter++ % 5) == 0)
            {
                _content = string.Format("Hello from ASP.net MVC {0}", 
                    DateTime.Now.ToString(CultureInfo.InvariantCulture));
                _lastHash = Guid.NewGuid().ToString();
            }
        }

        public string Index()
        {
            Update();
            var response = HttpContext.Response;
            var request = HttpContext.Request;

            response.Cache.SetETag(_lastHash);

            var incomingHash = request.Headers["If-None-Match"];

            if (
                incomingHash == _lastHash
                )
            {
                response.ClearContent();
                response.StatusCode = 304;
                response.SuppressContent = true;
                return null;
            }

            return _content;
        }
    }
}

Neste exemplo, “gero” um conteúdo novo a cada 5 requests. Atribuo um hash ao ETag e, depois, em cada request, verifico se o hash permanece adequado ao  “conteúdo atual”.

Bela alternativa.

Era isso!