Cutting Scheme in Half

2009-08-24 1 min read Programming Eddie

Apple in Half, by a href= — Apple in Half

The Scheme steering committee has decided to sever the Scheme language into “Large Scheme” and “Small Scheme.” Can we expect the same from Scheme-inspired languages like JavaScript? 🙂

Advantages of push-style XSLT over pull-style

2008-11-25 3 min read Programming Xslt Eddie

Working with more than a few new-hires over the last few weeks, I’ve noticed that new XSLT developers often write pull-style XSLTs by default. However, this tends to defy XSLT’s functional heritage, and is not as useful as the opposite form, push-style XSLTs.

Pull-style XSLTs reach into the source document and pull out the data they need to transform. The pull-style is similar to template systems like those found in Rails or Django, or inserting PHP commands between HTML elements. For example, given the trivial input:

<?xml version="1.0" encoding="UTF-8"?>
<books>
    <book>
        <title>The Scheme Programming Language</title>
        <author>R. Kent Dybvig</author>
    </book>
    <book>
        <title>Essentials of Programming Languages</title>
        <author>Daniel P. Friedman</author>
    </book>
    <book>
        <title>An Introduction to Information Theory</title>
        <author>John R. Pierce</author>
    </book>
</books>

an XSLT novice will produce a stylesheet like the following (note lines 11 and 12 which reach into the source and grab the data):

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
    <xsl:template match="/">
        <html>
            <head>
                <title>books</title>
            </head>
            <body>
                <dl>
                    <xsl:for-each select="books/book">
                        <dt><xsl:value-of select="title"/></dt>
                        <dd><xsl:value-of select="author"/></dd>
                    </xsl:for-each>
                </dl>
            </body>
        </html>
    </xsl:template>
</xsl:stylesheet>

which transforms into:

<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <title>books</title>
   </head>
   <body>
      <dl>
         <dt>The Scheme Programming Language</dt>
         <dd>R. Kent Dybvig</dd>
         <dt>Essentials of Programming Languages</dt>
         <dd>Daniel P. Friedman</dd>
         <dt>An Introduction to Information Theory</dt>
         <dd>John R. Pierce</dd>
      </dl>
   </body>
</html>

The real power of XSLT, however, is defining templates for the elements found within the source document. These are push-style XSLTs. They have two main advantages. First, push-style gracefully handles complex source structures, including recursively nested elements. It would be near impossible to handle the following source document using pull-style,

<pre lang="xml">
<div><div><div>a</div></div></div>

if you didn’t know how deep the recursive divs would go. A push-style solution, though, is incredibly simple.

<pre lang="xml">
<template match="div">
     * <apply-templates></apply-templates> *
</template>

Will transform the previous source into the following.

* * * a * * *

In addition to handling complex source structures, push-style allows code reuse. This is of course an ideal of any programming language. Push-style XSLTs have a greater ability to be reused, because the individual templates can be reused. When you only have one template, it is quite difficult to make it general without resorting to numerous choose-when statements. Here is an example of code reuse, where we extend a previously written template with the xsl:apply-imports rule.

Given the input,

<images>
    <image>
        <url>http://www.filmjunkie.com/drinks/blixa/blixa.jpg</url>
        <alt>Blixa!</alt>
    </image>
</images>

and the XSLTs,

    <xsl:import href="imageformat.xsl"/>
 
    <xsl:template match="image">
        <div class="wrapper">
            <xsl:apply-imports/>
        </div>
    </xsl:template>

and the rule in “imageformat.xsl” (the template being extended in this case),

PHP and Me

2008-04-01 2 min read Programming Xslt Eddie

I just finished writing a not-so-simple, not-so-complex PHP script. First, lemme say that I had a good time with it, since it isn’t either XSLT or Portal (my workplace’s homebrew) code. It’s kinda refreshing to look outside of my multi-month project. Exciting, in fact… despite how insignificant (in the grand scheme of things) it is.

I’ve got to admit, thought, that I don’t really like PHP. I’m not going to bash PHP outright (as I’ve heard MANY people do). It is a programming language, and it certainly has it’s place. I’ve used many things written in PHP. In fact, I feel bad about the way people dismiss PHP. That said, I still don’t like it. My problem is that I feel PHP is simply too verbose. There seems to be a function for everything. It is the total opposite of Scheme, where every function is a based on a handful of core functions. I have had to deal with a number of languages in my life, and I certainly prefer languages with as little syntax as possible.

I spend a lot of time googling the functions. And then the parameters. And then the return types. And then I run across another function that is kinda like the first one that I saw, but slightly different (maybe even described as more or less efficient!) And then I have to research the return types. I’m mostly bothered by the related functions. Just give me something I can use in different ways. Don’t give me the kitchen sink and tell me to choose the faucet type.

This is the same problem that I have with XSLTs. It is a rather verbose language (which happens to usually be interspersed in XML/HTML). This makes it hard to pick-up in a hurry, and makes it unintuitive. This is important. Unintuitive. I spend a major part of my work day making sure that all of the webpages, all of the components, all of the behavior… even the URLs of my work are intuitive. So I don’t like to accept much less from the tools I work with.

To extend the analogy slightly further… I have seen that when websites are unintuitive, that said websites can fail. Is the same thing the case for programming languages?

Writing Scheme in Javascript I

2008-02-10 1 min read Javascript Eddie

This is an interesting little function that I ran across in Kent Dybvig’s The Scheme Programming Language. I thought I would give it a go in javascript. I wrote it out, and ran into two problems. First, I wasn’t returning anything from the anonymous-self-executing function, so it was being garbage collected, and the call to tell() would give an undefined (secret didn’t exist anymore). The second was that I initially declared secret without the var which gave it global scope. Took me a little while to figure these out, but since I haven’t looked at any javascript in months, I don’t feel so bad.
``



/* the original function from The Scheme Programming Language
(define shhh #f)
(define tell #f)

(let ((secret 0))
  (set! shhh
    (lambda (message)
      (set! secret message)))
  (set! tell
    (lambda ()
      secret)))


(shhh "sally likes harry")
(tell) <graphic> "sally likes harry"
secret <graphic> Error: variable secret is not bound
*/
</graphic></graphic>

<graphic><graphic>//the Javascript version of the same function
</graphic></graphic>

<graphic><graphic>var shhh = false;
var tell = (function(){
 var secret = 0;
 shhh = function(message) { secret = message; }
 return function() { console.info(secret); }
})();

shhh("harry likes sally");
console.info("tell: " + tell() );</graphic></graphic>

Class over

2007-10-18 1 min read Xslt Eddie

I am finished my XSLT class, and learned some very interesting things. Very cool the way some of the features of the language fit within the context of Scheme (and Lisp, for that matter). More to come.