Extension syntax for Boo

I was thinking about the proposals for expanded extensions for Boo -- I would rather call them mixins, since this is what they seem like in my mind, with their syntactic sugar. Its also easier to type mixin.

I've been thinking about properties and mixins. Take the following example, with my completely made-up syntax.

mixin System.String:
Words as (string):
return self.Split(' ', ';', '.', '!') #Doesn't work, no implict conversion to char

As far as code goes, its pretty simple. Infact, this could easily be a method.

def Words(target as string):
return self.Split(' ', ';', '.', '!')

Then you, know, Words("Hello, world!") is just as effective as "Hello, world!".Words.

But sometimes, being able to do something one way doesn't necessarily mean its better than doing it another way. This kind of syntax blends very well with the way of the OOP, and allows for a better visual recognition of what object is being manipulated.

The flip side is, of course, "Is Words part of System.String, or an extension?"

My answer is, "Does it matter?" Do you really need to know wheither its an external function or an instance function? Well, that would be my answer in an ideal system, where extensions showed up when you used reflection on a type. Right now, they don't, though, so knowing the difference between an extension and instance members is important if you plan on doing reflection-based operations on a type at runtime - you'll have to root around in some namespaces for those extensions rather than just checking the members of a type.

Hey, you!

Rodrigo B de Oliveira, why the hell are you syndicated by Monologue?! You post like once a month, you lazy bastard. ;)

Thanks, Blogger.

Thanks for saying, "Hey, you can't post this because it has unclosed HTML tags!" to my face but secretly going behind my back and posting the entry anyway, generating at least 10 half-assed blogposts because I think none of my posts are showing up on my blog: people tend to assume that when you tell them, anyway.

Ugh. I think I should get a new blog somewhere else. That's ridiculiously pathetic.

Attack of the WinFX December CTP!

http://blogs.msdn.com/tomarcher/archive/2005/12/19/505502.aspx

The WinFX December CTP has been dropped to the public at large. The one big change I'm sure everyone has noticed by now is that, aside from a few minor tweaks, the "mini language" of XAML has been removed entirely. Bits and chunks have been removed piece by piece, but the December CTP finally sees the removal of the last straggling hold-outs.

If you're not sure what I'm talking about, here's a snippet from Chris Sells' blog:

Or, rather, you would be seeing a snippet, if Blogger's posting control what's it didn't suck an incredible amount of ass. Infact, I just had to copy and paste the text here to note-pad and back, because Blogger's state of the art RTF control forgot to close a tag. Thanks, bitch. Anyway:

http://www.sellsbrothers.com/writing/avbook/changenotes/Wpf09-05CtpTo11-05CtpChangeNotes.htm

Its under the general section.

Anyway, thank God.

By making the format more rigid in terms of syntax it means that XAML won't become the kind of mess the SVG spec turned out to be; and as someone who once wrote a SVG-to-VG transformer, I know exactly the kind of pains in that spec. Taking the "convenience" out of the spec means that there's no ambiguity or multiple ways to parse one attribute.

These file formats aren't meant to be written by hand, damn it. Tweaked? Sure. WRITTEN? No. Its harder to automate this junk when there are seven different *valid* ways to write something. The easier it is to programmatically consume XAML the more tools will crop up that can read/write XAML and modify it.

No, sorry, VIM is not a good example of a tool. I mean *REAL* tools, like Sparkle, Cider, #develop.

Wikipedia founder 'shot by friend of Siegenthaler' | The Register

Andrew Orlowski apparently spent several hours on Wikipedia today trying to track down something to make Wikipedia look bad. Took him awhile, but he finally found something in the revision log: vandalism claiming that the Wikipedia founder was murdered by a friend. Like all incredibly bad journalists, he cropped out of the revert time, so even though the vandalism was corrected within minutes, he decided to "only" take a screenshot of the edits, rather than the edit times.

Ahh, quality journalism from The Register strikes again. Tell me why I shouldn't trust Wikipedia more than those guys, again?

Read more at www.theregister.com/200...

Nemerle, a hybrid functional / OO langauge for .NET

With my itchy, twitchy fingers, I have been checking out other languages that run on top of the .NET platform. Nemerle is one I checked out over the weekend. The language has a lot of features - a nuclear silo's worth. A powerful matching construct, a readable syntax (compared to any other functional language I've seen), and generic support. Mmm, generics. Those who know me all too well know I yearn for generics in Boo, and the lack of support causes me to stray and check out other languages from time to time.

For the sake of brevity, I'll model this blog post after the things I don't like about the language, and modifications I would make. There are too many things about the language I really like, so starting off like that would really eat up some time.

To get one thing straight, I'll pop up this disclaimer: I know nothing about functional programming. At all. I just tend to drill into a language, ignoring the design methodologies that went into and whatever. So, make no mistake: I have no idea what I'm talking about.

Things I would change:

• The match construct throws an exception if there is an unmatched item. This is suprisingly useful in theory; in practice however the exception provides so little detail that its barely worth it. It should at least spit out what the match variable was. C'mon man, gimme a hint or something, Christ.
• The match construct syntax. The match construct is powerful - it is easily the sweetest thing I've laid eyes on. But the syntax is the ugliest I've ever seen. Personally, I would just totally rip Boo's "given when" syntax and call it "match when" and whistle innocently. The problem with the match syntax is that its completely foreign to everything else in the language for no apparent reason. I cannot think of one reason for the syntax to be laid out in such a hard to type (finger acrobatics, maximum!) and hard to stare at manner. It looks like a twitchy, "shit, let's just do what the old guys did" implementation. I'd 21st century-ize that sucka.
  
• Explicit return statements. Recently, a pattern I've developed is using return statements to avoid processing the rest of a method without having to drop an exception. This is extremely handy for methods that can return null, or a default object. This seems thoroughly impossible with Nemerle, unless you're willing to use the match construct at the very beginning of a method. This of course means two or three relatively small match bodies, and then one huge match body for the "rest" of the method. I like implict returns, but I wanna be able to be explicit, too.
  
• N10005. The reason Nemerle sample code is littered with ignore() functions. The reason sample code scrolls an entire screen of N10005's because nobody wanted to type ignore() everywhere. Man, that might be cool or hip when you're running on a framework where every return value is important, but some of the time all it this return data is, is extracellnous information that we don't need. I don't really wanna type ignore(). I'm sorry. I don't. I'm lazy.
• Fuse braces and indentation. Boo/Python really turned me on to indentation based syntax. Hell, I was going to indent anyway. I would fuse'em in Nemerle: start a block with a brace, end a block with a brace. Otherwise, use indentation for syntax. There we go. Kung-fu with both syntaxes, now. Nemerle offers an -i switch, but that's almost as good as not offering indentation-based syntax at all.

Yep, that's about it, doc. Otherwise, its a really swell language that doesn't have decent IDE support. They've got a Corsavy addin, but it takes too much effort to get working: why they bundled a .sh script with it I'll never know. Copying the relatively simple instructions from the shell script do no good, since something in the plugin or the architecture of #develop 2.0 have changed, so you have to do some kind of wobbly dance to make the addin work. I can't remember what I did the first time to make it work.

Anyway, that's it. There. I posted a blog entry. Now, don't expect another one for awhile.