Couple of things which you probably jumped across by now but just in case for other passers by here…

1. Packages. Something I’ve fallen over before was this….

use strict;
use warnings;

package A;
our $X = 'X create while in Package A';
my $x = "lexical x";

package B;
say "In package B...", $X;
say "In package B...", $x;

Package B will happily print whats in $X & $x without giving an error ;-(

Instead you need to put packages into separate files or enclose a block around them….

{
    package A;
    our $X = 'X create while in Package A';
    my $x = "lexical x";
}

{
    package B;
    say "In package B...", $X;
    say "In package B...", $x;
}

Now above will throw a compile error on both those say lines in Package B.

2. Easy way to return hash or array references from sub….

sub return_hashref {
    return { hello => 'Hello' };
}

sub return_arrayref {
    return [ 'zero', 'one', 'two' ];
}

# thus your Moose has statement can be a bit sweeter....

has 'Rows' => (isa => 'HashRef', is => 'rw', default => sub { {} } );
has 'Columns' => (isa => 'ArrayRef[Str]', is => 'rw', default => sub { [] } );

Learning Perl is fun eh!

/I3az/

Check out this article by Jeff Moser for inspiration. He uses his port of OMeta (OMeta#) to write a small language in which to implement FizzBuzz. Really neat! Instead of writing a program in Java, C#, Ruby, etc. that directly implements FizzBuzz (which is like, DUH! EASY!), he wrote his own mini-language to provide the structures he needed in order to write FizzBuzz. He first shows the implementation of FizzBuzz in the language he wrote. Then he shows the complete source code, in OMeta#, for the language.

Yeah… it’s definitely time to (a) start reading more code and (b) start learning about parsing and grammers.

There’s a big difference between code written to get something done and code written to explore an idea. The code above is more of the former than the latter right now.

I think what I want… sort of like how sed is a command-line driven text editor… I want a script driven subtitute for spreadsheets and desktop databases…. I’m going to need to write a BASIC-like mini-language for writing simple functions and operating on the environment….

I tried playing with some source filtering, but it was an absolute pain to implement. Extending the dispatch tables is pretty easy in comparison even though it might be less efficient.

That reminds me of something I want to go figure out real quick….

As for Alan Kay, something he’s railed about for years is how there’s barely a literary culture in the computer field. There’s no sense of history. We keep reinventing the wheel, because “we don’t read”, he says. One example he cited was that Rand had figured out in the late 1960s how to do handwriting recognition really well, but no one’s bothered to read how they did it, and instead industry has produced crappy handwriting recognition systems.

I’ve been reading your last few posts on the Perl stuff you’re working on, as much as I can without knowing much about Perl. In terms of what you’re working on you’re ahead of me. I have yet to develop a good sense of system architecture. I’ve mostly been building a philosophical basis for ultimately getting into this stuff.

I’ll just say that your dispatch table looks a lot like code I’ve seen from a language that’s being developed at Viewpoints Research Institute, Alan Kay’s organization, called OMeta. It’s a pattern language that uses PEGs (Parsing Expression Grammars), memoization, and objects. It looks a bit like BNF, but it doesn’t act like older LR parsers. Instead it tries to find the closest match in subsets of rules. Whichever subset is closer, it goes through that subset, and then goes through it sequentially to find a match. If it finds a match, it executes the corresponding action block. It handles left-recursion just fine via. memoization, making grammars simpler to write. You can check out OMeta at http://www.cs.ucla.edu/~awarth/ometa/. You can run it right inside your browser (the current version only works on Firefox, and I think Safari) since the primary version is written in Javascript. I think there’s a PDF link there that shows documentation on a different implementation they worked on. This gives you an idea of the concepts being used anyway.

Other people are working on ports. Jeff Moser is working on making a version that runs in .Net 3.0. He’s been writing about it on his blog (the link I cite).

You can write multiple languages in OMeta and bring in parts of them for whatever you’re working on, however you choose. One of the goals they have with the project is being able to write code in a way that’s more self-explanatory. Jeff Moser has written a couple posts that illustrate this idea.

One thought I had on your program overall, though it may be totally uninformed, is why not have the goals drive the program? This is thinking in more of a functional, perhaps Prolog-ish style. Rather than taking the data and saying “if (blah) then”, what I was thinking was along the lines of “(enlistedp (blah))”, where the predicate drives functionality that seeks structures that will match its conditions, and either succeeds or fails. If it does, then the next predicate is tried.

first, right click on the title bar of a cmd window and select ‘properties’. then select the ‘options’ tab and enable QuickEdit mode.

now you can highlight the text that you want copied with your mouse. right click to copy the active mark to the clipboard.

if there is no active mark in a cmd window, a right click will paste into the cmd window from the clipboard.