MSDN Magazine - February 2009 - (Page 66)

meets the constraints set by that type. To check whether a value is in the set defined by a type, you use the “in” operator (shown here from inside the Mr. Epl tool): M>>> type SmallInteger : Integer32 where value >> 4 in SmallInteger true M>>> 4 in Integer32 true M>>> 256 in SmallInteger false M>>> 256 in Integer true }; Language : Integer32 = 1033; // default value Compressed : Logical = true; // defaults value Here you can see that 4 is a SmallInteger and an Integer32, but 256 is only an Integer32. Entity values can be checked for type membership as well: M>>> M>>> true M>>> M>>> true M>>> true M>>> true type Point { X : Integer32; Y : Integer32; }; { X = 100, Y = 200 } in Point pt1 { X = 10, Y = 20 } pt1 in Point pt1 in { X : SmallInteger; Y : SmallInteger; } pt1 in { X; Y; } Here you see the Package type from the WiX module. Every product (the top-level concept in an MSI setup) has a package, which has an optional set of text keywords, an optional description and comment, a required manufacturer, an installer version that defaults to Windows Installer 2.0, a language the defaults to U.S. English and a compression flag that defaults to true. The required values have no suffix, like Product and Manufacturer. The default values have an equals sign and a value, such as InstallerVersion and Language. The optional values have a question mark suffix, such as Description and Comments. The collection values (those with zero or more values) end in star. The question mark and star notions (? and *) are meant to remind you of the Kleene operators from your favorite regular expression language. Here’s an example Package value: Products { SuperNotepad : Product* { Name = "SuperNotepad", } } You can see that the named and unnamed X, Y pairs are both Points and that both fields of the named X, Y pair are SmallInteger values, this time defining an anonymous type to do the checking for you. The last line indicates that the named X, Y pair fits into the set of values that have fields named X and Y, with no restric- All “M” code must be inside a module, much like all .NET-based code must be inside a namespace. tion on their values—they could be strings or dates or collections or whatever. Here’s another example. In this case, because the named X, Y pair doesn’t also have a Z field, it doesn’t fit into the anonymous type that requires X, Y, and Z fields: M>>> pt1 in { X; Y; Z; } false M>>> pt1 in { x; y; } false Packages : Package* where item.Product in Products { Package1 { Product = Products.SuperNotepad, Description = "A really super pad for notes", Manufacturer = Products.SuperNotepad.Manufacturer, Keywords = { "Installer", "Super", "Notepad", "Sample" } } } Here I’ve got part of a Product and an entire Package. Notice that I have two kinds of constraints. The first kind is of the form “: something”, as in: SuperNotepad : Product* { This is called type ascription and constraints all values inside the curly braces to conform to the constraints of the type. The second constraint is the where clause that tells the “M” compiler where to find the storage for the Product entity values: Packages : Package* where item.Product in Products { Further, the last line shows that M is case-sensitive. Finally, you’ll want to understand the default value and collection notations: type Product { Name : Text; }; type Package { Product : Product; // required value Keywords : Text*; // collection of 0 or more values Description : Text?; // optional value Comments : Text?; // optional value Manufacturer : Text; // required value InstallerVersion : Integer32 = 200; // default value Also notice that two of the values have names (SuperNotepad and Package1). The MGraph syntax allows for names to be used in the middle of initializing a graph of values so that one part of the graph can reference another part without duplicating the data. I am doing this so that I can reference my product in the definition of the package. As useful as Mr. Epl is, you’ll want to use a text editor for larger things. Both Visual Studio 2008 and Intellipad provide language services to make editing “M” a pleasant experience. For example, to check that you’ve got something syntactically valid, you can look for data tips over the red squiggles showing errors (for example, a missing closing double quote). All “M” code must be inside a module, much like all .NETbased code must be inside a namespace. This scopes the types and values. If the lack of squiggles isn’t enough to make you happy, you can also run the “M” compiler from the command line: C:\>set path=%path%;"c:\Program Files\Microsoft Oslo SDK 1.0\Bin" 66 msdn magazine “Oslo” Basics

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.