Free Essay

Foundations of F-Sharp

In: Other Topics

Submitted By ADream
Words 52491
Pages 210
The eXPeRT’s VOIce ® In .neT

Robert Pickering
Foreword by Don Syme

Foundations of

Foundations of F#

Robert Pickering

Foundations of F# Copyright © 2007 by Robert Pickering
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13: 978-1-59059-757-6 ISBN-10: 1-59059-757-5 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Lead Editors: James Huddleston, Ewan Buckingham Technical Reviewer: Don Syme Editorial Board: Steve Anglin, Ewan Buckingham, Gary Cornell, Jason Gilmore, Jonathan Gennick, Jonathan Hassell, Chris Mills, Matthew Moodie, Jeffrey Pepper, Dominic Shakeshaft, Matt Wade Project Manager: Elizabeth Seymour Copy Edit Manager: Nicole Flores Copy Editor: Kim Wimpsett Assistant Production Director: Kari Brooks-Copony Production Editor: Laura Cheu Compositor: Lynn L’Heureux Proofreader: Elizabeth Berry Indexer: Broccoli Information Management Artist: April Milne Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail, or visit For information on translations, please contact Apress directly at 2855 Telegraph Avenue, Suite 600, Berkeley, CA 94705. Phone 510-549-5930, fax 510-549-5939, e-mail, or visit The information in this book is distributed on an “as is” basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work. The source code for this book is available to readers at in the Source Code/ Download section.

For Susan and for Jim

Contents at a Glance
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Preface: The Story of the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi


1 2 3 4 5 6 7 8 9 10 11 12 13

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 How to Obtain, Install, and Use F# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Functional Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Imperative Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Object-Oriented Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Organizing, Annotating, and Quoting Code . . . . . . . . . . . . . . . . . . . . 111 The F# Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Distributed Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Language-Oriented Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 The F# Tool Suite and .NET Programming Tools . . . . . . . . . . . . . . . 299 Compatibility and Advanced Interoperation . . . . . . . . . . . . . . . . . . . 323

I INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345


Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Preface: The Story of the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi


Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
What Is Functional Programming? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Why Is Functional Programming Important? . . . . . . . . . . . . . . . . . . . . . . . . . 2 What Is F#? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Who Is Using F#? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Who Is This Book For? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5


How to Obtain, Install, and Use F#


Obtaining F# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Installing F# on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Installing F# on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Using F# in Different Ways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Installing the Software Used in This Book . . . . . . . . . . . . . . . . . . . . . . 13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


Functional Programming

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Values and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Anonymous Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 vii viii


Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 List Comprehensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Types and Type Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Pattern Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Defining Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Exceptions and Exception Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Lazy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53


Imperative Programming

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

The unit Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 The mutable Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Defining Mutable Record Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 The ref Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Array Comprehensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Loops over Comprehensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Calling Static Methods and Properties from .NET Libraries . . . . . . . . . . 69 Using Objects and Instance Members from .NET Libraries . . . . . . . . . . 71 Using Indexers from .NET Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Working with Events from .NET Libraries . . . . . . . . . . . . . . . . . . . . . . . 74 Pattern Matching over .NET Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 The |> Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80


Object-Oriented Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Type Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Type Annotations for Subtyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Records As Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 F# Types with Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Object Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Defining Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Implementing Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Classes, Fields, and Explicit Constructors . . . . . . . . . . . . . . . . . . . . . . 95 Implicit Class Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Classes and Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Classes and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101



Accessing the Base Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Properties and Indexers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Classes and Static Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Overriding Methods from Non-F# Libraries . . . . . . . . . . . . . . . . . . . . . 107 Defining Delegates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Structs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Enums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110


Organizing, Annotating, and Quoting Code

. . . . . . . . . . . . . . 111

Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Opening Namespaces and Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Giving Namespaces and Modules Aliases . . . . . . . . . . . . . . . . . . . . . . 115 Signature Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Module Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Module Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Optional Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Doc Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Custom Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Quoted Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127


The F# Libraries

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Libraries Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 The Native F# Library FSLib.dll . . . . . . . . . . . . . . . . . . . . . . . . . 130 The ML Compatibility Library MLLib.dll . . . . . . . . . . . . . . . . . . . 131 The Native F# Library FSLib.dll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 The Microsoft.FSharp.Core.Operators Module . . . . . . . . . . . . . . 132 The Microsoft.FSharp.Reflection Module . . . . . . . . . . . . . . . . . . 137 The Microsoft.FSharp.Collections.Seq Module . . . . . . . . . . . . . . 139 The Microsoft.FSharp.Core.Enum Module . . . . . . . . . . . . . . . . . 149 The Microsoft.FSharp.Text.Printf Module . . . . . . . . . . . . . . . . . . 151 The Microsoft.FSharp.Control.IEvent Module . . . . . . . . . . . . . . . 154 The Microsoft.FSharp.Math Namespace . . . . . . . . . . . . . . . . . . 156 The ML Compatibility Library MLLib.dll . . . . . . . . . . . . . . . . . . . . . . . 160 The Microsoft.FSharp.Compatibility.OCaml.Pervasives Module . . . 160 The Microsoft.FSharp.Compatibility.OCaml.Arg Module . . . . . . . 164 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166




User Interfaces

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Introducing WinForms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Drawing WinForms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Working with Controls in WinForms . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Using the Visual Studio Form Designer’s Forms in F# . . . . . . . . . . . . . 179 Working with WinForms Events and the IEvent Module . . . . . . . . . . . . 182 Creating New Forms Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Introducing ASP.NET 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Creating an IHttpHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Working with ASP.NET Web Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Introducing Windows Presentation Foundation . . . . . . . . . . . . . . . . . . 195 Introducing Windows Presentation Foundation 3D . . . . . . . . . . . . . . . 197 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207


Data Access

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

The System.Configuration Namespace . . . . . . . . . . . . . . . . . . . . . . . . 209 The System.IO Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 The System.Xml Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 The EntLib Data Access Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Data Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Data Binding and the DataGridView . . . . . . . . . . . . . . . . . . . . . . . . . . 225 ADO.NET Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Introducing LINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Using LINQ to XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Using LINQ to SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

I CHAPTER 10 Distributed Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Networking Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Using TCP/IP Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Using HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Calling Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Creating Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Windows Communication Foundation . . . . . . . . . . . . . . . . . . . . . . . . . 261 Hosting WCF Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270



I CHAPTER 11 Language-Oriented Programming . . . . . . . . . . . . . . . . . . . . . . . . 271
What Is Language-Oriented Programming? . . . . . . . . . . . . . . . . . . . . 271 Data Structures As Little Languages . . . . . . . . . . . . . . . . . . . . . . . . . 271 A Data Structure–Based Language Implementation . . . . . . . . . . 272 Metaprogramming with Quotations . . . . . . . . . . . . . . . . . . . . . . . . . . 278 An Arithmetic-Language Implementation . . . . . . . . . . . . . . . . . . . . . . 280 The Abstract Syntax Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Tokenizing the Text: Fslex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Generating a Parser: Fsyacc . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Using the Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Interpreting the AST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Compiling the AST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Compilation vs. Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

I CHAPTER 12 The F# Tool Suite and .NET Programming Tools . . . . . . . . . 299
Using Useful fsc.exe Command-Line Switches . . . . . . . . . . . . . . . . . . 299 Basic Compiler Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Compiler Optimization Switches . . . . . . . . . . . . . . . . . . . . . . . . 300 Compiler Warning Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Compiler Target Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Signing and Versioning Switches . . . . . . . . . . . . . . . . . . . . . . . . 303 Printing the Interface Switches . . . . . . . . . . . . . . . . . . . . . . . . . 304 Adding Resources Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Generating HTML Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 CLI Version Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Compilation Details Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Statically Linking Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Using fsi.exe Effectively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 fsi.exe Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Controlling the fsi.exe Environment . . . . . . . . . . . . . . . . . . . . . . 308 fsi.exe Command-Line Switches . . . . . . . . . . . . . . . . . . . . . . . . 310 Using the Source Directory Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Writing NUnit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Using Assembly Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Using Debugging Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315



Using Profiling Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Ntimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Perfmon and Performance Counters . . . . . . . . . . . . . . . . . . . . . 317 NProf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 CLR Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

I CHAPTER 13 Compatibility and Advanced Interoperation . . . . . . . . . . . . . 323
Calling F# Libraries from C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Returning Tuples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Exposing Functions That Take Functions As Parameters . . . . . . 324 Using Union Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Using F# Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Defining Types in a Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 329 Defining Classes and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 330 Using F# with the .NET Framework Versions 1 and 1.1 . . . . . . . . . . . 332 Calling Using COM Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Using P/Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Using Inline IL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Using F# from Native Code via COM . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

I INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345


new language needs a simple and clear introductory book that makes it accessible to a broad range of programmers. In Foundations of F#, Robert Pickering has captured the essential elements that the professional programmer needs to master in order to get started with F# and .NET. As the designer of F#, I am thrilled to see Robert take up the challenge of presenting F# in a way that is accessible to a wide audience. F# combines the simplicity and elegance of typed functional programming with the strengths of the .NET platform. Although typed functional programming is relatively new to many programmers and thus requires some learning, in many ways it makes programming simpler. This is mainly because F# programs tend to be built from compositional, correct foundational elements, and type inference makes programs shorter and clearer. Robert first introduces the three foundational paradigms of F#: functional programming, imperative programming, and object-oriented programming, and he shows how F# lets you use them in concert. He then shows how this multiparadigm approach can be used in conjunction with the .NET libraries to perform practical programming tasks such as GUI implementation, data access, and distributed programming. He then introduces some of the particular strengths of F# in the area of “language-oriented” programming. F# is a practical language, and Robert has ensured that the reader is well equipped with information needed to use the current generation of F# tools well. Many computer professionals first encounter functional programming through a short section of the undergraduate curriculum and often leave these courses uncertain about the real-world applicability of the techniques they have been taught. Similarly, some people encounter functional programming only in its purest forms and are uncertain whether it is possible to combine the elements of the paradigm with other approaches to programming and software engineering. Robert has helped remove this uncertainty: typed functional programming is practical, easy to learn, and a powerful addition to the .NET programming landscape. F# is also a research language, used in part to deliver recent advances in language design, particularly those that work well with .NET. It combines a stable and dependable base language with more recent extensions. Robert’s book describes F# 2.0, the latest release of the language at the time of writing. The rest of the F# team and I are very grateful to Robert’s many suggestions, and the language has been greatly improved through this. I hope you enjoy reading this book as much as I enjoyed being its technical reviewer.
Don Syme Cambridge, UK


About the Author
IROBERT PICKERING was born in Sheffield, in the north of England, but a fascination with computers and the “madchester” indie music scene led him to cross the Pennines and study computer science at the University of Manchester. After finishing his degree, he moved to London to catch the tail end of the dot-com boom working at marchFirst; then he moved to Avanade to do some more serious work. At Avanade, he specialized in creating enterprise applications using the .NET Framework, and he got the chance to work on projects in Denmark, Holland, and Belgium; he finally settled in Paris, France, where he lives now with his wife and their two cats. He has been writing about F# almost since it began, and the F# wiki on his web site is among the most popular F# web sites. He currently works for LexiFi, which is an innovative ISV that specializes in software for analyzing and processing complex financial derivatives—products such as swaps and options. LexiFi has pioneered the use of functional programming in finance in order to develop a rigorous formalism for representing financial instruments.


About the Technical Reviewer
IDON SYME is a researcher at Microsoft Research, Cambridge. Born in Toowoomba, Australia, his love for programming was sparked by family and teachers at age 10. He studied at the Australian National University and the University of Cambridge, becoming an expert in the application of automated proof to real-world problems, participating in the team that formally verified the correctness of aspects of the Intel Pentium IV floating-point circuits. Joining Microsoft in 1998, he saw the opportunity to enhance and transform the design of the .NET Framework by including elements of functional programming, beginning with the addition of generics to C# 2.0 and the .NET common language runtime, a project he saw through to completion in Visual Studio 2005. In 2003 he began the design and implementation of F#, which has now become the premier functional programming language for the .NET Framework. He continues to be a driving force in the design, implementation, and enhancement of the language.



f there is one person I feel I should be acknowledging, it is Jim Huddleston, the book’s editor. Jim was there from the book’s beginning. He helped me get it commissioned, he aided me in working out the contents, he gave me much encouragement and constructive criticism, and he showed great skill as an editor. Sadly, Jim died on February 25, 2007, just as the book was entering its final stages of production. Even though I never met Jim in person, never even talked to him on the telephone, I feel a real sense of loss knowing he is gone. My thoughts are with his family at this very sad time, and I’m very disappointed that I never got to meet him in person and that he never saw the finished book. Sadly, Jim’s was not the only death that coincided with the closing stages of writing this book. On March 28, 2007, my uncle Gordon lost his battle with cancer. He was a great lover of life, with many interests. He was a maths teacher who was an avid New Scientist reader with a deep interest in maths and science and a passion for music; he was a talented musician who played many gigs across Orkney and the north of Scotland. He will be greatly missed by me and all my family. I feel very lucky to have worked on the project with my technical reviewer, Don Syme, who went above and beyond the cause by contributing many ideas to the book, helping improve the implementations of many of the samples, and giving me much encouragement. I’d also like to thank all the Apress staff who took part in creating this book, especially Elizabeth Seymour, Kim Wimpsett, and Laura Cheu. I’d also like to thank Don in another capacity, as the creator and developer of F#, along with James Margetson and all the others at Microsoft Research, Cambridge, who worked on F#. Specifically, I’d like to thank them for their hard work on the compiler, and I’d like to let them know that their quick response times to bugs and queries have been very much appreciated. I’d also like to thank all the F# community, in particular Christopher J. Barwick (a.k.a. optionsScalper), who did so much to boost the F# community when he created the hubFS ( I’d like to thank all the people who had to put up with me while I wrote this book. My family: Mum, Dad, and Sister had to put up with me sneaking off to write whenever I went to visit them. Also, my work colleagues often suffered grumpy mornings after late nights of F# hacking and writing: Arnaud, Aurélie, Baptiste, Buuloc, Daniel, Dennis, Emmanuel, Fabrice, François, Frederik, Guillaume, Ibrahima, Jean-Marc, Laurent, Lionel, Oussama, Patrice, Philippe, Regis, Sebastien J., Sebastien P Stefaan, Stefany, and Stephane—I thank you all. Last ., but by no means least, I’d like to thank my wife, Susan, for all the help and support she has given; without her understanding, this book could never have happened.


Preface: The Story of the Book

n 2003 I was looking for a way to process IL, the intermediate language into which all .NET languages are compiled. At the time, .NET was fairly new, and there weren’t a lot of options for doing this. I quickly realized that the best option at the time, and probably still today, was an API called Abstract IL (AbsIL). AbsIL was written in a language called F#, and I decided to use this language to write a small wrapper around AbsIL so I could extract the information I needed from a DLL in a form more usable from C#. But a funny thing happened while writing the wrapper: even though in those days writing F# was a little hard going because the compiler was far from polished, I found that I actually enjoyed programming in F# so much that when I had finished the wrapper, I didn’t want to go back to C#. In short, I was hooked. At the time I was working as a consultant, so I needed to regularly check out new technologies and their APIs; therefore, I got to do all my experimentation using F#. At the same time, people were talking about a new way to communicate on the Web, and a new word was about to enter the English language: blog. I decided I should have a blog because anyone who was anyone in technology seemed to have one, so I created (where my blog can still be found to this today). This was later followed by a wiki about F#, which can also be found at and which continues to be very popular. My job meant I had to do a lot of traveling, so this meant quite a lot of time in hotel rooms or on trains and planes, and I came to view this time as time to try out stuff in F#. So, I ended up exchanging quite a lot emails with Don Syme, and then eventually we met. We went for a beer in the pub where Watson and Crick went after they first pieced together the structure of DNA. Will people talk about the pub were Syme and Pickering first met years from now? Errrm, perhaps not. Anyway, all this led me to the point where I was wondering what I should do with my newfound knowledge of F# and functional programming. About this time a guy called Jim Huddleston mailed the F# mailing list and asked whether anyone would like to write a book about F#. Well, I just couldn’t help myself—it sounded like the job for me. So, with much help and encouragement from Jim, I started writing the book. Some of it was written in Paris where I was living on the weekends, some of it was written in Brussels were I was working during the week, and much of it was written while I was traveling between the two on the Thalys (the high-speed train between France and Belgium). A little of it was written as far north as the Orkney Islands in Scotland while visiting my aunt and uncle, and a little of the reviewing was done while meeting my in-laws in New Zealand. Finally, thanks to the contacts I made while writing the book, I got a new job working for the prestigious ISV LexiFi. It has been great fun watching the language evolve over time and turn from the beginnings of a language into the fully fledged and highly usable language you see today. I hope reading this book changes your life as much as writing it has changed mine.





his introductory chapter will address some of the major questions you may have about F# and functional programming.

What Is Functional Programming?
Functional programming (FP) is the oldest of the three major programming paradigms. The first FP language, IPL, was invented in 1955, about a year before Fortran. The second, Lisp, was invented in 1958, a year before Cobol. Both Fortran and Cobol are imperative (or procedural) languages, and their immediate success in scientific and business computing made imperative programming the dominant paradigm for more than 30 years. The rise of the object-oriented (OO) paradigm in the 1970s and the gradual maturing of OO languages ever since have made OO programming the most popular paradigm today. Despite the vigorous and continuous development of powerful FP languages (SML, OCaml, Haskell, and Clean, among others) and FP-like languages (APL and Lisp being the most successful for real-world applications) since the 1950s, FP remained a primarily academic pursuit until recently. The early commercial success of imperative languages made it the dominant paradigm for decades. Object-oriented languages gained broad acceptance only when enterprises recognized the need for more sophisticated computing solutions. Today, the promise of FP is finally being realized to solve even more complex problems—as well as the simpler ones. Pure functional programming views all programs as collections of functions that accept arguments and return values. Unlike imperative and object-oriented programming, it allows no side effects and uses recursion instead of loops for iteration. The functions in a functional program are very much like mathematical functions because they do not change the state of the program. In the simplest terms, once a value is assigned to an identifier, it never changes, functions do not alter parameter values, and the results that functions return are completely new values. In typical underlying implementations, once a value is assigned to an area in memory, it does not change. To create results, functions copy values and then change the copies, leaving the original values free to be used by other functions and eventually be thrown away when no longer needed. (This is where the idea of garbage collection originated.) The mathematical basis for pure functional programming is elegant, and FP therefore provides beautiful, succinct solutions for many computing problems, but its stateless and recursive nature makes the other paradigms convenient for handling many common programming tasks. However, one of F#’s great strengths is that you can use multiple paradigms and mix them to solve problems in the way you find most convenient.



Why Is Functional Programming Important?
When people think of functional programming, they often view its statelessness as a fatal flaw, without considering its advantages. One could argue that since an imperative program is often 90 percent assignment and since a functional program has no assignment, a functional program could be 90 percent shorter. However, not many people are convinced by such arguments or attracted to the ascetic world of stateless recursive programming, as John Hughes pointed out in his classic paper “Why Functional Programming Matters”: The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. John Hughes, Chalmers University of Technology ( To see the advantages of functional programming, you must look at what FP permits, rather than what it prohibits. For example, functional programming allows you to treat functions themselves as values and pass them to other functions. This might not seem all that important at first glance, but its implications are extraordinary. Eliminating the distinction between data and function means that many problems can be more naturally solved. Functional programs can be shorter and more modular than corresponding imperative and object-oriented programs. In addition to treating functions as values, functional languages offer other features that borrow from mathematics and are not commonly found in imperative languages. For example, functional programming languages often offer curried functions, where arguments can be passed to a function one at a time and, if all arguments are not given, the result is a residual function waiting for the rest of its parameters. It’s also common for functional languages to offer type systems with much better “power-to-weight ratios,” providing more performance and correctness for less effort. Further, a function might return multiple values, and the calling function is free to consume them as it likes. I’ll discuss these ideas, along with many more, in detail and with plenty of examples, in Chapter 3.

What Is F#?
Functional programming is the best approach to solving many thorny computing problems, but pure FP isn’t suitable for general-purpose programming. So, FP languages have gradually embraced aspects of the imperative and OO paradigms, remaining true to the FP paradigm but incorporating features needed to easily write any kind of program. F# is a natural successor on this path. It is also much more than just an FP language. Some of the most popular functional languages, including OCaml, Haskell, Lisp, and Scheme, have traditionally been implemented using custom runtimes, which leads to problems such as lack of interoperability. F# is a general-purpose programming language for .NET, a general-purpose runtime. F# smoothly integrates all three major programming paradigms. With F#, you can choose whichever paradigm works best to solve problems in the most effec, tive way. You can do pure FP if you’re a purist, but you can easily combine functional,



imperative, and object-oriented styles in the same program and exploit the strengths of each paradigm. Like other typed functional languages, F# is strongly typed but also uses inferred typing, so programmers don’t need to spend time explicitly specifying types unless an ambiguity exists. Further, F# seamlessly integrates with the .NET Framework base class library (BCL). Using the BCL in F# is as simple as using it in C# or Visual Basic (and maybe even simpler). F# was modeled on Objective Caml (OCaml), a successful object-oriented FP language, and then tweaked and extended to mesh well technically and philosophically with .NET. It fully embraces .NET and enables users to do everything that .NET allows. The F# compiler can compile for all implementations of the Common Language Infrastructure (CLI), it supports .NET generics without changing any code, and it even provides for inline Intermediate Language (IL) code. The F# compiler not only produces executables for any CLI but can also run on any environment that has a CLI, which means F# is not limited to Windows but can run on Linux, Apple Mac OS X, and OpenBSD. (Chapter 2 covers what it’s like to run F# on Linux.) The F# compiler can be integrated into Visual Studio, supporting IntelliSense expression completion and automatic expression checking. It also gives tooltips to show what types have been inferred for expressions. Programmers often comment that this really helps bring the language to life. F# was invented by Dr. Don Syme and is now the product of a small but highly dedicated team he heads at Microsoft Research (MSR) in Cambridge, England. However, F# is not just a research or academic language. It is used for a wide variety of real-world applications, whose number is growing rapidly. Although other FP languages run on .NET, F# has established itself as the de facto .NET functional programming language because of the quality of its implementation and its superb integration with .NET and Visual Studio. No other .NET language is as easy to use and as flexible as F#!

Who Is Using F#?
F# has a strong presence inside Microsoft, both in MSR and throughout the company as a whole. Ralf Herbrich, coleader of MSR’s Applied Games Group, which specializes in machine learning techniques, is typical of F#’s growing number of fans: The first application was parsing 110GB of log data spread over 11,000 text files in over 300 directories and importing it into a SQL database. The whole application is 90 lines long (including comments!) and finished the task of parsing the source files and importing the data in under 18 hours; that works out to a staggering 10,000 log lines processed per second! Note that I have not optimized the code at all but written the application in the most obvious way. I was truly astonished as I had planned at least a week of work for both coding and running the application. The second application was an analysis of millions of feedbacks. We had developed the model equations and I literally just typed them in as an F# program; together with the reading-data-from-SQL-database and writing-results-to-MATLAB-data-file the F# source code is 100 lines long (including comments). Again, I was astonished by the running time; the whole processing of the millions of data items takes 10 minutes on a



standard desktop machine. My C# reference application (from some earlier tasks) is almost 1,000 lines long and is no faster. The whole job from developing the model equations to having first real world data results took 2 days. Ralf Herbrich, Microsoft Research ( F# usage outside Microsoft is also rapidly growing. I asked Chris Barwick, who runs hubFS (, a popular web site dedicated to F#, about why F# was now his language of choice, and he said this: I’ve been in scientific and mathematics computing for more than 14 years. During that time, I have waited and hoped for a platform that would be robust in every manner. That platform has to provide effective tools that allow for the easy construction and usage of collateral and that makes a scientific computing environment effective. .NET represents a platform where IL gives rise to consistency across products. F# is the language that provides for competent scientific and mathematical computing on that platform.With these tools and other server products, I have a wide range of options with which to build complex systems at a very low cost of development and with very low ongoing costs to operate and to improve. F# is the cornerstone needed for advanced scientific computing. Christopher J. Barwick, JJB Research (private email) Finally, I talked to Jude O’Kelly, a software architect at Derivatives One, a company that sells financial modeling software, about why Derivatives One used F# in its products: We tested our financial models in both C# and F#; the performance was about the same, but we liked the F# versions because of the succinct mathematical syntax. One of our problems with F# was the lack of information; we think this book improves this situation enormously. Jude O’Kelly, Derivatives One (private email)

Who Is This Book For?
This book is aimed primarily at IT professionals who want to get up to speed quickly on F#. A working knowledge of the .NET Framework and some knowledge of either C# or Visual Basic would be nice, but it’s not necessary. All you really need is some experience programming in any language to be comfortable learning F#. Even complete beginners, who’ve never programmed before and are learning F# as their first computer language, should find this book very readable. Though it doesn’t attempt to teach introductory programming per se, it does carefully present all the important details of F#.



What’s Next?
This book teaches F#, by example, as a compiled language rather than a scripting language. By this I mean most examples are designed to be compiled with the fsc.exe compiler, either in Visual Studio or on a command line, rather than executed interactively with fsi.exe, the F# interactive environment. In reality, most examples will run fine either way. Chapter 2 gives you just enough knowledge about setting up an F# development environment to get you going. Chapters 3, 4, 5, and 6 cover the core F# syntax. I deliberately keep the code simple, because this will give you a better introduction to how the syntax works. Chapter 7 looks at the core libraries distributed with F# to introduce you to their flavor and power, rather than to describe each function in detail. The F# online documentation (http:// is the place to get the details. Then you’ll dive into how to use F# for the bread-and-butter problems of the working programmer. Chapter 8 covers user interface programming, Chapter 9 covers data access, and Chapter 10 covers how applications can take advantage of a network. The final chapters take you through the topics you really need to know to master F#. Chapter 11 looks at support for creating little languages or domain-specific languages (DSLs), a powerful and very common programming pattern in F#. Chapter 12 covers the tools you can use to debug and optimize F# programs. Finally, Chapter 13 explores advanced interoperation issues.



How to Obtain, Install, and Use F#

his chapter is designed to get you up and running with F# as quickly as possible. You’ll look at how to obtain F#, how to install it on both Windows and Linux, and how to use the compiler in various ways. I’ll also discuss what version of software the examples in this book were tested with and what extra software you might need to install.

Obtaining F#
You can download F# from the Microsoft Research F# Download page at http://research. The package includes various versions of the compiler, which are compatible with different versions of the CLR, fsi.exe (the F# interactive console), some F#-based parsing tools, the F# base class libraries, the F# documentation, and some F# samples.

Installing F# on Windows
Installing F# on Windows is straightforward. You need to be running as an account with system administrator privileges to install F#. Simply unzip the contents of the F# distribution to a temporary location, and then run the InstallFSharp.msi package, which is in the root of the distribution. The .msi should work whether or not Visual Studio 2003 or Visual Studio 2005 is installed. If you’d prefer not to use an .msi, you can compile from the command line simply by unzipping to your preferred location and running alternative-install.bat, which will install the F# runtime libraries into the global assembly cache (GAC). You can also use this batch file to install F# against the Shared Source Common Language Infrastructure (SSCLI), more commonly known as Rotor, by using the –sscli command-line switch.




I Note The SSCLI is a compressed archive of the source code for a working implementation of the ECMA
CLI and the ECMA C# language specifications. This implementation builds and runs on Windows XP, and you can also compile and run it on other operating systems such as Linux or Mac OS X. This implementation is ideal if you really want to get under the covers and see what’s going on; however, you may find it more difficult to use than .NET, so you’re probably best off sticking with .NET while reading this book.

If you use the alternative-install.bat batch file, Visual Studio integration will not be installed. For installing Visual Studio integration, two further batch files are available, alternative-install-vs2003.bat and alternative-install-vs2005.bat. Please note that at the time of this writing the free Express Editions of Visual Studio do not support plug-ins, so you cannot use F# integration with them.

Installing F# on Linux
It’s difficult to write a simple guide to installing F# on Linux, because there are so many different distributions of Linux and so many ways you can configure them. The following are the steps that worked well for me running SUSE Linux on a single computer. I performed all these steps as the root account. 1. Install Mono using the packages provided with the SUSE Linux distribution; you can find these by searching for mono and then sharp in the Install Software dialog box available from the Computer menu. 2. Unpack the F# distribution, and copy the resulting files to /usr/lib/fsharp. 3. In the /usr/lib/fsharp directory, run chmod +x 4. Run the dos2unix tool on the text file 5. Still in the /usr/lib/fsharp directory, run the command sh After performing those steps, I was able to use F# from any account from the command line by running mono /usr/lib/fsharp/bin/fsc.exe, followed by the command-line options. Obviously, this was inconvenient to run every time, so I created a shell script file in /usr/bin and as fsc: #!/bin/sh exec /usr/bin/mono $MONO_OPTIONS /usr/lib/fsharp/bin/fsc.exe "$@"



I then ran chmod +x fsc to give users permission to execute it. After this, running the F# compiler was as simple as typing fsc at the command line. The F# interactive compiler, fsi.exe, will also run under Linux, but on the installation I used at the time of this writing, I needed to use the --no-gui switch. The shell script for this is as follows: #!/bin/sh exec /usr/bin/mono $MONO_OPTIONS /usr/lib/fsharp/bin/fsi.exe --no-gui "$@"

I Note I used SUSE Linux, available from, because I found it installed smoothly on real and virtual machines, requiring very little manual setup.

Using F# in Different Ways
F# programs are just text files, so you can use any text editor to create them. Just save your program with the extension .fs, and use fsc.exe to compile them. For example, if you had the following program in the text file helloworld.fs: #light print_endline "Hello World" you could just run fsc.exe helloworld.fs to compile your program into helloworld.exe, which would output the following to the console: Hello World In my opinion, the easiest and quickest way to develop F# programs is in Visual Studio in conjunction with the F# interactive compiler (see Figure 2-1). You can type F# programs into the text editor, taking advantage of syntax highlighting and IntelliSense code completion; compile them into executables; and debug them interactively by setting breakpoints and pressing F5. Also, you can execute parts of your code interactively using F# interactive. Just highlight the code you want to execute, and press Alt+Enter; F# interactive will execute the code and show the results. This is great for testing snippets individually.



Figure 2-1. Visual Studio hosting F# interactive

I Note If you are not convinced you want to invest in a copy of Visual Studio, trial versions of this software are available at

If you prefer, you can type your programs into the F# interactive console directly when it’s running in stand-alone mode, as shown in Figure 2-2.



Figure 2-2. The F# interactive console running in stand-alone mode When you use the interactive console, you type the code you want; then when you’ve completed a section, you use two semicolons (;;) to indicate that the compiler should compile and run it. F# interactive responds to commands in two ways. If you bind a value to an identifier, it prints the name of the identifier and its type. So, typing the following into F# interactive: > let i = 1 + 2;; gives the following: val i : int However, if you just type a value into F# interactive, it will respond slightly differently. Typing the following into F# interactive: > 1 + 2;; gives the following: val it : int = 3



This means the value has been bound to a special identifier, called it, that is available to other code within the F# interactive session. When any expression is evaluated at the top level, its value is also printed, after the equals sign; note the 3 in the previous example. As you get to know fsi.exe and F# in general, using F# interactive will become more and more useful for debugging programs and finding out how they work. (I discuss values, identifiers, and types in more detail in Chapter 3.) You can get code completions by pressing Tab. I find this mode of working useful in testing short programs by copying and pasting them into the console or for checking properties on existing libraries. For example, in Figure 2-2 I checked the System.Environment.Version property. However, I find this mode inconvenient for creating longer programs since it’s difficult to store the programs once they’re coded; they have to be copied and pasted from the console. Using Visual Studio, even if you don’t intend to just run them interactively, you can still easily execute snippets with Alt+Enter. If you save your program with the .fsx extension instead of the .fs extension, you can run your programs interactively by right-clicking them and selecting the Run with F# Interactive menu option, as shown in Figure 2-3. This scripting style of programming is great for creating small programs to automate repetitive tasks. This way your program’s configuration, such as the file paths it uses, can be stored inside regular strings in the program and can be quickly edited by the programmer using any text editor as needed.

Figure 2-3. Running an F# script by right-clicking it You can find more information about the F# programming tools and general programming tools for .NET in Chapter 11.



Installing the Software Used in This Book
The code in this book will focus on using fsc.exe, rather than fsi.exe. This is because although fsi.exe is great for testing code, running simple scripts, and running experiments, I believe fsc.exe is more useful for producing finished software. Since there’s little difference between the syntax and the commands, most examples will work with little or no adaptation in fsi.exe, and I’ll warn you when any changes are necessary. All the samples in this book were created using .NET 2.0 running on Windows XP Professional. If you’re using .NET 1.0 or 1.1, you’ll experience problems with many of the samples because quite a few of them use classes and methods from the .NET 2.0 base class library (BCL) that aren’t available in version 1.0 or 1.1. The most common problem you will face when working with .NET 1.0 and 1.1 is that I use System.Collections.Generic.List, referred to as ResizeArray in F#, and System.Collections. Generic.Dictionary. You can always work around this by replacing these two classes with System.Collections.ArrayList and System.Collections.Hashtable, respectively. There may be other places where I use methods or classes not available in .NET 1.0 and 1.1, but generally you will be able to work around this with a little extra coding. At the time of this writing, Mono shipped with its version of Framework 2.0, which the F# compiler targets by default; however, this was still in beta, with a production-quality version due to ship in mid-2007. A small subset of this book’s examples has been tested on Mono 2.0, and the examples ran without problems. A small number of examples use several other software libraries and packages. It’s not necessary to immediately download and install all these software packages, but for specific examples, as listed in Table 2-1, you’ll need to do this at some point. Table 2-1. Additional Software Used Within This Book

.NET Framework 3.0

Used In
Chapter 8, Chapter 10 Chapter 8, Chapter 10 Chapter 9 Chapter 9

URL aspx?FamilyId=10CC340B-F857-4A14-83F525634C3BF043&displaylang=en aspx?familyid=C2B1E300-F358-4523-B479F53D234CDCCF&displaylang=en sql/register/default.aspx aspx?familyid=E719ECF7-9F46-4312-AF896AD8702E4E6E&displaylang=en aspx?familyid=1e902c21-340c-4d13-9f0470eb5e3dceea&displaylang=en aspx?FamilyID=9d467a69-57ff-4ae7-96eeb18c4790cffd&DisplayLang=en

SDK for .NET Framework 3.0

SQL Server 2005 Express Edition SQL Server 2005 Samples

Microsoft .NET LINQ Preview (May 2006) Windows Server 2003 Resource Kit Tools NUnit

Chapter 9

Chapter 12

Chapter 12




Table 2-1. Continued

NProf CLR Profiler for .NET 2.0

Used In
Chapter 12 Chapter 12

URL NProf/Home aspx?familyid=a362781c-3870-43be-8926862b40aa0cd0&displaylang=en


Chapter 12

Obviously, some of these links are a little long to type, so I’ve summarized them all at where I’ll keep them updated.

This chapter described how to install and run F# and the different ways you can work with it. The following chapters will explain how to program with F#, starting in Chapter 3 with functional programming in F#.



Functional Programming

ou saw in Chapter 1 that pure functional programming treats functions as values, relies on recursion for looping, and does not allow changes to state. In this chapter, you’ll survey the major language constructs of F# that support the functional programming paradigm.

Identifiers are the way you give names to values in F# so you can refer to them later in a program. You define an identifier using the keyword let followed by the name of the identifier, an equals sign, and an expression that specifies the value to which the identifier refers. An expression is any piece of code that represents a computation that will return a value. The following expression shows a value being assigned to an identifier: let x = 42 To most people coming from an imperative programming background, this will look like a variable assignment. There are a lot of similarities, but there are key differences. In pure functional programming, once a value is assigned to an identifier, it never changes. This is why I will refer to them throughout this book as identifiers and not variables. You will see in the “Scope” section later in this chapter that, under some circumstances, you can redefine identifiers and that in imperative programming in F#, in some circumstances, the value of an identifier can change. An identifier can refer to either a value or a function, and since F# functions are really values in their own right, this is hardly surprising. (I discuss this relationship in detail in the “Functions and Values” section later in this chapter.) This means F# has no real concept of a function name or parameter name; they are all just identifiers. You write a function definition the same way as a value identifier, except a function has two or more identifiers between the let keyword and the equals sign, as follows: let raisePowerTwo x = x ** 2.0 The first identifier is the name of the function, raisePowerTwo, and the identifier that follows it is the name of the function’s parameter, x.




Most, if not all, programming languages have the concept of keywords. A keyword is a language token that the compiler reserves for special use. In F# you cannot use a keyword as an identifier name or a type name (I discuss types later in this chapter in “Defining Types”). The following are the F# keywords: abstract and as assert asr begin class default delegate do done downcast downto else end exception false finally for fun function if in inherit inline interface land lor lsl lsr lxor match member mod module mutable namespace new null of open or override rec sig static struct then to true try type val when upcast while with



The words listed next are not currently F# keywords but have been reserved for possible future use. It is possible to use them as identifiers or type names now, but the compiler will issue a warning if you do. If you care that your code is compatible with future versions of the compiler, then it is best to avoid using them. I will not use them in the examples in this book. async atomic break checked component const constraint constructor continue decimal eager enum event external fixed functor include method mixin namespace object process property protected public pure readonly return sealed switch virtual void volatile where

If you really need to use a keyword as an identifier or type name, you can use the double back quote syntax: let ``class`` = "style" The usual reason for doing this is when you need to use a member from a library that was not written in F# and that uses one of F#’s keywords as a name (you’ll learn more about using non-F# libraries in Chapter 4). The best practice is to avoid using keywords as identifiers if possible.

Literals represent constant values and are useful building blocks for computations. F# has a rich set of literals, summarized in Table 3-1.



Table 3-1. F# Literals

"Hello\t ", "World\n" @"c:\dir\fs", @""""

F# Type string string

.NET Type
System.String System.String

A string in which a backslash (\) is an escape character A verbatim string where a backslash (\) is a regular character A string that will be stored as a byte array A character A Boolean An integer as a hexadecimal An integer as an octal An integer as a binary A signed byte An unsigned byte A 16-bit integer An unsigned 16-bit integer A 32-bit integer An unsigned 32-bit integer A native-sized integer An unsigned native-sized integer A 32-bit integer An unsigned 32-bit integer A 32-bit IEEE floating-point number A 64-bit IEEE floating-point number An arbitrary large integer An arbitrary large number

"bytesbytesbytes"B 'c' true, false 0x22 0o42 0b10010 34y 34uy 34s 34us 34l 34ul 34n 34un 34L 34UL 3.0F, 3.0f 3.0 3474262622571I 474262612536171N

byte array char bool int/int32 int/int32 int/ int32 sbyte byte int16 uint16 int/int32 uint32 nativeint unativeint int64 uint64 float32 float bigint bignum

System.Byte[] System.Char System.Boolean System.Int32 System.Int32 System.Int32 System.SByte System.Byte System.Int16 System.UInt16 System.Int32 System.UInt32 System.IntPtr System.UIntPtr System.Int64 System.Int64 System.Single System.Double Microsoft.FSharp. Math.BigInt Microsoft.FSharp. Math.BigNum

In F# string literals can contain newline characters, and regular string literals can contain standard escape codes. Verbatim string literals use a backslash (\) as a regular character, and two double quotes ("") are the escape for a quote. You can define all integer types using hexadecimal and octal by using the appropriate prefix and postfix. The following example shows some of these literals in action, along with how to use the F# printf function with a %A pattern to output them to the console. The printf function interprets the %A format pattern using a combination of F#’s reflection (covered in Chapter 7) and the .NET ToString method, which is available for every type, to output values in a readable way. You can also access this functionality by using the print_any and any_to_string functions from the F# library.



#light let message = "Hello World\r\n\t!" let dir = @"c:\projects" let bytes = "bytesbytesbytes"B let xA = 0xFFy let xB = 0o7777un let xC = 0b10010UL let print x = printfn "A%" x let main() = print message; print dir; print bytes; print xA; print xB; print xC main() The results of this example, when compiled and executed, are as follows: "Hello\n World\r\n\t!" "c:\\projects" [|98uy; 121uy; 116uy; 101uy; 115uy; 98uy; 121uy; 116uy; 101uy; 115uy; 98uy; 121uy; 116uy; 101uy; 115uy|] -1y 4095 18UL

Values and Functions
Values and functions in F# are indistinguishable because functions are values, and F# syntax treats them both similarly. For example, consider the following code. On the first line, the value 10 is assigned to the identifier n; then on the second line, a function, add, which takes two parameters and adds them together, is defined. Notice how similar the syntax is, with the only difference being that a function has parameters that are listed after the function name. Since everything is a value in F#, the literal 10 on the first line is a value, and the result of the expression a + b on the next line is also a value that automatically becomes the result of the add function. Note that there is no need to explicitly return a value from a function as you would in an imperative language.



#light let n = 10 let add a b = a + b let addFour = add 4 let result = addFour n printfn "result = %i" result The results of this code, when compiled and executed, are as follows: result = 14 F# also supports the idea of the partial application of functions (these are sometimes called partial or curried functions). This means you don’t have to pass all the arguments to a function at once. I did this in the third line in the previous code, where I passed a single argument to the add function, which takes two arguments. This is very much related to the idea that functions are values. Because a function is just a value, if it doesn’t receive all its arguments at once, it returns a value that is a new function waiting for the rest of the arguments. So, in the example, passing just the value 4 to the add function results in a new function that I have named addFour because it takes one parameter and adds the value 4 to it. At first glance, this idea can look uninteresting and unhelpful, but it is a powerful part of functional programming that you’ll see used throughout the book. This behavior may not always be appropriate; for example, if the function takes two floating-point parameters that represent a point, it may not be desirable to have these numbers passed to the function separately because they both make up the point they represent. You may alternatively surround a function’s parameters with parentheses and separate them with commas, turning them into a tuple (rhymes with “couple”). You can see this in the following code, which will not compile because the sub function requires both parameters to be given at once. This is because sub now has only one parameter, the tuple (a, b), instead of two, and although the call to sub in the second line provides only one argument, it’s not a tuple. You’ll examine tuples properly later in this chapter in “Defining Types.” #light let sub (a, b) = a - b let subFour = sub 4 When attempting to compile this example, you will receive the following error message; this is because the program does not type check as you are trying to pass an integer to a function that takes a tuple. prog.fs(15,19): error: FS0001: This expression has type int but is here used with type 'a * 'b



In general, functions that can be partially applied are preferred over functions that use tuples. This is because functions that can be partially applied are more flexible than tuples, giving users of the function more choice about how to use them. This is especially true when creating a library to be used by other programmers. You may not be able to anticipate all the ways your users will want to use your functions, so it is best to give them the flexibility of functions that can be partially applied. You never need to explicitly return a value, but how do you compute intermediate values within a function? In F#, this is controlled by whitespace. An indention means that the let binding is an intermediate value in the computation, and the end of the expression is signaled by the end of the indented section. To demonstrate this, the next example shows a function that computes the point halfway between two integers. The third and fourth lines show intermediate values being calculated. First the difference between the two numbers is calculated, and this is assigned to the identifier dif using the let keyword. To show that this is an intermediate value within the function, it is indented by four spaces. The choice of the number of spaces is left to the programmer, but the convention is four. Note that you cannot use tabs because these can look different in different text editors, which causes problems when whitespace is significant. After that, the example calculates the midpoint, assigning it to the identifier mid using the same indentation. Finally, you want the result of the function to be the midpoint plus a, so you can simply say mid + a, and this becomes the function’s result. #light let halfWay a b = let dif = b - a let mid = dif / 2 mid + a printfn "(halfWay 5 11) = %i" (halfWay 5 11) printfn "(halfWay 11 5) = %i" (halfWay 11 5) The results of this example are as follows: (halfWay 5 11) = 8 (halfWay 11 5) = 8

I Note It’s the #light declaration, which should be placed at the top of each F# source file, that makes whitespace significant in F#, allowing you to omit certain keywords and symbols such as in, ;, begin, and end. I believe that significant whitespace is a much more intuitive way of programming, because it helps the programmer decide how the code should be laid out; therefore, in this book, I’ll cover the F# syntax only when #light is declared.



The scope of an identifier defines where you can use an identifier (or a type; see “Defining Types” later in this chapter) within a program. Scope is a fairly simple concept, but it is important to have a good understanding because if you try to use an identifier that’s not in scope, you will get a compile error. All identifiers, whether they relate to functions or values, are scoped from the end of their definitions until the end of the sections in which they appear. So, for identifiers that are at the top level (that is, identifiers not local to another function or other value), the scope of the identifier is from the place where it’s defined to the end of the source file. Once an identifier at the top level has been assigned a value (or function), this value cannot be changed or redefined. An identifier is available only after its definition has ended, meaning that it is not usually possible to define an identifier in terms of itself. Identifiers within functions are scoped to the end of the expression that they appear in; ordinarily, this means they’re scoped until the end of the function definition in which they appear. So if an identifier is defined inside a function, then it cannot be used outside it. Consider the next example, which will not compile since it attempts to use the identifier message outside the function defineMessage: #light let defineMessage() = let message = "Help me" print_endline message print_endline message When trying to compile this code, you’ll get the following error message: Prog.fs(34,17): error: FS0039: The value or constructor 'message' is not defined. Identifiers within functions behave a little differently from identifiers at the top level, because they can be redefined using the let keyword. This is useful; it means that the F# programmer does not have to keep inventing names to hold intermediate values. To demonstrate, the next example shows a mathematical puzzle implemented as an F# function. Here you need to calculate lots of intermediate values that you don’t particularly care about; inventing names for each one these would be an unnecessary burden on the programmer. #light let mathsPuzzle() = print_string "Enter day of the month on which you were born: " let input = read_int () let x = input * 4 // Multiply it by 4 let x = x + 13 // Add 13 let x = x * 25 // Multiply the result by 25 let x = x - 200 // Subtract 200 print_string "Enter number of the month you were born: " let input = read_int () let x = x + input



let x = x * 2 // Multiply by 2 let x = x - 40 // Subtract 40 let x = x * 50 // Multiply the result by 50 print_string "Enter last two digits of the year of your birth: " let input = read_int () let x = x + input let x = x - 10500 // Finally, subtract 10,500 printf "Date of birth (ddmmyy): %i" x mathsPuzzle() The results of this example, when compiled and executed, are as follows: Enter day of the month on which you were born: 23 Enter number of the month you were born: 5 Enter last two digits of the year of your birth: 78 Date of birth (ddmmyy): 230578 I should note that this is different from changing the value of an identifier. Because you’re redefining the identifier, you’re able to change the identifier’s type, but you still retain type safety.

I Note Type safety, sometimes referred to as strong typing, basically means that F# will prevent you from performing an inappropriate operation on a value; for example, you can’t treat an integer as if it were a floating-point number. I discuss types and how they lead to type safety later in this chapter in the section “Types and Type Inference.”

The next example shows code that will not compile, because on the third line you change the value of x from an integer to the string "change me", and then on the fourth line you try to add a string and an integer, which is illegal in F#, so you get a compile error: #light let changeType () = let x = 1 let x = "change me" let x = x + 1 print_string x

// bind x to an integer // rebind x to a string // attempt to rebind to itself plus an integer

This program will give the following error message because it does not type check: prog.fs(55,13): error: FS0001: This expression has type int but is here used with type string stopped due to error



If an identifier is redefined, its old value is available while the definition of the identifier is in progress but after it is defined; that is, after the new line at the end of the expression, the old value is hidden. If the identifier is redefined inside a new scope, the identifier will revert to its old value when the new scope is finished. The next example defines a message and prints it to the console. It then redefines this message inside an inner function called innerFun that also prints the message. Then, it calls the function innerFun and after that prints the message a third time. #light let printMessages() = // define message and print it let message = "Important" printfn "%s" message; // define an inner function that redefines value of message let innerFun () = let message = "Very Important" printfn "%s" message // define message and print it innerFun () // finally print message again printfn "%s" message printMessages() The results of this example, when compiled and executed, are as follows: Important Very Important Important A programmer from the imperative world might have expected that message when printed out for the final time would be bound to the value Very Important, rather than Important. It holds the value Important because the identifier message is rebound, rather than assigned, to the value Very Important inside the function innerFun, and this binding is valid only inside the scope of the function innerFun, so once this function has finished, the identifier message reverts to holding its original value.

I Note Using inner functions is a common and excellent way of breaking up a lot of functionality into manageable portions, and you will see their usage throughout the book. They are sometimes referred to as closures or lambdas, although these two terms have more specific meanings. A closure means that the function uses a value that is not defined at the top level, and a lambda is an anonymous function. The section “Anonymous Functions” later in the chapter discusses these concepts in more detail.



Recursion means defining a function in terms of itself; in other words, the function calls itself within its definition. Recursion is often used in functional programming where you would use a loop in imperative programming. Many believe that algorithms are much easier to understand when expressed in terms of recursion rather than loops. To use recursion in F#, use the rec keyword after the let keyword to make the identifier available within the function definition. The following example shows recursion in action. Notice how on the fifth line the function makes two calls to itself as part of its own definition. #light let rec fib x = match x with | 1 -> 1 | 2 -> 1 | x -> fib (x - 1) + fib (x - 2) printfn "(fib 2) = %i" (fib 2) printfn "(fib 6) = %i" (fib 6) printfn "(fib 11) = %i" (fib 11) The results of this example, when compiled and executed, are as follows: (fib 2) = 1 (fib 6) = 8 (fib 11) = 89 This function calculates the nth term in the Fibonacci sequence. The Fibonacci sequence is generated by adding the previous two numbers in the sequence, and it progresses as follows: 1, 1, 2, 3, 5, 8, 13, …. Recursion is most appropriate for calculating the Fibonacci sequence, because the definition of any number in the sequence, other than the first two, depends on being able to calculate the previous two numbers, so the Fibonacci sequence is defined in terms of itself. Although recursion is a powerful tool, you should always be careful when using it. It is easy to inadvertently write a recursive function that never terminates. Although intentionally writing a program that does not terminate is sometimes useful, it is rarely the goal when trying to perform calculations. To ensure that recursive functions terminate, it is often useful to think of recursion in terms of a base case and the recursive case. The recursive case is the value for which the function is defined in terms of itself; for the function fib, this is any value other than 1 and 2. The base case is the nonrecursive case; that is, there must be some value where the function is not defined in terms of itself. In the fib function, 1 and 2 are the base cases. Having a base case is not enough in itself to ensure termination. The recursive case must tend toward the base case. In the fib example, if x is greater than or equal to 3, then the recursive case will tend toward the base case because x will always become smaller and at some point reach 2. However, if x is less than 1, then x will grow continually more negative, and the function will recurse until the limits of the machine are reached, resulting in a stack overflow error (System.StackOverflowException).



The previous code also uses F# pattern matching, which I discuss in the “Pattern Matching” section later in this chapter.

Anonymous Functions
F# provides an alternative way to define functions using the keyword fun; you can see this in the following example. Ordinarily, you would use this notation when it is not necessary to give a name to a function, so these are referred to as anonymous functions and sometimes called lambda functions or even just lambdas. The idea that a function does not need a name may seem a little strange, but if a function is to be passed as an argument to another function, then often you don’t need to give it a name of its own. I demonstrate this idea in the section “Lists” later in this chapter when you look at operations on lists. The arguments defined for this style of function can follow the same rules as when defining a function with a name, meaning that you can define the arguments so they can be partially applied or defined in the form of a tuple (see the section “Defining Types” later in this chapter for an explanation of tuples). The following example shows two functions that are created and then immediately applied to arguments so that the identifier x holds the result of the function rather than the function itself: #light let x = (fun x y -> x + y) 1 2 You can create an anonymous function with the keyword function. Creating functions this way differs from using the keyword fun since you can use pattern matching when using the keyword function (see the section “Pattern Matching” later in this chapter). Consequently, it can be passed only one argument, but you can do a couple of things if the function needs to have multiple parameters. The first line of the following example shows a function using the function keyword written so the function can be partially applied, meaning the arguments can be passed one at a time if needed. The second line shows a function defined using the function keyword that takes a tuple argument. let x1 = (function x -> function y -> x + y) 1 2 let x2 = (function (x, y) -> x + y) (1, 2) The keyword fun is generally preferred when defining anonymous functions because it is more compact; you can see this is the case when browsing the source for the libraries and examples distributed with F#.

In F#, you can think of operators as a more aesthetically pleasing way to call functions. F# has two different kinds of operators, prefix and infix; a prefix operator is an operator that takes one operand, and an infix operator takes two or more. Prefix operators appear before their operand, whereas infix operators appear between the first two operands. F# provides a rich and diverse set of operators that you can use with numeric, Boolean, string, and collection types. The operators defined in F# and its libraries are too numerous to be covered in this section, so instead you’ll look at the way you use and define operators in F# rather than looking at individual operators.



Like in C#, F# operators are overloaded, meaning you can use more than one type with an operator; however, unlike in C#, both operands must be the same type, or the compiler will generate an error. F# also allows users to define and redefine operators; I discuss how to do that at the end of this section. Operators follow a set of rules similar to C#’s for operator overloading resolution; therefore, any class in the BCL, or any .NET library, that was written to support operator overloading in C# will support it in F#. For example, you can use the + operator to concatenate stings (you can also use ^ for this) as well as to add a System.TimeSpan to a System.DataTime because these types support an overload of the + operator. The following example illustrates this: #light let ryhm = "Jack " + "and " + "Jill" let anotherRyhm = "Wee " ^ "Willy " ^ "Winky" open System let oneYearLater = DateTime.Now + new TimeSpan(365, 0, 0, 0, 0) Users can define their own operators or redefine any of the existing ones if they want (although this is not always advisable, because the operators then no longer support overloading). Consider the following perverse example that redefines + to perform subtraction: #light let (+) a b = a - b print_int (1 + 1) User-defined (custom) operators must be nonalphanumeric and can be a single character or a group of characters. You can use the following characters in custom operators: !$%&*+-./?@^|~ : Custom operators can start with any of the characters on the first line and after that can use any of these characters and also the colon (:), listed on the second line. The syntax for defining an operator is the same as using the let keyword to define a function, except the operator replaces the function name and is surrounded by parentheses so the compiler knows that the symbols are used as a name of an operator rather than as the operator itself. The following example shows defining a custom operator, +:*, that adds its operands and then multiplies them: #light let ( +:* ) a b = (a + b) * a * b printfn "(1 +:* 2) = %i" (1 +:* 2) The results of this example, when compiled and executed, are as follows: (1 +:* 2) = 6 Unary operators always come before the operand; binary operators are always infix.



F# lists are simple collection types that are built into F#. An F# list can be an empty list, represented by square brackets ([]), or it can be another list with a value concatenated to it. You concatenate values to the front of an F# list using a built-in operator that consists of two colons (::), pronounced “cons.” The next example shows some lists being defined, starting with an empty list on the first line, followed by two lists where strings are placed at the front by concatenation: #light let emptyList = [] let oneItem = "one " :: [] let twoItem = "one " :: "two " :: [] The syntax to add items to a list by concatenation is a little verbose, so if you just want to define a list, you can use shorthand. In this shorthand notation, you place the list items between square brackets and separate them with a semicolon (;), as follows: #light let shortHand = ["apples "; "pairs "] F# has a second operator that works on lists; this is the at (@) symbol, which you can use to concatenate two lists together, as follows: let twoLists = ["one, "; "two, "] @ ["buckle "; "my "; "shoe "] All items in an F# list must be of the same type, and if you try to place items of different types in a list—for example, you try to concatenate a string to a list of integers—you will get a compile error. If you need a list of mixed types, you can create a list of type obj (the F# equivalent of System.Object), as in the following code. I discuss types in F# in more detail in “Types and Type Inference” and “Defining Types” later in this chapter. #light let emptyList = [] let oneItem = "one " :: [] let twoItem = "one " :: "two " :: [] let shortHand = ["apples "; "pairs "] let twoLists = ["one, "; "two, "] @ ["buckle "; "my "; "shoe "] let objList = [box 1; box 2.0; box "three"] let printList l = List.iter print_string l print_newline()



let main() = printList printList printList printList printList

emptyList oneItem twoItem shortHand twoLists

for x in objList do print_any x print_char ' ' print_newline() main() The results of these examples, when compiled and executed, are as follows: one one two apples pairs one, two, buckle my shoe 1 2.000000 "three" F# lists are immutable; in other words, once a list is created, it cannot be altered. The functions and operators that act on lists do not alter them, but they create a new, altered version of the list, leaving the old list available for later use if needed. The next example shows this. An F# list containing a single string is created, and then two more lists are created, each using the previous one as a base. Finally, the List.rev function is applied to the last list to create a new reversed list. When you print these lists, it is easy to see that all the original lists remain unaltered. #light let one = ["one "] let two = "two " :: one let three = "three " :: two let rightWayRound = List.rev three let printList l = List.iter print_string l print_newline() let main() = printList printList printList printList main()

one two three rightWayRound



The results of this example, when compiled and executed, are as follows: one two one three two one one two three The regular way to work with F# lists is to use recursion. The empty list is the base case, and when a function working on a list receives the empty list, the function terminates; when the function receives a nonempty list, it processes the first item in the list (the head) and then recursively processes the remainder of the list (the tail). The next example demonstrates processing a list recursively: #light let listOfList = [[2; 3; 5]; [7; 11; 13]; [17; 19; 23; 29]] let rec concatList l = if List.nonempty l then let head = List.hd l in let tail = l in head @ (concatList tail) else [] let primes = concatList listOfList print_any primes First, you define an F# list composed of three other lists. Then, you define a recursive function, concatList, which is designed to merge a list of lists into one list. The function uses an F# library function, List.nonempty, to check whether the F# list is empty. If it is not empty, the function takes the head and tail of the list, passes the tail to a call to itself, and then concatenates the head of the list to the result. If the tail is empty, the function must still return something, so it simply returns the empty list, [], because concatenating the empty list with another list has no effect on the contents of the list. The results of this example, when compiled and executed, are as follows: [2; 3; 5; 7; 11; 13; 17; 19; 23; 29] The concatList function is fairly verbose for what this example is trying to achieve. Fortunately, F# includes some pattern matching syntax for lists that can really help tidy this up. I cover this syntax later in this chapter in “Pattern Matching.” All the examples in this section demonstrate another nice feature of F# lists, the set of library functions provided for lists. The List.iter function is a library function that takes two arguments. The first argument is a function that will be applied to each item in the list, and the second is the list to which that function will be applied. You can think of the List.iter function as just a nice shorthand way to write a for loop over a list, and the library contains



many other functions for transforming and manipulating lists, including a List.concat function that has a similar effect to the concatList function defined earlier. For more information about these functions, see Chapter 7, which covers the F# ML compatibility library.

List Comprehensions
List comprehensions make creating and converting collections easy. You can create F# lists, sequences, and arrays directly using comprehension syntax. (I cover arrays in more detail in the next chapter, and sequences are collections of type seq, which is F#’s name for the .NET BCL’s IEnumerable type; I describe them in the section “Lazy Evaluation.”) The simplest comprehensions specify ranges, where you write the first item you want, either a number or a letter, followed by two periods (..) and then the last item you want, all within square brackets (to create a list) or braces (to create a sequence). The compiler then does the work of calculating all the items in the collection, taking the first number and incrementing it by 1, or similarly with characters, until it reaches the last item specified. The following example demonstrates how to create a list of numbers from 0 through 9 and a sequence of the characters from A through Z: #light let numericList = [ 0 .. 9 ] let alpherSeq = { 'A' .. 'Z' } printfn "%A" numericList printfn "%A" alpherSeq The results of this example are as follows: [0; 1; 2; 3; 4; 5; 6; 7; 8; 9] seq ['A'; 'B'; 'C'; 'D'; ...] To create more interesting collections, you can also specify a step size for incrementing numbers—note that characters do not support this type of list comprehension. You place the step size between the first and last items separated by an extra pair of periods (..). The next example shows a list containing multiples of 3, followed by a list that counts backward from 9 to 0: #light let multiplesOfThree = [ 0 .. 3 .. 30 ] let revNumericSeq = [ 9 .. -1 .. 0 ] printfn "%A" multiplesOfThree printfn "%A" revNumericSeq The results of this example are as follows: [0; 3; 6; 9; 12; 15; 18; 21; 24; 27; 30] [9; 8; 7; 6; 5; 4; 3; 2; 1; 0]



List comprehensions also allow loops to create a collection from another collection. The idea is that you enumerate the old collection, transform each of its items, and place any generated items in the new collection. To specify such a loop, use the keyword for, followed by an identifier, followed by the keyword in, at the beginning of the list comprehension. In the next example, you create a sequence of the squares of the first ten positive integers. You use for to enumerate the collection 1 .. 10, assigning each item in turn to the identifier x. You then use the identifier x to calculate the new item, in this case multiplying x by itself to square it. #light let squares = { for x in 1 .. 10 -> x * x } print_any squares The results of this example are as follows: seq [1; 4; 9; 16; ...] You can also add a when guard to suppress items you don’t want in the collection. A when guard is the keyword when followed by a Boolean expression. Only when the when guard evaluates to true will an item be placed in the collection. The next example demonstrates how to use a when guard, checking whether the modulus of x is zero. This is an easy way to check whether a number is even, and only if the number is even is it placed in the collection. The example also demonstrates how to create a function that returns a sequence based on a list comprehension. In the function evens, the parameter n specifies the size of the collection to be generated. #light let evens n = { for x in 1 .. n when x % 2 = 0 -> x } print_any (evens 10) The results of this example are as follows: seq [2; 4; 6; 8; ...] It’s also possible to use list comprehensions to iterate in two or more dimensions by using a separate loop for each dimension. In the next example, you define a function, squarePoints, that creates a sequence of points forming a square grid, each point represented by a tuple of two integers. #light let squarePoints n = { for x in 1 .. n for y in 1 .. n -> x,y } print_any (squarePoints 3) The results of this example are as follows: [(1, 1); (1, 2); (1, 3); (2, 1); ...]



You’ll look at using comprehensions with arrays and collections from the .NET Framework BCL in Chapter 4.

Control Flow
F# has a strong notion of control flow. In this way it differs from many pure functional languages, where the notion of control flow is very loose, because expressions can be evaluated in essentially any order. You can see the strong notion of control flow in the following if … then … else … expression. In F# the if … then … else … construct is an expression, meaning it returns a value. One of two different values will be returned, depending on the value of the Boolean expression between the if and then keywords. The next example illustrates this. The if … then … else … expression is evaluated to return either "heads" or "tails" depending on whether the program is run on an even second or an odd second. #light let result = if System.DateTime.Now.Second % 2 = 0 then "heads" else "tails" print_string result The if … then … else … expression has some implications that you might not expect if you are more familiar with imperative-style programming. F#’s type system requires that the values being returned by the if … then … else … expression must be the same type, or the compiler will generate an error. So, if in the previous example you were to replace the string "tails" with an integer or Boolean value, you would get a compile error. If you really require the values to be of different types, you can create an if … then … else … expression of type obj (F#’s version of System.Object); the next example shows how to do this. It prints either "heads" or false to the console. #light let result = if System.DateTime.Now.Second % 2 = 0 then box "heads" else box false print_any result Imperative programmers may be surprised that an if … then … else … expression must have an else if the expression returns a value. This is pretty logical when you think about it and if you consider the examples you’ve just seen. If the else were removed from the code, the identifier result could not be assigned a value when the if evaluated to false, and having uninitialized identifiers is something that F#, and functional programming in general, aims to avoid. There is a way for a program to contain an if … then expression without the else, but this is very much in the style of imperative programming, so I discuss it in Chapter 4.



Types and Type Inference
F# is a strongly typed language, which means you cannot use a function with a value that is inappropriate. You cannot call a function that has a string as a parameter with an integer argument; you must explicitly convert between the two. The way the language treats the type of its values is referred to as its type system. F# has a type system that does not get in the way of routine programming. In F#, all values have a type, and this includes values that are functions. Ordinarily, you don’t need to explicitly declare types; the compiler will work out the type of a value from the types of the literals in the function and the resulting types of other functions it calls. If everything is OK, the compiler will keep the types to itself; only if there is a type mismatch will the compiler inform you by reporting a compile error. This process is generally referred to as type inference. If you want to know more about the types in a program, you can make the compiler display all inferred types with the –i switch. Visual Studio users get tooltips that show types when they hover the mouse pointer over an identifier. The way type inference works in F# is fairly easy to understand. The compiler works through the program assigning types to identifiers as they are defined, starting with the top leftmost identifier and working its way down to the bottom rightmost. It assigns types based on the types it already knows, that is, the types of literals and (more commonly) the types of functions defined in other source files or assemblies. The next example defines two F# identifiers and then shows their inferred types displayed on the console with the F# compiler’s –i switch. The types of these two identifiers are unsurprising, string and int, respectively, and the syntax used by the compiler to describe them is fairly straightforward: the keyword val (meaning “value”) and then the identifier, a colon, and finally the type. #light let aString = "Spring time in Paris" let anInt = 42

val aString : string val anInt : int The definition of the function makeMessage in the next example is a little more interesting. You should note two things about makeMessage. First, its definition is prefixed with the keyword val, just like the two values you saw before, since even though it is a function, the F# compiler still considers it to be a value. Second, the type itself uses the notation int -> string, meaning a function that takes an integer and returns a string. The -> between the type names (an ASCII arrow, or just arrow) represents the transformation of the function being applied. It is worth noting that the arrow represents a transformation of the value but not necessarily the type, because it can represent a function that transforms a value into a value of the same type, as shown in the half function on the second line.



#light let makeMessage x = (string_of_int x) + " days to spring time" let half x = x / 2

val makeMessage : int -> string val half : int -> int The types of functions that can be partially applied and functions that take tuples differ. See the section “Values and Functions” earlier in the chapter for an explanation of the difference between these types of functions. The functions div1 and div2 are designed to illustrate this. The function div1 can be partially applied, and its type is int -> int -> int, representing that the arguments can be passed in separately. You can compare this to the function div2 that has the type int * int -> int, meaning a function that takes a pair of integers, a tuple of integers, and turns them into a single integer. You can see this in the function div_remainder, which performs integer division and also returns the remainder at the same time. Its type is int -> int -> int * int, meaning a curried function that returns an integer tuple. let div1 x y = x / y let div2 (x, y) = x / y let divRemainder x y = x / y, x % y

val div1 : int -> int -> int val div2 : int * int -> int val divRemainder : int -> int -> int * int The next function, doNothing, looks inconspicuous enough, but it is quite interesting from a typing point of view. It has the type 'a -> 'a, meaning a function that takes a value of one type and returns a value of the same type. Any type that begins with a single quotation mark (') means a variable type. F# has a type, obj, that maps to System.Object and that represents a value of any type, a concept that you will probably be familiar with from other common language runtime (CLR)–based programming languages (and indeed many languages that do not target the CLR). However, a variable type is not the same. Notice how the type has an 'a on both sides of the arrow. This means the compiler knows that even though it does not yet know the type, it knows that the type of the return value will be the same as the type of the argument. This feature of the type system, sometimes referred to as type parameterization, allows the compiler to find more type errors at compile time and can help avoid casting. let doNothing x = x

val doNothing : 'a -> 'a



I Note The concept of a variable type, or type parameterization, is closely related to the concept of generics that were introduced in the CLR version 2.0 and have now become part of the EMCA specification for the CLI version 2.0. When F# targets a CLI that has generics enabled, it takes full advantage of them by using them anywhere it finds an undetermined type. It is also worth noting that Don Syme, the creator of F#, designed and implemented generics in the .NET CLR before he started working on F#. One might be temped to infer that he did this so he could create F#!

The function doNothingToAnInt, shown next, is an example of a value being constrained, a type constraint; in this case, the function parameter x is constrained to be an int. The syntax for constraining a value to be of a certain type is straightforward. Within parentheses, the identifier name is followed by a colon (:) followed by the type name; this is also sometimes called a type annotation. Constraining values is not usually necessary when writing pure F#, though it can occasionally be useful. It’s most useful when using .NET libraries written in languages other than F# and for interoperation with unmanaged libraries. In both these cases, the compiler has less type information, so it is often necessary to give it enough information to disambiguate things. It is possible to constrain any identifier, not just function parameters, to be of a certain type, though it is more typical to have to constrain parameters. The list stringList here shows how to constrain an identifier that’s not a function parameter: let doNothingToAnInt (x : int) = x let intList = [1; 2; 3] let (stringList : list) = ["one"; "two"; "three"]

val doNothingToAnInt _int : int -> int val intList : int list val stringList : string list The intList value is a list of integers, and the identifier’s type is int list. This indicates that the compiler has recognized that the list contains only integers and that in this case the type of its items is not undetermined but is int. Any attempt to add anything other than values of type int to the list will result in a compile error. The identifier stringList has a type annotation. Although this is unnecessary, since the compiler can resolve the type from the value, it is used to show an alternative syntax for working with undermined types. You can place the type between angle brackets after the type that it is associated with instead of just writing it before the type name. Note that even though the type of stringList is constrained to be list (a list of strings), the compiler still reports its type as string list when displaying the type, and they mean exactly the same thing. This syntax is supported to make F# types with a type parameter look like generic types from other .NET libraries.



Pattern Matching
Pattern matching allows you to look at the value of an identifier and then make different computations depending on its value. It is a bit like a chain of if … then … else … expressions and also might be compared to the switch statement in C++ and C#, but it is much more powerful and flexible than either. The pattern matching construct in F# allows you to pattern match over a variety of types and values. It also has several different forms and crops up in several places in the language including its exception handling syntax, which I discuss in “Exceptions and Exception Handling” later in this chapter. The simplest form of pattern matching is matching over a value, and you have already seen this earlier in this chapter in the section “Values and Functions,” where you used it to implement a function that generated numbers in the Fibonacci sequence. To illustrate the syntax, the next example shows an implementation of a function that will produce the Lucas numbers, a sequence of numbers as follows: 1, 3, 4, 7, 11, 18, 29, 47, 76, …. The Lucas sequence has the same definition as the Fibonacci sequence; only the starting points are different. #light let rec luc x = match x with | x when x failwith "value must be greater than 0" | 1 -> 1 | 2 -> 3 | x -> luc (x - 1) + luc (--x - 2) printfn printfn printfn printfn "(luc "(luc "(luc "(luc 2) = %i" (luc 2) 6) = %i" (luc 6) 11) = %i" (luc 11) 12) = %i" (luc 12)

The results of this example, when compiled and executed, are as follows: (luc (luc (luc (luc 2) = 3 6) = 18 11) = 199 12) = 322

This syntax for pattern matching is the keyword match followed by the identifier that will be matched and then the keyword with. This is followed by all the possible matching rules separated by vertical bars (|). In the simplest case, a rule consists of either a constant or an identifier, followed by an arrow (->) and then by the expression to be used when the value matches the rule. In this definition of the function luc, you can see that the second two cases are literals, the values 1 and 2, and these will just be replaced with the values 1 and 3, respectively. The fourth case will match any value of x greater than 2, and this will cause two further calls to the luc function. The rules are matched in the order in which they are defined, and the compiler will issue an error if pattern matching is incomplete, that is, if there is some possible input value that will not match any rule. This would be the case in the luc function if you had omitted the final



rule, because any values of x greater than 2 would not match any rule. The compiler will also issue a warning if there are any rules that will never be matched, typically because there is another rule in front of them that is more general. This would be the case in the luc function if the fourth rule were moved ahead of the first rule. In this case, none of the other rules would ever be matched because the first rule would match any value of x. You can add a when guard (as in the first rule of the example) to give exact control about when a rule fires. A when guard is composed of the keyword when followed by a Boolean expression. Once the rule is matched, the when clause is evaluated, and the rule will fire only if the expression evaluates to true. If the expression evaluates to false, the remaining rules will be searched for another match. The first rule is designed to be the function’s error handler. The first part of the rule is an identifier that will match any integer, but the when guard means the rule will match only those integers that are less than or equal to zero. If you want, you can omit the first |. This can be useful when the pattern match is small and you want to fit it on one line. You can see this in the next example, which also demonstrates the use of the underscore (_) as a wildcard. The _ will match any value and is a way of telling the compiler that you’re not interested in using this value. For example, in this booleanToString function, you do not need to use the constant true in the second rule, because if the first rule is matched, you know that the value of x will be true. Moreover, you do not need to use x to derive the string "True", so you can ignore the value and just use _ as a wildcard. #light let booleanToString x = match x with false -> "False" | _ -> "True" Another useful feature of pattern matching is that you can combine two patterns into one rule through the use of the vertical bar (|). The next example, stringToBoolean, demonstrates this. In the first two rules, you have two strings that you would like to have evaluate to the same value, so rather than having two separate rules, you can just use | between the two patterns. #light let stringToBoolean x = match x with | "True" | "true" -> false | "False" | "false" -> true | _ -> failwith "unexpected input" printfn "(booleanToString true) = %s" (booleanToString true) printfn "(booleanToString false) = %s" (booleanToString false) printfn "(stringToBoolean \"True\") = %b" (stringToBoolean "True") printfn "(stringToBoolean \"false\") = %b" (stringToBoolean "false") printfn "(stringToBoolean \"Hello\") = %b" (stringToBoolean "Hello")



The results of these examples, when compiled and executed, are as follows: (booleanToString true) = True (booleanToString false) = False (stringToBoolean "True") = false (stringToBoolean "false") = true (stringToBoolean "Hello") = Microsoft.FSharp.FailureException: unexpected input at Prog.stringToBoolean(String x) at Prog._main() It is also possible to pattern match over most of the types defined by F#. The next two examples demonstrate pattern matching over tuples, with two functions that implement a Boolean “and” and “or” using pattern matching. Each takes a slightly different approach. #light let myOr b1 b2 = match b1, b2 with | true, _ -> true | _, true -> true | _ -> false let myAnd p match p | true, | _ -> = with true -> true false

The myOr function has two Boolean parameters, and they are placed between the match and with keywords and separated by commas to form a tuple. The myAnd function has one parameter, which is itself a tuple. Either way, the syntax for creating pattern matches for tuples is the same and similar to the syntax for creating tuples. If it’s necessary to match values within the tuple, the constants or identifiers are separated by commas, and the position of the identifier or constant defines what it matches within the tuple. This is shown in the first and second rules of the myOr function and in the first rule of the myAnd function. In these rules, you match parts of the tuples with constants, but you could have used identifiers if you wanted to work with the separate parts of the tuple later in the rule definition. Just because you’re working with tuples doesn’t mean you always have to look at the various parts that make up the tuple. The third rule of myOr and the second rule of myAnd show the whole tuple matched with a single _ wildcard character. This too could have been replaced with an identifier if you wanted to work with the value in the second half of the rule definition. printfn "(myOr true false) = %b" (myOr true false) printfn "(myOr false false) = %b" (myOr false false) printfn "(myAnd (true, false)) = %b" (myAnd (true, false)) printfn "(myAnd (true, true)) = %b" (myAnd (true, true)) The results of these examples, when compiled and executed, are as follows:



(myOr true false) = true (myOr false false) = false (myAnd (true, false)) = false (myAnd (true, true)) = true A common use of a pattern matching in F# is pattern matching over a list; in fact, this is the preferred way to deal with lists. The next example is a reworking of an example given in earlier in this chapter in the “Lists” section, but this one uses pattern matching instead of if … then … else …. For convenience, the original function definition is shown, renamed to concatListOrg. Comparing the two, it is easy to see that the version that uses pattern matching is about half the number of lines, a much preferable implementation. The pattern syntax for pulling the head item off a list is the same as the syntax for concatenating an item to a list. The pattern is formed by the identifier representing the head, followed by :: and then the identifier for the rest of the list. You can see this in the first rule of concatList. You can also pattern match against list constants; you can see this in the second rule of concatList, where you have an empty list. #light let listOfList = [[2; 3; 5]; [7; 11; 13];

[17; 19; 23; 29]]

let rec concatList l = match l with | head :: tail -> head @ (concatList tail) | [] -> [] let rec concatListOrg l = if List.nonempty l then let head = List.hd l in let tail = l in head @ (concatListOrg tail) else [] let primes = concatList listOfList print_any primes The results of this example, when compiled and executed, are as follows: [2; 3; 5; 7; 11; 13; 17; 19; 23; 29] Taking the head from a list, processing it, and then recursively processing the tail of the list is the most common way of dealing with lists via pattern matching, but it certainly isn’t the only thing you can do with pattern matching and lists. The following example shows a few other uses of this combination of features. The first rule demonstrates how to match a list of a fixed length, in this case a list of three items, and here you use identifiers to grab the values of these items so they can be printed to the console. The second rule looks at the first three items



in the list to see whether they are the sequence of integers 1, 2, 3, and if they are, it prints a message to the console. The final two rules are the standard head/tail treatment of a list, designed to work their way through the list doing nothing, if there is no match with the first two rules. #light let rec findSequence l = match l with | [x; y; z] -> printfn "Last 3 numbers in the list were %i %i %i" x y z | 1 :: 2 :: 3 :: tail -> printfn "Found sequence 1, 2, 3 within the list" findSequence tail | head :: tail -> findSequence tail | [] -> () let testSequence = [1; 2; 3; 4; 5; 6; 7; 8; 9; 8; 7; 6; 5; 4; 3; 2; 1] findSequence testSequence The results of this example, when compiled and executed, are as follows: Found sequence 1, 2, 3 within the list Last 3 numbers in the list were 3 2 1 Because pattern matching is such a common task in F#, the language provides an alternative shorthand syntax. If the sole purpose of a function is to pattern match over something, then it may be worth using this syntax. In this version of the pattern matching syntax, you use the keyword function, place the pattern where the function’s parameters would usually go, and then separate all the alternative rules with |. The next example shows this syntax in action in a simple function that recursively processes a list of strings and concatenates them into a single string. #light let rec conactStringList = function head :: tail -> head + conactStringList tail | [] -> "" let jabber = ["'Twas "; "brillig, "; "and "; "the "; "slithy "; "toves "; "..."] let completJabber = conactStringList jabber print_endline completJabber The results of this example, when compiled and executed, are as follows: 'Twas brillig, and the slithy toves ...




Pattern matching has a couple of other uses within F#, but I have not yet covered in detail the types on which these other kinds of pattern matching are based. You can find further details on pattern matching with record types and union types in the next section, “Defining Types.” You can find details of pattern matching and exception handling in the section “Exceptions and Exception Handling,” and you can find details of how to pattern match over types from non-F# libraries in Chapter 3.

Defining Types
The type system in F# provides a number of features for defining custom types. All of F#’s type definitions fall into two categories. The first category is types that are tuples or records. These are a set of types composed to form a composite type (similar to structs in C or classes in C#). The second category is sum types, sometimes referred to as union types. Tuples are a way of quickly and conveniently composing values into a group of values. Values are separated by commas and can then be referred to by one identifier, as shown in the first line of the next example. You can then retrieve the values by doing the reverse, as shown in the second and third lines, where identifiers separated by commas appear on the left side of the equals sign, with each identifier receiving a single value from the tuple. If you want to ignore a value in the tuple, you can use _ to tell the compiler you are not interested in the value, as in the second and third lines. #light let pair = true, false let b1, _ = pair let _, b2 = pair Tuples are different from most user-defined types in F# because you do not have to explicitly declare them using the type keyword. To define a type, you use the type keyword followed by the type name, an equals sign, and then the type you are defining. In its simplest form, you can use this to give an alias to any existing type, including tuples. Giving aliases to single types is not often useful, but giving aliases to tuples can be very useful, especially when you want to use a tuple as a type constraint. The next example shows how to give an alias to a single type and a tuple and also how to use an alias as a type constraint: #light type Name = string type Fullname = string * string let fullNameToSting (x : Fullname) = let first, second = x in first + " " + second Record types are similar to tuples in that they compose multiple types into a single type. The difference is that in record types each field is named. The next example illustrates the syntax for defining record types. You place field definitions between braces and separate them with semicolons. A field definition is composed of the field name followed by a colon and the field’s type. The type definition Organization1 is a record type where the field names are unique. This means you can use a simple syntax to create an instance of this type where there



is no need to mention the type name when it is created. To create a record, you place the field names followed by equals signs and the field values between braces ({}), as shown in the Rainbow identifier: #light type Organization1 = { boss : string ; lackeys : string list } let rainbow = { boss = "Jeffrey" ; lackeys = ["Zippy"; "George"; "Bungle"] } type Organization2 = { chief : string ; underlings : string list } type Organization3 = { chief : string ; indians : string list } let thePlayers = { new Organization2 with chief = "Peter Quince" and underlings = ["Francis Flute"; "Robin Starveling"; "Tom Snout"; "Snug"; "Nick Bottom"] } let wayneManor = { new Organization3 with chief = "Batman" and indians = ["Robin"; "Alfred"] } F# does not force field names to be unique, so sometimes the compiler cannot infer the type of a field from the field names alone. In this case, you must use the syntax that specifies the type. Again, you place the record definition between braces, but the new keyword, the type name, and the keyword with precede the field definitions. The field definitions themselves remain the same but are separated with the keyword and instead of semicolons. This is illustrated by the types Organization2 and Organization3 and their instances thePlayers and wayneManor. (This syntax is similar to that used for object expressions, which are a way of creating .NET objects in F# and are discussed in Chapter 5.) Ordinarily the scope of a type definition is from where it is declared forward to the end of the source file in which it is declared. If a type needs to reference a type declared after it, it can do so if they are declared together, in the same block. Types declared in the same block must be declared next to each other, that is, no value definitions in between, and the keyword type is replaced by the keyword and for every type definition after the first one. Types declared in this way are not any different from types declared the regular way. They can reference any other type in the block, and they can even be mutually referential. The next example shows two types, recipe and ingredient, declared in the same block. If they were declared separately, recipe would not be able to reference ingredient because recipe is declared before ingredient; because their declarations are joined with the keyword and, recipe can have a field of type ingredient. #light type recipe = { recipeName : string ; ingredients : ingredient list ; instructions : string }



and ingredient = { ingredientName : string ; quantity : int } let greenBeansPineNuts = { recipeName = "Green Beans & Pine Nuts" ; ingredients = [{ ingredientName = "Green beans" ; quantity = 250 }; { ingredientName = "Pine nuts" ; quantity = 250 }; { ingredientName = "Feta cheese" ; quantity = 250 }; { ingredientName = "Olive oil" ; quantity = 10 }; { ingredientName = "Lemon" ; quantity = 1 }] ; instructions = "Parboil the green beans for about 7 minutes. Roast the pine nuts carefully in a frying pan. Drain the beans and place in a salad bowl with the roasted pine nuts and feta cheese. Coat with the olive oil and lemon juice and mix well. Serve ASAP." } let name = greenBeansPineNuts.recipeName let toBuy = List.fold_left (fun acc x -> acc + (Printf.sprintf "\t%s - %i\r\n" x.ingredientName x.quantity) ) "" greenBeansPineNuts.ingredients let instructions = greenBeansPineNuts.instructions printf "%s\r\n%s\r\n\r\n\t%s" name toBuy instructions The results of this example, when compiled and executed, are as follows: Green Beans & Pine Nuts Green beans Pine nuts Feta cheese Olive oil Lemon - 1 - 250 250 - 250 10

Parboil the green beans for about 7 minutes. Roast the pine nuts carefully in a frying pan. Drain the beans and place in a salad bowl with the roasted pine nuts and feta cheese. Coat with the olive oil and lemon juice and mix well. Serve ASAP. As well as demonstrating two types being declared together, this example also demonstrates how you access fields in records. One advantage that records have over tuples is that accessing their contents is easier. The construct is simply an identifier dot (.) field name, as shown when associating values with the identifiers name, toBuy, and instructions.



Record types can also be pattern matched; that is, you can use pattern matching to match fields within the record type. The findDavid function in the next example does this. As you would expect, the syntax for examining a record using pattern matching is similar to the syntax used to construct it. You can compare a field to a constant with field = constant. You can assign the values of fields with identifiers with field = identifier. Or, you can ignore a field with field = _. The first rule in the find_david function is the one that does the real work, where you check the her field of the record to see whether it is "Posh", David’s wife. The him field is associated with the identifier x so it can be used in the second half of the rule. #light type couple = { him : string ; her : string } let couples [ { him { him { him { him = = = = =

"Brad" ; her = "Angelina" }; "Becks" ; her = "Posh" }; "Chris" ; her = "Gwyneth" }; "Michael" ; her = "Catherine" } ]

let rec findDavid l = match l with | { him = x ; her = "Posh" } :: tail -> x | _ :: tail -> findDavid tail | [] -> failwith "Couldn't find David" print_string (findDavid couples) The results of this example, when compiled and executed, are as follows: Becks Field values can also be functions. Since this technique is mainly used in conjunction with mutable state to form values similar to objects, I won’t discuss this here but in its own section in Chapter 4. Union types, sometimes called sum types or discriminated unions, are a way of bringing together data that may have a different meaning or structure. The next example defines a type volume whose values can have three different meanings—liter, U.S. pint, or imperial pint. Although the structure of the data is the same and is represented by a float, the meanings are quite different. Mixing up the meaning of data in an algorithm is a common cause of bugs in programs, and the volume type is in part an attempt to avoid this. You define a union type using the type keyword, followed by the type name, followed by an equals sign—just as all type definitions. Then comes the definition of the different constructors, separated by vertical bars. The first vertical bar is optional. A constructor is composed of a name that must start with a capital letter; this is to stop the common bug of getting constructor names mixed up with identifier names. The name can optionally be followed by the keyword of and then the types that make up that constructor. Multiple types that make up a constructor are separated by asterisks. The names of constructors within a type must be unique. If several union types are defined, then the names of their constructors can overlap; however, you should



be careful when doing this, because it can be that further type annotations are required when constructing and consuming union types. The following Volume type is a union type with three constructors, each composed of a single item of type float. The syntax for constructing a new instance of a union type is the constructor name followed by the values for the types, with multiple values separated by commas. Optionally, you can place the values in parentheses. You use the three different Volume constructors to construct three different identifiers, vol1, vol2, and vol3. #light type Volume = | Liter of float | UsPint of float | ImperialPint of float let vol1 = Liter 2.5 let vol2 = UsPint 2.5 let vol3 = ImperialPint (2.5) To deconstruct the values of union types into their basic parts, you always use pattern matching. When pattern matching over a union type, the constructors make up the first half of the pattern matching rules. You don’t need a complete list of rules, but if you don’t, there must be a default rule, using either an identifier or a wildcard to match all remaining rules. The first part of a rule for a constructor consists of the constructor name followed by identifiers or wildcards to match the various values within it. The following functions, convertVolumeToLiter, convertVolumeUsPint, and convertVolumeImperialPint, demonstrate this syntax: let convertVolumeToLiter x = match x with | Liter x -> x | UsPint x -> x * 0.473 | ImperialPint x -> x * 0.568 let convertVolumeUsPint x = match x with | Liter x -> x * 2.113 | UsPint x -> x | ImperialPint x -> x * 1.201 let convertVolumeImperialPint x = match x with | Liter x -> x * 1.760 | UsPint x -> x * 0.833 | ImperialPint x -> x



let printVolumes x = printfn "Volume in liters = %f, in us pints = %f, in imperial pints = %f" (convertVolumeToLiter x) (convertVolumeUsPint x) (convertVolumeImperialPint x) printVolumes vol1 printVolumes vol2 printVolumes vol3 The results of these examples, when compiled and executed, are as follows: Volume in liters = 2.500000, in us pints = 5.282500, in imperial pints = 4.400000 Volume in liters = 1.182500, in us pints = 2.500000, in imperial pints = 2.082500 Volume in liters = 1.420000, in us pints = 3.002500, in imperial pints = 2.500000 Both union and record types can be parameterized. Parameterizing a type means leaving one or more of the types within the type being defined to be determined later by the consumer of the types. This is a similar concept to the variable types discussed earlier in this chapter. When defining types, you must be a little bit more explicit about which types are variable. F# supports two syntaxes for type parameterization. In the first, you place the type being parameterized between the keyword type and the name of the type, as follows: #light type 'a BinaryTree = | BinaryNode of 'a BinaryTree * 'a BinaryTree | BinaryValue of 'a let tree1 = BinaryNode( BinaryNode ( BinaryValue 1, BinaryValue 2), BinaryNode ( BinaryValue 3, BinaryValue 4) )



In the second syntax, you place the types being parameterized in angle brackets after the type name, as follows: #light type Tree list | Value of 'a let tree2 = Node( [ Node( [Value "one"; Value "two"] ) ; Node( [Value "three"; Value "four"] ) ]


Like variable types, the names of type parameters always start with a single quote (') followed by an alphanumeric name for the type. Typically, just a single letter is used. If multiple parameterized types are required, you separate them with commas. You can then use the type parameters throughout the type definition. The previous examples defined two parameterized types, using the two different syntaxes that F# offers. The BinaryTree type used OCaml-style syntax, where the type parameters are placed before the name of the type. The tree type used .NET-style syntax, with the type parameters in angle brackets after the type name. The syntax for creating and consuming an instance of a parameterized type does not change from that of creating and consuming a nonparameterized type. This is because the compiler will automatically infer the type parameters of the parameterized type. You can see this in the following construction of tree1 and tree2 and their consumption by the functions printBinaryTreeValues and printTreeValues: let rec printBinaryTreeValues x = match x with | BinaryNode (node1, node2) -> printBinaryTreeValues node1; printBinaryTreeValues node2 | BinaryValue x -> print_any x; print_string ", " let rec printTreeValues x = match x with | Node l -> List.iter printTreeValues l | Value x -> print_any x print_string ", " printBinaryTreeValues tree1 print_newline() printTreeValues tree2 The results of this example, when compiled and executed, are as follows: 1, 2, 3, 4, "one", "two", "three", "four",



You may have noticed that although I’ve discussed defining types, creating instances of them, and examining these instances, I haven’t discussed updating them. This is because it is not possible to update these kinds of types because the idea of a value that changes over time goes against the idea of functional programming. However, F# does have some types that are updatable, and I discuss them in Chapter 4.

Exceptions and Exception Handling
Exception definitions in F# are similar to defining a constructor of a union type, and the syntax for handling exceptions is similar to pattern matching. You define exceptions using the exception keyword followed by the name of the exception and then optionally the keyword of and the types of any values the exception should contain, with multiple types separated by asterisks. The next example shows the definition of an exception, WrongSecond, which contains one integer value: exception WrongSecond of int You can raise exceptions with the raise keyword, as shown in the else clause in the following testSecond function. F# also has an alterative to the raise keyword, the failwith function, as shown in the following if clause. If, as is commonly the case, you just want to raise an exception with a text description of what went wrong, you can use failwith to raise a generic exception that contains the text passed to the function. let primes = [ 2; 3; 5; 7; 11; 13; 17; 19; 23; 29; 31; 37; 41; 43; 47; 53; 59 ] let testSecond() = try let currentSecond = System.DateTime.Now.Second in if List.exists (fun x -> x = currentSecond) primes then failwith "A prime second" else raise (WrongSecond currentSecond) with WrongSecond x -> printf "The current was %i, which is not prime" x testSecond() As shown in testSecond, the try and with keywords handle exceptions. The expressions that are subject to error handling go between the try and with keywords, and one or more pattern matching rules must follow the with keyword. When trying to match an F# exception, the syntax follows that of trying to match an F# constructor from a union type. The first half of the rule consists of the exception name, followed by identifiers or wildcards to match values that the exception contains. The second half of the rule is an expression that states how the exception should be handled. One major difference between this and the regular pattern matching constructs is that no warning or error is issued if pattern matching is incomplete. This is because any exceptions that are unhandled will propagate until they reach the top level and



stop execution. The example handles exception wrongSecond, while leaving the exception raised by failwith to propagate. F# also supports a finally keyword, which is used with the try keyword. You can use the finally keyword in conjunction with the with keyword as well as some rules for error handling or no rules. Always place the finally expression after the with block, if it exists; the finally expression will be executed whether an exception is thrown. The next example shows a finally block being used to ensure a file is closed and disposed of after it is written to: #light let writeToFile() = let file = System.IO.File.CreateText("test.txt") in try file.WriteLine("Hello F# users") finally file.Dispose() writeToFile()

I Caution Programmers coming from an OCaml background should be careful when using exceptions in
F#. Because of the architecture of the CLR, throwing an exception is pretty expensive—quite a bit more expensive than in OCaml. If you throw lots of exceptions, profile your code carefully to decide whether the performance costs are worth it. If the costs are too high, revise the code appropriately. I discuss tools for profiling F# applications in Chapter 12.

Lazy Evaluation
Lazy evaluation is something that goes hand in hand with functional programming. The theory is that if there are no side effects in the language, the compiler or runtime is free to choose the evaluation order of expressions. As you know, F# allows functions to have side effects, so it’s not possible for the compiler or runtime to have a free hand in function evaluation; therefore, F# is said to have a strict evaluation order or be a strict language. You can still take advantage of lazy evaluation but must be explicit about which computations can be delayed, that is, evaluated in a lazy manner. You use the keyword lazy to delay a computation, that is, invoke lazy evaluation. The computation within the lazy expression remains unevaluated until evaluation; it is explicitly forced with the force function from the Lazy module. When the force function is applied to a particular lazy expression, the value is computed; then the result is cached, and subsequent calls to the force function return the cached value, whatever it is, even if this means raising an exception. The following code shows a simple use of lazy evaluation: #light let lazyValue = lazy ( 2 + 2 )



let actualValue = Lazy.force lazyValue print_int actualValue print_newline() On the first line, you delay a simple expression for evaluation later. The next line forces evaluation. Then you print the value. The value has been cached, so any side effects that take place when the value is computed will occur only the first time the lazy value is forced. This is fairly easy to demonstrate. In the next example, you create a lazy value that has a side effect when it is calculated: it writes to the console. To show that this side effect takes place only once, you force the value twice, and it is plain to see from the result that writing to the console takes place only once. #light let lazySideEffect = lazy ( let temp = 2 + 2 print_int temp print_newline() temp ) print_endline "Force value the first time: " let actualValue1 = Lazy.force lazySideEffect print_endline "Force value the second time: " let actualValue2 = Lazy.force lazySideEffect The results of this example are as follows: Force value the first time: 4 Force value the second time: Laziness can also be useful when working with collections. The idea of a lazy collection is that elements in the collection are calculated on demand. Some collection types also cache the results of these calculations, so there is no need to recalculate elements. F# provides the LazyList collection type, which caches computed results and is useful for functional programming and search. The second lazy collection is the seq type, a shorthand for the BCL’s IEnumerable type. This plays a similar role to LazyList but does not cache computed results. LazyList and seq values are created and manipulated using functions in the LazyList and Seq modules, respectively. Many other values are also compatible with the type seq; for example, all F# lists and arrays are compatible with this type, as are most other collection types. The next example shows how to use the LazyList module. Possibly its most important function, and probably the most difficult to understand, is unfold. This function allows you to create a lazy list. What makes it complicated is that you must provide a function that will be repeatedly evaluated to provide the elements of the list. The function passed to LazyList. unfold can take any type of parameter and must return an option type. An option type is a union type that can be either None or Some(x), where x is a value of any type. None is used to



represent the end of a list. The Some constructor must contain a tuple. The first item in the tuple represents the value that will become the first value in the list. The second value in the tuple is the value that will be passed into the function the next time it is called. You can think of this value as an accumulator. The next example shows how this works. The identifier lazyList will contain three values. If the value passed into the function is less than 13, you append the list using this value to form the list element and then add 1 to the value passed to the list. This will be value passed to the function the next time it is called. If the value is greater than or equal to 13, you terminate the list by returning None. To display the list, you use the function display, a simple recursive function that processes the head of the list and then recursively processes the tail. #light let lazyList = LazyList.unfold (fun x -> if x < 13 then Some(x, x + 1) else None) 10 let rec display l = match l with | LazyList.Cons(h,t) -> print_int h print_newline () display t | LazyList.Nil -> () display lazyList The results of this example, when compiled and executed, are as follows: 10 11 12 Lazy lists are also useful to represent lists that don’t terminate. A nonterminating list can’t be represented by a classic list, which is constrained by the amount of memory available. The next example demonstrates this by creating fibs, an infinite list of all the Fibonacci numbers; it uses the Seq module, although it could just as well have used the LazyList module because the unfold function works in the same way in both. To display the results conveniently, you use the function Seq.take to turn the first 20 items into an F# list, but you carry on calculating many more Fibonacci numbers as you use F# bigint integers, so you are limited by the size of a 32-bit integer.



#light let fibs = Seq.unfold (fun (n0, n1) -> Some(n0, (n1, n0 + n1))) (1I,1I) let first20 = Seq.take 20 fibs print_any first20 The results of this example are as follows: [1I; 1I; 2I; 3I; 5I; 8I; 13I; 21I; 34I; 55I; 89I; 144I; 233I; 377I; 610I; 987I; 1597I; 2584I; 4181I; 6765I] These examples are too simple to really demonstrate the power of lazy evaluation. You’ll look at lazy evaluation again in several places in this book, notably in Chapter 7, where you’ll see how to use lazy evaluation in user-interface programming to make user interfaces more responsive by ensuring computations do not happen until really needed.

In this chapter, you looked at the major functional programming constructs in F#. This is the core of the language, and I hope you’ve developed a good feel for how to approach writing algorithms and handling data in F#. The next chapter will cover imperative programming, and you’ll see how to mix functional and imperative programming techniques to handle tasks such as input/output (I/O).



Imperative Programming

s you saw in Chapter 3, you can use F# for pure functional programming. However, some issues, most notably I/O, are almost impossible to address without some kind of state change. F# does not require that you program in a stateless fashion. It allows you to use mutable identifiers whose values can change over time. F# also has other constructs that support imperative programming. You’ve already seen some in Chapter 3. Any example that wrote to the console included a few lines of imperative code alongside functional code. In this chapter, you’ll explore these constructs, and many others, in much more detail. First, you’ll look at F#’s unit type, a special type that means “no value,” which enables some aspects of imperative programming. Next, you’ll look at some of the ways F# can handle mutable state, that is, types whose values can change over time. These are the ref type, mutable record types, and arrays. Finally, you’ll look at using .NET libraries. The topics will include calling static methods, creating objects and working with their members, using special members such as indexers and events, and using the F# |> operator, which is handy when dealing with .NET libraries.

The unit Type
Any function that does not accept or return values is of type unit, which is similar to the type void in C# and System.Void in the CLR. To a functional programmer, a function that doesn’t accept or return a value might not seem interesting, since if it doesn’t accept or return a value, it does nothing. In the imperative paradigm, you know that side effects exist, so even if a function accepts or returns nothing, you know it can still have its uses. The unit type is represented as a literal value, a pair of parentheses (()). This means that whenever you want a function that doesn’t take or return a value, you just put () in the code: #light let main() = () In this example, main is a function because you placed parentheses after the identifier, where its parameters would go. If you didn’t this, it would mean main is not a function and instead just a value that is not a function. As you know, all functions are values, but here the difference between a function and a nonfunction value is important. If main were a nonfunction value, the expressions within it would be evaluated only once. Since it is a function, the expressions will be evaluated each time it is called.



I Caution Just because a function is named main doesn’t mean it is the entry point of the program and is executed automatically. If you wanted your main function to be executed, then you would need to add a call to main() at the end of the source file. Chapter 6 details exactly how the entry point is determined for an F# program.

Similarly, by placing () after the equals sign, you tell the compiler you are going to return nothing. Ordinarily, you need to put something between the equals sign and the empty parentheses, or the function is pointless; however, for the sake of keeping things simple, I’ll leave this function pointless. Now you’ll see the type of main by using the fsc –i switch; the results of this are as follows. (I explained the notation used by the compiler’s –i switch in Chapter 3’s “Types and Type Inference.”) As you can see, the type of main is a function that accepts unit and transforms it into a value of type unit: val main : unit -> unit Because the compiler now knows the function doesn’t return anything, you can now use it with some special imperative constructs. To call the function, you can use the let keyword followed by a pair of parentheses and the equals sign. This is a special use of the let keyword, which means “call a function that does not return a value.” Alternatively, you can simply call the function without any extra keywords at all: #light let () = main() // -- or -main() Similarly, you can chain functions that return unit together within a function—simply make sure they all share the same indentation. The next example shows several print_endline functions chained together to print text to the console: #light let poem() = print_endline print_endline print_endline print_endline poem()

"I wandered lonely as a cloud" "That floats on high o'er vales and hills," "When all at once I saw a crowd," "A host, of golden daffodils"

It’s not quite true that the only functions that return unit type can be used in this manner; however, using them with a type other than unit will generate a warning, which is something most programmers want to avoid. So, to avoid this, it’s sometimes useful to turn a function that does return a value into a function of type unit, typically because it has a side effect. The need to do this is fairly rare when just using F# libraries written in F# (although situations where it is useful do exist), but it is more common when using .NET libraries that were not written in F#.



The next example shows how to turn a function that returns a value into a function that returns unit: #light let getShorty() =


let _ = getShorty() // -- or -ignore(getShorty()) // -- or -getShorty() |> ignore First you define the function getShorty, which returns a string. Now imagine, for whatever reason, you want to call this function and ignore its result. The next two lines demonstrate different ways to do this. First, you can use a let expression with an underscore (_) character in place of the identifier. The underscore tells the compiler this is a value in which you aren’t interested. Second, this is such a common thing to do that it has been wrapped into a function, ignore, which is available in the F# base libraries and is demonstrated on the third line. The final line shows an alternative way of calling ignore using the pass-forward operator to pass the result of getShorty() to the ignore function. I explain the pass-forward operator in the “The |> Operator” section.

The mutable Keyword
In Chapter 3 I talked about how you could bind identifiers to values using the keyword let and noted how under some circumstances you could redefine and rebound, but not modify, these identifiers. If you want to define an identifier whose value can change over time, you can do this using the mutable keyword. A special operator, the left ASCII arrow (or just left arrow), is composed of a less-than sign and a dash ( robert3): %b\r\n" (robert2 > robert3) The results of this code, when compiled and executed, are as follows: (robert2 > robert3): true If you need to determine whether two objects are physically equal, then you can use the eq function available in the Obj module, as in the following example: #light let robert1 = { name = "Robert" ; favoriteColor = "Red" } let robert2 = { name = "Robert" ; favoriteColor = "Red" } printfn "(Obj.eq robert1 robert2): %b" (Obj.eq robert1 robert2)

Floating-Point Arithmetic Functions
The Pervasives module also offers a number of functions (see Table 7-2) specifically for floatingpoint numbers, some of which are used in the following sample:



#light printfn "(sqrt 16.0): %f" (sqrt 16.0) printfn "(log 160.0): %f" (log 160.0) printfn "(cos 1.6): %f" (cos 1.6) The results of this code, when compiled and executed, are as follows: (sqrt 16.0): 4.000000 (log 160.0): 5.075174 (cos 1.6): -0.029200

Table 7-2. Arithmetic Functions for Floating-Point Numbers

Function abs_float acos asin atan atan2 ceil floor exp infinity ldexp log log10 max_float min_float mod_float modf nan neg_infinity sqrt cos cosh sin

Returns the absolute value of the argument Returns the inverse cosine (arccosine) of the argument, which should be specified in radians Returns the inverse sine (arcsine) of the argument, which should be specified in radians Returns the inverse tangent (arctangent) of the argument, which should be specified in radians Returns the inverse tangent (arctangent) of the two arguments, which should both be specified in radians Returns the next highest integer value by rounding up the value if necessary; the value returned is still of type float Returns the next lowest integer value by rounding up the value if necessary; the value returned is still of type float Returns the exponential Returns the floating-point number that represents infinity Returns the floating-point number from the mantissa and exponent Returns the natural log of the floating-point number Returns the base 10 log of the floating-point number Returns the maximum floating-point number Returns the minimum floating-point number Returns the remainder of the first parameter with respect to the second parameter Returns the floating-point number split into the integer and fractional part Returns the floating-point number that represents “not a number” Returns the floating-point number that represents negative infinity Returns the square root of the number Returns the cosine of the parameter, which should be specified in radians Returns the hyperbolic cosine of the parameter, which should be specified in radians Returns the sine of the parameter, which should be specified in radians



Function sinh tan tanh truncate float float32

Returns the hyperbolic sine of the parameter, which should be specified in radians Returns the tangent of the parameter, which should be specified in radians Returns the hyperbolic tangent of the parameter, which should be specified in radians Returns the parameter converted to an integer Takes an integer and returns it as a float Takes an integer and returns it as a float32

Mutable Integer Functions
The Pervasives module also offers two useful functions that operate on mutable integers. The incr and decr functions increment and decrement a mutable integer, respectively. The use of these functions is demonstrated here: #light let i = ref 0 (incr i) print_int !i print_newline () (decr i) print_int !i The results of this code are as follows: 1 0

Finally, you’ve come to the last major set of functions within the Pervasives module—functions that read from and write to streams. Streams are a way of managing I/O that allows a file, a network connection, or an area of memory to be written to in a homogeneous fashion. A stream is a value that provides functions to either read from it or write to it. A stream is an abstract concept, because no matter whether it represents a file, a connection, or memory, you can use the same methods to write to it. You have already seen the functions print_endline, print_newline, print_string, print_int, and printf used throughout the examples in this book. These are all examples of functions that write to the standard output stream, typically the console. The Pervasives module also provides several functions for reading from the standard input stream, typically the keyboard: #light let myString = read_line () let myInt = read_int () let myFloat = read_float ()



When executed, this sample will bind the identifier myString to a string input by the user. It will also bind myInt and myFloat to the integer and float values input by the user, provided the user types a correctly formed integer and float. The fact that these functions read from and write to streams is not entirely obvious because they don’t take stream parameters. This is because they are wrapper methods that hide that they are reading from or writing to a stream. They are built on top of some more general functions for reading from and writing to a stream. The next example demonstrates how to use the stream stdout, which defaults to the console, and shows how this can be written to in the same manner as writing to a file, using the output_string function: #light let getStream() = print_string "Write to a console (y/n): " let input = read_line () match input with | "y" | "Y" -> stdout | "n" | "N" -> print_string "Enter file name: " let filename = read_line () open_out filename | _ -> failwith "Not an option" let main() = let stream = getStream() output_string stream "Hello" close_out stream read_line() |> ignore main() The function getStream allows the user to switch between writing to the console and writing to a file. If the user chooses to write to the console, the stream stdout is returned; otherwise, it asks the user to provide a filename so open_out can be used to open a file stream. The implementation of streams is based on the classes available in System.IO namespace; the out_channel is an alias for TextWriter, and in_channel is an alias for TextReader. These aliases were included for compatibility purposes; you probably want to consider the classes available in the BCL’s System.IO namespace directly, because this often gives you more flexibility.

The Microsoft.FSharp.Compatibility.OCaml.Arg Module
The Arg module allows users to quickly build a command-line argument parser. It does this by using F#’s union and list types to create a little language that is then interpreted by a number of functions provided in the Arg module. The Arg module exposes a tuple type called argspec, which consists of two strings and a union type called spec. The first string in the tuple specifies the name of the command-line argument. The second item in the tuple is the union type spec, which specifies what the command-line argument is; for example, is it followed by a string value, or is it just a flag? It also specifies what should be done if and when the command-line token is found. The final string in



the tuple is a text description of what the flag does. This will be printed to the console in the case of a mistake in the command-line arguments. It also serves as a useful note to the programmer. The Arg module exposes two functions for parsing arguments: parse, which parses the command passed in on the command line, and parse_argv, which requires the arguments to be passed directly to it. Both should be passed a list of type argspec describing the commandline arguments expected, a function that will be passed all the command-line arguments not prefixed with -, and finally a string to describe the usage. The module also exposes a third function usage, which can be passed a list of type argspec and will just directly write out the usage. The following example demonstrates an argument parser built in this manner. The parameters collected from the command line are stored in identifiers for later use, in this case being written to the console. #light let let let let let myFlag = ref true myString = ref "" myInt = ref 0 myFloat = ref 0.0 (myStringList : string list ref) = ref []

let argList = [ ("-set", Arg.Set myFlag, "Sets the value myFlag"); ("-clear", Arg.Clear myFlag, "Clears the value myFlag"); ("-str_val", Arg.String(fun x -> myString := x), "Sets the value myString"); ("-int_val", Arg.Int(fun x -> myInt := x), "Sets the value myInt"); ("-float_val", Arg.Float(fun x -> myFloat := x), "Sets the value myFloat"); ] if Sys.argv.Length 1 then Arg.parse argList (fun x -> myStringList := x :: !myStringList) "Arg module demo" else Arg.usage argList "Arg module demo" exit 1 printfn "myFlag: %b" !myFlag printfn "myString: %s" !myString printfn "myInt: %i" !myInt printfn "myFloat: %f" !myFloat printfn "myStringList: " print_any !myStringList



When run with no command-line arguments or faulty command-line arguments, the program will output this: Arg module demo -set: Sets the value my_flag -clear: Clears the value my_flag -str_val : Sets the value my_string -int_val : Sets the value my_int -float_val : Sets the value my_float --help: display this list of options -help: display this list of options When run with the command line args.exe -clear -str_val "hello world" -int_val 10 -float_val 3.14 "file1" "file2" "file3", the program will output the following: myFlag: false myString: hello world myInt: 10 myFloat: 3.140000 myStringList: ["file3"; "file2"; "file1"] The Arg module is an excellent example of how creating a little language can make programming tasks easier and quicker and the resulting code easier to understand and more maintainable. You’ll find more details on this style of programming in Chapter 11.

I covered a lot ground in this chapter, since the F# libraries have a diverse range of functionalities. First you looked through the FSLib.dll library with its useful Collections, Reflection, and Math modules. Then you looked at MLLib.dll, which provides functions that are excellent building blocks for all applications. Its Seq module is something that any nontrivial F# program will not be able to do without. The next three chapters will look at how you can use F# with various .NET APIs for common programming tasks. You’ll start with a look at implementing user interfaces in Chapter 8, and then you’ll move to data access in Chapter 9 and distributed applications in Chapter 10.



User Interfaces

n this chapter, you will look at one of the most common tasks a programmer needs to perform—the art of putting pixels on the screen. In F# this is all about the libraries and API that you call, and you have a lot of choices in this area. You can create WinForms, a set of classes found in System.Windows.Form.dll. These classes allow you to create desktop applications based on forms and controls. You can create ASP.NET applications. This library is contained in System.Web.dll, which is a simple way to create server-based dynamic HTML applications. You also have the option to use Windows Presentation Foundation (WPF), which is a new library distributed with .NET 3.0 that allows you to design interfaces in an XML-based language called XAML. These three technologies (WinForms, ASP .NET, and WPF) will be the focus of this chapter. Since whole books have been written on each topic, I won’t be able to cover them all in detail. Instead, you’ll look at techniques for working with these technologies in F#. F# can also use a lot of other graphics libraries—some designed to work with the technologies already mentioned and others, such as the DirectX or GTK# libraries, designed to replace them.

Introducing WinForms
WinForms are based on the System.Windows.Forms.Form class. By creating an instance of this class, you essentially create a new window. You must then create an event loop, a way of ensuring user interactions with the window are responded to. You do this by calling the System.Windows.Application.Run method and passing it the form object you have created. You can control the look of the form by setting its properties and calling its methods. The following example demonstrates this: #light open System.Drawing open System.Windows.Forms let form = new Form(BackColor = Color.Purple, Text = "Introducing WinForms") Application.Run(form) This example will not work with F# interactive, fsi, because you cannot start an event loop from within fsi. So to work with forms in fsi, you simply call the form’s Show method or set the form’s Visible property to true. This example shows the second technique:



> #light open System.Drawing open System.Windows.Forms let form = new Form(BackColor=Color.Purple, Text="Introducing WinForms", Visible=true);; Either way, you have the advantage that you can dynamically interact with your form object. For example: > form.Text temp.Invalidate()) temp.Paint.Add (fun e -> if temp.Width - 64 > 0 && temp.Height - 96 > 0 then e.Graphics.FillPie (brush, 32, 32,



temp.Width - 64, temp.Height - 64, 0, 290)) temp Application.Run(form) Figure 8-1 shows the resulting form.

Figure 8-1. A WinForm containing a pie shape Because this image is linked to the size of the form, you must tell the form to redraw itself whenever the form is resized. You do this by attaching an event handling function to the Resize event. In this function, you call the form’s Invalidate method, which tells the form that it needs to redraw itself. You’ll now look at a more complete WinForms example. Imagine you want to create a form to display the Tree type defined in the next code example and displayed in Figure 8-2. // The tree type type 'a Tree = | Node of 'a Tree * 'a Tree | Leaf of 'a // The definition of the tree let tree = Node( Node( Leaf "one", Node(Leaf "two", Leaf "three")), Node( Node(Leaf "four", Leaf "five"), Leaf "six"))



Figure 8-2. A WinForm showing a tree structure You can draw this tree with the code in Listing 8-1. I will walk you through how the code works directly after the listing. Listing 8-1. Drawing a Tree #light open System open System.Drawing open System.Windows.Forms // The tree type type 'a Tree = | Node of 'a Tree * 'a Tree | Leaf of 'a // The definition of the tee let tree = Node( Node( Leaf "one", Node(Leaf "two", Leaf "three")), Node( Node(Leaf "four", Leaf "five"), Leaf "six")) // A function for finding the maximum depth of a tree let getDepth t = let rec getDepthInner t d = match t with | Node (l, r) -> max (getDepthInner l d + 1.0F) (getDepthInner r d + 1.0F) | Leaf x -> d getDepthInner t 0.0F



// Constants required for drawing the form let brush = new SolidBrush(Color.Black) let pen = new Pen(Color.Black) let font = new Font(FontFamily.GenericSerif, 8.0F) // a useful function for calculating the maximum number // of nodes at any given depth let raise2ToPower (x : float32) = Convert.ToSingle(Math.Pow(2.0, Convert.ToDouble(x))) let drawTree (g : Graphics) t = // constants that relate to the size and position // of the tree let center = g.ClipBounds.Width / 2.0F let maxWidth = 32.0F * raise2ToPower (getDepth t) // function for drawing a leaf node let drawLeaf (x : float32) (y : float32) v = let value = any_to_string v let l = g.MeasureString(value, font) g.DrawString(value, font, brush, x - (l.Width / 2.0F), y) // draw a connector between the nodes when necessary let connectNodes (x : float32) y p = match p with | Some(px, py) -> g.DrawLine(pen, px, py, x, y) | None -> () // the main function to walk the tree structure drawing the // nodes as we go let rec drawTreeInner t d w p = let x = center - (maxWidth * w) let y = d * 32.0F connectNodes x y p match t with | Node (l, r) -> g.FillPie(brush, x - 3.0F, y - 3.0F, 7.0F, 7.0F, 0.0F, 360.0F) let d = (d + 1.0F) drawTreeInner l d (w + (1.0F / d)) (Some(x, y)) drawTreeInner r d (w - (1.0F / d)) (Some(x, y)) | Leaf v -> drawLeaf x y v drawTreeInner t 0.0F 0.0F None



// create the form object let form = let temp = new Form(WindowState = FormWindowState.Maximized) temp.Resize.Add(fun _ -> temp.Invalidate()) temp.Paint.Add (fun e -> e.Graphics.Clip g.DrawLine(pen, px, py, x, y) | None -> () Finally, you define drawTreeInner as a recursive function that does the real work of walking the Tree type and drawing it:



// the main function to walk the tree structure drawing the // nodes as we go let rec drawTreeInner t d w p = let x = center - (maxWidth * w) let y = d * 32.0F connectNodes x y p match t with | Node (l, r) -> g.FillPie(brush, x - 3.0F, y - 3.0F, 7.0F, 7.0F, 0.0F, 360.0F) let d = (d + 1.0F) drawTreeInner l d (w + (1.0F / d)) (Some(x, y)) drawTreeInner r d (w - (1.0F / d)) (Some(x, y)) | Leaf v -> drawLeaf x y v This function uses parameters to store values between recursive calls. Because it is an inner function, you know that the outside world cannot misuse it by initializing its initial values incorrectly; this is because the outside world cannot see it. Hiding parameters to store working values between recursive function calls is another common pattern in functional programming. In some ways this tree-drawing function is satisfactory; it gives a nice hierarchical overview of the tree in a fairly concise 86 lines of F# code. However, there is a limit to how well this approach scales. As you draw more complicated images, the number of lines of code can grow rapidly, and working out all the geometry can become time-consuming. To help manage this complexity, F# can use controls, as discussed in the next section.

I Caution Although you can use these techniques to produce animation, such animations will flicker. To avoid this flicker, you must use a technique called double buffering, which requires you to understand a lot about how Windows draws forms. For more information about double buffering, please see http:// To make the most of drawing on WinForms, you should get to know the System.Drawing namespace contained in System.Drawing.dll. You should concentrate on two areas, first learning how to use the Graphics object, particularly the overloads of methods prefixed with either Draw or Fill. To help you get started, Table 8-1 summaries them. Table 8-1. Important Methods on the System.Drawing.Graphics Object

Method Name
DrawArc DrawBezier DrawCurve DrawClosedCurve

Draws a portion of an ellipse. Draws a Bézier spline, which is a curve represented by two endpoints and two free-floating points controlling the angle of the curve. Draws a curved line defined by an array of points. Draws a closed curved line defined by an array of points. continued



Table 8-1. Continued

Method Name
DrawEllipse DrawPie DrawLine DrawLines DrawPolygon DrawRectangle DrawRectangles FillClosedCurve FillEllipse FillPie FillPolygon FillRectangle FillRectangles DrawIcon DrawImage DrawImageUnscaled DrawString MeasureString DrawPath

Draws the outline of an ellipse represented by a rectangle or rectangular set of points. Draws a portion of the outline of an ellipse, represented by a rectangle and two radial lines representing the start and finish angles. Draws a single line from two points. Draws a set of lines from an array of points. Draws the outline of a polygon, which is a closed set of lines from an array of points. Draws the outline of a rectangle represented by a coordinate and its width and height. Draws the outline of a set of rectangles from an array of rectangles. Draws a solid closed curve defined by an array of points. Draws a solid ellipse represented by a rectangle or rectangular set of points. Draws a portion of a solid ellipse, represented by a rectangle and two radial lines representing the start and finish angles. Draws a solid polygon, which is a closed set of lines from an array of points. Draws a solid rectangle represented by a coordinate and its width and height. Draws a solid set of rectangles from an array of rectangles. Draws an image specified by the System.Drawing.Icon type. Draws an image specified by the System.Drawing.Image type. Draws an image specified by the System.Drawing.Image type with no scaling. Draws a string of characters. Gives the dimensions of the string of characters so the programmer can calculate where it should be placed on the image. Draws an outline represented by the System.Drawing.Drawing2D.GraphicsPath. This is a class that allows you to add geometric constructs such as the curves, rectangle, ellipses, and polygons described earlier to save you from recalculating them each time. This is useful if you want to draw something that is complicated but fairly static. Provides the same functionality as DrawPath, except draws an image that is solid rather than an outline.


The second area is closely related to the System.Drawing.Graphics object; it is the creation of the Icon, Image, Pen, and Brush objects that are used by its methods. Table 8-2 shows examples of how to create these objects via their constructors.



Table 8-2. Important Methods on the System.Drawing.Graphics Object

Color.FromArgb(33, 44, 55) Color.FromKnownColor(KnownColor.Crimson) Color.FromName("HotPink") new Font(FontFamily.GenericSerif, 8.0f) Image.FromFile("myimage.jpg") Image.FromStream(File.OpenRead ("myimage.gif")) new Icon("myicon.ico") new Icon(File.OpenRead("myicon.ico")) new Pen(Color.FromArgb(33, 44, 55)) new Pen(SystemColors.Control, 2.0f) new SolidBrush(Color.FromName("Black")) new TexturedBrush(Image.FromFile ("myimage.jpg"))

Creates a color from its red, green, and blue components Creates a color from a member of the KnownColor enumeration Creates a color from its name in string form Creates a new font that is a generic serif font and 8 points tall Creates a new image from a file Creates a new image from a stream Creates a new icon from a file Creates a new icon from a stream Creates a pen, used to draw lines, from a color Creates a pen, used to draw lines, from a color and with a width of 2 pixels Creates a solid brush that can be used to draw filled shapes Creates a new textured brush from an image and draws a filled shape with an image mapped across it

If you prefer to use standard objects, you can use several classes in the System.Drawing namespace that contain predefined objects. These are Brushes, Pens, SystemBrushes, SystemColors, SystemFonts, SystemIcons, and SystemPens; the following is a quick example of using these: #light open System.Drawing let myPen = Pens.Aquamarine let myFont = SystemFonts.DefaultFont

Working with Controls in WinForms
A control is simply a class that derives from System.Windows.Forms.Control. Any class that derives from this can be displayed in a form by adding it to the Controls collection on the form object.



You’ll now look at a way to draw the tree using controls. The WinForms library defines a TreeView class, which is specifically for displaying tree-like structures, so you’ll use this control to display the tree. To use TreeView, you create an instance of it and configure it by setting its properties and calling its methods. Most important, you add to its Nodes collection the nodes you want to display. Once the control is ready to be displayed, you add it to the form’s Controls collection. The TreeView class uses TreeNode objects to represent nodes, so you’ll define the function mapTreeToTreeNode to recursively walk the tree structure and create a TreeNode graph. The program in Listing 8-2 produces the tree in Figure 8-3. Listing 8-2. Drawing a Tree via a TreeView Control #light open System.Windows.Forms // The tree type type 'a Tree = | Node of 'a Tree * 'a Tree | Leaf of 'a // The definition of the tee let tree = Node( Node( Leaf "one", Node(Leaf "two", Leaf "three")), Node( Node(Leaf "four", Leaf "five"), Leaf "six")) // A function to transform our tree into a tree of controls let mapTreeToTreeNode t = let rec mapTreeToTreeNodeInner t (node : TreeNode) = match t with | Node (l, r) -> let newNode = new TreeNode("Node") node.Nodes.Add(newNode) |> ignore mapTreeToTreeNodeInner l newNode mapTreeToTreeNodeInner r newNode | Leaf x -> node.Nodes.Add(new TreeNode(any_to_string x)) |> ignore let root = new TreeNode("Root") mapTreeToTreeNodeInner t root root



// create the form object let form = let temp = new Form() let treeView = new TreeView(Dock = DockStyle.Fill) treeView.Nodes.Add(mapTreeToTreeNode tree) |> ignore treeView.ExpandAll() temp.Controls.Add(treeView) temp Application.Run(form)

Figure 8-3. A TreeView control used to view a tree This code is about half the length of Listing 8-1, when you drew the tree yourself. It is also more functional, because it allows you to fold away parts of the tree in which you’re not interested. This greatly improves the size of tree that can be manageably displayed. In this example, you use the “dock style” to control how the control looks. You do this by setting the control’s Dock property with a member of the DockStyle enumeration. Docking means that the control will take up as much space as available in the form that contains it on the left side if you use DockStyle.Left, on the right side if you use DockStyle.Right, at the top if you use DockStyle.Top, on the bottom if you use DockStyle.Bottom, and on the whole form if you use DockStyle.Fill. This is great when you have just a few controls, because it creates a nice dynamic effect because the controls are resized when the user resizes the form; however, it does not work well with a lot of controls because it is difficult to get lots of controls to fit together nicely using this technique. For example, if you have two controls that are docked to the left, it’s confusing which one is supposed to be the leftmost one and how much of the left side they both take up. A better solution with a lot of controls is to explicitly control their layout using the Top and Left properties. You can create a dynamic effect by using the Anchor property to anchor the control to the edge of the containing form. The following example creates a form with a single textbox on it that will grow and shrink as the user resizes the form:



#light open System open System.Windows.Forms let form = let temp = new Form() let textBox = new TextBox(Top=8,Left=8, Width=temp.Width – 24. Anchor = (AnchorStyles.Left ||| AnchorStyles.Right ||| AnchorStyles.Top)) temp.Controls.Add(textBox) temp [] do Application.Run(form) However, this method of working with controls is not always satisfactory. Here you displayed only one control. Often you want to display tens, even hundreds, of controls on a form. Writing all the code to create and configure the controls can quickly become tedious and error-prone. To get around this, Visual Studio provides some form designers that allow you to graphically create forms. However, a designer is not currently available for F#, so the next section will discuss working in F# with forms created with the C# designer. One of the difficulties facing the WinForms programmer when working with controls is that there are many controls from which to choose. In this chapter, I have covered just one control. Unfortunately, in learning what works, there’s no real substitute for experience. The MSDN library ( provides an excellent reference, but the volume of information there can also be a little off-putting for learners, so I have summarized some of the most useful ones in Table 8-3 to give you a head start. Table 8-3. Common WinForm Controls and Their Usages


A control for displaying text information to the user; generally most other controls should be accompanied by a Label to explain their usage. Placing an & in the text of the Text property of the Label will underline the letter directly after it and allow the keyboard user to hop to the control associated with the Label (the control next in the tab order) by pressing Alt+; this is good for improving application usability. A box for entering text. The default is a single line of text but can be changed to support multiline entry if you set the Multiline property to true; in this case, also check that the WordWrap and ScrollBar properties are to your liking. This is also useful for displaying text to the user that you want them to be able to copy and paste; in this case, set the ReadOnly property to true. A textbox similar in a lot of respects to the previous control; it allows you limit the data a user can enter via setting the Mask property. A button for the user to click; as with the Label control, placing an & in the text of the Text property of the Button control will allow underline the letter directly after it and allow the keyboard user to hop to the Button by pressing Alt+. Again, this is great for usability.


MaskedTextBox Button



Control LinkLabel

Description Not really to be used as a label as the name might suggest but as a type of button that looks like an HTML link. This is great for users who are used to a web environment or to indicate that clicking the button leads to opening a web page. A box for the users to check if you have a set of options that are not mutually exclusive. Similar to a CheckBox but for options that are mutually exclusive. Several of these placed in the same container are automatically mutually exclusive. The container is usually a Form. A control to allow the user to pick a date via a drop-down calendar. A control to allow a user to pick a date from a calendar that is permanently on display. A control to allow a user to make a selection from a drop-down list; this is great for showing a dynamic set of data via data binding. For more details on this, see Chapter 9. Similar to a ComboBox but the list of items is displayed within the form rather than as a drop-down list. Favor this one if your form has lots of free space. A control to provide an excellent way to display information from a database table, though this can be used to display any kind of tabular data. This should always be used in preference to the older DataGrid. I’ll discuss this further in Chapter 9. Another control great for showing dynamic data, but this time it is most useful for data in a tree-like form. Giving your users feedback about any long-running activity is vital for a usable application, and this control provides a good way to do this. A control for providing a way to display and edit rich text documents, which is useful if your users want a little more formatting than offered by the standard textbox. A control for displaying HTML documents; this is useful since a lot of information is available in HTML format. A control for breaking your form into different sections; this is highly effective when used with HScrollBar and VScrollBar. A horizontal scroll bar, used to fit more information on a Form or Panel. A vertical scroll bar, used to fit more information on a Form or Panel. A form that uses a series of tabs to display user controls.

CheckBox RadioButton

DateTimePicker MonthCalander ComboBox

ListBox DataGridView

TreeView ProgressBar RichTextBox

WebBrowser Panel HScrollBar VScrollBar TabControl

Using the Visual Studio Form Designer’s Forms in F#
F# does not yet have a form designer of its own; however, thanks to the great interoperability of .NET, it is easy to use forms created with the designer in F#. You have two approaches. You can create an F# library and call functions from this library in your Windows form, or you can create a library of forms and use them from your F# application. You’ll look first at creating an



F# library, and then you will look at creating a forms library. Then I’ll compare the two techniques. Both examples will be based on the same Fibonacci calculator shown in Figure 8-4.

I Caution This book is about F#, and for the majority of the material, knowledge of no other programming language is necessary. However, for this topic, it will be necessary to understand a little of another .NET programming language, in this case C#. Specifically, you’ll see two short listings in C# in this section. You can easily replace the C# code with Visual Basic .NET code if you feel more comfortable with that language.

Figure 8-4. A Fibonacci calculator form created with the Visual Studio designer The main consideration in creating an F# library to be used from a form is making it easy to use from the form. In this case, you’ll create a function to calculate the Fibonacci number, so this will take an integer and return an integer. This makes things simple since a form has no problem using the .NET integer type. You want the library to be reasonably efficient, so create a lazy list of Fibonacci numbers and define a function that can get the nth number: #light module Strangelights.Fibonacci let fibs = (1,1) |> Seq.unfold (fun (n0, n1) -> Some(n0, (n1, n0 + n1))) let getFib n = Seq.nth n fibs Using this function from a form is pretty straightforward; you just need to reference your F# .dll from the Visual Studio form project. You can use the module Strangelights.Fibonacci by opening the Strangelights namespace and treating Fibonacci as if it were a class in C#. The following example shows how to call the function in C# and place the result in a control. Note that because this form was created with Visual Studio 2005, the control definitions are in a separate source file. using System; using System.Windows.Forms; using Strangelights;



namespace CSApp { public partial class FibForm : Form { public FibForm() { InitializeComponent(); } private void calculate_Click(object sender, EventArgs e) { int n = Convert.ToInt32(input.Text); n = Fibonacci.get(n); result.Text = n.ToString(); } } } If you want to be able to use the form created in C# from F#, you need to expose certain controls as properties. Not all controls need to be exposed—just the ones that you want to interact with from F#. The following example shows how to do this in C#; again, any designergenerated code is hidden in a separate file: using System; using System.Windows.Forms; namespace Strangelights.Forms { public partial class FibForm : Form { public FibForm() { InitializeComponent(); } public Button Calculate { get { return calculate; } } public Label Result { get { return result; } }



public TextBox Input { get { return input; } } } } It is then very straightforward to reference the C# .dll from F# and create an instance of the form and use it. The following example demonstrates the code you use to do this: #light open System.Windows.Forms open Strangelights.Forms let fibs = (1,1) |> Seq.unfold (fun (n0, n1) -> Some(n0, (n1, n0 + n1))) let getFib n = Seq.nth n fibs let form = let temp = new FibForm() temp.Calculate.Click.Add (fun _ -> let n = int_of_string temp.Input.Text let n = getFib n temp.Result.Text IEvent.filter (fun e -> e.Button = MouseButtons.Left) |> IEvent.listen (fun _ -> MessageBox.Show("Left button") |> ignore) temp Application.Run(form) Here the filter function is used with a function that checks whether the left mouse button is pressed; the resulting event is then piped forward to the listen function that adds an event handler to the event, exactly as if you had called the event’s .Add method. You could have implemented this using an if expression within the event handler, but this technique has the advantage of separating the logic that controls the event firing and what happens during the event itself. If you want, several event handlers can reuse the new event. Listing 8-3 demonstrates using more of IEvent’s functions to create a simple drawing application (shown in Figure 8-5). Here you want to use the MouseDown event in different ways, first to monitor whether the mouse is pressed at all and then to split the event into left or right button presses using the IEvent.partition function. This is used to control the drawing color, either red or black. Listing 8-3. Using Events to Implement a Simple Drawing Application #light open System open System.Drawing open System.Windows.Forms let form = let temp = new Form(Text = "Scribble !!") let let let let pointsMasterList = ref [] pointsTempList = ref [] mouseDown = ref false pen = ref (new Pen(Color.Black))

temp.MouseDown.Add(fun _ -> mouseDown := true)



let leftMouse, rightMouse = temp.MouseDown |> IEvent.partition (fun e -> e.Button = MouseButtons.Left) leftMouse.Add(fun _ -> pen := new Pen(Color.Black)) rightMouse.Add(fun _ -> pen := new Pen(Color.Red)) temp.MouseUp |> IEvent.listen (fun _ -> mouseDown := false if List.length !pointsTempList > 1 then let points = List.to_array !pointsTempList pointsMasterList := (!pen, points) :: !pointsMasterList pointsTempList := [] temp.Invalidate()) temp.MouseMove |> IEvent.filter(fun _ -> !mouseDown) |> IEvent.listen (fun e -> pointsTempList := e.Location :: !pointsTempList temp.Invalidate()) temp.Paint |> IEvent.listen (fun e -> if List.length !pointsTempList > 1 then e.Graphics.DrawLines (!pen, List.to_array !pointsTempList) !pointsMasterList |> List.iter (fun (pen, points) -> e.Graphics.DrawLines(pen, points))) temp [] do Application.Run(form)



Figure 8-5. Scribble: a simple drawing application implemented using events Events created this way can also be published on the form’s interface so that code consuming the form can also take advantage of these events. Again, a big problem facing a programmer working with events in WinForms is the volume of events available, which can make choosing the right one difficult. Perhaps surprisingly, most events are defined on the class Control, with each specialization providing only a handful of extra events. This generally makes life a bit easier, because if you have used an event with a control, odds are it will also be available on another. To help beginners with the most common events on the Control class, I have provided a summary in Table 8-4. Table 8-4. A Summary of Events on the Control Class


This event is caused by the user clicking the control. It is a high-level event, and although it is ordinarily caused by the user clicking with the mouse, it might also be caused by the user pressing Enter or the spacebar when on a control. There are a series of events called MouseDown, MouseClick, and MouseUp that provide more detailed information about the actions of the mouse, but because these events just provide information about the mouse actions, generally the Click should be handled instead of these events. Otherwise, this will lead to the control responding in ways users expect, because it will respond to keystrokes and mouse clicks. This is raised when the mouse is clicked twice in quick succession; the amount of time is determined by the user’s operating system settings. Programmers should be careful when handling this event because every time this event is raised, a Click event will have been raised before it, so in general programmers should handle either this event or the Click event. continued




Table 8-4. Continued


This event is raised when the control becomes active—either the user presses Tab to enter it, the programmer calls Select or SelectNextControl, or the user clicks it with the mouse. It is usually used to draw attention to the fact that the control is active, such as setting the background to a different color. It is suppressed on the Form class, and programmers should use Activated instead. This event is raised when the control is deactivated—either the user presses Tab to leave it, the programmer calls Select or SelectNextControl, or the user clicks another control with the mouse. The programmer might be tempted to use this event for validation, but they should not do this and should use the Validating and Validated events instead. This event is suppressed on the Form class, and programmers should use Activated instead. This event is part of a sequence of events that can be used to get detailed information about the state of the keyboard. To get details about when a key is first pressed, use KeyDown, and to find out when it is released, use KeyUp instead. This event is raised whenever the control is moved by the user. This event is useful to find out whether the mouse is hovering over a control so can be used to give users more information about the control. The events MouseEnter and MouseLeave are also useful for this. This event occurs when the form will be repainted by Windows; handle this event if you want to take care of drawing the control yourself. For more information about this, see the section “Drawing WinForms” earlier in this chapter. This event occurs when the user resizes the form; it can be useful to handle this event to adjust the layout of the form to the new size.



Move MouseHover



Creating New Forms Classes
So far you’ve looked only at a script style of programming, using an existing form and controls to quickly put forms together. This style of programming is great for the rapid development of single-form applications but has some limitations when creating applications composed of multiple forms or creating libraries of forms for use with other .NET languages. In these cases, you must take a more component-oriented approach. Typically, when creating a large WinForms application, you’ll want to use some forms repeatedly; furthermore, these forms typically communicate with each other by adjusting their properties and calling their methods. You usually do this by defining a new form class that derives from System.Windows.Forms. Listing 8-4 shows a simple example of this, using the class syntax introduced in Chapter 5. Listing 8-4. A Demonstration of Creating a New Type of Form #light open System open System.Windows.Forms



type MyForm() as x = class inherit Form(Width=174, Height=64) let label = new Label(Top=8, Left=8, Width=40, Text="Input:") let textbox = new TextBox(Top=8, Left=48, Width=40) let button = new Button(Top=8, Left=96, Width=60, Text="Push Me!") do button.Click.Add (fun _ -> let form = new MyForm(Text=textbox.Text) form.Show()) do x.Controls.Add(label) do x.Controls.Add(textbox) do x.Controls.Add(button) member x.Textbox = textbox end let form = let temp = new MyForm(Text="My Form") temp.Textbox.Text IEvent.filter (fun e -> e.Button = MouseButtons.Left) |> IEvent.listen (fun e -> trigger e) member x.LeftMouseClick = event end Forms created in this component-based manner will undoubtedly be easier to use than forms created with a more scripted approach, but there are still pitfalls when creating libraries for other .NET languages. Please refer to Chapter 13 for more information about making F# libraries usable by other .NET languages.

Introducing ASP.NET 2.0
ASP .NET 2.0 is a technology designed to simplify creating dynamic web pages. The simplest way to do this is to implement an interface called IHttpHandler. This interface allows the implementer to describe how an HTTP request should be responded to; the next section of the chapter will concentrate on how this works. Merely implementing the IHttpHandler interface will not allow you to take full advantage of the ASP .NET 2.0 feature set. ASP .NET allows users to create web forms, which are composed of controls that know how to render themselves into HTML. The advantage of this is that the programmer has a nice object model to manipulate rather than having to code HTML tags. It also allows a programmer to separate out the layout of controls in an .aspx file. An .aspx file is basically all the static HTML you don’t want to worry about in your F# code, plus a few placeholders for the dynamic controls. This approach is great for programming in F#, because it allows you to separate the code that represents the layout of a form, which can look a little long in F#, from the code that controls its behavior. ASP .NET also lets you store configuration values in an XML-based web.config file. Working with ASP.NET presents an additional challenge; you must configure the web server that will host the ASP .NET application. Your configuration will vary depending on your development environment. Visual Studio 2005 comes with a built-in web server, so to create a new web site, it is just a matter of selecting File ® New ® Web Site and then choosing the location for the web site. This site will run only those pages written in C# or Visual Basic .NET, so you need to add an F# project to the solution and then manually alter the solution file so that it lives inside the web site directory. This is easier than it sounds. You just need to copy the .fsharpp file to the web site directory, open the .sln file in Notepad, and alter the path to the .fsharpp file. After this you merely need to configure the project file to output a library and write this to a bin subdirectory. This might seem like a lot of effort, but after this you will just be able to press F5, and your project will compile and run.



If you do not have Visual Studio 2005, then the next best thing to do is host the site in IIS. In some ways, this is easier than hosting in Visual Studio but doesn’t have the convenience of just being able to execute your code once coding is completed. To host your code in IIS, you need to create an IIS virtual directory with a subdirectory called bin. You then need to copy your .aspx pages and your web.config file to the virtual directory.

I Note Getting ASP.NET to work with F# and Apache is possible but is more difficult than the situation either with or without Visual Studio 2005. Please see the following site for more details of how to do this: Creating an IHttpHandler
Creating an IHttpHandler is the simplest way to take advantage of ASP .NET 2.0. It is a simple interface with just two members. The first of these members is a read-only Boolean property called IsReusable that the programmer should use to indicate whether the runtime can reuse the instance of the object. It is generally best to set this to false. The other member of the interface is the ProcessRequest method, and this is called when a web request is received. It takes one parameter of HttpContent type; you can use this type to retrieve information about the request being made through its Request property and also to respond to the request via its Response property. The following code is a simple example of an IHttpHandler that just responds to a request with the string "Hello World": #light namespace Strangelights.HttpHandlers open System.Web type SimpleHandler() = class interface IHttpHandler with member x.IsReusable = false member x.ProcessRequest(c : HttpContext) = c.Response.Write("Hello World") end end After this, you must configure the URL where the IHttpHandler is available. You do this by adding an entry to the web.config file. If a web.config file is not already in the project, you can add one by right-clicking the web project and choosing Add New Item. The handlers are added to the httpHandlers section, and you need to configure four properties for each handler: path, which is the URL of the page; verb, which configures which HTTP verbs the handler will respond to; type, which is the name of the type that will be used to handle the request; and finally validate, which tells the runtime whether it should check the availability of the type when the application is first loaded.



Figure 8-7 shows the resulting web page.

Figure 8-7. The resulting web page when the SimpleHandler is executed This technique is unsatisfactory for creating web pages, because it requires the HTML tags to be mixed into the F# code. It does have some advantages, though. You can use this technique to put together documents other than HTML documents; for example, you can use it to dynamically create images on the server. The following example shows an IHttpHandler that generates a JPEG image of a pie shape. The amount of pie shown is determined by the angle value that that is passed in on the query string. #light namespace Strangelights.HttpHandlers open System.Drawing open System.Drawing.Imaging open System.Web



type PictureHandler() = class interface IHttpHandler with member x.IsReusable = false member x.ProcessRequest(c : HttpContext) = let bitmap = new Bitmap(200, 200) let graphics = Graphics.FromImage(bitmap) let brush = new SolidBrush(Color.Red) let x = int_of_string(c.Request.QueryString.Get("angle")) graphics.FillPie(brush, 10, 10, 180, 180, 0, x) bitmap.Save(c.Response.OutputStream, ImageFormat.Gif) end end Again, you still need to register this type in the web.config file; the required configuration is as follows: Figure 8-8 shows the resulting image. In this case, I passed in an angle of 200.

Figure 8-8. Using an IHttpHandler to dynamically generate a picture



Although this is a great technique for spicing up web sites, you should be careful when using it. Generating images can be very processor intensive, especially if the images are large or complicated. This can lead to web sites that do not scale up to the required number of concurrent users; therefore, if you do use this technique, ensure you profile your code correctly. For more information about profiling your applications and for some general performance enhancements, please see Chapter 13.

Working with ASP.NET Web Forms
If you want to create dynamic web pages, then you will probably have an easier time using ASP.NET forms than implementing your own IHttpHandler. The main advantage of web forms is that you do not need to deal with HTML tags in F# code; most of this is abstracted away for you. There are other, smaller advantages too, such as that you do not have to register the page in web.config. To create an ASP.NET web form, you generally start by creating the user interface, defined in an .aspx file. The .aspx file is all the static HTML, plus some placeholders for the dynamic controls. An .aspx file always starts with a Page directive; you can see this at the top of the next example. The Page directive allows you to specify a class that the page will inherit from; you do this by using the Inherits attribute and giving the full name of the class. This will be a class in F# that provides the dynamic functionality. If you look at the following example, in among the regular HTML tags you’ll find some tags that are prefixed with asp:. These are ASP .NET web controls, and these provide the dynamic functionality. A web control is a class in the .NET Framework that knows how to render itself into HTML, so for example, the tag will become an HTML tag. You will be able to take control of these controls in your F# class and use them to respond to user input. F# - Hello User Hello User



When designing your class, you need to provide mutable fields with the same name as the controls you want to manipulate. Although the HTML page you created had three controls in it, you provide only two mutable fields, because you don’t want to manipulate the third control, a link button. You just want it to call the SayHelloButton_Click function when you click it. You do this by adding the function name to the OnClick attribute of the asp:LinkButton control. When the other two controls are created, a label and a textbox, they will be stored in the mutable fields OutputControl and InputControl, respectively. It is the code contained in the .aspx page, not your class, that is responsible for creating these controls. This is why you explicitly initialize these controls to null in the constructor. Finally, all that remains in SayHelloButton_Click is to take the input from InputControl and place it into OutputControl. #light namespace Strangelights.HttpHandlers open System open System.Web.UI open System.Web.UI.WebControls type HelloUser = class inherit Page val mutable OutputControl : Label val mutable InputControl : TextBox new() = { OutputControl = null InputControl = null } member x.SayHelloButton_Click((sender : obj), (e : EventArgs)) = x.OutputControl.Text (XamlReader.Load(stream) :?> Window))



// create the window object and add event handler // to the button control let window = let temp = createWindow "Window1.xaml" let press = temp.FindName("press") :?> Button let textbox = temp.FindName("input") :?> TextBox let label = temp.FindName("output") :?> Label press.Click.Add (fun _ -> label.Content ignore [] do main() To get this program to compile, you must add references to PresentationCore.dll, PresentationFramework.dll, and WindowsBase.dll, which are usually found in the directory C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0. In the other examples in this chapter, you didn’t need to add references, since the libraries were automatically referenced by the compiler. The form appears as in Figure 8-11.

Figure 8-11. A form created using XAML and F#

Introducing Windows Presentation Foundation 3D
Another great advantage of WPF is the huge number of controls it offers. One control that you’ll dig a little deeper into is Viewport3D, which offers the ability to create impressive 3D graphics, something not readily available with the WinForms library. You’ll learn how you can display a 3D plane and then map an equation over it.



The example (shown later in Listing 8-7) starts with the XAML script. Both XAML and 3D graphics are huge topics; my aim is not to cover them in detail but to give you enough of an idea of what they involve and to give you the basis for your own experiments. The following XAML script describes a window with one control, a Viewport3D, on it. The script is fairly lengthy because there are quite a few elements required to make a 3D scene. First you must define a camera so you know which direction you are looking at the scene from. You do this using the element: The tags inside describe what the scene will look like. The tag describes how the scene will be lit, and the tag describes the 3D shape in the scene: Here you could describe all the objects that make up the scene by giving the points that make them up using the tag; however, you don’t describe the points that make up the shape since it is a lot easier to do this in F# than in XAML. The tag describes what the surface of the shape will look like: The tag describes a transformation that will be applied to the shape, that is, a transformation that will mean the shape will be rotated by a certain angle:



You do this mainly so you can use the tag to define an animation that will alter the angle it is shown at over time: To demonstrate how these various sections hang together, Listing 8-7 shows the complete example. Listing 8-7. An XAML Definition of a 3D Scene





The example continues later in Listing 8-8, with the F# script, which borrows a couple of functions from Listing 8-6; it also assumes that Listing 8-7 is saved in a file called Window2.xaml. You use the createWindow function to load the window and use a similar main function to display the window. You then use the findMeshes function to find any meshes in the picture (a mesh is a set of points used to describe the 3D plane). You find the meshes by walking the various objects in the Viewport3D and building up a list: // finds all the MeshGeometry3D in a given 3D view port let findMeshes ( viewport : Viewport3D ) = viewport.Children |> Seq.choose (function :? ModelVisual3D as c -> Some(c.Content) | _ -> None) |> Seq.choose (function :? Model3DGroup as mg -> Some(mg.Children) | _ -> None) |> Seq.concat |> Seq.choose (function :? GeometryModel3D as mg -> Some(mg.Geometry) | _ -> None) |> Seq.choose (function :? MeshGeometry3D as mv -> Some(mv) | _ -> None) I kept this function generic so it could work with any Viewport3D. It is highly likely that you will want to grab a list of all the meshes in your 3D scene in any 3D work you do in XAML and F# because it is likely that you will want to manipulate your meshes in some way in F#. Then you use createPlaneItemList, createSquare, createPlanePoints, createIndicesPlane, and addPlaneToMesh to add a flat plane to the mesh object in the scene. The function mapPositionsCenter centers the plane so it is in the middle of the scene. Finally, a clever little function called changePositions maps the function movingWaves repeatedly across the plane ten times a second. The core of this function creates a new Point3DCollection from the Point3D objects contained within the old one using the function movingWaves to decide what the new Z position should be. let changePositions () = let dispatcherTimer = new DispatcherTimer() dispatcherTimer.Tick.Add (fun e -> let t = (float_of_int DateTime.Now.Millisecond) / 2000.0 let newPositions = mesh.Positions |> (fun position -> let z = movingWaves t position.X position.Y new Point3D(position.X, position.Y, z)) mesh.Positions Window temp.Height None) |> Seq.choose (function :? Model3DGroup as mg -> Some(mg.Children) | _ -> None) |> Seq.concat |> Seq.choose (function :? GeometryModel3D as mg -> Some(mg.Geometry) | _ -> None) |> Seq.choose (function :? MeshGeometry3D as mv -> Some(mv) | _ -> None) // loop function to create all items necessary for a plane let createPlaneItemList f (xRes : int) (yRes : int) = let list = new List() for x = 0 to xRes - 1 do for y = 0 to yRes - 1 do f list x y list



// function let point x // function let point3D

to initialize a point y = new Point(x, y) to initialize a "d point x y = new Point3D(x, y, 0.0)

// create all the points necessary for a square in the plane let createSquare f (xStep : float) (yStep : float) (list : List) (x : int) (y : int) = let x' = Float.of_int x * xStep let y' = Float.of_int y * yStep list.Add(f x' y') list.Add(f (x' + xStep) y') list.Add(f (x' + xStep) (y' + yStep)) list.Add(f (x' + xStep) (y' + yStep)) list.Add(f x' (y' + yStep)) list.Add(f x' y') // create all items in a plane let createPlanePoints f xRes yRes = let xStep = 1.0 / Float.of_int xRes let yStep = 1.0 / Float.of_int yRes createPlaneItemList (createSquare f xStep yStep) xRes yRes // create the 3D positions for a plane, i.e., the thing that says where // the plane will be in 3D space let createPlanePositions xRes yRes = let list = createPlanePoints point3D xRes yRes new Point3DCollection(list) // create the texture mappings for a plane, i.e., the thing that // maps the 2D image to the 3D plane let createPlaneTextures xRes yRes = let list = createPlanePoints point xRes yRes new PointCollection(list) // create indices list for all our triangles let createIndicesPlane width height = let list = new System.Collections.Generic.List() for index = 0 to width * height * 6 do list.Add(index) new Int32Collection(list) // center the plane in the field of view let mapPositionsCenter (positions : Point3DCollection) = let newPositions = positions |>



(fun position -> new Point3D( (position.X - 0.5 ) * -1.0 , (position.Y - 0.5 ) * -1.0, position.Z)) new Point3DCollection(newPositions) // create a plane and add it to the given mesh let addPlaneToMesh (mesh : MeshGeometry3D) xRes yRes = mesh.Positions (fun position -> let z = movingWaves t position.X position.Y new Point3D(position.X, position.Y, z)) mesh.Positions 0.0) // function for changing the plane over time let changePositions () = let dispatcherTimer = new DispatcherTimer() dispatcherTimer.Tick.Add (fun e -> let t = (float_of_int DateTime.Now.Millisecond) / 2000.0 let newPositions = mesh.Positions |> (fun position -> let z = f t position.X position.Y new Point3D(position.X, position.Y, z)) mesh.Positions List.iter (fun x -> let element = temp.CreateElement(fst x) element.InnerText ignore ) temp animalsDoc.Save("animals.xml") The result of this code is a file, animals.xml, containing the following XML document: 6 8 4 The System.Xml namespace is large, with many interesting classes to help you work with XML data. Table 9-1 describes some of the most useful ones.



Table 9-1. Summary of Useful Classes from the System.XML Namespace

System.Xml.XmlDocument System.Xml.XmlNode

The Microsoft .NET implementation of the W3C’s XML DOM. This class can’t be created directly but is often used; it is the result of the XmlDocument’s SelectSingle node method. This class is a collection of nodes and is the result of the XmlDocument’s SelectNode method. This provides forward-only, read-only access to an XML document. Although not as easy to use as the XmlDocument class, it does not require the whole document to be loaded into memory. When working with big documents, it can often provide better performance than the XmlDocument. This class provides a forward-only way to write to an XML document. If you must start your XML document from scratch, this is often the easiest way to create it. This provides a way of loading an XML schema into memory and then allows the user to validate XML documents with it. This allows a user to serialize .NET objects directly to and from XML. However, unlike the BinarySerializer available elsewhere in the framework, this class serializes only public fields. This class is designed to be the most efficient way to work with XPath expressions. This class is just the wrapper for the XML document; the programmer must use the XPathExpression and XPathNavigator to actually do the work. This class represents an XPath expression to be used with an XPathDocument; it can be compiled to make it more efficient when used repeatedly. Once an XPathExpression has been executed against the XPathDocument, this class can be used to navigate the results; the advantage of this class is that it pulls only one node at a time into memory, making it efficient in terms of memory. This class can be used to transform XML using XSLT style sheets.

System.Xml.XmlNodeList System.Xml.XmlTextReader








Relational database management systems are the most pervasive form of data storage. ADO.NET, in System.Data and associated namespaces, makes it easy to access relational data. In this section, you’ll look at various ways you can use F# with ADO.NET.



I Note All database providers use a connection string to specify the database to which to connect. You can find a nice summary of the connection strings you need to know at

All examples in this section use the AdventureWorks sample database and SQL Server 2005 Express Edition, both freely available for download from It should be easy to port these samples to other relational databases. To use this database with SQL Server 2005 Express Edition, you can use the following connection settings or an adaptation of them appropriate to your system: I’ll discuss options for accessing other relational databases in the section “ADO.NET Extensions.” The following example shows a simple way of accessing a database: #light #r "System.Configuration.dll";; open System.Configuration open System.Data open System.Data.SqlClient let connectionSetting = ConfigurationManager.ConnectionStrings.Item("MyConnection") let connectionString = connectionSetting.ConnectionString using (new SqlConnection(connectionString)) (fun connection -> let command = let temp = connection.CreateCommand() temp.CommandText readOneRow(reader)) After defining a function such as execCommand, accessing a database becomes pretty easy. You call execCommand, passing the chosen connection and command, and then enumerate the results. This is as follows: let contactsTable = execCommand "MyConnection" "select * from Person.Contact" for row in contactsTable do for col in row.Keys do printfn "%s = %O" col (row.Item(col)) The results are as follows: ... ContactID = 18 NameStyle = False Title = Ms. FirstName = Anna MiddleName = A. LastName = Albright Suffix = EmailAddress = EmailPromotion = 1 Phone = 197-555-0143 PasswordHash = 6Hwr3vf9bo8CYMDbLuUt78TXCr182Vf8Zf0+uil0ANw= PasswordSalt = SPfSr+w= AdditionalContactInfo = rowguid = b6e43a72-8f5f-4525-b4c0-ee84d764e86f ModifiedDate = 01/07/2002 00:00:00 ...



One thing you should be careful about when dealing with relational databases is ensuring that the connection is closed in a timely manner. Closing the connection quickly makes the connection available to other database users, improving concurrent access. Let’s look at how the previous sample creates connections and how they are “cleaned up” automatically. In the previous example, the opener function openConnectionReader is called every time the collection is enumerated using Seq.iter. This uses an IEnumerator object to iterate the data, which in turn uses the generator function to generate individual results. Each call to Seq.iter creates one SqlDataReader and one SqlDataReader object. These must be closed at the end of the iteration or if the iteration terminates abruptly for some reason. Fortunately, the F# library implementation of Seq.iter and Seq.generate_using are careful to invoke the right functions to clean up resources on both complete and partial iterations. They do this by calling IDisposable.Dispose methods on the intermediate IEnumerator objects, which in turn cause the SqlDataReader to be closed. You must also close the corresponding SqlConnection object, which is done by linking the closing of the database connection to the closing of the SqlDataReader: command.ExecuteReader(CommandBehavior.CloseConnection) To avoid keeping the connection open for too long, you should avoid complicated or timeconsuming operations while iterating the resulting IEnumerable collection, and you should especially avoid any user interaction with the collection. For example, rewriting the previous example so the user can move on to the next record by pressing Enter would be bad for database performance, as shown here: for row in contactsTable do for col in row.Keys do printfn "%s = %O" col (row.Item(col)) printfn "Press to see next record" read_line() |> ignore If you want to use the collection more than once or let the user interact with it, you should generally convert it to a list or an array; an example of this is as follows: let contactsTable = execCommand "select * from Person.Contact" "MyConnection" let contactsList = Seq.to_list contactsTable Although connections will be closed when the cursors are garbage collected, this generally takes too long, especially if a system is under stress. For example, if the code you are writing will run in a server application that will handle lots of concurrent users, then not closing connections will cause errors because the server will run out of database connections.

The EntLib Data Access Block
The Enterprise Library (EntLib) is a library produced by the Microsoft Patterns and Practices department and is available for download at This section uses EntLib 2.0. It includes a data access block, which is designed to help programmers conform to best practices when writing data access code.



EntLib includes a configuration console, which allows you to configure connection strings without having to deal directly with the XML .config file. Figure 9-1 shows the configuration console.

Figure 9-1. The enterprise library configuration console EntLib simplifies data access by allowing you to create an instance of the Database class that is based on the connection string and provider configured in the section in the .config file. This Database class then allows you to execute queries against the database with minimal effort. Further, because you don’t directly create the ADO.NET objects, you can change which type of provider you want to use just by changing the configuration file. I’ll discuss how this works in the section “ADO.NET Extensions” later in the chapter. The following example shows how to use EntLib to execute a stored procedure, "uspGetBillOfMaterials", against the configured AdventureWorks database: #light #r "Microsoft.Practices.EnterpriseLibrary.Data.dll";; open System open Microsoft.Practices.EnterpriseLibrary.Data let database = DatabaseFactory.CreateDatabase()



let reader = database.ExecuteReader( "uspGetBillOfMaterials", [| box 316; box (new DateTime(2006,1,1)) |]) while reader.Read() do for x = 0 to (reader.FieldCount - 1) do printfn "%s = %O" (reader.GetName(x)) (reader.Item(x)) The results are as follows: ProductAssemblyID = 316 ComponentID = 486 ComponentDesc = Metal Sheet 5 TotalQuantity = 1,00 StandardCost = 0,0000 ListPrice = 0,0000 BOMLevel = 4 RecursionLevel = 0 In my experience, EntLib can help you reduce the amount of data access code you need to write and assist you in changing between the types of databases you are using.

Data Binding
Data binding is the process of mapping a value or set of values to a user interface control. The data does not particularly need to be from a relational database, but it is generally from some system external to the program, and the process of accessing this data and transforming it into a state where it can be bound is more complicated than the binding itself, which is straightforward. This is why I cover this topic in this chapter rather than in Chapter 8. The next example shows how to bind data from a database table to a combo box: #light #r "Microsoft.Practices.EnterpriseLibrary.Data.dll";; open System open System.Collections.Generic open System.Data open System.Windows.Forms open Microsoft.Practices.EnterpriseLibrary.Data let opener commandString = let database = DatabaseFactory.CreateDatabase() database.ExecuteReader(CommandType.Text, commandString)



let generator (reader : IDataReader) = if reader.Read() then let dict = new Dictionary() for x = 0 to (reader.FieldCount - 1) do dict.Add(reader.GetName(x), reader.Item(x)) Some(dict) else None let execCommand (commandString : string) = Seq.generate_using (fun () -> opener commandString) (fun r -> generator r) let contactsTable = execCommand "select top 10 * from Person.Contact" let contacts = [| for row in contactsTable -> Printf.sprintf "%O %O" (row.Item("FirstName")) (row.Item("LastName")) |] let form = let temp = new Form() let combo = new ComboBox(Top=8, Left=8, DataSource=contacts) temp.Controls.Add(combo) temp Application.Run(form) Figure 9-2 shows the resulting form.

Figure 9-2. A data-bound combo box



If you break the previous example down a bit, first you execute the query: let contactsTable = execCommand "select top 10 * from Person.Contact" You then need to turn the resulting IEnumerable collection into something suitable to be bound to the combo box; you do this by first grabbing the important members, then mapping them into a string collection, and finally converting it to an array. Then you must bind the collection to the control that will display it; you do this by setting the control’s DataSource property: combo.DataSource You do this so you can explicitly give the generic argument 'a. This is used later in the function to create a type object that you then reflect over: let t = (type 'a) The function is designed to work with an F# record type, whose fields exactly match the fields resulting from the query. If this precondition is not met, then the code will fail, but such preconditions are typical in applications that use reflection in this way. The function execCommand you have defined is generic and can be used with any query and matching record type. The following example shows how to apply it: type Contact = { ContactID : Nullable ; NameStyle : Nullable ; Title : string ; FirstName : string ; MiddleName : string ; LastName : string ; Suffix : string ; EmailAddress : string ; EmailPromotion : Nullable ; Phone: string ; PasswordHash : string ; PasswordSalt : string ; AdditionalContactInfo : string ; rowguid : Nullable ; ModifiedDate : Nullable ; }



let form = let temp = new Form() let grid = new DataGridView(Dock = DockStyle.Fill) temp.Controls.Add(grid) let contacts = execCommand "select top 10 * from Person.Contact" let contactsArray = contacts |> Seq.to_array grid.DataSource openConnectionReader cmdString) // This function gets called to read a single item in // the enumerable for a reader/conn pair (fun reader -> readOneRow(reader)) let employeeTable = execCommand "select * from Employee" for row in employeeTable do for col in row.Keys do printfn "%s = %O " col (row.Item(col)) The results of this example are as follows: ... EMP_NO = 145 FIRST_NAME = Mark LAST_NAME = Guckenheimer PHONE_EXT = 221



HIRE_DATE = 02/05/1994 00:00:00 DEPT_NO = 622 JOB_CODE = Eng JOB_GRADE = 5 JOB_COUNTRY = USA SALARY = 32000 FULL_NAME = Guckenheimer, Mark You will observe that very little changes were needed to convert the SQL Server AdventureWorks contact table example given earlier in the chapter to an example that executed a query against the Firebird employee example database.

Introducing LINQ
Language-Integrated Query (LINQ) is the next generation of .NET data access technology. It borrows heavily from functional programming, so it fits very nicely with F#.

I Note All examples in this section and other sections about LINQ are based on the Community Technology
Preview of May 2006, the Microsoft .NET LINQ Preview (May 2006), and the F# LINQ bindings that match this release. If you use the examples with later versions of LINQ, you will have to make changes to the code.

At its heart, LINQ is a set of libraries for manipulating collections that implement the IEnumerable interface, a lot like F#’s Seq module, which was discussed in Chapter 7. The idea is that you can use this library to query any in-memory collection, whether the data comes from a database, an XML file, or just objects returned from another API. Although the concepts implemented in the LINQ library will be familiar to you by now, they follow a slightly different naming convention that is based on SQL. For instance, the equivalent of is called Sequence.Select, and the equivalent Seq.filter is called Sequence.Where. The next example shows how to use this library. The first step is to import the methods exposed by the LINQ library into a more usable form; this is how to do that: #light #I "C:\Program Files\LINQ Preview\Bin";; #r "System.Query.dll";; open System.Query open System.Reflection



// define easier access to LINQ methods let select f s = Sequence.Select(s, new Func(f)) let where f s = Sequence.Where(s, new Func(f)) let groupBy f s = Sequence.GroupBy(s, new Func(f)) let orderBy f s = Sequence.OrderBy(s, new Func(f)) let count s = Sequence.Count(s) Once these functions have been imported, they can easily be applied, typically using the pipe forward operator. The following example demonstrates this. It uses the LINQ library to query the string class and group the overloads of its nonstatic methods together. // query string methods using functions let namesByFunction = (type string).GetMethods() |> where (fun m -> not m.IsStatic) |> groupBy (fun m -> m.Name) |> select (fun m -> m.Key, count m) |> orderBy (fun (_, m) -> m) namesByFunction |> Seq.iter (fun (name, count) -> printfn "%s - %i" name count) The results are as follows: ToLowerInvariant - 1 TrimEnd - 1 GetHashCode - 1 TrimStart - 1 GetEnumerator - 1 GetType - 1 GetTypeCode - 1 ToUpperInvariant - 1 Clone - 1 CopyTo - 1 get_Length - 1 Insert - 1 get_Chars - 1 PadLeft - 2 CompareTo - 2 PadRight - 2 ToUpper - 2 ToLower - 2 ToString - 2 Trim - 2 Remove - 2 ToCharArray - 2 Substring - 2 IsNormalized - 2



Normalize - 2 Replace - 2 IndexOfAny - 3 EndsWith - 3 Equals - 3 StartsWith - 3 LastIndexOfAny - 3 Split - 6 LastIndexOf - 9 IndexOf - 9

Using LINQ to XML
The goal of LINQ to XML is to provide an XML object model that works well with LINQ’s functional style of programming. Table 9-4 summarizes the important classes within this namespace. Table 9-4. A Summary of the Classes Provided by LINQ to XML

Class Name
XNode XContainer XDocument XElement

Parent Class

This class provides the basic functionality that is applicable to all nodes in an XML document.

XNode XContainer XContainer

This class provides the functionality for XML nodes that can contain other nodes. This class represents the XML document as a whole. This class represents an element in the XML document, that is, a regular XML node that can be a tag, , or can possibly contain other tags or an attribute, such as myAttribute="myVal". This class represents a document type tag. This class represents a processing instruction, which is a tag of the form . This class represents text contained within the XML document. This class represents the name of a tag or an attribute.

XDocumentType XProcessInstruction XText XName

XNode XNode XNode

To show how to use this object model, you can revise the example from the previous section to output XML instead of plain text. LINQ to XML makes this easy to do; first you modify the select statement to return an XElement instead of a tuple: |> select (fun m -> new XElement(XName.Get(m.Key), count m)) This gives an array of XElements that you can then use to initialize another XElement, which provides the root of the document. It is then just a matter of calling the root XElement’s ToString method, which will provide the XML in the form of a string.



#light #I "C:\Program Files\LINQ Preview\Bin";; #r "System.Query.dll";; #r "System.Xml.XLinq.dll";; open System.Query open System.Reflection open System.Xml.XLinq // define easier access to LINQ methods let select f s = Sequence.Select(s, new Func(f)) let where f s = Sequence.Where(s, new Func(f)) let groupBy f s = Sequence.GroupBy(s, new Func(f)) let orderBy f s = Sequence.OrderBy(s, new Func(f)) let count s = Sequence.Count(s) // query string methods using functions let namesByFunction = (type string).GetMethods() |> where (fun m -> not m.IsStatic) |> groupBy (fun m -> m.Name) |> select (fun m -> new XElement(XName.Get(m.Key), count m)) |> orderBy (fun e -> int_of_string e.Value) let overloadsXml = new XElement(XName.Get("MethodOverloads"), namesByFunction) print_endline (overloadsXml.ToString()) The results of this code, when compiled and executed, are as follows: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2



2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 6 9 9

Using LINQ to SQL
LINQ to SQL is designed to allow data access to relational databases. It does this through a combination of code generation and the ability to quote code. For the code generation, LINQ to SQL provides a tool called SqlMetal.exe, which will generate a code version of your relational database; this code version of your database is an object model where the tables become classes with properties representing their columns. Quoting code means the ability to have the compile transform a section of code into data structure called an expression tree; you first came across this technique in Chapter 6, but this is the first time you will see it put into real use. The quoted code will be transformed into SQL that can then be executed on the database. The first step in working with LINQ to ADO.NET is to generate a code version of your database. To do this, you would use the following command line, which generates a code version of the AdventureWorks database that is running on the local version of SQL Server Express: SqlMetal.exe /server:.\SQLEXPRESS /database:AdventureWorks /code:AdWorks.cs /language:csharp The C# classes that represent the database’s objects are generated, but you do not need to know C# to work with it, because you only ever use a compiled version of the code, just like using any other .NET library. This example relies on an example LINQ library distributed with F# that you can find in the \samples\fsharp\FLinq directory of the distribution. This library also provides useful functions that your DLINQ library requires; first it imports the .NET methods, and then it transforms them into F# methods. The other function it provides is to transform the F# expression trees into the trees used by DLINQ. The library is distributed as a sample, rather than being integrated into the



F# libraries, because the F# team did not want to introduce a binary dependency onto something as experimental as LINQ. Once LINQ is released and part of the .NET Framework, the functionalities provided by this sample library will be migrated into the F# libraries. The following example shows how to use DLINQ in F#. It shows two powerful features of DLINQ: the ability to have your F# code transformed into a SQL query and the ability to create instances of rows without having to use reflection, like you did for the data binding example earlier in the chapter: #light #r "Microsoft.Practices.EnterpriseLibrary.Data.dll";; #r "flinq.dll";; #r "AdventureWorks.dll";; #r "System.Data.DLinq.dll";; #r "System.Query.dll";; open open open open System.Windows.Forms Microsoft.FSharp.Quotations.Typed Microsoft.FSharp.Bindings.DLinq.Query Microsoft.Practices.EnterpriseLibrary.Data

module sOps = Microsoft.FSharp.Bindings.Linq.SequenceOps let database = DatabaseFactory.CreateDatabase() let adventureWorks = new AdventureWorks(database.CreateConnection()) type Person = { Title : string ; FirstName : string ; LastName : string ; } let contacts = adventureWorks.Person.Contact |> where « fun c -> c.FirstName = "Robert" » |> (fun c -> { Title = c.Title ; FirstName = c.FirstName; LastName = c.LastName }) |> Seq.to_array let form = let temp = new Form() let grid = new DataGridView(Dock = DockStyle.Fill) temp.Controls.Add(grid) grid.DataSource c.FirstName =

Figure 9-4 shows that the results from both examples are the same.

Figure 9-4. Data grid containing the results of a DLINQ query

This chapter has looked at the options for data access in F#. It has shown that the combination of F# with .NET libraries is powerful yet straightforward, no matter what your data source is. The next chapter will look at the related topic of how applications exchange data to become distributed applications.



Distributed Applications

pplications that use networks, called distributed applications, become more important every day. Fortunately, the .NET BCL and other libraries offer many constructs that make communicating over a network easy, so creating distributed applications in F# is straightforward.

Networking Overview
Several types of distributed applications exist; they’re generally classified into either client-server applications, in which clients make requests to a central server, or peer-to-peer applications, in which computers exchange data among themselves. In this chapter, you’ll focus on building client-server applications, since these are currently more common. Whichever type of distributed application you want to build, the way computers exchange data is controlled by a protocol. A protocol is a standard that defines the rules for communication over a network. Building a network-enabled application is generally considered one of the most challenging tasks a programmer can perform, with good reason. When building a network application, you must consider three important requirements: Scalability: The application must remain responsive when used by many users concurrently; typically this means extensive testing and profiling of your server code to check that it performs when a high load is placed on it. You can find more information about profiling code in Chapter 12. Fault tolerance: Networks are inherently unreliable, and you shouldn’t write code that assumes that the network will always be there. If you do, your applications will be very frustrating to end users. Every application should go to lengths to ensure communication failures are handled smoothly, which means giving the user appropriate feedback, displaying error messages, and perhaps offering diagnostic or retry facilities. Do not let your application crash because of a network failure. You should also consider data consistency (that is, can you be sure that all updates necessary to keep data consistent reached the target computer?). Using transactions and a relational database as a data store can help with this. Depending on the type of application, you might also want to consider building an offline mode where the user is offered access to locally stored data and network requests are queued up until the network comes back online. A good example of this kind of facility is the offline mode that most email clients offer.




Security: Although security should be a concern for every application you write, it becomes a hugely important issue in network programming. This is because when you expose your application to a network, you open it up to attack from any other user of the network; therefore, if you expose your application to the Internet, you might be opening it up to thousands or even millions of potential attackers. Typically you need to think about whether data traveling across the network needs to be secured, either signed to guarantee it has not been tampered with or encrypted to guarantee only the appropriate people can read it. You also need to ensure that the people connecting to your application are who they say they are and are authorized to do what they are requesting to do. Fortunately, modern programmers don’t have to tackle these problems on their own; network protocols can help you tackle these problems. For example, if it is important that no one else on the network reads the data you are sending, you should not attempt to encrypt the data yourself. Instead, you should use a network protocol that offers this facility. These protocols are exposed though components from libraries that implement them for you. The type of protocol, and the library used, is dictated by the requirements of the applications. Some protocols offer encryption and authentication, and others don’t. Some are suitable for client-server applications, and others are suitable for peer-to-peer applications. You’ll look at the following components and libraries, along with the protocols they implement, in this chapter: TCP/IP sockets: Provide a great deal of control over what passes over a network for either client-server or peer-to-peer applications HTTP/HTTPS requests: Support requests from web pages to servers, typically only for client-server applications Web services: Expose applications so other applications can request services, typically used only for client-server applications Windows Communication Foundation: Extends web services to support many features required by modern programmers including, but not limited to, security, transactions, and support for either client-server or peer-to-peer applications A simple way of providing a user interface over a network is to develop a web application. Web applications are not covered here, but you can refer to the ASP .NET sections in Chapter 8.

Using TCP/IP Sockets
TCP/IP sockets provide a low level of control over what crosses over a network. A TCP/IP socket is a logical connection between two computers through which either computer can send or receive data at any time. This connection remains open until it is explicitly closed by either of the computers involved. This provides a high degree of flexibility but raises various issues that you’ll examine in this chapter, so unless you really need a very high degree of control, you’re better off using the more abstract network protocols you’ll look at later in this chapter. The classes you need in order to work with TCP/IP sockets are contained in the namespace System.Net, as summarized in Table 10-1.



Table 10-1. Classes Required for Working with TCP/IP Sockets

System.Net.Sockets.TcpListener System.Net.Sockets.TcpClient System.Net.Sockets.NetworkStream

This class is used by the server to listen for incoming requests. This class is used by both the client and the server to control how data is sent over a network. This class can be used to both send and receive data over a network. It sends bytes over a network, so it is typically wrapped in another stream type to send text. This class can be used to wrap the NetworkStream class in order to read text from it. The StreamReader provides the methods ReadLine and ReadToEnd, which both return a string of the data contained in the stream. Various different text encodings can be used by supplying an instance of the System.Text.Encoding class when the StreamWriter is created. This class can be used to wrap the NetworkStream class in order to write text to it. The StreamWriter provides the methods Write and WriteLine, which both take a string of the data to be written to the stream. Various different text encodings can be used by supplying an instance of the System.Text.Encoding class when the StreamWriter is created.



In this chapter’s first example, you’ll build a chat application, consisting of a chat server (shown in Listing 10-1) and a client (shown in Listing 10-2). It is the chat server’s job to wait and listen for clients that connect. Once a client connects, it must ask the client to provide a username, and then it must constantly listen for incoming messages from all clients. Once it receives an incoming message, it must push that message out to all clients. It is the job of the client to connect to the server and provide an interface to allow the user to read the messages received and to write messages to send to the other users. The TCP/IP connection works well for this type of application because the connection is always available, and this allows the server to push any incoming messages directly to the client without polling from the client. Listing 10-1. A Chat Server #light open System open System.IO open System.Net open System.Net.Sockets open System.Threading open System.Collections.Generic type ClientTable() = class let clients = new Dictionary()



/// Add a client and its stream writer member t.Add(name,sw:StreamWriter) = lock clients (fun () -> if clients.ContainsKey(name) then sw.WriteLine("ERROR - Name in use already!") sw.Close() else clients.Add(name,sw)) /// Remove a client and close it, if no one else has done that first member t.Remove(name) = lock clients (fun () -> clients.Remove(name) |> ignore) /// Grab a copy of the current list of clients member t.Current = lock clients (fun () -> clients.Values |> Seq.to_array) /// Check whether a client exists member t.ClientExists(name) = lock clients (fun () -> clients.ContainsKey(name) |> ignore)

end type Server() = class let clients = new ClientTable() let sendMessage name message = let combinedMessage = Printf.sprintf "%s: %s" name message for sw in clients.Current do try lock sw (fun () -> sw.WriteLine(combinedMessage) sw.Flush()) with | _ -> () // Some clients may fail let emptyString s = (s = null || s = "") let handleClient (connection : TcpClient) = let stream = connection.GetStream() let sr = new StreamReader(stream) let sw = new StreamWriter(stream) let rec requestAndReadName() = sw.WriteLine("What is your name? "); sw.Flush()



let rec readName() = let name = sr.ReadLine() if emptyString(name) then readName() else name let name = readName() if clients.ClientExists(name) then sw.WriteLine("ERROR - Name in use already!") sw.Flush() requestAndReadName() else name let name = requestAndReadName() clients.Add(name,sw) let rec listen() = let text = try Some(sr.ReadLine()) with _ -> None match text with | Some text -> if not (emptyString(text)) then sendMessage name text Thread.Sleep(1) listen() | None -> clients.Remove name sw.Close() listen() let server = new TcpListener(IPAddress.Loopback, 4242) let rec handleConnections() = server.Start() if (server.Pending()) then let connection = server.AcceptTcpClient() printf "New Connection" let t = new Thread(fun () -> handleClient connection) t.Start() Thread.Sleep(1); handleConnections() member server.Start() = handleConnections() end (new Server()).Start()



Let’s work our way through Listing 10-1 starting at the top and working down. The first step is to define a class to help you manage the clients connected to the server. The members Add, Remove, Current, and ClientExists share a mutable dictionary, defined by the binding: let clients = new Dictionary() This contains a mapping from client names to connections, hidden from other functions in the program. The Current member copies the entries in the map into an array to ensure there is no danger of the list changing while you are enumerating it, which would cause an error. You can still update the collection of clients using Add and Remove, and the updates will become available the next time Current is called. Because the code is multithreaded, the implementation of Add and Remove lock the client collection to ensure no changes to the collection are lost through multiple threads trying to update it at once. The next function you define, sendMessage, uses the Current member to get the map of clients and enumerates it using a list comprehension, sending the message to each client as you go through the collection. Note here how you lock the StreamWriter class before you write to it: lock sw (fun () -> sw.WriteLine(message) sw.Flush()) This is to stop multiple threads writing to it at once, which would cause the text to appear in a jumbled order on the client’s screen. After defining the emptyString function, which is a useful little function that wraps up some predicate that you use repeatedly, you define the handleClient function, which does the work of handling a client’s new connection and is broken down into a series of inner functions. The handleClient function is called by the final function you will define, handleConnections, and will be called on a new thread that has been assigned specifically to handle the open connection. The first thing handleClient does is get the stream that represents the network connection and wrap it in both a StreamReader and a StreamWriter: let stream = connection.GetStream() let sr = new StreamReader(stream) let sw = new StreamWriter(stream) Having a separate way to read and write from the stream is useful because the functions that will read and write to the stream are actually quite separate. You have already met the sendMessage function, which is the way messages are sent to clients, and you will later see that a new thread is allocated specifically to read from the client. The inner function requestAndReadName that you define next in handleClient is fairly straightforward; you just repeatedly ask the user for a name until you find a name that is not an empty or null string and is not already in use. Once you have the client name, you use the addClient function to add it to the collection of clients: let name = requestAndReadName() addClient name sw The final part of handleConnection is defining the listen function, which is responsible for listening to messages incoming from the client. Here you read some text from the stream, wrapped in a try expression using the option type’s Some/None values to indicate whether text was read:



let text = try Some(sr.ReadLine()) with _ -> None You then use pattern matching to decide what to do next. If the text was successfully read, then you use the sendMessage function to send that message to all the other clients; otherwise, you remove yourself from the collection of clients and allow the function to exit, which will in turn mean that the thread handling the connections will exit.

I Note Although the listen function is recursive and could potentially be called many times, there is no danger of the stack overflowing. This is because the function is tail recursive, meaning that the compiler emits a special tail instruction that tells the .NET runtime that the function should be called without using the stack to store parameters and local variables. Any recursive function defined in F# that has the recursive call as the last thing that happens in the function is tail recursive.

Next you create an instance of the TcpListener class. This is the class that actually does the work of listening to the incoming connections. You normally initialize this with the IP address and the port number on which the server will listen. When you start the listener, you tell it to listen on the IPAddress.Any address so that the listener will listen for all traffic on any of the IP addresses associated with the computer’s network adapters; however, because this is just a demonstration application, you tell the TcpListener class to listen to IPAddress.Loopback, meaning it will pick up the request only from the local computer. The port number is how you tell that the network traffic is for your application and not another. Using the TcpListener class, it is possible for only one listener to listen to a port at once. The number you choose is somewhat arbitrary, but you should choose a number greater than 1023, because the port numbers from 0 to 1023 are reserved for specific applications. So, to create a listener on port 4242 that you code, you use the TcpListener instance in the final function you define, handleConnections: let server = new TcpListener(IPAddress.Loopback, 4242) This function is an infinite loop that listens for new clients connecting and creates a new thread to handle them. It’s the following code that, once you have a connection, you use to retrieve an instance of the connection and start the new thread to handle it: let connection = server.AcceptTcpClient() print_endline "New Connection" let t = new Thread(fun () -> handleClient connection) t.Start() Now that you understand how the server works, let’s take a look at the client, which is in many ways a good deal simpler than the server. Listing 10-2 shows the full code for the client, which is followed by a discussion of how the code works. Listing 10-2. A Chat Client #light open System open System.ComponentModel open System.IO



open System.Net.Sockets open System.Threading open System.Windows.Forms let form = let temp = new Form() temp.Text Application.Exit() Environment.Exit(0)) let output = new TextBox(Dock = DockStyle.Fill, ReadOnly = true, Multiline = true) temp.Controls.Add(output) let input = new TextBox(Dock = DockStyle.Bottom, Multiline = true) temp.Controls.Add(input) let tc = new TcpClient() tc.Connect("localhost", 4242) let load() = let run() = let sr = new StreamReader(tc.GetStream()) while(true) do let text = sr.ReadLine() if text null && text "" then temp.Invoke(new MethodInvoker(fun () -> output.AppendText(text + Environment.NewLine) output.SelectionStart ignore let t = new Thread(new ThreadStart(run)) t.Start() temp.Load.Add(fun _ -> load()) let sw = new StreamWriter(tc.GetStream()) let keyUp _ = if(input.Lines.Length > 1) then let text = input.Text if (text null && text "") then



begin try sw.WriteLine(text) sw.Flush() with err -> MessageBox.Show(sprintf "Server error\n\n%O" err) |> ignore end; input.Text keyUp e) temp [] do Application.Run(form) Figure 10-1 shows the resulting client-server application.

Figure 10-1. The chat client-server application Now you’ll look at how the client in Listing 10-2 works. The first portion of code in the client is taken up initializing various aspects of the form; this is not of interest to you at the moment, though you can find details of how WinForms applications work in Chapter 8. The first part of Listing 10-2 that is relevant to TCP/IP sockets programming is when you connect to the server. You do this by creating a new instance of the TcpClient class and calling its Connect method:



let tc = new TcpClient() tc.Connect("localhost", 4242) In this example, you specify localhost, which is the local computer, and port 4242, which is the same port on which the server is listening. In a more realistic example, you’d probably give the DNS name of the server or allow the user to give the DNS name, but localhost is good because it allows you to easily run the sample on one computer. The function that drives the reading of data from the server is the load function. You attach this to the form’s Load event; to ensure this executes after the form is loaded and initialized properly, you need to interact with the form’s controls: temp.Load.Add(fun _ -> load()) To ensure that you read all data coming from the server in a timely manner, you create a new thread to read all incoming requests. To do this, you define the function run, which is then used to start a new thread: let t = new Thread(new ThreadStart(run)) t.Start() Within the definition of run, you first create a StreamReader to read text from the connection, and then you loop infinitely, so the thread does not exit and reads from the connection. When you find data, you must use the form’s Invoke method to update the form; you need to do this because you cannot update the form from a thread other than the one on which it was created: temp.Invoke(new MethodInvoker(fun () -> output.AppendText(text + Environment.NewLine) output.SelectionStart keyUp e) The implementation of the keyUp function is fairly straightforward: if you find that there is more than one line—meaning the Enter key has been pressed—you send any available text across the wire and clear the text box. Now that you understand both the client and server, you’ll take a look at a few general points about the application. In both Listings 10-1 and 10-2, you called Flush() after each network operation. Otherwise, the information will not be sent across the network until the stream cache fills up, which leads to one user having to type many messages before they appear on the other user’s screen. This approach has several problems, particularly on the server side. Allocating a thread for each incoming client ensures a good response to each client, but as the number of client connections grows, so will the amount of context switching needed for the threads, and the overall performance of the server will be reduced. Also, since each client requires its own thread, the maximum number of clients is limited by the maximum number of threads a process can contain. Although these problems can be solved, it’s often easier to simply use one of the more abstract protocols discussed next.



Using HTTP
The Web uses Hypertext Transfer Protocol (HTTP) to communicate, typically with web browsers, but you might want to make web requests from a script or a program for several reasons, for example, to aggregate site content through RSS or Atom feeds. To make an HTTP request, you use the static method Create from the System.Net. WebRequest class. This creates a WebRequest object that represents a request to the uniform resource locator (URL, an address used to uniquely address a resource on a network) that was passed to the Create method. You then use the GetResponse method to get the server’s response to your request, represented by the System.Net.WebResponse class. The following example (Listing 10-3) illustrates calling an RSS on the BBC’s website. The core of the example is the function getUrlAsXml, which does the work of retrieving the data from the URL and loading the data into an XmlDocument. The rest of the example illustrates the kind of post-processing you might want to do on the data, in this case displaying the title of each item on the console and allowing users to choose which item to display. Listing 10-3. Using HTTP #light open System.Diagnostics open System.Net open System.Xml let getUrlAsXml (url : string) = let request = WebRequest.Create(url) let response = request.GetResponse() let stream = response.GetResponseStream() let xml = new XmlDocument() xml.Load(new XmlTextReader(stream)) xml let url = "" let xml = getUrlAsXml url let mutable i = 1 for node in xml.SelectNodes("/rss/channel/item/title") do printf "%i. %s\r\n" i node.InnerText i >) : seq< list obj; the function is executed only on types that match the type of the parameter of the function. This adds a printer, which is a function that will be called to get the output that should be printed for an object. It differs from a print transformer because the function is directly responsible for creating text that will be printed, whereas a printer transformer transforms the object to be printed into something more relevant to be printed. This function takes a function of type 'a -> string, and the function is executed only on types that match the type of the parameter of the function.

PrintLength PrintWidth ShowIEnumerable ShowProperties AddPrintTransformer


fsi.exe Command-Line Switches
Table 12-13 summarizes the command-line switches that you can use with fsi.exe. Table 12-13. The F# Interactive Command-Line Switches


This creates a GUI loop so that the fsi.exe user can open WinForms windows. There is a script, load-wpf.fsx, available as part of the samples in the F# distribution that shows how to replace the WinForms event loop with WPF so WPF applications will run correctly interactively. You can find more information about WPF in Chapter 8. This turns off the GUI loop required for a WinForms application.




--exec --no-logo --no-banner --no-readline

This causes fsi.exe to exit after running the scripts given on the command line, which is useful for using F# to execute finished scripts. This stops the splash text being shown on start-up. This is the same as --no-logo. This stops attempts to process individual keystrokes from the console.

Using the Source Directory Macro
The source directory macro is a #define macro with the name __SOURCE_DIRECTORY__ automatically set to the directory for each file being processed by fsi.exe and to the current directory for a script fragment being loaded into fsi.exe (including fragments loaded interactively using Visual Studio). You could use this to access image files that are required for the script and are stored in the same directory as the script. You can use the identifier __SOURCE_DIRECTORY__ as if it were a string inside any F# fsi.exe script. The following example shows it being used to create a DirectoryInfo object that could then be used to find out what files that directory contains: #light open System.IO let dir = new DirectoryInfo(__SOURCE_DIRECTORY__);;

Writing NUnit Tests
NUnit is an open-source framework for creating NUnit tests for .NET code. The idea is loosely based on JUnit, a Java open source framework. The idea has been popular amongst the .NET development community, and a similar framework is now also included in the Team Editions of Visual Studio 2005. The idea behind NUnit is simple; you create a .NET class that is a suite of unit tests for your code. Ideally each test will call the functions that you have created with a number of different parameters, asserting that each function returns the expected result. The class and class members are then marked with attributes that show they represent a test. NUnit then provides a framework for running your tests, either through a GUI so programs can easily see the results of their test and drill down on any that are failing or through a command-line tool so the test can be automated as part of a build process. The following example shows a small library and a unit test suite associated with it. Notice how the test suite, the class TestCases, is marked with the custom attribute TestFixture, and all its members are marked with the custom attribute Test. These custom attributes are both defined in the assembly NUnit.Framework.dll. This is so NUnit knows that this class is a test suite. The assembly can contain other types that are test suites, and equally the class



TestCases can contain other members that are not directly test cases but are, for example, helper functions. It would be more natural to separate the code for the test cases from the code being tested into separate files and even separate assembles, but for simplicity I’ll show them both together. Each test case typically calls the function it is testing and then uses the Assert class to check the result. This is not true for the TestDiv02 case; here you know that calling div with a second argument of 0 will cause the function to raise an exception, so you mark the method with the ExpectedException attribute instead of making an assertion. #light open System let add x y = x + y let div x y = x / y open NUnit.Framework [] type TestCases = class new() = {} [] member x.TestAdd01() = Assert.AreEqual(3, add 1 2) [] member x.TestAdd02() = Assert.AreEqual(4, add 2 2) [] member x.TestDiv01() = Assert.AreEqual(1, div 2 2) [] member x.TestDiv02() = div 1 0 |> ignore end You could load this test case into the NUnit GUI, allowing you to call each test individually or all the tests together. Figure 12-1 shows the NUnit GUI in action, with the TestDiv01 case being run.



Figure 12-1. The NUnit GUI

Using Assembly Browsers
Because of all the metadata built into .NET assemblies, it is a fairly easy task to reflect over an assembly to determine its contents. Several class browsers are available that take advantage of this to let developers see the contents of an assembly. The .NET Framework SDK includes a tool called ildasm.exe that lets you browse the contents of an assembly and even look at the IL bytecodes that make up the method bodies. Visual Studio also ships with a .NET class browser that allows you to browse classes and view the signatures of their methods. However, the best class browser in my opinion is Reflector, which is shown in Figure 12-2 and available for download from Reflector lets you browse a number of different assembles at once and provides an easy way to navigate between related types. It also allows you to view the method signatures, and even the code itself, in a variety of different languages. At the time of this writing, IL, C#, VB .NET, and Delphi were supported by default with the option to add others through a plug-in system; currently, a plug-in to view code in F# is in the early stages of development.



Although looking at the code that makes up an assembly is fun, there are some serious uses for the F# user. If you intend to produce a library that is suitable for use from other languages, it is likely that your target audience will consist of a lot of C# and VB .NET developers. If you want them to be able to use the library easily, it is important to know what the method signatures will look like in C# or VB .NET. Although after a while you’ll have a good idea of what will play nicely in other languages and what won’t, Reflector can help shortcut this by allowing you to view the method signature and check that it looks OK. You can find more about how to create a .NET library that will work well when used from other languages in Chapter 13.

Figure 12-2. Reflector, a class browser



Using Debugging Tools
Visual Studio provides a graphical debugger that is easy and intuitive to use. If you have F# integration installed, then debugging is simply a matter of setting a breakpoint and pressing F5. However, not everybody uses Visual Studio; if you don’t, several other debugging options are available. The .NET Framework SDK comes with two command-line debuggers, mdbg.exe and cordbg.exe, but personally I find command-line debuggers too difficult to use. Fortunately, it also comes with a graphical debugger. The debugger is located by default in SDK\v2.0\ GuiDebug, under the install root of the SDK. This debugger, shown in Figure 12-3, is also simple to use. You generally open a source file, set breakpoints within it, and then use the Tools ® Attach to Process menu option to choose the program you want to debug. If the program has debugging symbols (generated by the -g option) and the debugger can find them, then your breakpoints will be hit, and you can step through the code. A good way to check whether symbols are loaded is through the Modules windows (Debug ® Windows ® Modules). This shows all the DLLs that are currently loaded into the process and whether they have debugging symbols associated with them. If no symbols are associated with a particular DLL, then you can try to load some by right-clicking and searching for the correct symbols on the disk.

Figure 12-3. Debugging using the GUI debugger available with the .NET Framework SDK



Some sections of code can be difficult to debug because it is impossible to attach the debugger before they’ve executed. To allow these sections to be debugged more easily, .NET provides the System.Diagnostics.Debugger class. This has a useful method called Launch(). When this method is hit, it will generate a special type of exception that will cause Windows to show a dialog box offering the user the opportunity to attach a debugger. Once attached, the debugger will function normally, and you’ll be able to step through the code as you’d expect.

I Note Another option for debugging on the Windows platform is WinDbg. This is a tool originally targeted at unmanaged code, but it has been extended to managed code, such as F# programs, via SOS.dll. WinDbg is quite a bit harder to use than your typical graphical debugger, but it has the advantage that it can be used to monitor software in production and thus investigate any production problems you have. You can find more information about how to set up WinDbg at default.aspx/FSharpFoundations.WinDbg. Also, if you release your software and an exception is generated while a user is using it, the user will get the option to send an error report to Microsoft. You can register to receive these reports of your crashes at

Using Profiling Tools
Debugging performance problems is one of the most difficult challenges for programmers. Fortunately, several tools exist to help you profile applications so you can see where problems lie. Although performance profiling and optimizing a program is a huge subject, it is generally based on a simple set of steps. I find that most performance optimizations follow these steps: 1. Time the execution of your application to create a baseline. This is an important step because it will allow you to judge whether your changes really have enhanced performance. This means running your applications and generating some load on them, either by directly interacting with the program or preferably by using a script to automatically perform tasks that would commonly be performed by users. The advantage of using a script is that you can more easily run your test multiple times. The tool ntimer.exe is good for this. 2. Use a profiler to create a profile of your application. This will allow you to look at how your application could be enhanced. It is important to perform this as a separate step from your baseline because profilers can seriously slow the execution of your application.



3. Form a hypothesis about what is causing your code to run slowly. This is the most difficult part of any performance investigation and generally involves a detailed analysis of the profile you generated. 4. Make changes to your code base, based on the conclusions you came to in the previous steps. 5. Rerun the baseline you took of your application. This will allow you to see whether your hypothesis is correct and whether you have enhanced the performance of your application. 6. If you have enhanced the performance of your code base, then you should commit the changes you made; otherwise, you should throw them away. Typically, you’ll repeat these steps until you are happy with the performance of your application. You’ll now look at some tools that can help you profile your applications.

Although not actually a profiler, ntimer.exe is a nifty little tool that allows you to get the overall execution time for a program, which is useful for establishing a baseline for application performance. It’s part of Windows 2003 Resource Kit Tools. Using ntimer.exe couldn’t be simpler; just run ntimer followed by the name of the program you want to time and any command-line arguments you want to pass to it.

Perfmon and Performance Counters
Perfmon is a monitoring tool built into Windows, so it’s readily available on every Windows machine. It allows you to examine performance counters that reveal information about almost every aspect of a machine. Select Control Panel ® Administrative Tools to open it (see Figure 12-4). The three counters that are loaded by default, Pages/sec (the number of pages swapped from disk each second), Avg. Disk Queue (the amount of information in the queue to be read or written to the disk), and % Processor Time (the amount of time the processor is actually in use), give you a good idea of the overall health of the machine. If any of these values are high, then the machine will probably seem slow and unresponsive.



Figure 12-4. Perfmon, a tool for monitoring performance If you want to examine other aspects of the machine’s performance, you can add more counters by right-clicking the graph pane and choosing Add Counters. Since each piece of software installed on a machine can install its own counters, the number of counters varies from machine to machine, but a typical machine has at least 50 categories of counters (performance objects) and more than 100 counters. To help you navigate this maze of counters, Table 12-14 summarizes some of the most useful ones to the .NET programmer. It’s important to remember when adding counters that most counters either can be the total for the machine or can be the total for a specific process; often it best to choose the one that is specific to the process you are trying to profile. Table 12-14. Useful Performance Counters and Their Meanings

Performance Object
Process Process

% Processor Time Page Faults/sec

This is the amount of processor time consumed by the process. This is the number of page faults per second. If this number increases dramatically, this means the process does not have enough memory to operate effectively; you need to reduce your memory consumption.



Performance Object

Handle Count

This represents the number of files the process has open. If this number increases throughout the lifetime of an application, you are probably leaking file handles. In other words, you forgot to close a file stream by calling its Dispose() method. This is the number of bytes used by the process that are not shared with other processes. If this figure continues to rise throughout the lifetime of an application, this typically means you have a memory leak. This measures the amount of .NET exceptions being thrown. If this number is high, then your application will perform poorly since exceptions are relatively expensive in .NET. This tells how much of the CLR’s time is spent just-in-time compiling the application. If this figure is too high, then you might consider using ngen.exe when you deploy your application. This will precompile the application, removing the need for the JIT compiler. This is the amount of memory consumed by managed objects in your program. If this figure grows continually, then you might have a memory leak. This is the amount of time your application spends in garbage collection (GC). If this number is too high, then you might need to consider changing the way you use memory; typically you will be looking to reduce the number of objects you create. However, do not panic if the application spends a seemingly large amount of time in GC; typically, most applications, managed or unmanaged, spend a lot of time managing memory. If this figure is greater than 20 percent, then there might be cause for concern. However, only if the figure is consistently higher than 50 percent should you put some effort into trying to bring this number down. This is the number of objects that were not garbage collected because they required finalization. If this counter is high, it means that you are forgetting to call the Dispose() method on objects that implement the IDisposable interface, which will add unnecessary overhead to your application.


Private Bytes

.NET CLR Exceptions

# of Exceptions Thrown/sec


% Time in Jit

.NET CLR Memory

# Bytes in all Heaps

.NET CLR Memory

% Time in GC

.NET CLR Memory

Finalization Survivors

Although the counters in Table 12-2 will serve as a useful starting point when investigating any .NET performance problem, it’s probably best not to limit yourself to these counters. It is usually best to try to find the counter that most directly relates to your problem.



I Caution Memory leaks can still occur in managed applications, typically when you still have references to objects that you are no longer using. For example, if your program places an object in a collection at the top level of a module and doesn’t remove it when it has finished with it, then the memory associated with that object has effectively been leaked, since it’s no longer in use and won’t be reclaimed.

You can also use Perfmon to log performance counter values to a file. This can be useful when monitoring applications in production. Typically, you set up Perfmon to log counters you think will help you diagnose performance problems. Then if users complain about a sudden drop in application performance, you retrieve the logs to evaluate what caused the problem. Logging performance counters to a file is quite easy and intuitive; you just need to open the Performance Logs and Alerts node on the left side of Perfmon, then right-click the main pane, and finally choose New Log Settings, which allows you to choose the counters you want to log and when you want to log them. Again, for this logging to work correctly, you must start the Performance Logs and Alerts service, which is not started by default.

I Note You can read performance counter values within your code and create your own performance counters using the class System.Diagnostics.PerformanceCounter. You can find more information about how to do this at FSharpFoundations.PerfCounters.

NProf is a timing profiler. It measures the amount of time it takes to execute a method and displays this to the user as a percentage of the overall execution time. As a timing profiler, it is suitable for investigating problems where you believe a section of code is running too slowly. It is an open source utility available from NProf, shown in Figure 12-5, is quite straightforward to use; it is the interpretation of the results that can be the tricky part. To start a profile, just select the executable you want to profile, and give its command-line arguments; alternatively, you can connect to an ASP .NET application. When you’ve chosen the application you want to profile, you can start profiling by pressing F5, and when the application finishes, NProf will list all the methods called during the application and statistics about them such as the number of times a method was called and the overall percentage of time spent in this method. There is also a window that allows you to see the callees of the method. Once you’ve collected this information, you usually look at which methods take the highest overall percentage of execution time and consider how this can be reduced. Typically, you look at the callees to try to figure out whether any of them can be removed or replaced with calls to other methods that execute faster.



Figure 12-5. The NProf profiler GUI It’s also worth looking at the methods that have the highest number of calls. In this case, you typically look at the callers to try to figure out whether a method is being called when it’s not necessary to call it.

I Note At the time of this writing, two releases of NProf, 0.10 and 0.9.1, are available. Both are available from Release 0.10 runs considerably faster than 0.9.1, but the UI has been cut down to the bare minimum. I actually prefer the 0.9.1 version because I find it easier to use. I hope future releases will revert to the old UI while retaining the speed of the latest version.

CLR Profiler
Despite its name, the CLR Profiler is not a general-purpose profiler for the CLR. It is, in fact, a managed-memory profiler. If you see that your application has memory-related performance problems but have no idea what is causing them, then the CLR Profiler can help you get a better idea of what types of objects are taking up memory and when they get allocated.



The CLR Profiler can generate several different types of graph to help you visualize how memory is being used. It can generate an allocation graph that shows which methods created which object types, a histogram of all the allocated types, histograms of objects by ages and address, and timelines of object allocation. Perhaps the most useful feature is the ability to generate a histogram of the types in use on the managed heap, as shown in Figure 12-6. This allows you to get a better idea of which types are consuming memory. With this knowledge, you can review the code and look for places where you can remove instances of types.

Figure 12-6. A histogram generated by the CLR Profiler CLR Profiler also has a command-line mode where it logs its results to a file. This is useful because you can use it as part of an automated testing process to check that each build doesn’t have any regression errors.

I Note This tool is freely available for download from details.aspx?familyid=a362781c-3870-43be-8926-862b40aa0cd0&displaylang=en. Summary
In this chapter, you surveyed a number of development tools that help make the lives of the F# users easier. Some tools, such as fsi.exe (F# interactive), are very flexible, and you’ll probably use them every time you code in F#; others you’ll use less frequently to track down tricky bugs. In the next chapter, you’ll look at compatibility and advanced interoperation.



Compatibility and Advanced Interoperation

n this chapter, you will look at everything you need to make F# interoperate well with other languages, not just within the .NET Framework but also using unmanaged code from F# and using F# from unmanaged code.

I Caution Throughout this book, I have made every effort to make sure the only language you need to understand is F#. However, in this chapter, it will help if you know a little C#, C++, or .NET Common IL, although I’ve kept the code in these languages to the minimum necessary.

Calling F# Libraries from C#
You can create two kinds of libraries in F#: libraries that are designed to be used from F# only and libraries that are designed to be used from any .NET language. This is because F# utilizes the .NET type system in a rich and powerful way, so some types can look a little unusual to other .NET languages; however, these types will always look like they should when viewed from F#. So, although you could use any library written in F# from any .NET language, you need to follow a few rules if you want to make the library as friendly as possible. Here is how I summarize these rules: • Always use a signature .fsi file to hide implementation details and document the API expected by clients. • Avoid public functions that return tuples. • If you want to expose a function that takes another function as a value, expose the value as a delegate. • Do not use union types in the API, but if you absolutely must use these types, add members to make them easier to use.



• Avoid returning F# lists, and use the array System.Collections.Generic.IEnumerable or System.Collections.Generic.List instead. • When possible, place type definitions in a namespace, and place only value definitions within a module. • Be careful with the signatures you define on classes and interfaces; a small change in the syntax can make a big difference. I will illustrate these points with examples in the following sections.

Returning Tuples
First I’ll talk about why you should avoid tuples; if you return a tuple from your function, you will force the user to reference fslib.dll. Also, the code needed to use the tuple just doesn’t look that great from C#. Consider the following example where you define the function hourAndMinute that returns the hour and minute from a DateTime structure: #light module Strangelights.DemoModule open System let hourAndMinute (time : DateTime) = time.Hour, time.Minute To call this from C#, you will need to follow the next example. Although this isn’t too ugly, it would be better if the function had been split in two, one to return the hour and one to return the minute. static void HourMinute() { Tuple t = DemoModule.hourAndMinute(DateTime.Now); Console.WriteLine("Hour {0} Minute {1}", t.Item1, t.Item2); } The results of this example, when compiled and executed, are as follows: Hour 16 Minute 1

Exposing Functions That Take Functions As Parameters
If you want to expose functions that take other functions as parameters, the best way to do this is using delegates. Consider the following example that defines one function that exposes a function and one that exposes this as a delegate: #light open System open System.Collections.Generic let filterStringList f (l : List) = l |> Seq.filter f



let filterStringListDelegate (del : Predicate) (l : List) = let f x = del.Invoke(x) new List(l |> Seq.filter f) Although the filterStringList is considerably shorter than filterStringListDelegate, the users of your library will appreciate the extra effort you’ve put in to expose the function as a delegate. When you look at using the functions from C#, it’s pretty clear why. The following example demonstrates calling filterStringList; to call your function, you need to create a delegate and then use the FuncConvert class to convert it into a FastFunc, which is the type F# uses to represent function values. As well as being pretty annoying for the user of your library, this also requires a dependency on fslib.dll that the user probably didn’t want. static void MapOne() { List l = new List( new string[] { "Stefany", "Oussama", "Sebastien", "Frederik" }); Converter pred = delegate (string s) { return s.StartsWith("S");}; FastFunc ff = FuncConvert.ToFastFunc(pred); IEnumerable ie = DemoModule.filterStringList(ff, l); foreach (string s in ie) { Console.WriteLine(s); } } The results of this example, when compiled and executed, are as follows: Stefany Sebastien Now, compare and contrast this to calling the filterStringListDelegate function, shown in the following example. Because you used a delegate, you can use the C# anonymous delegate feature and embed the delegate directly into the function call, reducing the amount of work the library user has to do and removing the compile-time dependency on fslib.dll. static void MapTwo( { List l = new List( new string[] { "Aurelie", "Fabrice", "Ibrahima", "Lionel" }); List l2 = DemoModule.filterStringListDelegate( delegate(string s) { return s.StartsWith("A"); }, l);



foreach (string s in l2) { Console.WriteLine(s); } } The results of this example, when compiled and executed, are as follows: Aurelie

Using Union Types
You can use union types from C#, but because C# has no real concept of a union type, they do not look very pretty when used in C# code. In this section, you will examine how you can use them in C# and how you as a library designer can decide whether your library will expose them (though personally I recommend avoiding exposing them in cross-language scenarios). For the first example, you will define the simple union type Quantity, which consists of two constructors, one containing an integer and the other a floating-point number. You also provide the function getRandomQuantity() to initialize a new instance of Quantity. #light open System type Quantity = | Discrete of int | Continuous of float let rand = new Random() let getRandomQuantity() = match rand.Next(1) with | 0 -> Quantity.Discrete (rand.Next()) | _ -> Quantity.Continuous (rand.NextDouble() * float_of_int (rand.Next())) Although you provide getRandomQuantity() to create a new version of the Quantity type, the type itself provides static methods for creating new instances of the different constructors that make up the type. These static methods are available on all union types that are exposed by the assembly by default; you do not have to do anything special to get the compiler to create them. The following example shows how to use these methods from C#: static void GetQuantityZero() { DemoModule.Quantity d = DemoModule.Quantity.Discrete(12); DemoModule.Quantity c = DemoModule.Quantity.Continuous(12.0); }



Now you know how to create union types from C#, so the next most important task is being able to determine the constructor to which a particular Quantity value belongs. You can do this in three ways; I cover the first two in the next two code examples, and I cover the third at the end of this section. The first option is that you can switch on the value’s Tag property. This property is just an integer, but the compiled version of the union type provides constants, always prefixed with tag_, to help you decode the meaning of the integer. So if you want to use the Tag property to find out what kind of Quantity you have, you would usually write a switch statement, as shown in the following example: static void GetQuantityOne() { DemoModule.Quantity q = DemoModule.getRandomQuantity(); switch (q.Tag) { case DemoModule.Quantity.tag_Discrete: Console.WriteLine("Discrete value: {0}", q.Discrete1); break; case DemoModule.Quantity.tag_Continuous: Console.WriteLine("Continuous value: {0}", q.Continuous1); break; } } The results of this example, when compiled and executed, are as follows: Discrete value: 65676 If you prefer, the compiled form of the union type also offers a series of methods, all prefixed with Is; this allows you to check whether a value belongs to a particular constructor within the union type. For example, on the Quantity union type, two methods, IsDiscrete() and IsContinuous(), allow you to check whether the Quantity is Discrete or Continuous. The following example demonstrates how to use them: static void GetQuantityTwo() { DemoModule.Quantity q = DemoModule.getRandomQuantity(); if (q.IsDiscrete()) { Console.WriteLine("Discrete value: {0}", q.Discrete1); } else if (q.IsContinuous()) { Console.WriteLine("Continuous value: {0}", q.Continuous1); } } The results of this example, when compiled and executed, are as follows:



Discrete value: 2058 Neither option is particularly pleasing because the code required to perform the pattern matching is quite bulky. There is also a risk that the user could get it wrong and write something like the following example where they check whether a value is Discrete and then mistakenly use the Continuous1 property. This would lead to a NullReferenceException being thrown. DemoModule.EasyQuantity q = DemoModule.getRandomEasyQuantity(); if (q.IsDiscrete()) { Console.WriteLine("Discrete value: {0}", q.Continuous1); } To give your libraries’ users some protection against this, it is a good idea to add members to union types that perform the pattern matching for them. The following example revises the Quantity type to produce EasyQuantity, adding two members to transform the type into an integer or a floating-point number: #light open System let rand = new Random() type EasyQuantity = | Discrete of int | Continuous of float with member x.ToFloat() = match x with | Discrete x -> float_of_int x | Continuous x -> x member x.ToInt() = match x with | Discrete x -> x | Continuous x -> int_of_float x end let getRandomEasyQuantity() = match rand.Next(1) with | 0 -> EasyQuantity.Discrete (rand.Next()) | _ -> EasyQuantity.Continuous (rand.NextDouble() * float_of_int (rand.Next())) This will allow the user of the library to transform the value into either an integer or a floating-point without having to worry about pattern matching, as shown in the following example:



static void GetQuantityThree() { DemoModule.EasyQuantity q = DemoModule.getRandomEasyQuantity(); Console.WriteLine("Value as a float: {0}", q.ToFloat()); }

Using F# Lists
It is entirely possible to use F# lists from C#, but I recommend avoiding this since a little work on your part will make things seem more natural for C# programmers. For example, it is simple to convert a list to an array using the List.to_array function, to a System.Collections.Generic.List using the List.to_ResizeArray function, or to a System.Collections.Generic.IEnumerable using the List.to_seq function. These types are generally a bit easier for C# programmers to work with, especially System.Array and System.Collections.Generic.List, because these provide a lot more member methods. You can do the conversion directly before the list is returned to the calling client, making it entirely feasible to use the F# list type inside your F# code. If you need to return an F# list directly, you can do so, as shown in the following example: let getList() = [1; 2; 3] To use this list in C#, you typically use a foreach loop: static void GetList() { Microsoft.FSharp.Collections.List l = DemoModule.getList(); foreach (int i in l) { Console.WriteLine(i); } } The results of this example, when compiled and executed, are as follows: 1 2 3

Defining Types in a Namespace
If you are defining types that will be used from other .NET languages, then you should place them inside a namespace rather than inside a module. This is because modules are compiled into what C# and other .NET languages consider to be a class, and any types defined within the module become inner classes of that type. Although this does not present a huge problem to C# users, the C# client code does look cleaner if a namespace is used rather than a module. This is because in C# you can open namespaces using only the using statement, so if a type is inside a module, it must always be prefixed with the module name when used from C#.



I’ll now show you an example of doing this. The following example defines the class TheClass, which is defined inside a namespace. You also want to provide some functions that go with this class; these can’t be placed directly inside a namespace because values cannot be defined inside a namespace. In this case, you define a module with a related name TheModule to hold the function values. #light namespace Strangelights open System.Collections.Generic type TheClass = class val mutable TheField : int new(i) = { TheField = i } member x.Increment() = x.TheField c.Increment()) let decList (l : List) = l |> Seq.iter (fun c -> c.Decrement()) end Using the TheClass class in C# is now straightforward because you do not have to provide a prefix, and you can also get access to the related functions in TheModule easily: static void UseTheClass() { List l = new List(); l.Add(new TheClass(5)); l.Add(new TheClass(6)); l.Add(new TheClass(7)); TheModule.incList(l); foreach (TheClass c in l) { Console.WriteLine(c.TheField); } }

Defining Classes and Interfaces
In F# there are two ways you can define parameters for functions and members of classes: the “curried” style where members can be partially applied and the “tuple” style where all members must be given at once. When defining classes, your C# clients will find it easier to use your classes if you use the tuple style.



Consider the following example in which you define a class in F#. Here one member has been defined in the curried style, called CurriedStyle, and the other has been defined in the tuple style, called TupleStyle. type DemoClass = class val Z : int new(z) = { Z = z} member this.CurriedStyle x y = x + y + this.Z member this.TupleStyle (x, y) = x + y + this.Z end When viewed from C#, the member CurriedStyle has the following signature: public FastFunc CurriedStyle(int x) whereas the TupleStyle will have the following signature: public int TupleStyle(int x, int y); So if you wanted to use both methods from C#, you would end up with code that looked as follows: static void UseDemoClass() { DemoClass c = new DemoClass(3); FastFunc ff = c.CurriedStyle(4); int result = ff.Invoke(5); Console.WriteLine("Curried Style Result {0}", result); result = c.TupleStyle(4, 5); Console.WriteLine("Tuple Style Result {0}", result); } It is clear from this sample that users of your library will be much happier if you use the tuple style for the public members of your classes. Specifying abstract members in interfaces and classes is slightly more complicated because you have a few more options. The following example demonstrates this: type IDemoInterface = interface abstract CurriedStyle : int -> int abstract OneArgStyle : (int * int) abstract MultiArgStyle : int * int abstract NamedArgStyle : x : int * end

-> int -> int -> int y : int -> int

Note that the only difference between OneArgStyle and MultiArgStyle is that the latter is not surrounded by parentheses. This small difference in the F# definition has a big effect on the signature as seen from C#. With the former, you see the signature as this: int OneArgStyle(Tuple); With the latter, you see the following signature: int MultiArgStyle(int, int);



The latter is a good bit friendlier for the C# user. However, you can take it bit further and add names to each of your parameters. This won’t change the signature the C# user will use when implementing the method, but it will change the names they see when using Visual Studio tools to implement the interface; furthermore, some other .NET languages treat argument names as significant. This may sound like a small difference, but it will make implementing your interface a lot easier, because the implementer will have a much better idea of what the parameters of the method actually mean. The following example shows the C# code for implementing the interface IDemoInterface defined in the previous example. It makes it clear that C# users will be happier with interfaces containing methods specified using either MultiArgStyle or NamedArgStyle. class DemoImplementation : IDemoInterface { public FastFunc CurriedStyle(int x) { Converter d = delegate (int y) {return x + y;}; return FuncConvert.ToFastFunc(d); } public int OneArgStyle(Tuple t) { return t.Item1 + t.Item2; } public int MultiArgStyle(int x, int y) { return x + y; } public int NamedArgStyle(int x, int y) { return x + y; } }

Using F# with the .NET Framework Versions 1 and 1.1
Using F# with the .NET Framework versions 1 and 1.1 is surprisingly straightforward, because all you need to do is use the compiler switch --cli-version, discussed in more detail in Chapter 12. However, there are some small differences in both the F# code that you can write and the resulting assembly that you need to be aware of, so if at all possible, I recommend using the .NET Framework 2. Readers who are familiar with the differences between the .NET Framework versions 1, 1.1, and 2 may have expected that any code that uses type parameterization, or generics as it



more commonly known, would not compile using the .NET Framework versions 1 and 1.1. However, this is not the case, because these differences can be compiled away by the F# compiler. Consider the following simple example: let doNothing x = x The function doNothing is generic because the parameters are of any type, and you can guarantee that the returned value will be the same as the input parameter. If you check the function’s signature, using the Visual Studio tooltips or the compiler’s -i switch, you see the following: val doNothing : 'a -> 'a meaning that doNothing takes a parameter of type 'a and returns a value of type 'a where 'a is a type parameter. Unsurprisingly, in the .NET Framework 2, this compiles down to have the following signature in C#: public static T doNothing(T x) However, when compiled under the .NET Framework version 1 or 1.1, the function will have the following signature: public static object doNothing(object x) This means if you are creating a library for use with the .NET Framework version 1 or 1.1, the users of your functions from other .NET languages will have to cast the object returned to its original type. They would not have to do this if using a version of the library compiled for the .NET Framework 2. The other problem area is arrays, because these were pseudogeneric in the .NET Framework versions 1 and 1.1 and fully generic in the .NET Framework 2. For those of you not familiar with the .NET Framework version 1 or 1.1, pseudogeneric means that arrays in the .NET Framework version 1 or 1.1 could have a type parameter, but nothing else could. For example, the method GetFiles from the System.IO.Directory class has the following signature, meaning that it returns an array of type string: public static string[] GetFiles(string path); These pseudogeneric arrays are trouble for F# because its array type is fully generic. Effectively this means that if you are using “pure F#” (that is, not calling methods from libraries written in C#), then it is OK to use the F# Array module when using the .NET Framework version 1 or 1.1. You will notice that arrays will always appear as object arrays (Object[]) when viewed from other .NET languages, but they seamlessly keep their types when used from F# code. When calling methods that accept arrays, or return arrays, like the aforementioned GetFiles method, then you will need to use the CompatArray module located in the Microsoft.FSharp.Compatibility namespace. This will all be clearer when you see an example. Consider the following F# code that creates an array and then maps it to create a new array: #light let ones = Array.create 1 3 let twos = ones |> (fun x -> x + 1)



This code will compile under the .NET Framework versions 1, 1.1, and 2; however, the signatures of these values when viewed from other .NET languages would be as follows: public static object[] ones { get; } public static object[] twos { get; } If you are designing a library and interoperation is important to you, you could replace the calls to the array module with calls to the CompatArray module, and you get the signatures typed using pseudogeneric arrays, just as your clients from other .NET code would probably want and expect. This means under the .NET Framework versions 1 and 1.1, you should use the following code: #light open Microsoft.FSharp.Compatibility let ones = CompatArray.create 1 3 let twos = ones |> (fun x -> x + 1) This would mean that your module would have the signatures as shown here when viewed from other .NET languages: public static int[] ones { get; } public static int[] twos { get; } Similarly, when using the .NET Framework versions 1 and 1.1, calls to methods from assemblies not written in F#, including all assemblies in the BCL, will generally use pseudogeneric arrays. This means when using the .NET Framework versions 1 and 1.1, it’s important to use the CompatArray module and not the Array module. For example, the following will compile without a problem in the .NET Framework 2, but in both 1 and 1.1, it will not compile. #light open System.IO open Microsoft.FSharp.Compatibility let paths = Directory.GetFiles(@"c:\") let files = paths |> (fun path -> new FileInfo(path)) When compiled using the --cli-version 1.1 switch, it will give the following error: prog.fs(5,13): error: FS0001: Type mismatch. Expecting a string [] -> 'c but given a 'a array -> 'b array. The type string [] does not match the type 'a array This is easily corrected by replacing functions from the Array module with their equivalents in ComptArray, as shown in the following example: #light open System.IO open Microsoft.FSharp.Compatibility let paths = Directory.GetFiles(@"c:\") let files = paths |> (fun path -> new FileInfo(path))



Calling Using COM Objects
Most programmers who work with the Windows platform will be familiar with the Component Object Model (COM). To a certain extent the .NET Framework was meant to replace COM, but the system remains popular and is likely to be with us for some time. Many of the APIs in Windows are exposed as COM objects, and although more and more now have managed equivalents within the .NET Framework, there are still some without managed equivalents. Also, there are still some vendors that sell software that exposes its APIs via COM. The .NET Framework was designed to interoperate well with COM, and calling COM components is generally quite straightforward. Calling COM components is always done through a managed wrapper that takes care of calling the unmanaged code for you. You can produce these wrappers using a tool called TlbImp.exe, the Type Library Importer, that ships with the .NET SDK.

I Note You can find more information about the TlbImp.exe tool at the following site: However, despite the existence of TlbImp.exe, if you find yourself in a situation where you need to use a COM component, first check whether the vendor provides a managed wrapper for it. This is quite common; for example, if you want to automatically manipulate programs from Microsoft Office 2003, then you need to use the COM APIs they provide, but there is no need to use TlbImp.exe to create a new wrapper, because Office already ships a series of managed wrappers contained in assemblies prefixed with Microsoft.Office.Interop. However, sometimes it is necessary to use TlbImp.exe directly. Fortunately, this is very straightforward; normally all that is necessary is to pass TlbImp.exe the location of the .dll that contains the COM component, and the managed wrapper will be placed in the current directory. So if you wanted to create a managed wrapper for the Microsoft Speech API, you would use the following command line: tlbimp "C:\Program Files\Common Files\Microsoft Shared\Speech\sapi.dll"

I Note I find two command-line switches to be useful with TlbImp.exe. These are /out:, which controls the name and location of the resulting manage wrapper, and /keyfile:, which can provide a key to sign the output assembly.

The resulting .dll is a .NET assembly and can be used just like any .NET assembly—by referencing it via the fsc.exe command-line switch -r. A useful side effect of this is if the API is not well documented, you can use an assembly browser, such as Reflector discussed in Chapter 12, to find out more about the structure of the API. After that, the worst thing I can say about using managed wrappers is you might find the structure of these assemblies a little unusual since the COM model dictates structure, and



therefore they do not share the same naming conversions as most .NET assemblies. You will notice that all classes in the assembly are post-fixed with the word Class, and each one is provided with a separate interface; this is just a requirement of COM objects. The following example shows the wrapper for the Microsoft Speech API that you created in the previous example being used: #light open SpeechLib let voice = new SpVoiceClass() voice.Speak("Hello world", SpeechVoiceSpeakFlags.SVSFDefault)

I Note More managed .NET APIs are becoming available all the time; the latest version of Office, Office
2007, ships with a fully managed .NET API, and Windows Vista includes a managed version of the Speech API. Although the basic calling of COM components is straightforward if you do a lot of COM-based programming in F#, you will soon find there are subtleties. You can find more information about COM programming at

Using P/Invoke
P/Invoke, or platform invoke to give its full name, is used to call unmanaged flat APIs implemented in DLLs and is called using the C or C++ calling convention. The most famous example of this is the Win32 API, a vast library that exposes all the functionality built into Windows. To call a flat unmanaged API, you must first define the function you want to call; you can do this in two parts. First you use the DllImport attribute from the System.Runtime.InteropServices namespace, which allows you to define which .dll contains the function you want to import, along with some other optional attributes. Then, you use the keyword extern, followed by the signature of the function to be called in the C style, meaning you give the return type, the F# type, the name of the function, and finally the types and names of the parameters surrounded by parentheses. The resulting function can then be called as if it were an external .NET method. The following example shows how to import the Windows function MessageBeep and then call it: #light open System.Runtime.InteropServices [] extern bool MessageBeep(uint32 beepType) MessageBeep(0ul) |> ignore



I Note The trickiest part of using P/Invoke can often be working out what signature to use to call the function; the website contains a list of signatures for common APIs in C# and VB .NET, which are similar to the required signature in F#. The site is a wiki, so feel free to add the F# signatures as you find them.

The following code shows how to use P/Invoke when the target function expects a pointer. You need to note several points about setting up the pointer. When defining the function, you need to put an asterisk (*) after the type name to show that you are passing a pointer. You need to define a mutable identifier before the function call to represent the area of memory that is pointed to; this may not be global, in the top level, but it must be part of a function definition. This is why you define the function main, so the identifier status can be part of the definition of this. Finally, you must use the address of operator (&&) to ensure the pointer is passed to the function rather than the value itself.

I This compiled code will always result in a warning because of the use of the address of operator (&&). Tip
This can be suppressed by using the compiler flag --nowarn 51 or the command #nowarn 51.

#light open System.Runtime.InteropServices [] extern bool FileEncryptionStatus(string filename, uint32* status) let main() = let mutable status = 0ul FileEncryptionStatus(@"C:\test.txt", && status) |> ignore print_any status main() The results of this example, when compiled and executed (assuming you have a file at the root of your C: drive called test.txt that is encrypted), are as follows: 1ul



I Note P/Invoke can be one of the trickiest things you can do in .NET because of the need to marshal data between the managed and unmanaged worlds, often requiring you to define structures that represent the data to be marshaled. You can find more information about marshaling and other aspects of P/Invoke at

The DllImport attribute has some useful functions that you can set to control how the unmanaged function is called; I summarize them in Table 13-1. Table 13-1. Useful Attributes on the DllImport Attribute

Attribute Name
CharSet EntryPoint

This defines the character set to be used when marshaling string data; it can be CharSet.Auto, CharSet.Ansi, or CharSet.Unicode. This allows you to set the name of the function to be called. If no name is given, then it defaults to the name of the function as defined after the extern keyword. This is a Boolean value that allows you to specify whether any error that occurs should be marshaled and therefore available by calling the Marshell.GetLastWin32Error() method.


I Note As with COM components, the number of flat unmanaged APIs that have no .NET equivalent is decreasing all the time; always check whether a managed equivalent of the function you are calling is available, which will generally save you lots of time.

Using Inline IL
Inline IL allows you to define your function’s body directly in intermediate language (IL), the language into which F# is compiled. This was mainly added to the language to implement certain low operators and functions such as addition and box and not. It is rare that you will need to use this feature because the F# libraries fslib.dll and mllib.dll already expose all of the functionality built into IL that you are likely to need. However, for those rare occasions where you need to do something that you can’t do in F# but you can in IL, it’s nice to know you have the option of inline IL.



I Caution To use inline IL effectively, you really need to have a good understanding of IL. Some of the passages in this section will not make sense if you do not have at least a basic knowledge of IL. You can find resources to help you learn IL at FSharpFoundations.IL.

Using inline IL is simple; you just place the IL instructions you would like between parentheses with pound signs, as in (# #). The IL instructions are placed inside a string and use the standard notation that can be compiled with ilasm.exe. This must be correctly formed IL, or you will get a compiler error. You can then pass parameters to your IL instruction; they are pushed onto the IL evaluation stack. You must also use the standard colon notation to tell the compiler what the return type will be; this is placed inside the parentheses. You will also need to be explicit about the types of the parameters since the compiler has no way of inferring their types. You’ll now look at an example of using inline IL. Imagine for whatever reason that you do not want to use the add and subtract operators defined in the F# base library fslib.dll; say you want to replace them with your own functions. So, you define two functions, add and sub, whose bodies are defined using IL: #light let add (x:int) (y:int) = (# "add" x y : int #) let sub (x:int) (y:int) = (# "sub" x y : int #) let x = add 1 1 let y = sub 4 2 printf "x: %i y: %i" x y The results of this example, when compiled and executed, are as follows: x: 2 y: 2 The programmer should be careful when using this technique because it is trivial to write a program that does not make any sense, and the compiler is unable to warn you about this. Consider the following program where you revise your previous example to replace the "add" instruction with a "ret" instruction, which means “return a value” and makes no sense in this context. This example will compile without error or warning; on execution, you will get an error. #light let add (x:int) (y:int) = (# "ret" x y : int #) let x = add 1 1



The results of this example, when compiled and executed, are as follows: Unhandled Exception: System.InvalidProgramException: Common Language Runtime detected an invalid program. at Error.add(Int32 x, Int32 y)

I Note One tool distributed with .NET SDK can help you detect these kinds of errors. The tool is called peverify.exe, and you can find more information about peverify.exe at com/en-us/library/62bwd2yd(vs.80).aspx.

Using F# from Native Code via COM
Although it is more likely that you will want to call native code from F# code, sometimes you might want to call F# library functions from native code. For example, suppose you have a large application written in C++, and perhaps you are happy for the user interface to remain in C++ but want to migrate some logic that performs complicated mathematical calculations to F# for easier maintenance. In this case, you would want to call F# from native code. The easiest way to do this is to use the tools provided with .NET to create a COM wrapper for your F# assembly; you can then use the COM runtime to call the F# functions from C++.

I Caution Using COM in C++ is a huge topic, and it is advisable that any programmer wanting to call
F# in this way is already experienced in C++/COM. If you need more information about this topic, you can find some starting points at FSharpFoundations.CPPCOM.

To expose functions through COM, you need to develop them in a certain way. First you must define an interface that will specify the contract for your functions, the members of the interface must be written using named arguments (see the section “Calling F# Libraries from C#” earlier in the chapter), and the interface itself must be marked with the System.Runtime.InteropServices.Guid attribute. Then you must provide a class that implements the interface; this too must be marked with the System.Runtime.InteropServices.Guid attribute and also System.Runtime.InteropServices.ClassInterface, and you should always pass the ClassInterfaceType.None enumeration member to the ClassInterface attribute constructor to say that no interface should be automatically generated.



I’ll now show an example of doing this; suppose you want to expose two functions called Add and Sub to your unmanaged client. So, create an interface IMath in the namespace Strangelights, and then create a class Math to implement this interface. You then need to ensure that both the class and the interface are marked with the appropriate attributes. The resulting code is as follows: namespace Strangelights open System open System.Runtime.InteropServices

[] type IMath = interface abstract Add : x: int * y: int -> int abstract Sub : x: int * y: int -> int end

[] type Math = class new () = {} interface IMath with member this.Add(x, y) = x + y member this.Sub(x, y) = x - y end end The functions Add and Sub are of course simple, so there is no problem implementing them directly in the body of the Math class. If you needed to break them down into other helper functions outside the class, then this would not have been a problem; it is fine to implement your class members in any way you see fit. You simply need to provide the interface and the class so the COM runtime has an entry point into your code. Now comes arguably the most complicated part of the process—registering the assembly so the COM runtime can find it. To do this, you need to use a tool called RegAsm.exe. Suppose you compiled the previous sample code into a .NET .dll called ComLibrary.dll; then you would need to call RegAsm.exe twice using the following command lines: regasm comlibrary.dll /tlb:comlibrary.tlb regasm comlibrary.dll The first time is to create a type library file, a .tlb file, which you can use in your C++ project to develop against. The second registers the assembly itself so the COM runtime can find it. You will also need to perform these two steps on any machine to which you deploy your assembly.



The C++ to call the Add function appears after the next list; the development environment and how you set up the C++ compiler will also play a large part in getting this code to compile. In this case, I created a Visual Studio project, choosing a console application template, and activated ATL. Notice the following about this source code: • The #import command tells the compiler to import your type library; you may need to use the full path to its location. The compiler will also automatically generate a header file, in this case comlibrary.tlh, located in the debug or release directory. This is useful because it lets you know the functions and identifiers that are available as a result of your type library. • You then need to initialize the COM runtime; you do this by calling the CoInitialize function. • You then need to declare a pointer to the IMath interface you created; you do this via the code comlibrary::IMathPtr pDotNetCOMPtr;. Note how the namespace comes from the library name rather than the .NET namespace. • Next you need to create an instance of your Math class; you achieve this by calling the CreateInstance, method passing it the GUID of the Math class. Fortunately, there is a constant defined for this purpose. • If this was successful, you can call the Add function; note how the result of the function is actually an HRESULT, a value that will tell you whether the call was successful. The actual result of the function is passed out via an out parameter. Here’s the code: #include "stdafx.h" #import "ComLibrary.tlb" named_guids raw_interfaces_only int _tmain(int argc, _TCHAR* argv[]) { CoInitialize(NULL); comlibrary::IMathPtr pDotNetCOMPtr; HRESULT hRes = pDotNetCOMPtr.CreateInstance(comlibrary::CLSID_Math); if (hRes == S_OK) { long res = 0L; hRes = pDotNetCOMPtr->Add(1, 2, &res); if (hRes == S_OK) { printf("The result was: %ld", res); } pDotNetCOMPtr.Release(); } CoUninitialize (); return 0; }



The results of this example, when compiled and executed, are as follows: The result was: 3 When you execute the resulting executable, you must ensure that ComLibrary.dll is in the same directory as the executable, or the COM runtime will not be able to find it. If you intend that the library be used by several clients, then I strongly recommend that you sign the assembly and place it in the GAC; this will allow all clients to be able to find it without having to keep a copy in the directory with them.

I Note Another option for calling F# code from unmanaged code is by the custom hosting of the CLR. This is even more complicated than calling F# methods via COM; however, it can give you fine-grained control over the behavior of the CLR. If you want to investigate this option, please see Foundations/default.aspx/FSharpFoundations.CLRHosting.

In this chapter, you saw some advanced techniques in F# for compatibility and interoperation. Although these techniques are definitely some of the most difficult to master, they also add a huge degree of flexibility to your F# programming.

I Special Characters
"" (double quotes), 18 #define macro, 311 #I "";; command, 307 #if FLAG command, 119 #import command, 342 #light declaration, 21 #load ".".."";; command, 308 #nowarn 51 command, 337 #quit;; command, 308 #r "";; command, 307 #time;; command, 308 #types;; command, 308 #use "";; command, 308 %A flag, 151 %a flag, 152 %A format pattern, 18 %b flag, 151 %d flag, 151 %E flag, 151 %e flag, 151 %f flag, 151 %g flag, 151 %i flag, 151 %left declaration, fsyacc.exe file, 284 %M flag, 151 %nonassoc declaration, fsyacc.exe file, 284 %O flag, 151 %right declaration, fsyacc.exe file, 284 %s flag, 151 %start declaration, fsyacc.exe file, 284 %t flag, 152 %token declaration, fsyacc.exe file, 284 %token declaration, fsyacc.exe file, 284 %type declaration, fsyacc.exe file, 284 %u flag, 151 %x flag, 151 &&& operator, 151 * (asterisk), 337 :? (colon and question mark operator), 76 [ ] (square brackets), 28, 62 _ (underscore) character, 38, 57, 72 | (vertical bar), 37–38, 62 ||| operator, 151 |> operator, 55 + flag, 152 + operator, 27 (greater-than sign), 82 > operator, 161 0 flag, 152 \ (backslash), 18 : (colon), 27–28 ! (exclamation point), 61 . (period), 62, 70 ; (semicolons), 28, 62 ' ' flag, 152 ( ) (parentheses), 55


a switch, 300 abs_float function, 162 abstract keyword, 101 abstract method, 101 Abstract Syntax Tree (AST), 280–281 compiling, 289–293 interpreting, 288–289 AbstractIL library, 290 AbstractProperties base class, 105 accessors, 104 acos function, 162 add function, 19 Add function, 154, 341–342 "add" instruction, 339 Add method, 74 AddHandler method, 75 AddPrinter property, fsi Value, 310 AddPrintTransformer property, fsi Value, 310 ADO.NET extensions, 228–232 overview, 216–221 advanced interoperation. See compatibility and advanced interoperation aliases, for namespaces and modules, 115 allocation graph, 322 all-warnings switch, 303 all-warnings-as-errors switch, 303 alternative-install.bat batch file, 8 alternative-install.bat command, 7 alternative-install-vs2003.bat batch file, 8 alternative-install-vs2005.bat batch file, 8 Anchor property, 177 AnchorStyles.Left enumeration value, 150



and keyword, 43, 91, 105, 283 anonymous function, 24, 26, 126 anonymous modules, 111 any_to_string function, 18 AppendChild method, 215 Application class, 196, 206 Applied Games Group, 3 Arg module, 160, 164 argspec tuple type, 164 arithmetic operators, 160 arithmetic-language implementation, 280–297 Abstract Syntax Tree (AST), 281 compilation vs. interpretation, 293–297 compiling AST, 289–293 generating parser, 284–286 interpreting AST, 288–289 overview, 280–281 tokenizing text, 281–284 using parser, 286–287 Array class, 115 array comprehensions, 66 Array module, 333–334 arrays, 62–66 arrow (->), 34, 37 as keyword, 76, 97, 103 ASCII arrow, 34 asin function, 162 .asmx file, 255, 257, 262 asp:LinkButton control, 193 ASP .NET 2.0, 188–189 ASP .NET web forms, 192–195 .aspx file, 188, 192 .aspx pages, 189 assembly browsers, 313–314 Assert class, 312 AST. See Abstract Syntax Tree (AST) asterisk (*), 337 atan2 function, 162 Attribute string, 122 attributes, custom, 122–124 Attributes property, 71–72 Aurora, 195


BinaryTree type, 48 block, 43 booleanToString function, 38 boxing, 82 Button control, WinForm, 178 button field, 187 Button object, 74 Button type, 83


backslash (\), 18 Barwick, Chris, 4 base class, 100 Base class, 103 base class, 103–104 base class library (BCL), 3, 13 BCL (base class library), 3, 13 BCL Exists method, 70 BCL System.Array type, 62 begin keyword, 111 bigint integers, 52 bin subdirectory, 188, 256 binary operators, 27

'c' char, 18 C#, calling F# libraries from, 323–332 defining classes and interfaces, 330–332 defining types in namespace, 329–330 exposing functions that take functions as parameters, 324–326 overview, 323–324 returning tuples, 324 using F# lists, 329 using union types, 326–329 casting, 81–83 ceil function, 162 center function, 172 changePositions function, 201, 206 ChangeState method, 93–94 CharSet attribute, DllImport attribute, 338 CheckBox control, WinForm, 179 CheckListBox class, 225 chmod +x fsc command, 9 choose function, 139, 143 class keyword, 99, 108 classes, 95–97 defining, 330–332 implicit class construction, 98–99 and inheritance, 99–101 and methods, 101–103 and static methods, 106–107 classes keyword, 108 ClassInterface attribute, 340 ClassInterfaceType.None attribute, 340 CLI (Common Language Infrastructure), 3 CLI version switches, 306 Click event, 74–75, 185 client-server applications, 239 cli-version switch, 306 cli-version 1.1 switch, 334 cli-version compiler switch, 332 closer function, 145–146 closures, 24 CLR (common language runtime), 35 CLR Profiler, 14, 321–322 clr-root switch, 306 cMax constant, 157 cMin constant, 157 code samples, installing, 13–14 CoInitialize function, 342 colon (:), 27



colon and question mark operator (:?), 76 colons (::), 28 color parameter, 103 Color.FromArgb(33, 44, 55) method, System.Drawing.Graphics object, 175 Color.FromKnownColor(KnownColor.Crimson) method, System.Drawing.Graphics object, 175 Color.FromName("HotPink") method, System.Drawing.Graphics object, 175 COM. See Component Object Model (COM) Combination phrase, 272 combine function, 149–151 combinel function, 274 ComboBox class, 225 ComboBox control, WinForm, 179 ComLibrary.dll file, 341, 343 comlibrary::IMathPtr pDotNetCOMPtr code, 342 comlibrary.tlh file, 342 command-line switches fsc.exe, 299–307 adding resources switches, 304–305 basic compiler options, 300 CLI version switches, 306 compilation details switches, 307 compiler optimization options, 300–302 compiler target switches, 303 compiler warning switches, 302–303 generating HTML switches, 305–306 overview, 299 printing interface switches, 304 signing switches, 303–304 statically linking switches, 307 fsi.exe, 310–311 CommandText property, 218 comment function, 283 comment rule, 283 comments, 120–122 Common Language Infrastructure (CLI), 3 common language runtime (CLR), 35 compact class syntax, 98 Compare method, 91 comparer identifier, 91 CompareTo method, 93 CompatArray module, 333 CompatArray types, Microsoft.FSharp.Compatibility namespace, 66 compatibility and advanced interoperation, 323–343 calling F# libraries from C#, 323–332 defining classes and interfaces, 330–332 defining types in namespace, 329–330 exposing functions that take functions as parameters, 324–326 overview, 323–324

returning tuples, 324 using F# lists, 329 using union types, 326–329 calling using COM objects, 335–336 overview, 323 using F# from native code via COM, 340–343 using F# with .NET frameworks versions 1 and 1.1, 332–334 using Inline IL, 338–340 using P/Invoke, 336–338 CompatMatrix types, Microsoft.FSharp.Compatibility namespace, 66 compilation details switches, 307 compiler optimization options, 300–302 compiler options, 300 compiler target switches, 303 compiler warning switches, 302–303 compiling F# programs, 9–12 Component Object Model (COM) objects, 335–336 using F# from native code via, 340–343 concat function, 139–140 concatList function, 30, 40 concatListOrg function, 40 .config extension, 209 .config file, 222, 263, 266 ConfigurationManager class, 209 Connect method, TcpClient class, 247 ConnectionString property, 210 constructors, 45, 95 Continuous1 property, 328 Control base class, 82 Control class, 93, 185 control flow, 33, 66–68 Controls collection, 175 convertVolumeImperialPint function, 46 convertVolumeToLiter function, 46 convertVolumeUsPint function, 46 cordbg.exe command-line debugger, 315 cos function, 162 cosh function, 162 couple type, 60 create function, IEvent module, 154 Create static method, 249 createDynamicMethod method, 290, 293 CreateElement method, 215 CreateInstance method, 342 CreateText( ) instance method, 71 createWindow function, 196, 201 critical section, 133 Current member, 244 curried functions, 2, 20 CurriedStyle class, 331 custom attributes, 122–124 custom operators, 27

Find it faster at



I D dash (

Similar Documents

Premium Essay

Music Theory

...concepts that will help you understand what you and others are creating, help you speak and understand the language of music theory and, hopefully, stimulate some new ways of thinking about your own EDM compositions. It will be very elementary to the more advanced musicians, but hopefully it will help people struggling with basic music theory concepts and practices. My original plan was to make this a blog, but given the other knowledgeable theory minds around here (e.g., RichieV, Diginut, Sonic_c, etc.), I think it would be better to keep it in an open forum format to facilitate an open dialog, Q&A, etc.So, for this first session, I am going to talk about major and minor scales, which are typically used in EDM. This session will lay a foundation for later sessions discussing the relevant modes, the relationships between chords and modes, how chords are structured and arranged, and ultimately some discussions of melodies and harmonies. I will assume for this first session that the reader is familiar with note names and can locate the notes on a piano, has a general understanding of how to read music (e.g., treble vs. bass clef, notation), etc. I am going to focus on the familiar diatonic (7-note) scales in this...

Words: 1999 - Pages: 8

Premium Essay

Organization Paper

...Organizational Paper Sheila Madison Management 330 Glenn Conowitch February 21, 2007 Organizational Structure Paper Businesses in today’s world are looking to organizational structure to assist with building a successful organization. Organizational structure is used as a foundation to ensure each department as well as employee knows the proper direction to take. There are two organizations, The Sharp and AT&T, which incorporate organizational structure in the day-to-day business. Each organization will be evaluated to compare and contrast the impact of organizational structure. AT&T utilizes the three functions of management to build a dynamic organization. By introducing organizational structure to the corporation, an effective working environment is created for each employee. Now AT&T has created an organizational chart to provide a reporting structure for employees to follow. The organizational chart also provides where each department stands in the corporation. Both vertical differentiation as well as horizontal differentiation is utilized in AT&T. The chief executive officer along with the human resources department have worked together to create an organizational chart for the Mission Systems sector of AT&T. The program manager is at the top of the chart. His primary function is to oversee the sector and works with the assistant program managers. The assistant program managers work with the program manager to task the engineers with assignments to be......

Words: 1321 - Pages: 6

Premium Essay

Unit 1 Research Paper: Exploring Programming Languages

...Exploring Programming Languages Popular programming languages of the 1970’s: * B – Was a forerunner to “C” * Created by Dennis Ritchie and Ken Thompson at Bell Labs in 1969. * Designed for recursive, non-numeric, machine independent applications, such as system and language software. * C – A general purpose, imperative computer programming language, supporting structured programming. * Was designed by Dennis Ritchie at Bell Labs in 1972. * Used to re-implement the Unix operating system. * Smalltalk – An object oriented, dynamic typed, reflective programming language. * Designed and created in 1972 at the Learning Research Group by Alan Kay, Dan Ingalls, and Adelle Goldberg. * Created as the language to underpin the “new world” of computing exemplified by “human-computer symbiosis.” * Prolog – The first logic programming language. * Designed in 1972 by a group around Alan Colmerauer. * Intended use was for natural language processing. * ML – A statically typed functional programming language. * Designed by Robin Milner in 1973. * Purpose was to develop proof tactics in the LCF theorem prover. Popular programming languages of the 1980’s: * C++ - General-purpose programming language. Imperative, object-oriented and generic programming features. * Designed by Bjarne Stroustrup at Ben Labs in 1980. * Designed with a bias toward system programming and...

Words: 902 - Pages: 4

Free Essay

Programming Lenguages

...ro1970’s Pascal is an influential imperative and procedural programming language, designed in 1968–1969 and published in 1970 by Niklaus Wirth as a small and efficient language intended to encourage good programming practices using structured programming and data structuring. A derivative known as Object Pascal designed for object-oriented programming was developed in 1985. ------------------------------- C is a general-purpose programming language initially developed by Dennis Ritchie between 1969 and 1973 at AT&T Bell Labs. Like most imperative languages in the ALGOL tradition, C has facilities for structured programming and allows lexical variable scope and recursion, while a static type system prevents many unintended operations. Its design provides constructs that map efficiently to typical machine instructions, and therefore it has found lasting use in applications that had formerly been coded in assembly language, most notably system software like the Unix computer operating system. ----------------------------------- Prolog is a general purpose logic programming language associated with artificial intelligence and computational linguistics. Prolog has its roots in first-order logic, a formal logic, and unlike many other programming languages, Prolog is declarative: the program logic is expressed in terms of relations, represented as facts and rules. A computation is initiated by running a query over these relations. The language was first conceived by a...

Words: 2012 - Pages: 9

Free Essay

Pt1420 Programming Unit 1 Research Assignment

...1970’s CLU is a programming language created at MIT by Barbara Liskov and her students between 1974 and 1975. It was notable for its use of constructors for abstract data types that included the code that operated on them, a key step in the direction of object-oriented programming (OOP). Euclid is an imperative programming language for writing verifiable programs. It was designed by Butler Lampson and associates at the Xerox PARC lab in the mid-1970s. The implementation was led by Ric Holt at the University of Toronto and James Cordy was the principal programmer for the first implementation of the compiler. It was originally designed for the Motorola 6809 microprocessor. Forth is an imperative stack-based computer programming language and programming environment. Language features include structured programming, reflection (the ability to modify the program structure during program execution), concatenative programming (functions are composed with juxtaposition) and extensibility (the programmer can create new commands). Although not an acronym, the language's name is sometimes spelled with all capital letters as FORTH, following the customary usage during its earlier years. Forth was designed by Charles H. Moore and appeared in the 1970’s. GRASS is the original version of GRASS was developed by Tom DeFanti for his 1974 Ohio State University Ph.D. thesis. It was developed on a PDP-11/45 driving a Vector General 3DR display, and as the name implies, this was a purely......

Words: 1885 - Pages: 8

Premium Essay


...making process Chapter 6 Chapter 7 Strategic management process Chapter 8 Fundamentals of organizing Chapter 9 Midterm Exam 5 Chapter 1 History of Management thought Fundamentals of planning 4 Overview International Management 3 INTRODUCTION External environment & Org culture 2 Chapters The Management Process 1 Topics & Assignments Midterm Case studies must be presented BEFORE the following lecture 7 © IES Business Consultants Week Chapter 12 Chapter 13 Teams & teamwork Chapter 14 Chapter 15 Essentials of Leadership Chapter 16 Chapter 17 Operations Management & Control Chapter 18 Overview Overview FINAL EXAM 10 Chapter 11 Foundations of individual behavior Fundamentals of Control 9 Chapter 10 Communication, Conflict...

Words: 441 - Pages: 2

Free Essay

Eisenhower Doctrine

...POL 300 – International Relations Dr. Barsegian June 3, 2012 Eisenhower “Revised” Introduction In the United States, the term "doctrine" has been applied to a particular set of presidential statements, usually consisting only of several sentences. (Micheals, 2011)Presidential doctrines have also been defined as "a grand strategy or a master set of principles and guidelines controlling policy decisions. (Micheals, 2011) Eisenhower “Man” Dwight D. Eisenhower was born on October 14, 1890 in Denison, Texas and raised in Kansas. He was born to a poor family and attended public schools his entire life, finally graduating high school in 1909. (Dwight D Eisenhower) Inspired by the example of a friend who was going to the U.S. Naval Academy, Eisenhower won an appointment to the U.S. Military Academy at West Point. (Chester J. Pach) Many have said that Eisenhower was a born leader becoming one of America’s greatest military commanders. As early as 1943 Eisenhower was mentioned as a possible presidential candidate. (Micheals, 2011) Presidents Eisenhower' began his first term in 1952 and his first task upon assuming office was to fulfill his campaign promise to end the Korean War. (Dwight D Eisenhower) Within six months of his assuming office, an armistice agreement was signed. Eisenhower instituted a new military policy for the US Armed Forces, that policy was called the "New Look". ...

Words: 2931 - Pages: 12

Free Essay


...Workbook on Science (Grade 5) Produced by 57-75 in partnership with the Ateneo Center for Educational Development and the Department of Education Divisions of Bayombong (Nueva Vizcaya), Guimaras, Iligan City (Lanao del Norte), Iloilo City (Iloilo), Pampanga, San Isidro (Nueva Ecija), Pagbilao (Quezon) and Sual (Pangasinan) Workbook on Science (Grade 5) Writers: Ms. Nenita Gellego (Guimaras) Ms. Jacinta Abeleda (Sual,Pangasinan) Reviewers: Ms. Michelle Jose (Ateneo Loyola Schools) Ms. Anna Marie Q. Benedicto (Ateneo High School) In partnership with: Ateneo Center for Educational Development Foundation for Worldwide People Power League of Corporate Foundations Philippine Business for Education Philippine Business for Social Progress SynergeiaFoundation PREFACE In April 2008 the 57-75 Movement organized a workbooks development write-shop in order to come up with an immediate and effective response to the problem of lacking textbooks and instructional materials in public schools. For two weeks, master teachers from each of the 57-75 pilot sites compiled a series of workbooks on Science, English, and Mathematics designed for their elementary and high school students. The write-shop aimed to: (1) identify least mastered skills in a subject area; (2) produce lesson guides that will help increase the ability of classroom instructors in developing the mastery level of students particularly in problematic subject areas; and (3) help teachers be creative in developing their own......

Words: 23678 - Pages: 95

Premium Essay


...SAFETY HANDBOOK Student’s name Course title Date Safety Handbook Introduction Safety is the state of serenity being devoid of harm or any form of event that may be considered non-desirable. In any type of institution, be it, a business, school, industry, laboratory or even the common workplace, safety plays a major role in ensuring activities run smoothly and no-one gets hurt while doing their job. Safety encompasses protection from a wide host of potential hazards which could be physical, financial, emotional or biological. In the common workplace health is a major concern and infection control is the main aim of a safety handbook. Biosafety in the work setup starts by assuming every individual is a potential source of infection. Basic techniques such as scheduled cleaning of the workplace and regular hand washing by staff go a long way in ensuring infection control and biosafety of workers. All workplaces should ideally possess appropriate safety apparatus e.g. a first aid kit with an employee having necessary expertise in first aid. Provision of necessary safety equipments e.g. gowns, gloves and goggles is also essential in as far as biosafety in the workplace is concerned. General Principles Disease is caused by organisms termed pathogens. There are various pathogens that are located routinely in work setups. These include bacteria, fungi, viruses, prions or protozoa. When these manage to enter your body or attach onto your skin, disease arises. It usually......

Words: 932 - Pages: 4

Free Essay

Nature of the Church

...Article: The Nature of the Church By Walvoord, John F. Submitted to Professor Kevin Richard in partial fulfillment of the requirements for the completion of the course THEO 510-B06 Survey of Theology by Mark W. Clark, L26613732 January 23, 2014 Contents Introduction 1 Brief Summary 1 Critical Interaction 2 Conclusion.....................................................................................................................................................4 Bibliography 6 Grading Rubric 7 Introduction: Digging around the archived files of Bibliotheca Sacra (affectionately known as “Bib Sac”) evoked a deep sense of history and legacy. Although my exploration was limited to the broad, colorful screen of my iMac computer, I could almost smell the dusty stacks, piled high in the bowels of Dallas Theological Seminary’s archive rooms. Bib Sac was first published in 1844 and lays claim to being the oldest theological journal in America. The list of past editors stirs my earliest memories in Bible college on the coast of Maine. The theological foundations of my studies there included Lewis Sperry Chafer, John Walvood and Roy Zuck, all prolific writers and former editors of Bib Sac. It was here, in a relatively modern volume: October, nineteen fifty-nine, that I struck pay dirt. The volume I was perusing contained an article entitled The Nature of the Church, by Dr. John F. Walvoord. I was overjoyed and wondered how Muhammed......

Words: 1481 - Pages: 6

Premium Essay

Cognitive Psychology

...including how people think, perceive, and even learn. (Van Wagner, 2009)." Cognitive Psychology is a psychological perspective that addresses mental processes such as thinking, problem solving, perceiving, remembering, believing, and speaking, and seeks to identify behavior by characteristics other than its obvious properties” ("Cognitive psychology," 2009). Cognitive psychology is often compared to behaviorism because of the sharp contrast of the perspectives (Willingham, 2007) Cognitive psychology is used the most when someone is evaluating patients for different types of mental disorders and diseases. The principles that have evolved from the founding of cognitive psychology from the early times starting from the Greek philosophers to modern day psychologist it has greatly affect how people around the world think about the psychological processes of the human mind. Greek philosophers were the first people to start looking into the human mind and how it works. Plato and some of the other early Greek philosophers started creating the foundation for what would be known as today as cognitive psychology (Anderson, 2005). Plato's principles of rationalism described how reality should be viewed, stating that "reality resides not in the concrete objects we perceive but in the abstract forms that these objects represent (University of Arizona, 2008)." He also believed that the route of knowing knowledge could only be first found through logical analysis. Then Artistotle......

Words: 1061 - Pages: 5

Premium Essay

Comparison of William Brickman and Paulo Freire

...A Comparison of William Brickman and Paulo Freire (1921-1997) Paulo Freire (1921-1997) was an advocate for the liberation of the oppressed through the process of critical thought. He learned at an early age that conventional education is a vehicle for oppression and to escape that oppression, one must develop critical consciousness. Freire believed that students should be “given encouragement and opportunity to engage in critical thinking in the quest for the humanization of both learner and teacher” (Flanagan, 2005, p. 189). This quest for humanization and the transcendence from oppression is attained when both teacher and student is neither subject nor object but equal in the process of exchanging learning. Freire’s methodology endures today in quality education at all levels as student creativity is both encouraged and enhanced through dialogue and lived experiences. William Brickman is known as the founder of the Comparative Education Society. His greatest contribution to the field of education was his extensive research in diversified education. Through his participation in various cultures and exchanges with foreign scholars, William Brickman led the charge for comparative education. He promoted his belief of academic freedom and championed the idea that “there was no one correct way of doing comparative education” (Brehm, W.C., and Silova, I., Summer 2010, p. 23). As with any pioneer, both Freire and Brickman struggled with resistance to their methodologies...

Words: 746 - Pages: 3

Premium Essay

Applying Trompenaars Typology of Organizational Culture to Implementation of Csr Strategy

...Journal of Intercultural Management Vol. 3, No. 2, October 2011, pp. 113–125 Adrian Pyszka Michał Piłat Cracow University of Economics Applying trompenaars typology of organizational culture to implementation of csr strategy 1. Introduction Nowadays many authors declare Corporate Social Responsibility (CSR) in strategic terms as it is no longer seen as the invention of some social activist but important source of competitive advantage. However various researchers still struggle to figure out what shape and utility should the tools of CSR have and what implementation model could be the best to fulfill the business objectives. The study aims to demonstrate whether Trompenaars bipolar model of organizational culture could prove useful while implementing CSR strategy and to propose some good practice in this case. 2. Theoretical framework Culture A lot has changed in world of management since 80s and many leaders tend to ask a question whether corporate culture is still important. However high interest in that area seems to be a sufficient prove that it still is. According to a recent survey by management consultancy Bain & Company, 9 of 10 senior executives believe that corporate culture is as important as strategy for business - - - - - Electronic PDF security powered by 114 Adrian Pyszka, Michał Piłat success1. Corporate culture is described as general constellation of beliefs, mores, customs, value systems and......

Words: 4847 - Pages: 20

Free Essay

Art in Architecture

...Architecture as form of Art Abstract Art was always an inspiration to works in architecture. Architects have always rifled around looking for inspiration from art around us and tried to integrate it with building designs. The Husain-Doshi Gufa renamed, as Amdavad Gufa, a unique art gallery was designed by the architect B.V.Doshi and housed works of his friend a famous artist M.F.Husain in city of Ahmedabad, India. It was designed as an underground gallery with structure consisting of domes, curvilinear walls, tree shaped columns, contoured floors and snouts on domes for light source. The gallery enchanted the people with the surreal sensation of being in a cave. The wall of the gallery has acted as a canvas on which the artist Husain doodled paintings similar to the art in Palaeolithic caves. The entire structure was conceptualized on the confluence of sustainable and vernacular practises alongside the theme drawn from organic architecture. Turtle shell, domes, mountains, and Buddha caves of Ajanta & Ellora inspired the form of the building. The gallery was built underground with china mosaic finish on the top of the domes in order to encounter the harsh heat of the city. The gallery has stood out against the conventional dictum of white cube ideology and opened the dialogue between art and architecture and their mutual dependence. The gallery has brought a distinctive confluence of art in architecture, where the architecture is piece of art itself showcasing art works.......

Words: 1520 - Pages: 7

Premium Essay

Solar Tree

...Solar tree reliable and will try to make them gain more energy. 2 Benefits Solar trees deliver the following benefits: • Build awareness and interest in solar technology, thereby promoting its adoption • Provide shade and a meeting places • Differentiate properties, especially those with other hidden green building measures 3 Origin and Progress Unique sculptural creations for a single sites began to appear in 1998 (e.g., the 7 kW tree in Gleisdorf, Austria) or earlier. A number of variants of solar trees have been conceived, not all of them realized in installations. Locations have included roadways, public areas in cities, schools and universities, office buildings, science museums, and more. Recently, designers and manufacturers have introduced solar trees as products, designed to deliver the benefits of solar trees in a repeatable way to more places. Examples include Ross Lovegrove’s solar tree which incorporated seating, lighting, and circular groupings of photovoltaic cells, Envision Solar solar parking canopy specifically trademarked Solar Tree, and Spotlight Solar’s line of architectural structures. Solar tree in Gleisdorf, Austria The Solar Tree blends art and solar energy technology in a sculptural expression. Solar trees are both artistic and functional clean energy machines. The term Solar Tree has been used to describe a variety of structures incorporating solar energy technology on a single pillar (like a tree trunk), and has become a......

Words: 1559 - Pages: 7