I just fought with this for a while and figured I'd record this in the vast internets in case others come across this. While attempting to extend the functionality of our Grails project at work I needed to add a new table and related foreign key constraints. We use the Grails Database Migration Plugin which uses liquibase to keep our schema in sync between production, staging, and development boxes. I declared a foreign key constraint similar to this one:

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

addForeignKeyConstraint(
    baseColumnNames: 'column_name,
    baseTableSchemaName: 'my_schema',
    baseTableName: 'my_table',
    constraintName: 'my_constraint_name',
    deferrable: 'false',
    initiallyDeferred: 'false',
    onDelete: 'CASCADE',
    onUpdate: 'CASCADE',
    referencedTableName: 'referenced_table',
    referencedColumnNames: 'my_referenced_column',
    referencedTableSchemaName: 'my_schema',
    referencesUniqueColumn: 'true',
)

and got this exception:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

2012-01-25 15:53:13,963 [Thread-12] ERROR context.GrailsContextLoader  - Error executing bootstraps: liquibase.exception.ValidationFailedException: Validation Failed:
     1 changes have validation errors
          java.lang.ClassCastException: liquibase.statement.core.AddForeignKeyConstraintStatement cannot be cast to liquibase.statement.core.CreateTableStatement

org.codehaus.groovy.runtime.InvokerInvocationException: liquibase.exception.ValidationFailedException: Validation Failed:
     1 changes have validation errors
          java.lang.ClassCastException: liquibase.statement.core.AddForeignKeyConstraintStatement cannot be cast to liquibase.statement.core.CreateTableStatement

	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:97)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:884)
	at groovy.lang.Closure.call(Closure.java:410)
	at DatabaseMigrationGrailsPlugin$_closure2.call(DatabaseMigrationGrailsPlugin.groovy)
	at org.codehaus.groovy.grails.plugins.DefaultGrailsPlugin.doWithApplicationContext(DefaultGrailsPlugin.java:489)
	at org.codehaus.groovy.grails.plugins.AbstractGrailsPluginManager.doPostProcessing(AbstractGrailsPluginManager.java:169)
	at org.codehaus.groovy.grails.commons.spring.GrailsRuntimeConfigurator.performPostProcessing(GrailsRuntimeConfigurator.java:232)
	at org.codehaus.groovy.grails.commons.spring.GrailsRuntimeConfigurator.configure(GrailsRuntimeConfigurator.java:172)
	at org.codehaus.groovy.grails.commons.spring.GrailsRuntimeConfigurator.configure(GrailsRuntimeConfigurator.java:124)
	at org.codehaus.groovy.grails.web.context.GrailsConfigUtils.configureWebApplicationContext(GrailsConfigUtils.java:121)
	at org.codehaus.groovy.grails.web.context.GrailsContextLoader.initWebApplicationContext(GrailsContextLoader.java:104)
	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4723)
	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226)
	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:680)
Caused by: liquibase.exception.ValidationFailedException: Validation Failed:
     1 changes have validation errors
          java.lang.ClassCastException: liquibase.statement.core.AddForeignKeyConstraintStatement cannot be cast to liquibase.statement.core.CreateTableStatement

	at liquibase.changelog.DatabaseChangeLog.validate(DatabaseChangeLog.java:138)
	at liquibase.Liquibase.update(Liquibase.java:110)
	at liquibase.Liquibase$update.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at grails.plugin.databasemigration.MigrationRunner$_autoRun_closure1.doCall(MigrationRunner.groovy:50)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
	at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:226)
	at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:52)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
	at grails.plugin.databasemigration.MigrationRunner$_autoRun_closure1.doCall(MigrationRunner.groovy)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1054)
	at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:884)
	at groovy.lang.Closure.call(Closure.java:410)
	at grails.plugin.databasemigration.MigrationRunner$_autoRun_closure1.call(MigrationRunner.groovy)
	at groovy.lang.Closure.call(Closure.java:404)
	at grails.plugin.databasemigration.MigrationRunner$_autoRun_closure1.call(MigrationRunner.groovy)
	at java_util_concurrent_Callable$call.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
	at grails.plugin.databasemigration.MigrationUtils.executeInSession(MigrationUtils.groovy:99)
	at grails.plugin.databasemigration.MigrationUtils$executeInSession.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at grails.plugin.databasemigration.MigrationRunner.autoRun(MigrationRunner.groovy:46)
	at grails.plugin.databasemigration.MigrationRunner$autoRun.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
	at DatabaseMigrationGrailsPlugin$_closure2.doCall(DatabaseMigrationGrailsPlugin.groovy:84)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	... 21 more

It turns out that passing in a named parameter of referencesUniqueColumn with a value of anything other than false causes this exception. This wasn't immediately obvious to me and I still don't know why, but I thought I'd note it in case someone else ran into it too.

Permalink | Leave a comment  »

Grails' GORM provides convenient ways to define many different constraints for inputing properties including basic ones like max, equal, & notEqual to more specific ones like creditCard, url, & email (full list here under Quick Reference). But sooner or later you’ll want to create your own custom validator. This can be done by providing a validator closure to your domain, for example:

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

class Groovyist {
    String username
    String password
    String email
    Long   favoritePrime

    static constraints = {
        username blank: false, unique: true
        password size: 5..15, blank: false
        email email: true, blank: false
        favoritePrime validator: { BigInteger(it).isProbablePrime(99) }
}

Now, in this example a domain will validate all of the fields, including the user’s favorite prime (to a degree of certainty). However, if the prime number certainly isn’t prime then the error message provided when validation fails (through validate or save) will be:

favoritePrime does not pass custom validation.

That probably isn’t a helpful message to eventually pass back to the user, they might guess what the mysterious “custom validation” is in this case, but certainly not in all others.

So what is the solution? You might try passing an error message back, but that won’t work; you’ll get the same message again. It turns out the proper approach is to return a key from your message.properties file. If the key exists in the proper localization file (e.g. French is messages_fr.properties) then it will use that string. A simple modification to the validator above will solve this:

1

favoritePrime validator { BigInteger(it).isProbablePrime(99) ?: 'my.localized.not.prime.message' }

Adding the line:

my.localized.not.prime.message=The number {2} is not prime.

Will cause Grails to generate a much more useful validation failed message. As you can probably guess the {2} will be replaced with the value inputed by the user.

You can include additional values to your message by returning an array. The first element should be a message key (e.g. ‘my.localized.not.prime.message’) and the subsequent entries will be interpolated into the message starting at index 3. So, if you returned ['my.localized.not.prime.message', 5] you could have the message: my.localized.not.prime.message=The number {2} is not prime, {3} is an example of a prime. And in this case if the user passed in 4 they would end up with the message:

The number 4 is not prime, 5 is an example of a prime.

Of course, if you aren’t using a prime number validator multiple times in your code it may seem silly to have a special key/value pair dedicated to primes. Another option is to use a key/value pair dedicated to that field. You can do this simply by using the code in the first example and addding a field to your message.properties file like:

Groovyist.favoritePrime.validator.invalid=The number {2} is not prime.

Much of this is documented in the validator docs.

Permalink | Leave a comment  »

I just finished reading this letter discussing why Yammer is going to slowly move from Scala to Java. While I’ve never done anything more substantial than basic toying around with scala and can’t say I know much about Yammer outside of what their website tells me about itself and the fact that Gabriel Weinberg seems to like it I do have some thoughts on general points hit on in the letter.

The letter that Coda Hale wrote seemed to be rather well thought out. The author goes into several criticisms of Scala which seem to boil down to:

1. Complicated concepts in the language
2. Community support
3. Lack of abundance of developers
4. Reality of the Scala-and-Java nature of real world development
5. Build toolchain issues
6. Performance issues

The first point and last two are very specific to Scala. Language designers have to decide between many difficult tradeoffs when designing a language and it is hard to say which ones will pay off for their community in the long run. It is certainly difficult to see how a given choice will pay off in the long run and while some of Scala’s features he mentions seem pretty simple, others make me go cross-eyed trying to read explanations of them. Having said that, I still am very much a novice in the language and don’t feel particularly qualified to actually weigh in on these topics.

The lack of developers and quality of community support can be bundled together and seem to have more to do with the age and uptake of the language than at the language itself. Any language will have bootstrapping issues similar to this. And when choosing a language, it is an important aspect that should, and to some extent can, be checked out before any major development undertaking. Evaluating a community around a technology is no easy task though. I’ve certainly been in situations where the community involvement around the technology used was unhelpful, misleading, or nonexistent; it is a crummy situation to be in. The best way to know the value of a community is to be a part of it for a while.

Coda points out the fact that Yammer wasn’t really deciding between Java or Scala but between Java or Scala+Java. If we ever meet I owe Coda a beer for this. I’ve had my share of arguments with people in the past on this reality and I’m glad to see something saying it so straight forward getting the circulation this is, even if it was never supposed to. Coming from a non-Java background to a Groovy position I feel acutely aware of all the times I’ve had to dig through Java code because of an impedence mismatch between a Java concept and a Groovy one, to better understand a library that doesn’t document something well and doesn’t have a functional equivalent in Groovy, or to debug or diagnose a framework bug. Having said that, I don’t believe my team has written a new line of Java for our core product since we migrated to Groovy some number of months ago.

I expect that the Java+otherLang situation is an inevitability of developing on the JVM. As long as Java is the dominant player on the platform it will be the lingua franca. The reality of these languages being so interoperable is that the cost to benefit analysis of porting a framework or library (internal or external) over to another language on the platform almost always works against porting it.

In the end, Coda seems to make a lot of good points. I can’t vouch for his Scala specific concerns, but others seem reaonable in the more general case of burgeoning JVM languages. And, while this doesn’t lower my interest or intent of learning Scala one of these days I do wonder why Yammer decided to start with Scala given the resources available to them with other languages.

My intention has been that were I to take a startup from day 1 I’d pick a language that I already had a team, or list of would be team members, with a strong understanding of and a good history with the community. Maybe they had that int he beginning or thought they did and that wasn’t mentioned, I certainly don’t have that information. And really, in the end, they have nearly sixty million dollars in VC funding, three million customers, and a rapidly growing revenue stream and I’m killing time waiting for my next robotics assignment to come down the pipe. I guess you can’t argue with results, hehe.

Edit: Also of note is Coda’s follow up, you should read it if you read the first.

Permalink | Leave a comment  »

Recently I took a job with a startup that is using Groovy as their main language. I find the language to be similar to several other languages and they have some comparisons on their site, however one comparison they are missing is to Perl. Since I'm learning Groovy anyway and the two are sufficiently similar that I thought I'd give it a shot.

Before I start with the articles there are a few important things to note about Groovy:

1. Groovy autoboxes, as such it is completely legitimate to write `"I like cheese".someMethodOnStrings()`.
2. Groovy automatically makes a variable named `it` as the only parameter for lambda function if no parameter list is given, meaning that: `def foo = { it * 2}` is similar to `def foo = { it -> it * 2}`.
3. Groovy's syntax provides an alternate way to list parameters for a method call when the last parameter is a lambda function meaning that `someData.someMethod(1,2, { it + 2})` is the same as `someData.someMethod(1,2) { it + 2}`, this is useful for methods that loop over lists, like `each`.

Permalink | Leave a comment  »

This entry will primarily go over various approaches towards iterating over structures of data. This will include basic looping as well as equivalents to Perl’s map & grep.

This is not intended to be an exhaustive guide or a best practice for either language. The attempt, as with all articles in this series, is to provide a basic set of mappings between the languages.

Iterating over collections

To loop over all the items in an array in Perl you would probably use the for loop construct:

for my $item (@array) {…}

You could do something similar in Groovy using the each method on collections:

list.each {…}

To loop over all the keys in a hash (or Map) you can combine the above with the keys builtin:

for my $key (keys(%hash)) {…}

In Groovy you simply use a lambda that accepts two parameters.

myMap.each { key, _value -> … }

Looping over all the values is similar to the examples above in both, so I will skip that. Looping over each entry in the hash with both the key and value in Groovy is the same as the example above, in Perl you would have to use each, which I don’t like.

It is important to note that with Groovy’s each different things are passed in based on the number of parameters. The example above gave each a 2 parameter lambda and so the lambda got inputs of [key, value]. Had a 1 parameter lambda been passed in then that lambda would have received an Entry object that had accessors for the key and value.

Iterating over a Set of Integers

Both Perl and Groovy provide many ways to iterate over a range. One popular approach in Perl is to use the dot-dot range operator (..) and for looping construct. By using this it is simple to print all the numbers between one and ten:

for my $num (1..10) { print $num }

Groovy has a similar approach:

(1..10).each { print it }

Groovy has a couple other ways to do the same thing, for example numbers have an upto method attached to them that can be used to iterate. As such, the same thing above could be written as:

1.upto(10) { print it }

Of course, Perl also has the ability to loop via the while looping construct and Groovy could loop using a for in on top of what I’ve listed here.

If you wanted to iterate over a set of integers that didn’t increment by one in Perl you might use map and for like this:

for my $multiple_of_five ( map { $_ * 5 } 1..5) {…}

Or you might use grep and for like this:

for my $multiple_of_five ( grep { not $_ % 5 } 1..25) {…}

Or, of course, you could pick up a useful module, like Math::Sequence.

In Groovy you would simply do this:

5.step(25,5) {…}

Mapping a List

Perl helpfully provides the map builtin to easily map a list of values from one to another. For example, were a developer wanting to square all the values in a list they would:

my @squared = map { $_**2 } @original_values

The same thing can be performed in Groovy using the collect() method on collections:

List squared = originalValues.collect { it.power(2) }

Grepping a List

Perl provides the grep builtin to easily filter values out of a list and provide a new list with only the remaining values. For example, if a developer was looking for all the items in a list that were odd they could:

my @odd = grep { $_ % 2 } @numbers

To do this in Groovy they would use the findAll method that exists on collections:

List odd = numbers.findAll { it % 2 }

Grepping for the First Item in a List

Perl has a number of modules which are considered ‘core’. It is reasonable to assume any core module is installed and readily available. To get the first item in a list that matches some criteria a Perl developer could use the example above for grepping a list and shift off the top, but more likely they would use List::Util’s first like this:

my $first_odd = first { $_ % 2} @numbers

A similar approach in Groovy could be done via the find method on collections:

def firstOdd = numbers.find { it % 2 }

Permalink | Leave a comment  »

Holy cow!  I decided to check my Google Analytics account to see what the impact of my If You Like X You Might Like Perl.  I thought it might, maybe, double the visitors to this page.  I was quite wrong, here is how wrong:

Permalink | Leave a comment  »

I'm reading Parallel Programming Design:  A Foundation by Chandy and Misra for a master's class and am finding it very interesting.  The book covers the Unity Model as an approach towards parallel programming.  The language used to model solutions to a problem isn't meant to be directly implemented as a language (though it has been incarnated as PCN) but instead to be used as a model for implementing the solution in some other language.  It is a fun language and hopefully now that I don't have a presentation looming over my head I can explore it independently and post some example.

The language is broken up into several parts:

1. Declare - used for declaring variables
2. Always - used for defining functions
3. Initially - used for initializing variables
4. Assign - the main portion of the code

The reason why initialization doesn't happen in the main portion of the code is that there is no guarantee that it would happen when you would want or that it would only happen once.  In fact, the assignment section of the program has very weak promises.  It only guarantees that when the program is executing any given line that any other line will eventually be executed if the program is run forever.  Other than that it just randomly picks statements to execute. 

By the way, the book has been out of print for a while now, so it isn't the easiest to find for cheap and is impossible to find new.  I ordered it three times used from third parties before someone finally actually had it in stock and shipped it to me.

Permalink | Leave a comment  »

One of the guys at the Genome Center mentioned he wanted to get a 7 Languages in 7 Weeks group started in St. Louis to go through the languages.  I thought that was a neat idea, but I also realized it was very simple and may not require a group.

If you look at the list that Tate provides for Tate's book, he lists these languages:

1. Ruby
2. Io
3. Scala
4. Erlang
5. Clojure
6. Haskell
7. Prolog

If you look at SLUUG's St. Louis Event Calendar you find that:

1. Ruby - Meets 2nd Monday of the Month
2. Io
3. Scala
4. Erlang - Is now dead due to lack if interest, but could be resurected (I know since I ran it :) )
5. Clojure - Meets 4th Thursday of the month
6. Haskell - Had its first social, maybe it can take off with meetings soon
7. Prolog

Sadly, we don't have a Scala, Io, or Prolog group that I know.  However, I bet that we could get people to volunteer for such talks in Lambda Lounge.

As an addendum, if STLRUBY didn't want to do a session I'm sure St. Louis Perl Mongers would be willing to shift around their schedule to do a talk on dynamic typing and meta programming.

Permalink | Leave a comment  »

Objective-C - You'd probably like Moose's concept of roles if you like categories.  Roles also provide the ability to require methods exist on classes so you could use them for interfaces too, but when you consume a role you can't guarantee it won't add functionality.

Clojure - If you were willing to play with Perl 6 you'd probably like the many of its lazy aspects.  The common example being binding an infinitely long fib sequence to a list (my @fib := 0,1,*+*...* ).  Perl 6 also supports multi-method dispatching and pattern matching.  I don't know about Clojure's pattern matching abilities, but I do know that Perl 6's is weaker than Erlang's, so be aware of that.

If you don't want to try Perl 6 you should look at the Higher Order Perl book.  It focuses on functional Perl and steals heavily from Lisp.  In fact, the author states very early on that of the 7 things that make Lisp different, Perl has 6.  It is available free online or from a book store.  The author is currently boycotting Amazon though, so while they sell it you may want to buy from someone else. 

Ruby - I haven't gotten around to learning Ruby.  For what it's worth, there are a lot of people I know that like both Ruby and Perl so I have to assume there are some good similarities.  If you are looking for method_missing it is called autoload.  Besides that, Moose::Exporter is great for making keywords for DSLs.  You can use Perl 5's prototypes, but that gets a little more complicated.  You can also use Devel::Declare if you just want to take the parser over altogether which, of course, is gets more complicated.

Feel free to add more in the comments or tell me where I'm wrong, I'll update the body of the post as the conversation goes along.

Permalink | Leave a comment  »

In a little over 12 hours I will be giving my Perl 6 talk at Strange Loop.  I have provided the finalized slides below.  Hopefully in the next week I will have an audio overlay on these slides so you can hear how badly I mess up. :)

Permalink | Leave a comment  »

This week's post is late and a copout.  Instead of actually writing an article I'm posting the slides to the talk I'll be giving this Thursday.  I will be a speaker at Strange Loop 2010 in beautiful St. Louis, MO.  The talk will be about Perl 6 and will be predominantly geared towards people who do not know Perl 5 or Perl 6 but are interested in exploring new languages. My intent is to give people a brief history lesson and then show them enough neat features about the language that they'll want to go pick up more.  More info here.

If you have any comments, criticism or suggestions please don't hesitate to post them.  I would greatly appreciate it.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Perl 6 provides many new and interesting approaches to method invocation.  New constructs in the language allow the developer to define how many matching methods are called, how they are called, as well as a few other things.

In Line Mutators

Perl 6 supports the idea of inline mutators.  In Perl 5 it isn't too uncommon to see code like this:

@array = sort @array

It is common enough in the Perl community to see "assign this mutated value back into the variable it came from" that Perl 6 gives a cleaner way.  The same code in Perl 6 could be written:

@array .= sort

The line above says to take @array, sort it, and put the values back in @array all in one fluid motion.  Of course, there is one motion that developers go through that is so common most probably don't think about it:

my SVG $svg_serializer = SVG.new;

Thankfully, .= can use used here to assign a value into $svg_serializer more cleanly:

my SVG $svg_serializer .= new;

Invoking Multiple Matched Methods

In Perl5 (and other languages) one often finds code litered with statements like this:

$foo->frobinicate() if $foo->can('frobinicate');

That gets old after a while.  Perl 6 solves this, and a few other problems, with a new approach to method calls that allows the developer to request 0 or 1, 1, 1 or more, or any number of methods be called at a time.  So, for example, the Perl6 equivalent of above is:

$foo.?frobinicate;

The above code will invoke the frobinicate method on $foo if one exists.  However, if no method exists that matches that criteria then nothing will be executed and instead of dying the statement simply returns Nil.

As I mentioned there are other options here also, for example if the developer wanted to execute all of the 'frobinicate's that existed within the inheritance hierarchy of $foo they could do either:

$foo.*frobinicate;

$foo.+frobinicate;

As readers can probably guess '.*' will invoke 0 or more methods named 'frobinicate' on $foo returning Nill if none exist.  That leaves '.+' to invoke 1 or more matching methods, the line dies if it finds no matching methods.

Here is an example of the above:

class Dog {

   method talk { 'bark' }

}

class TalkingDog is Dog {

   method talk { 'Hello' }

}

my TalkingDog $td .= new;

$td.talk # returns 'Hello'

$td.?talk # returns 'Hello'

$td.*talk # returns ('Hello', 'bark')

$td.+talk # also returns ('Hello', 'bark')

$td.*calculate_pi # returns Nil

$td.+calculate_pi # dies

$td.?calculate_pi # returns Nil

$td.calculate_pi # dies

Parallel Invokation

Perl 6 has an incredibly exciting new operator called the hyperoperator.  The hyperoperator indicates that the methods being invoked can be dispatched in parallel.  This makes simple cases of parallel execution very simple to do.  To do this, simply prepend '>>' between the object and the invocation operator.  For example:

@foo>>.frobinicate

This would invoke 'frobinicate' on all the elements in @foo in parallel.  

The hyperoperator can be combined with the previous topic of invoking all the methods that match.  This makes it very simple to invoke all of the possible methods on an object in parallel:

$foo>>.*frobinicate()

Here is a simple, but more fleshed out example to wrap things up:

class Department {

   has @.employees;

   has $.name;

   method gen_print_info { return "$.name:\n" ~"\t\t" ~ @.employees.sort.join(', ')}

}

my @company = (

   Department.new( name => 'Accounting', 'employees' => <Jeff Jane Susan>),

   Department.new( name => 'Security', employees => <Alice Bob>),

   Department.new( name => 'Marketing', employees => <Margaret Terry Lawrence>),

   Department.new( name => 'Development', employees => <Matt Fred Steve Joe Alith Jie>)

)

my @print_info = @company>>.gen_print_info;

The example above would execute gen_print_info on all of the Department typed objects in @company.

Further Reading

• Synopsis 12 - Objects
• Patrick Michaud's Cool Perl 6 has some neat examples 

Permalink | Leave a comment  »

Hey readers,

Have you looked at The Lacuna Expanse?  I'm afraid I just burned an hour of time playing it instead of doing other things.  It's a pretty neat MMO that combines strategy and SimCity in a fun game with a galactic theme.  I was surprised to see how well it is put together for being web based.  I'd really recommend checking it out.

If you aren't interested in the game then you might be interested in the tech behind it. The whole thing is written in Perl and uses a lot of fun tech.  Here is a slide deck.

Permalink | Leave a comment  »

I had a request that I not use gist.github to host the code snippets.  I guess it was a trouble for people who turned off JavaScript.  Since github does not currently support Perl 6 syntax highlighting I will inline my code snippets.  However, when github supports Perl 6 syntax highlighting I will probably go back to hosting on there.  If you have an opinion on this please let me know via email, the comments, or buying me a beer and saying what you think.

Permalink | Leave a comment  »

This entry will focus on creating and using classes in Perl 6.  Perl 6's class system greatly expands on the approach of Perl 5 in many ways, a few of which are giving a standard new method and providing an approach for easily declaring attributes on a class.

Here is a very simple example of a Perl 6 class:

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

class Animal
{
   has Str $.name;

   method eat( $food )
   {
       say "$.name is eating some $food";
   }

   method sleep($self:)
   {
       say $self.name ~ ' is sleeping.';
   }
}

This example shows a few basic concepts.  First there is the new class keyword.  Named classes can easily be declared in one of two ways.  The example above, with curly braces, is useful when defining more than one class in a file or providing for some code to execute outside of the scope of the class when loading.  Without the curly braces is also legal, however it means that the rest of the file is the class definition.

Additionally, this shows our first attribute, name.  The name attribute is defined as being of type Str.  The twigil '.' in this case indicates that this attribute should have a public accessor.  In this case that accessor is read-only because we did not define it otherwise (see below).

The eat and sleep method were also defined.  The sleep method uses the name attribute on the class in the string that it says.  It can do this without using $self because $. implies the object the method was invoked on.  So, the eat method could have also been rewritten like it is for the sleep method.

Instantiating new objects of type Animal and using their methods is simple:

1
2
3
4

my $dog = Animal.new( name => 'Leela' );
$dog.eat('dog food');
$dog.sleep();

A more complicated example is below.  In this one two more classes, 'Dog' and 'Tail', have been defined:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class Tail
{
    method wag()
    {
        say "swish, swish, swish";
    }
}

class Dog is Animal
{
   has Str $.tag is rw;
   has Tail $!tail handles 'wag' = Tail.new();

   method bark()
   {
       say "woof, woof!";
   }
}

The Dog class has a couple new interesting additions.  The first thing to notice is that Dog inherits from Animal via the is keyword on the first line.  The tag attribute is defined as 'rw'.  This means that public accessors for both acquiring and mutating the value of the tag are provided.  The tail attribute has a '!' as a twigil.  This twigil indicates that no public accessors should be defined.  However, an instance of the Dog class delegates to the tail attribute when the wag method is invoked upon it.  This means that when someone calls $a_dog.wag they are really calling wag on $a_dog's $!tail.  Delegation is a very handy way to improve code reuse, Perl 5 developers who use Møøse should be familiar with it.  Finally the tail also has a default value of a new Tail object.

This new class can be easily used like the following example:

1
2
3
4
5
6
7
8
9

$leela.eat('dog food');
$leela.bark();
$leela.eat('grass');

my $old_tag = $leela.tag();
$leela.tag = 'Leela Follett';
$leela.wag();
say $leela.name ~ '\'s tag said ' ~ $old_tag ~ ', now it says ' ~ $leela.tag;

However, what if we didn't want to use the simple Tail class for our dog's tail.  We could pass in an object of another class that had a wag method on it like so:

1
2
3
4
5
6
7
8
9
10

class ClumsyTail is Tail
{
    method wag()
    {
        say "knocked over a vase.";
    }
}

my $jewel = Dog.new( name => 'Jewel', tail => ClumsyTail.new() );
$jewel.wag();

That pretty much wraps up this entry on Perl 6's class system.  The system includes many more powerful features that should be covered at a later date.

Further Reading:

• Synopsis 12: Objects
• Moose
• Using Perl 6

Permalink | Leave a comment  »

This week we'll be covering the process of partially applying parameters to a subroutine, this is based off of closures which we covered last week.  This allows us to create new subroutines that we can pass around that already have some of their parameters defined.  One of the benefits of this is that we don't have to pass around a parameter list and wait until all the parameters are ready, instead we can apply each parameter as we get it and then execute the subroutine at some later time when we are ready.  Doing this in Perl is actually very simple.

The function above provides us the ability to curry other functions.  Analyzing it shows that all we are doing is creating a new anonymous function that is going to call the function we passed in with the parameters we passed in and the parameters it receives.  Let's see an example of how this would work.

So, let's look at how it all worked.  First, we made a new anonymous function that takes a list of parameters, joins them, and prints them.  Next we curried that list with 3 fruit.  To do this we created a new anonymous subroutine that passed in the three fruit into the first anonymous subroutine.  After that we repeated the process, by currying the new subroutine we created from the last curried we now have a subroutine that calls the subroutine created on line 3 with 2 new fruit, that subroutine calls the subroutine created on line 1.  Once we execute this we will output a list of all the fruit we've given to the function.

We don't have to only curry anonymous functions.  Because we can get the reference of named functions and builtins we can also curry those.

This concludes this week's lesson.  Next week we will move past the building blocks of functional programming and start getting into systems built on top of this functional foundation.  Next week we'll cover dynamic dispatch tables.

As an aside, the name curry didn't come from the tasty South Asian type of dish, unlike the naming of Mix-Ins.  Instead, currying is named after the American Mathematician and Logician Haskell Curry.

Permalink | Leave a comment  »

I will probably be cutting back to one larger article a week.  The articles will probably either focus on Perl 6 or functional programming, I doubt I will continue the Moose series during this time.  Moose is great, but the documentation is so approachable I doubt I can really add much to it, at least not until I read The Art of the Metaobject Protocol .

It is awfully early to be doing so but I'm doubling my course load for my masters, while holding a full time job, fixing up my house, and preparing my talk at Strange Loop 2010.  Sorry for anyone who enjoyed the current frequency.

Permalink | Leave a comment  »

One of the popular concepts in functional programming is the concept of lazy evaluation.  For code to be lazily evaluated it means that instead of being evaluated at the point when the system reaches it it is instead evaluated at the point that the results are needed.  The concept of lazy evaluation exists in lots of languages; Perl 6 uses them for lists, as does Python, and languages like Haskell, Clojure, and others use them quite frequently.  In fact, at the latest Clojure Cljub meeting one developer was complaining that Clojure was so lazy it was hard for him to tell when it was doing nothing at all.

The benefits of having the ability to lazily evaluate code show up in many cases.  Lazy evaluation can allow developers to represent "infinite streams" because the only portion of the stream that is computed is the portion that the program needs to perform its task.  Without lazy evaluation the program would try and compute all possible values and never complete.  Additionally, things like Moose use this concept to allow a developer to lazily evaluate attribute construction.  This is hugely beneficial because it means that attributes that take a long time to construct will only be constructed when they are needed, instead of on the main object's construction.  DBIx::Class also uses this, the query to the database doesn't happen when 'search' is called on the DBIx::Class object.  Instead, it is called when the first piece of data is retrieved.  This allows DBIx::Class to wait and collect as much information about what the query really needs to be before it executes it, saving precious database time by not making wasteful queries.  A final example would be Object::Trampoline, which can delay the construction of an object and the loading of modules.

So, how do we lazily evaluate code in Perl 5?  We simply wrap it in a subroutine.  Let's say, for example, we wanted to make a stream that generated the set of all natural numbers (N), which is simply all the integers ≥ 0.  We would simply write something like this:

1
2
3
4
5
6

my $stream;

{
    my $previous = 0;
    $stream = sub { $previous++ };
}

Now, each time we want a new natural number we can call the anonymous subroutine and a new one will be generated.  We could then use this in a while loop:

1
2
3
4
5

while( defined (my $val = $stream->() ) )
{
    say "We've reached number $val!";
}

Another benefit of this approach is that we can now provide streams of numbers logically separated from the looping method (which is a common benefit of iterators).  So, for example, we could use these two streams with the same while loop:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

my $stream;
{
    my $previous = 0;
    $stream = sub { $previous++ };
}

my $limited_stream;
{
    my $previous = 0;
    $limited_stream = sub { return $previous if $previous++ < 10; return; };
}

my $limited_even_stream;
{
    my $previous = 0;
    $limited_even_stream = sub { return $previous if(($previous+=2) <= 10); return; };
}

sub say_numbers_in_stream 
{
    my $stream = shift;
    while( defined (my $val = $stream->() ) )
    {
        say "We've reached number $val!";
    }
}

say_numbers_in_stream($limited_stream);
say_numbers_in_stream($limited_even_stream);

Obviously, we could do considerably more interesting things than this.  MJD's Higher Order Perl talks about creating lazy linked lists in chapter 6.2.

Permalink | Leave a comment  »

***Update: Carl Mäsak (@carlmasak) corrected some misunderstandings I had regarding the scoping of subroutines and the use of export.***

When I first announced the Functional Perl series on the STL-PM Bill Odom asked if I would be including Perl 6.  I declined at the time stating that there were sufficient difference between Perl 6 and Perl 5 to make the articles too busy.  There aren't a huge amount of differences, but I didn't want to clutter a Perl 5 article with things like method.assuming( x=> 11) or leave it out of a Perl 6 article.  This article isn't an article about functional programming, but it is a talk about functions in Perl 6 so that I can later do functional articles.

Named Functions

Perl 6 sports an incredible amount of power and flexibility without losing a bit of the flexibility one can find in Perl 5.  In fact, one could write a Perl 6 subroutine that looked like this:

1
2
3
4
5
6

   sub compound_interest
   {
       my ($present_value, $iterations, $rate) = @_; 
       return $present_value * ( 1 + $iterations ) ** $rate;
   }

Or like this, which gives us type checking:

1
2
3
4
5

sub compound_interest( Real $present_value, Real $iterations, Real $rate)
{
   return $present_value * ( 1 + $iterations ) ** $rate;
}

But constraint checking can even move beyond basic type checking.  Perl 6 can can provide further constraint checking with a where clause on a parameter:

1
2
3
4
5

sub compound_interest( Real $present_value, Real $iterations, Real $rate where ( * > 1))
{
    return $present_value * ( 1 + $iterations ) ** $rate;
}

This version only allows us to give interest rates that will increase the future value.  

Perl 6 also allows for functions to be able to declare through traits:

• if they are safe to automatically cache
• the precedence (if it is for an operator)
• tons of other stuff

Additionally, explicitly stating all the implicit traits on a method can make it very verbose, like AppleScript verbose.

Anonymous Functions

The Perl 5 way of creating anonymous functions is still valid in Perl6.  However, you now use the method invocation operator ('.') instead of the '->' available in Perl 5.  You can actually skip the method invocation operator since it can be implicit in this case.  So, for example, you can make and use an anonymous subroutine like this:

1
2
3
4

my $sub = sub { return 11; };

$sub.() # returns 11
$sub()  # also returns 11

Perl 6 also provides for a lot of new approaches towards creating and using anonymous functions.  In fact, according to Synopsis 4, every block is a closure.  so, for example, you can now write an anonymous function simply by doing this:

1

my $sub = { return 'hello world' }

If you wish to include a parameter list you can do so with a slightly modified version of that called the "pointy block":

1
2

my $to_the_power_of = -> $x, $y { return $x ** $y}
$to_the_power_of(2,3)

Additionally, If you read my post on Perl 6's Whatever then you already know that you can use Whatever in a statement to close over that statement and create a function to evaluate it later.

A Bump in the Road: Scope

The move isn't completely roses for function happy developers though, there is one little hiccup you might encounter.  This code, which uses a hash as a cache that's closed over in the subroutine will be a little different than the Perl 5 version:

1
2
3
4
5
6
7
8
9
10
11

{
   my %cache = {};
   sub long_running_thing { # imagine your own long running method here
      my $x = shift;
      return $cache{$x} if( exists $cache{$x} );
      my $result; 
      # do some long running thing, generate result
      return $result;
   }
}
say long_running_thing(42);

That is because subroutines are now also scoped and are implicitly given the same scope as provided by 'my'.  This is a simple matter though, we simply give the subroutine the 'our' scope.  Here is the equivalent example in Perl 6:

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

{
    my %cache = {};

    our sub long_running_thing( $x ) is export
    {    # imagine your own long running method here
        return %cache{$x} if ( %cache.exists($x) );
        my $result;

        # do some long running thing, generate result
        %cache{$x} = $result;
        return $result;
    }
}

A Tangent: Control Structures

This is a bit of a tangent, but I find it interesting.  Do you remember when I said that any block is a closure?  That counts for things you probably didn't consider, things like the blocks on if, while, and for statements.  These are all now closures too.  In fact, Perl 6 allows us to iterate over lists n-at-a-time because of this.  The for loop will now pass us as many values as we provide as parameters in our block. Here is an example:

1
2
3
4
5
6
7

my @list = 1..100;
for @list -> $left, $center, $right
{
    say "$left - $center - $right";
}
~/Documents/Projects/rakudo

Of course, this example will complain when we reach 100, so we can do this:

1
2
3
4
5
6
7

my @list = 1..100;
for @list -> $left, $center?, $right?
{
    say "$left - $center - $right";
}

The above example allows us to pass in 1-3 parameters, as many as are available.  In this case though Mu is assigned to values that aren't passed in, which stringifies to "Mu()".  We probably don't want that, so we'll just use defaults:

1
2
3
4
5
6

my @list = 1..100;
for @list -> $left, $center = '', $right = ''
{
    say "$left - $center - $right";
}

Summary

Perl 6 gives functions, named or otherwise, a wide variety of new syntactic features.  It also really promotes the role of closures and anonymous functions, which is a welcome addition.  Perl 6 is also bakes in new features, like memoization and currying.

Given all of that, I hope people understand why I'll be trying to keep Perl 5 and Perl 6 articles apart.

Further Reading

• Perl 5 to Perl 6 - Lesson 28 Currying
• Tyler Curtis - Age Discrimination in Perl 6 using Subsets and Multiple Dispatch - talk on multimethod dispatching
• Exegesis 6 - Subroutines
• Synopsis 6
• Synopsis 4
• Perl 6 - Whatever

Permalink | Leave a comment  »