PDF::Declarative

Man, I started PDF::Declarative two days ago, and nearly have something that can do the PDFs I want. Turns out text layout is hard - who knew? But building declarative wrappers for new domains is relatively easy, given good example code.

So I'm really quite happy about the declarative framework; it's making me a faster, better, more productive programmer, and that's all I really need it to do.

An interesting semantic domain at some point would be the generation of new semantic domains... Speeding up the process of speeding up the process should, um, speed up the process.

Dialogs, fields, and magic variables

So I've obviously been spending too much time with this, but I added magic variables to Class::Declarative today, and used them for text controls in Wx.

A magic variable is one for which a handler is registered with the context. When we read or write that variable in the context, our handler is called. That means that code can get or write field contents just by referring to the field as the variable it's tied to - and you tie a field to a variable just by naming it.

So the wxPerl dialogs.pl sample is this code:

#!/usr/bin/perl
#############################################################################
## Name:        samples/dialog/dialog.pl
## Purpose:     Dialog wxPerl sample
## Author:      Mattia Barbon
## Modified by:
## Created:     12/11/2000
## RCS-ID:      $Id: dialog.pl,v 1.4 2004/10/19 20:28:13 mbarbon Exp $
## Copyright:   (c) 2000 Mattia Barbon
## Licence:     This program is free software; you can redistribute it and/or
##              modify it under the same terms as Perl itself
#############################################################################

use Wx;

package MyApp;

use strict;
use vars qw(@ISA);

@ISA=qw(Wx::App);

use Wx qw(wxDefaultSize wxDefaultPosition);

sub OnInit {
  my( $this ) = @_;

  my( $dialog ) = MyDialog->new( "wxPerl dialog sample",
                                 wxDefaultPosition,
                               );

  $this->SetTopWindow( $dialog );

  $dialog->Show( 1 );

  1;
}

package MyDialog;

use strict;
use vars qw(@ISA);

@ISA=qw(Wx::Dialog);

use Wx::Event qw(EVT_CLOSE EVT_BUTTON);
use Wx qw(wxDefaultSize wxDefaultValidator);

sub new {
  my( $class ) = shift;
  my( $this ) = $class->SUPER::new( undef, -1, $_[0], $_[1], [250, 110] );

  # $this->SetIcon( Wx::GetWxPerlIcon() );

  my( $ct ) = $this->{CELSIUS} =
    Wx::TextCtrl->new( $this, -1, '0', [20, 20], [100, -1] );
  my( $cb ) = Wx::Button->new( $this, -1, 'Celsius', [130, 20] );
  my( $ft ) = $this->{FAHRENHEIT} = 
    Wx::TextCtrl->new( $this, -1, '32', [20, 50], [100, -1] );
  my( $fb ) = Wx::Button->new( $this, -1, 'Fahrenheit', [130, 50] );

  EVT_BUTTON( $this, $cb, \&CelsiusToFahrenheit );
  EVT_BUTTON( $this, $fb, \&FahrenheitToCelsius );

  EVT_CLOSE( $this, \&OnClose );

  $this;
}

sub CelsiusToFahrenheit {
  my( $this, $event ) = @_;

  $this->{FAHRENHEIT}->SetValue( ( $this->{CELSIUS}->GetValue() / 
                                   100.0 ) * 180 + 32 );
}

sub FahrenheitToCelsius {
  my( $this, $event ) = @_;

  $this->{CELSIUS}->SetValue( ( ( $this->{FAHRENHEIT}->GetValue()-32 ) / 
                                180.0 ) * 100 );
}

sub OnClose {
  my( $this, $event ) = @_;

  $this->Destroy();
}

package main;

my( $app ) = MyApp->new();

$app->MainLoop();

# Local variables: #
# mode: cperl #
# End: #

In the Wx::Declarative framework, that becomes this:

use Class::Declarative qw(Wx::Declarative);

dialog (xsize=250, ysize=110) "Wx::Declarative dialog sample"
   field celsius (size=100, x=20, y=20) "0"
   button celsius (x=130, y=20) "Celsius" { $^fahrenheit = ($^celsius / 100.0) * 180 + 32; }
   field fahrenheit (size=100, x=20, y=50) "32"
   button fahrenheit (x=130, y=50) "Fahrenheit" { $^celsius = (($^fahrenheit - 32) / 180.0) * 100; }

And it works, as of right now.

Wx::Declarative back where I was

Well, I've successfully factored the Class::Declarative out of Wx::DefinedUI (which is dead, long may it live) and I'm back to having all the stuff work that I had working last week. (!)

Going forward should be way easier now, and the hard stuff is factored out and unit tested so I can't break it as easily, but I feel oddly as though nothing had happened for a week. Except, of course, Class::Declarative is on CPAN now, which is very cool indeed.

So this is what works: code/closures, events (those are the core semantics), buttons, menus, message boxes (hardcoded text only), frames, sizers, dialogs. Next up is the status bar. Then I set out into serious wilderness by subclassing a window for the frame's client. Yikes!

Some thoughts circling back to semantic programming now

OK. So this declarative style of programming can be seen as the systematic laying out of the semantic structure of the program at the same time we are building the code. I'm a little worried that this structure is still very thin (that is, the extremely complex ramifications of meaning that come along with human understanding of a program are missing in this structure), but it's still a beginning.

Let's consider this: we could see the Class::Declarative structure as a sort of prototype. But knowing sufficient amounts of semantics for any given class, we could take a working structure and "compile" it into a pure-Perl structure that doesn't depend on Class::Declarative at all. In fact, we could compile it into any language for which we knew how to express the semantics of the structure.

This is important. This is what we will end up doing much, much farther down the road.

As a more proximate goal, this is what I was fumbling towards in January. I read January's posts and they seem sort of naive. I think that bodes well.

Let's posit a set of semantics that talks about databases, PHP code, Web pages, and AJAX. That's what sproggler is talking about. This declarative-plus-semantic framework would be the backbone of that system, and it could express itself using templates of some kind.

These templates are symbolic units. Remember symbolic units? They connect semantic units (the nodes in a Class::Declarative structure) with syntactic units (the pieces of code we compile), and they are mediated by templates of varying degrees of abstraction. So at some point in the very near future, we're going to want to think hard about them.

Parse::Indented on CPAN

Bit by bit, I'm establishing a useful toolset here.

I've been spending too much time today in organizing the unit tests for Class::Declarative. Test-driving programming has a higher initial threshold, but once you get the framework all set up, it really starts to take shape.

Anyway, Class::Declarative is parsing properly now; you'd think this would already work, but I spent some time generalizing the semantic framework to make it easy to build new semantic domains. I think this is really going to pay off in the medium term.

Class::Declarative

I'm splitting the declarative-programming part out of Wx::DefinedUI. There are just so many areas I can think of where the declarative paradigm will be so useful!

Data declaration (tables and so forth). Testing! Other messaging frameworks like POE or Moose. And, yeah, semantic programming.

I've literally been thinking about this in one form or another for over twenty years. This is the first time I can see an actual way to get it implemented, dammit, so I can use it.

Anyway, refactoring the code is cleaning it up a lot. I always get the feeling if I just refactored enough everything would be a one-liner.

Closures in Perl

So I've been getting deeper into Perl lately. I wrote a little IRC bot class (Bot::NotSoBasicBot) and during the course of that, found myself writing an event queue that took anonymous subroutines to be run at a scheduled time. Only after doing that did I realize that anonymous subroutines in Perl are closures.

That was something of an epiphany. I took a Scheme class from Dybvig, sure. So I had been exposed to the concept of closures. But not until now did I really comprehend them or really realize what they're for.

Now I'm realizing that Perl is a much, much more powerful language than I ever gave it credit for. As I get deeper into Wx::DefinedUI, I'm pushing my own envelope, building code generators and all kinds of things. I feel as though this programming hiatus of the past few years really allowed me to approach the topic with a fresh eye.

Wx::DefinedUI

For quite some time (like, years) I've toyed with the possibility of defining GUIs under wxWidgets (in Perl, Wx, or in Python, wxPython) by using a sort of pseudocode decorated with actual code to execute the meat of the program. This year, the Muse has accepted my application, and I've started on Wx::DefinedUI in Perl.

To do this, I first managed to get past the hump that's always stopped me in the past: syntax. Bear with me, this is important.

See, whenever I start brainstorming about a new way to reorganize programming, I first scratch out a bunch of data structures in pseudocode, then I realize it's hard to implement that stuff. Then I run aground. For I while I thought XML would help, but no, XML is also too hard to type. This is what killed MagnifiCat, it's what killed the semantic programming of last year (earlier posts on this blog), and it's what killed the Web programming framework I started over the holidays.

But early this year, I got back to Wx. And I looked at the structure of one of the demo programs, and it looks like this:

use Wx::DefinedUI qw(-filter);

dialog (resize) "Wx::BoxSizer"
size (box, v):
  size (box, h) [1, GROW]:
     button (id=OK) [0, ALL, 10] "Close window"
     button [0, 0] "Button 2"
     button [0, TOP BOTTOM, 5] "Button 3"
  space [10, 10, 0, GROW]
  size (box, h) [1, GROW]:
     button [1, ALL, 5] "Button 1"
     space [1, 30, 1, 0, 0]
     button [1, GROW ALL, 5] "Button 2"
     size (static, v) [2, GROW] "Wx::StaticBoxSizer":
        button [1, GROW ALL, 5] "Button 3"
        button [1, GROW ALL, 5] "Button 4"

That's it. Granted, that code doesn't do anything, it just demonstrates the use of box sizers, but there are two points I want to make about it.

First, it provides a detailed, extremely readable, and yet still parseable, overview of the application. If we provided IDs for all those buttons and wrote code to be called on click, we'd have a real application, and one that we could understand with no further ado.

Second - and this is important - as of yesterday, it works. I decided to go ahead and tackle the parsing problem. I looked up Parse::RecDescent and found it good - but then I went ahead and polished up my old XML::xmlapi as a structure manipulation module I can work quickly with, and wrote Parse::RecDescent::Simple to allow parsing of each of those lines. That stuff's already on CPAN, because it's working and stable to the point I need right now.

For parsing of the indentation, I've written part of Parse::Indented. It's not on CPAN yet, because I still want to add a feature allowing embedding of Perl code into my tree. Maybe tomorrow.

The crucial point here is this: I have a parsing framework that lets me use pseudocode to define things, things that will then run. Next step: use that very parsing framework to get back to the Web application framework and semantic programming. It should be easy!

Here's another point, by the bye: publishing early and often keeps the momentum going. I've published five modules to CPAN in the last week. It's heady stuff.

Only a matter of seeing simple data structures and designing lightweight tools that can cross the galaxy

Remember Markov chains? I should get back into that; they're awfully good for sparking creativity.

The structure of a project

You know, just having "sproggler" as a concept is focusing my thoughts. You could easily envision a Web application prototyping platform there. So ... what information would there be for any given project?

• Data schema
• Brief mission statement
• Requirements document
• Specification
• List of infrastructural components
• Basic system description
• Use cases
• Templates
• Style sheets

Each of these would be represented in an organized, standard fashion. With time I suppose you could even have a choice of methodology or something. Heh. This could be really cool.

Some links

Some things I'm finding useful:

Template Toolkit in Perl

Perl's Parse::RecDescent - actually, I'm surprised how long I lived without this one.

A little article along the way about judging C/C++ comments for readability using Parse::RecDescent and Lingua::EN::Fathom.

Then I found a bunch of stuff about PHP's session variable and how to implement login systems in PHP, some using Ajax.

I registered the domain "sproggler.com", for some nebulous future semantic-programming-online service. One probably shouldn't register speculative domains late at night.

General approach to site development

1. Set up test site
2. Sketch sitemap
3. Sketch data schema from initial sitemap
4. Create data, load database
5. Determine the areas to be placed on the front page, compile
6. ???
7. Profit.

iPhone tester

A useful way to test iPhone compliance without an iPhone.

jQuery

jQuery is pretty ubiquitous, but ... link, just in case.

Raphael Javascript drawing library

Again: an open-source drawing component that's both grist for a component-database mill, and for a pattern-mining mill.

Draw Anywhere

DrawAnywhere.com is a fascinating concept: with a free account, you can log in and define drawings, from anywhere, using a Flash diagramming tool. You can upgrade to a premium account to have their link taken off your drawings, and the usual.

That's cool. Semantic programming should allow me to throw together a concept site like this in minutes. That's the goal. So: target.

Open-source Flash chart

So this open-source Flash chart component is interesting for a couple of reasons.

First, a database of useful components must be part of the semantic programming toolkit. How would one organize that?

Second, it's Flash, and open source. There's probably a boatload of useful patterns to be mined from it.

Programmer/journalists

An article about how journalism is finding that some stories are best told with databases. I'd like to be doing stuff like that.

Higher-order Perl

Might as well use this blog for bookmarking programming-related things.

So: Higher-Order Perl.

BUT errors can happen

A process can always fail. The meaning of the process will include its expected outcome (e.g. "I open file -> file IS open") but we know, as a general principle, that processes can fail.

One of the failings of formal logic (as far as I'm concerned) is the need to account for this sort of global knowledge on a very repetitive local basis. Since we know attempts to do something may fail, it's difficult and bothersome to have to say so, every time.

But this begs the question: how do we define the semantics of error checking? Where do we put it? When the engine is actually writing a script, will patterns take care of error checking?

Since this is informal logic, actually all of the above can apply at the same time, so maybe I'm getting ahead of the game here. But it's an important notion.

Trust, but verify. Trust that a file can open, but verify that it actually did so. Trust that our script will work, but verify it using unit testing. The point is to describe the semantics of good programming, right?