from xkcd

Most of my work on this is on paper, and some code sketeches. There quite a few non-trivial issues, and hard decisions to be made. Since I have the knack of loosing or recycling the various paper bits lying around, I decided to keep at least some of them in my diary, aka this blog.

initial requirements

convenient syntax and semantics

convenience matters. The syntax should be obvious. The meaning of the syntax should be easy to grasp.

minimal core

the core of the macro processor should be minimal. This will help managing the code quality. The minimal core should be enriched using macros.

retargetable/multi-targets

using one and the same 'surface syntax' to produce different target code. It should be possible to have a one to many code generation. Example application - one definition producing javascript, php and sql code. Alternative example: one definition - three code targets - debug, deployment + a set of autogenerated tests

target and syntax agnostic

no assumptions should be made (at least at top level) about the target or syntax. We should be able to accomodate any theoretically parsable syntax, within reason, of course. Subject to parsing strategy selection, etc...

My obsession with things schemish and lispish and having to use php on a daily basis leads to the usual comparison and how would I do this in ... style questions. So here comes another go at how would I program lisp style in php. How much is possible? What is possible? Mind you not everything is really useful or the best way to do it. It is just an intellectual excersise, a study on using some of the php'f features to program in not a typical php (imperative) style.

the compulsory conses, car, cdr in php

Well for the benefit of non-lispers I will use head and tail instead of car and cdr respectively.

Well it’s impossible to remove all of the parentheses in Lisp, ..... One alternative to parentheses is being sensitive to white space, in a way that is reminiscent of Python. Lisp without Parenthesis

A good post, which goes along the lines of what I'm playing with as well. He (Peter Schombert) suggests using \ as line continuation mark, which is in line with tradition. I would probably prefer it in the end, as opposed to the beginning of a line, but that's sugar.

I wonder, how hard it would be to add such a language extention to mzscheme.

Me being a noobie, I haven't had a clue that there is an SRFI, which implements that already.

I'm intrigued. You might have noticed that I like Lisp. Itellectually, that is. I don't really speak it. I finally decided to dive and try and learn it. On the surface it is not that hard - the language is extremely simple, essentially it has brackets and white space as separators, a couple of special forms - something like built in functions or language constructs in other language terminology, and a few really cool features like quote, unquote, quasiquote, (precious special forms actually), oh, yes, it has an eval.

In order to go forward with the learning I shall try and implement a simple web-design friendly template for xml applications. The idea is similar to TAL, or taglibs, etc...

In a previous short post Idescribe a way to emulate closures in php. Using that technique execution environment, otherwise known as a call stack can be saved for future use. This can be put to good use. A couple of patterns or programming techniques could be useful in practice.

State pattern

A closure represents a state => implemenation of a state pattern. This is a bit rich. Usually in OO programming the state pattern is implemented by encapsulating different protocols, for denoted states. This is simple to implement by substituting your protocol specification with a different name. Drupal hooks are a good example implementation of this. The following is a simplisting example implementation of a state pattern based on closures. The last argument of the deduced function is the closure itself.

class function_object {
  var $scope;
  function __get($name) {
    return $this->$scope->$name;
  }
  function __call($name,$args) {
    $func =$this->$state."_$name";
    $args[]=$this;
    return call_user_func_args($func,$args);
  }
  function __constructor($scope) {
    $this->scope=$scope;
  }
  function __clone() {
    $this->scope = clone($this->scope);
  }
  function state($state) {
    $this->state=$state;
  }
  function call() {
    //the function body - do some work
  }
}

To save the state for future use, for example as part of an undo cycle:

  $saved = clone($closure);

Call/cc or call with current continuation in php

Closure effectively represent the future of computation. This means that we can say what we want to do, by where we are. Since php doesn't implement any call stack optimisation, the call/cc style of programming makes sense in a limited number of cases. To use this style of programming we need to redefine our functions to use the continuation

f(x,c) : c(f,x);
(var, continuation) -> continuation

and in php


//the function closure call method
...
function call($x, $continuation) {
$this->scope=$continuation; // emulate c(f,x)
...
do whatever you want here
}
...

OK, this is rather crude. In reality this is very limited - it is assumed that the function is defined in a 'global' scope, so we are putting it in some exhisting stack. It will be cleaner if the continuation implements the stack assignment, rather than rely on the function.

In programming languages, a closure is an abstraction that combines a function and a special lexical environment bound to that function (scope). The variables in the lexical environment are designed to retain state information between function calls. Unlike garden-variety functions which retain no memory of what happened in previous calls, closures are capable of storing information across function calls.closulres in computer science (wikipedia)

PHP doesn't have closures as an element of the language. What can we do to emulate it?

We need to be able to encapsulate in one entity scope, state and execution. The most obvious candidate will be a PHP object.

With the introduction of the __get(), __set() and __call() magic functions for PHP classes, something the manual calls overloading, PHP opens the gate to transparently enhance a class to add variables and methods to an object's body. We can abuse the __get() to implemet nested scopes. The state is preserved as part of the object body. The default function (call()) is a protocol to add a uniformity of execution between different function objects.

class function_object { var $scope; function __get($name) { return $this->$scope->$name; } function __constructor($scope) { $this->scope=$scope; } function call() { //the function body - do some work } } If all $scope objects are function objects we get a closure emulation in PHP. This opens the doors to such fancy ideas as namespaces, modules et.al. This technique opens the possibilities for functional style programming techniques and idioms as delayed evaluation, continuation, ...

Update: I've added closures to my design patterns collection