Doug Landauer: cs

The Segway Programming Language

Sat, 02 Feb 2008 23:41:38 GMT

On LtU, Koray Can writes about Paul Graham's recent preliminary release of Arc:

It seems to me that the only people who are talking about it are those who have followed Paul Graham's writings over the years and wanted to see what it, the thing, the real deal would look like.

I call it "Segway", due to the difference between the hype and the (current, pre-alpha) reality. Note that the hype mostly did not come from PG. My earlier guess was overoptimistic by three years or so.

It's 2008. Do you know where your projects are?

Sat, 05 Jan 2008 08:18:49 GMT

Mostly stalled, but here's a partial, cryptic list:

weblogs and pix coalescing at l6r (revive zia.pycs, extract data from Radio, etc)
finish out my OCaml version of Danvy's grand tour of SECD-like machines
mangle spj's sudoku solver
weblog engine in scala, including quarkup, my contribution to the babel of wikilike markup syntaxes, and maybe (im)port Pandoc
build the two ubuntu machines
prototype a streaker interface for gmail & reader
scala android experiments

Scala, conciseness, and higher-order functions

Wed, 26 Dec 2007 07:20:38 GMT

It was nice to see Dan Weinreb's "First Impressions" article about Scala. It's rare to see a programming language evaluation that's so well-informed and free of emotional reactions. Steve Yegge won't ever be accused of being that impartial, and his impassioned article about code size is entertaining, but could hardly be described as "unemotional". What I found appalling is that in 122 comments to an article about code size, not a single one mentioned the idea of higher order functions. I think that these, and pattern matching, are among the most effective language features for making code more concise while preserving readability.

PXSL, Scala Android, Giant Rat of Sumatra

Wed, 19 Dec 2007 07:00:05 GMT

Cool stuff this week:

Tom Moertel's PXSL, a Parsimonious XML Shorthand Language, which I'd love to look more deeply into, later. I think I posted something on Pyscerocha about the various XML shorthands, or alternate syntaxes, that people have come up with to ease the pain of using XML directly.
Scala Android — my first thought upon hearing of Android was how long before I could play with it in Scala?
Silliness: The Firesign Theatre had a 1974 album called "The Tale of the Giant Rat of Sumatra". This week, it appears that the animal has been discovered. Well it was on New Guinea, actually, but who can tell the difference from here?

Knuth's 2003 book tour

Wed, 31 Oct 2007 09:17:59 GMT

About four years ago, I wrote about Knuth's book "tour". Since the subject came up again, I thought I should update the LtU URLs that were mentioned in there:

"TPK algorithm": Pointer to a page of implementations of the "TPK algorithm". The (Florida Institute of Technology) page is still there.
Knuth and the IBM-650: this LtU classic thread mentions a restricted IEEE page. I remain astounded at the extent to which the IEEE and ACM both still live in the dark ages. I suppose the alternative in both their cases would be for the organization to simply shrivel up and blow away. I have a vague recollection of having written something about this (the gist: using ACM to publish your paper these days is like the *opposite* of publishing -- i.e., it renders your paper *more private* than if you just put it on your own web page) ... but now I can't find it any more.
Knuth's 1974 Turing Award Lecture (PDF) is referenced in this LtU classic thread. It points to this PDF link, but that may have gone missing since 2002. I was able to snag a copy from the Wayback machine, though I haven't read it yet.
Here is a mention that Knuth has an online preview of some segments of Volume 4 of The Art of Computer Programming, and Whoa, it's still there, these 6+ years later! It points to this gzip'd postscript.

Remarkable static vs dynamic discussion

Thu, 12 Jul 2007 07:37:45 GMT

On Artima, Bill Venners kicked off one of the more interesting discussions I've seen on the subject of static type checking versus dynamically typed languages. Bill's been active on the Scala mailing list lately, and it's nice to see folks mentioning Scala frequently as an example of a well-done statically typed language. As I read the discussion, I was thinking along the lines of making a translator for a subset of Ruby, into Scala, when I ran into Bill Pyne's suggestion to do just that (except starting with Python). It'd be nice to have such a tool for my work right now, since I have a compiler that I wrote completely in Ruby, but which is large enough now that it would IMHO benefit from a conversion to a language like Scala. Pity that Scala is probably not politically feasible, since my management would prefer that everything were written in C++.

Stalled SECD Work

Wed, 11 Jul 2007 07:55:33 GMT

Being the ongoing but abridged saga of a translation of a deconstructed abstract machine (interpreter) for a fairly basic lambda calculus, due to Peter Landin (the original 1964 SECD machine) and Olivier Danvy (the 2003 deconstruction), said translation starting with SML, detouring through Ruby, and stalling out for no intrinsic reason with a partially working OCaml version. In our last episode (May 2007) I wrote: "The machine part compiles; maybe I'll be able to get the test app running later this week." It being July now, that'd have to be a heck of a week. Fact is, I've been finding precious little time to work on it, with some major deadlines at work and other personal issues intruding. But I do recall that I never put the OCaml version up anywhere, and since I haven't even touched it in over three weeks, I figured it must be time to put it up here so I can find it later. Caveats: I've only compiled it on my old Mac at home, with Ocaml version 3.06. And it's not fully debugged yet, either. But it does say helpful stuff like this:

Evaluate 0 ... 
Evaluating     <LIT 7>
      result   7
Evaluating     <LIT 3>
      result   3
Evaluating     (\x -> [succ _ x])
      result   (E:<[ succ =succ
        ]>, V:x, T:[succ _ x]:)
Evaluating     [(\x -> [succ _ x]) _ <LIT 8>]
      result   9
Evaluating     (\x -> (\y -> [succ _ x]))
      result   (E:<[ succ =succ
        ]>, V:x, T:(\y -> [succ _ x]):)
Evaluating     [(\x -> [succ _ x]) _ <LIT 7>]
      result   8
Evaluate 3 ... Evaluating     <LIT 7>
      result   7
Evaluating     <LIT 3>
      result   3
Evaluating     (\x -> [succ _ x])
      result   (E:<[ succ =succ
        ]>, V:x, T:[succ _ x]:)
Evaluating     [(\x -> [succ _ x]) _ <LIT 8>]
      result   9
Evaluating     (x -> (y -> [succ _ x]))
      result   (E:<[ succ =succ
        ]>, V:x, T:(y -> [succ _ x]):)
Evaluating     [(\x -> [succ _ x]) _ <LIT 7>]
      result   8

At any rate, there are just two source files, so I didn't put together a Makefile or anything. They're here:

http://got.net/~landauer/cs/ohdr.ml
http://got.net/~landauer/cs/Danvy_SEC_M.ml

Though the current result is of somewhat questionable utility, I found it to be worth my time, since I did learn:

more OCaml;
how much FP-style pattern matching helps code conciseness; and
how much extra but necessary infrastructure stuff can be glossed over (i.e., omitted) in a technical paper like Danvy's.

Idle question

Wed, 30 May 2007 07:55:46 GMT

Do Lambda Calculus weenies call Java programmers "weak-head normals"?

Barendregt's Lambda Cube

Wed, 23 May 2007 08:00:26 GMT

In the programming subreddit, Alpheccar posted a link labeled Lambda Calculi with Types - Barendregt, with the brief comment "Great description of the lambda cube". IMHO, that depends on how much time you have -- that "great description" is 190 pages long! So I added a comment

I was just looking at this stuff a week or two ago. Barendregt's 190-page descriptions of the type systems that inhabit the vertices of the lambda cube is indeed very detailed, thorough, and well-presented. For those not wishing to wade through all the math, the cube's description starts in section 5; the illustration is on page "78" (79 of the PDF, according to Preview). Haskell heavyweights SPJ and/or Erik M named a typed intermediate language "Henk" after HB. That (1997) paper has a more understandable (to me, anyway) summary of the Lambda-cube than Henk B.'s 1992 compendium. Possibly a benefit of five years of hindsight. Here is Wikipedia's brief entry about the lambda cube. It describes the axes as

Terms depending on types, or polymorphism (as in System F),

Types depending on types, or type operators, and

Types depending on terms, or dependent types (as in LF).

And here's RBJones's nicely drawn web page illustrating Barendregt's lambda cube.
FWIW, RBJones' cube loses Barendregt's arrowheads that represent inclusion. Those arrows clearly indicate that the upper right back corner, lambda-P-omega, includes all of the others. Unfortunately, RBJones doesn't explain his boxes-and-stars notation, nor does he correlate the cube's axes with wikipedia-style understandable explanations. On page 89, HB defines the "sorts" star and box though not in understandable English. The SPJ/EM paper's description is better, though the concepts remain quite abstract.

I wanted to add the reference to TaPL (at the end of chapter 30); add the stuff below the <HR> here, use real lambda's and boxes, and figure out what the heck box really means, and what SPJ/EM mean by this (near the end of section 3.3 ("Notation") of their paper):

Each ... term has a type; each type has a kind. ...
A PTS may have >3 levels.
Lambda cube PTS's have <= 3 levels,
except that there is a solitary constant "[]" (box)
at the fourth level.

Hmmm... So, if * "means" terms and [] "means" types, that's the place where * and [] live two levels above their referents. Or something like that, I read, but no longer can find that statement. Will locate it later, and hopefully be able to explain it at that time.

(I'll use "[]" to represent a box). Here's the connections, I think: System LF has dependent types. System LF is at (*,[]) vertex of RBJones' cube. Omega is the most far-out, so it's gotta be type-operators, i.e., types depending on types. So: [] means types, * means terms, and ( X, Y ) means Y depending on X. So, to expand wikipedia's axes list with RBJones' notation:

Terms depending on types, or polymorphism (as in System F),
( [], * ) ... "2" as in "second-order lambda calculus"
The vertical axis
Types depending on types, or type operators, and
( [], [] ) ... omega or "w"
The axis that points directly away from us.
Types depending on terms, or dependent types (as in LF).
( *, [] ) ... P
The left-to-right axis

In in section 4 of HB's paper, lambda-> is extended in three ways, to

L2 ("second-order", aka "polymorphic"),
L-MU ("recursive types"),
L-INT ("intersection types" -- a variable can have two types at the same time)

L2 (Girard/Reynolds): has other names

polymorphic typed lambda calculus
second-order typed lambda calculus
second-order polymorphic typed lambda calculus
system F

SECD machine into OCaml ... in progress

Wed, 16 May 2007 07:38:06 GMT

One of my side projects this past winter has been to figure out what Landin's SECD machine was all about. I started by reading Danvy's "Rational Deconstruction" paper, which implemented the core of the interpreter in ML, in several different ways. Not having a handy ML compiler, nor knowing the language very well, I thought I'd just translate it straight into Ruby. When that was done, I couldn't easily tell whether it was really right, not having a decent set of test data. I grabbed some from the net, but still lacked confidence. So lately I've been translating it into OCaml instead, for which I do have an already-installed compiler. I don't know that language very well either, but it's more familiar to me than straight ML is. The machine part compiles; maybe I'll be able to get the test app running later this week. Here are my previous Landin/Danvy SECD machine entries:

The type-system silhouette of the proto-program

Tue, 01 May 2007 08:00:38 GMT

In an interesting description of typeful program development (Haskell-oriented in this case), totherme mentioned a nice metaphor for visualizing how one might go about creating a program in a typeful way. The situation is that we have a (most likely partial, and often only mental) spec of what the program should do, and we write down an approximation of some types that might help solve the problem. The central image of the metaphor is that this approximation is the silhouette of the spec on the type system. The activity then is to flesh out that silhouette, give it additional dimensions, depth and color (guided by the type system), until it's tangible.

Gwgl R3

Sat, 28 Apr 2007 07:58:07 GMT

Been playing around with Google Earth a bit lately. I know, I'm a little late to that party -- but it did take them a while to get it ported to the Mac. Anyway, I've managed to fly through the routes of most of the more memorable backpacking trips I've taken and some day hikes I've done. It's uncanny how much the GwglR3 view can look like the real terrain, sometimes. But it's not an "uncanny valley" -- it's just really cool.

1980 trip with Sheldon, Jeremiah, and the crippled Girl Scouts -- sort of a Rae Lakes Loop, but from the east -- Onion Valley, Kearsarge Pass, Charlotte Lake, Gardner Peak, Gardner Basin, Sixty Lakes Basin, Rae Lakes, Glen Pass
1994 hike to Grizzly Lake in the Trinity Alps (see http://tinyurl.com/yuhrq7 )
Part of my 1999 PCT Solo Week http://got.net/~landauer/bp/990928-YoseHigh.html
Most of the Y2K Emigrant Wilderness trek across Yosemite http://got.net/~landauer/bp/000729-EmW_Yosemite.html
The first day or two of the High Sierra Trail, from near Moro Rock, up to the Hamilton Lakes.
The hike from Koke`e down along the Nu`alolo trail, to a viewpoint about 2000' above the Nu`alolo Kai, then along the cliffs to the Awa`awapuhi trail, and another amazing viewspot. Do also check out the Kalalau Valley viewpoint, it looks quite a lot like the postcards.
The incredible NFSJ trip (I'll have to restage the trip report, I think Phil P.'s pycs Radio server finally gave up the ghost.)
and the more recent trip along the route that parallels the main part of Kings Canyon, but just south of it (past the Sugarloaf, Roaring River Ranger Station, Moraine Ridge, Avalanche Pass, and on down to Bubbs Creek). One of the awesome views from that trip is from near the Ranger Station, looking up this pair of canyons -- Deadman Canyon and Cloud Canyon -- and the GwglR3 view does not disappoint.

Now that GwglR3 has a hiking trails layer, it looks like it's also an awesome tool for planning trips, and/or for vicariously following along on trips you never intend to take. Everest, anyone? I can hardly wait for Google Mars to be converted to the same format.

Python Snippets for the BayPIGgies

Thu, 12 Apr 2007 08:52:53 GMT

I contributed a comment (about Ruby's "Array#flatten" method) in a mailing list thread about python code snippets, and as a result I was asked to present some python snippets at tonight's meeting of the (SF) Bay Area Python Interest Group. So I picked four little bits of code. The code itself is at http://got.net/~landauer/sw/snippets/dl_snippets.tgz , or as separate python sources in that directory.

1. Invert Color

This snippet is a whole command-line command; it takes a string representing a (hex) html color value, and prints out its bitwise inverse (one's complement). It's non-scientific and pretty much unrelated to any optical notion of color complements. Inspired by a ruby version at http://www.bigbold.com/snippets/posts/show/582 . There are only two bits of note here:

The join/map/lambda thing expands a three-hex-digit string into a six-digit string, by replicating each digit.
I thought of using the unary "~" complement operator, but it turns on too many other bits.

def invert_color (color):
    if color[0] == '#':
        color = color[1:]
    if len(color) == 3:
        color = ''.join( map( lambda m,n: m+n, color, color ) )
    return "#%06X" % (int(color, 16) ^ 0xFFFFFF)
#
import sys
for a in sys.argv[1:]:
    print invert_color(a)

2. Undent (aka "margin")

This function "undent" is nice to have in a utility library. It allows you to use nice source-relative indentation in triple-quoted strings, and it will strip off the extra indentation. I posted this snippet of code on the BayPIGgies list in February (2007). It was inspired by Hal Fulton's "margin" method from his Ruby book The Ruby Way. This does its work at runtime, and isn't as strict as the similar recipe that's in the Python cookbook. It's short (just four lines of meat) and a bit easier to use (less cluttered-looking at usage site) than other, more efficient compile-time versions. The code is very straightforward except for maybe the "rstrip" -- that removes the last line (of spaces and a newline).

import re
undent_pat = re.compile( r"^\s*\S(.*)$", re.M  )
def undent (str):
     return undent_pat.sub( r'\1', str.rstrip() )
#######################################
# Usage Example:
#
def getCustomerInfo(cust_id):
     sql  = undent( '''\
             |select customers.id as %s,
             |        sum(invoices.amount) as amount_total,
             |        blah as blah
             |   from customer 
             |   etc...
             ''')
     return sql % cust_id
print getCustomerInfo( '2345' )

Update: At the meeting, Drew pointed out that the standard library module "textwrap" has, since version 2.3, had a "dedent" function which does something similar (i.e., dedent does what the abovementioned cookbook recipe does).

3. My time/date stamp

See my "GIGO beH" posting for details. This command prints out my time/date stamp. No tricky code here.

import datetime
from string import digits as d, lowercase as lc, uppercase as uc
dom= '!' + d[1:] + uc[4:]      # Used for day of month
hms= d + uc + lc               # Used for mins, seconds.
now = datetime.datetime.now()
date_code= lc[ now.year - 2001 ] + lc[ now.month-1 ] + dom[ now.day ]
time_code= hms[ now.hour + 10 ] + hms[ now.minute ] +  hms[ now.second ]
print date_code + '_' + time_code

4. "flatten"

Because the flatten method was the subject of my contribution in the abovementioned email thread that got me into this trouble in the first place, I guess I ought to snip a bit of that here. This is a very minor tweak to Alex Martelli's cookbook version. Slightly shorter, probably slightly less clear, but I get to include a "no_can_do" function:

def can_do ( fn, exc = Exception ):
    try:          fn()
    except exc:   return 0
    else:         return 1
#
def no_can_do ( fn ):
    return not can_do( fn )
#
def isScalar(obj):
    return (    can_do( lambda: obj+'', TypeError ) or
             no_can_do( lambda: iter(obj) ) )
#
def flatten(sequence, scalarp=isScalar):
    for item in sequence:
        if scalarp(item):
            yield item
        else:
            for subitem in flatten(item, scalarp):
                yield subitem

Finally, for no good reason, here's a link to the rest of those Point Lobos pix.

SECD machine ... a bit more

Mon, 12 Mar 2007 07:59:04 GMT

Been super busy — note the recent posting frequency :-( . Major tree pruning and yard work this weekend. Did a bit of work on the SECD machine translation, but it's slow going. I think I'm going to have to do them all in sequence, since the opacity of my Ruby version of the simplest-looking one has made it somewhat tricky to debug in the dribs and drabs of time I've given myself to work on it.

vim insert multiple lines

Sun, 04 Mar 2007 07:33:44 GMT

The question was: "In olden times, vi would allow you to insert multiple lines with a ":g/pattern/i..." command. How does one do this in vim? My first answer was actually an answer to a question not quite asked: "How does one do something like this in vim?" And that answer was

  :g/pattern/s/^/one-new-line^V^Manother^V^M/

But naturally, the question as actually asked gnawed at my brain, and I tried a few things, including even (gasp!) vim's :help command! So, let me count the ways that ended up working for me:

  :g/pattern/i|only-one-inserted-line-can-be-typed-here

Hmm, that worked at work, but not here at home. (See below.) :help :g helped me find this one -- I had never heard of the "normal" command before:

  :g/^buz/normal ifirst-inserted-line^Msecond-one^M^[

I finally found the key here, under :help :insert

  These two commands will keep on asking for lines, until you type a line
  containing only a ".".  Watch out for lines starting with a backslash, see
  |line-continuation|.
  When these commands are used with |:global| or |:vglobal| then the lines are
  obtained from the text following the command.  Separate lines with a NL
  escaped with a backslash: >
        :global/abc/insert\
        one line\
        another line
  The final "." is not needed then.

Without that, It would have taken a lot longer to think of using the backslash, or the actual control-J instead of control-M. Soooo, the oh-so-user-friendly escaping required, to get as close as is reasonable to the old vi behavior, is approximately the least intuitive thing that could possibly work:

    :g/pattern/i\^v^jone-line\^v^janother

And, oh, by the way, the doubly-escaped newline displays as "^@". Dang, that again did not work at home. "Trailing characters." Aha, this appears to be something fixed between vim version 6.2 and vim version 7.0. (Mac OS X, in case that matters.) (Edit: I hadn't noticed that the backslashes disappeared upon publication.)

virtual server

Wed, 28 Feb 2007 08:57:32 GMT

Cool, that was easy — now I have my mac running both the new site and a virtual server for experimenting, the latter addressed via my old dyndns site zia dot mine dot nu. Now to locate that layout/CSS that I came up with a few weeks ago. Downloaded liftweb, but haven't really had the time yet to try deploying something using it.

liftweb framework

Wed, 28 Feb 2007 07:58:59 GMT

David Pollak released version 0.1.0 of liftweb today. I think I'll try using that for my ell six arr dot you ess site when I start rehabilitating it.

SECD machine into Ruby: fragments

Mon, 26 Feb 2007 07:35:44 GMT

As I hinted last Tuesday, I've been looking in to Olivier Danvy's excellent paper dissecting Landin's SECD machine, the first influential abstract machine for evaluating expressions in the lambda calculus. I made some progress on understanding Olivier Danvy's paper, in the guise of translating Danvy's ML into Ruby. It brought to my attention a couple of observations:

Man, this translation sure does get you to appreciate the power of pattern matching!!! I think I want to try to do this in Scala next. I do have one concern, though, in that pattern matching in ML makes it hard to tell what identifiers are being assigned due to a match. I suspect that this is probably due mostly to my lack of familiarity with ML.
Sheesh, there is an awful lot of infrastructure that gets glossed over as "obvious" (or not even mentioned at all) in formal papers like this. By my count, the meat of the section (2.4) of Danvy's paper that caught my eye is only 24 or so lines of very compact ML code, which I have translated (so far) into 58 or so lines of Ruby. The rest of the code I wrote to support this experiment (parsing lambda expressions and program arguments; defining classes; error-checking; and testing and debugging) takes 300+ lines.

It doesn't quite work yet, so I'll not inflict it upon the world, but I'll include (below) the "meat" section, in both ML and Ruby. Landin's original SECD machine stood for "Stack", "Environment", "Control", and "Data". Landin's abstract machine would have four registers, one for each of those data structures. The section 2.4 upon which I focused omits the "D" register. The meat of this section defines two functions: "eval" and "apply". Here's "eval" from Danvy's section 2.4 "SEC machine" (no D). I found the formatting and parameter naming of the APP branch utterly misleading, so I've changed those for clarity:

fun eval (LIT n, s, e, c) = c ((INT n) :: s, e)
    | eval (VAR x, s, e, c) = c ((Env.lookup (x, e)) :: s, e)
    | eval (LAM (x, t), s, e, c) = c ((CLOSURE (e, x, t)) :: s, e)
    | eval (APP (t0, t1), s, e, c)
       = eval (t1, s, e,
               fn (s2, e2) => eval (t0, s2, e2,
                                    fn (s3, e3) =>
                                        apply (s3, e3, c)
                                   )
              )

Here's my Ruby eval translation for now (as I mentioned above, it does not quite work yet):

def eval k, s, e, cfunc
    case k
     when St_LIT ;  n = k.val
                    cfunc.call( s.push( Val_int.new(n), e ))
     when St_VAR ;  x = k.id
                    xv = e.lookup x
                    cfunc.call( s.push( xv ), e )
     when St_LAM ;  x = k.lambda_param
                    t = k.lambda_body
                    cls = Val_closure.new( e, x, t )
                    cfunc.call( s.push( cls ), e )
     when St_APP ;  t0 = k.fn_to_apply
                    t1 = k.args
                    # I don't get what the => symbols mean here.
                    #  Oh, eww!  what ugly misleading formatting
                    #  and identifier name choices, and convoluted
                    #   expression!  Fixed those and unwound it.
                    innerF = proc{|s3,e3| apply s3,e3,c }
                    midF   = proc{|s2,e2| eval t0, s2, e2, innerF }
                    eval( t1, s, e,  midF )
    end
end

Here's apply, in Danvy's ML ...

and apply (SUCC :: (INT n) :: s, e, c)
                = c ((INT (n+1)) :: s, e)
  | apply ((CLOSURE (e', x, t)) :: v' :: s, e, c)
    = let val (v :: nil) =
            eval (t, nil, Env.extend (x, v', e'), 
                  fn (s, _) => s)
      in
           c(v::s,e)
      end

... and here's my Ruby translation of apply:

def apply s, e, cfunc
    s_top = s.pop
    if s_top.is_a? Val_succ
        s_nxt = s.pop
        if s_nxt.is_a? Val_int
            s.push( Val_int.new( s_nxt.val + 1 ) )
            cfunc.call( s, e )
        else
            puts "Apply error:  succ on non-INT"
            exit 1
        end
    elsif s_top.is_a? Val_closure
        ep = s_top.env
        x  = s_top.lambda_param
        t  = s_top.lambda_body
        vp = s.pop
        v_colon_nil = eval(t,
                           nil,
                           ep.extend(x, vp, ep), 
                           proc{|s,_| s}
                          )
        just_v = v_colon_nil.pop
        cfunc.call( s.push(just_v), e )
    else
        puts "Apply error:  apply on a non-SUCC, non-Closure"
    end
end

UI Blunders: Apple and Firefox

Sat, 24 Feb 2007 06:56:47 GMT

Channeling Hani today, but with fewer swearwords. IMHO, Apple has a well-deserved reputation as one of the best UI design organizations on the planet. But even the best err sometimes. So here's a list of what I consider to be User Interface Blunders that Apple has made, despite that reputation.

Page Setup vs the print dialog

EVERY application should provide the option, IN THE PRINT DIALOG, to switch between landscape and portrait mode. NO EXCEPTIONS. THIS IS BASIC.

To force me to close the print dialog, and go to Page Setup, just to get a page printed in the desired orientation, is to admit that your APIs are ossified, and cannot adapt to providing the smooth and simple interaction that Apple was once justly praised for.

the one-button mouse

Though it might have been the right choice even as late as 1987, it was definitely a mistake by 1997, and is a huge blunder in 2007.

Not giving Text files special status

Apple innovation: giving files types, and assigning a specific preferred ("creator") application to most kinds of files. This was actually a nice innovation.

Cool flexibility variation: the "open with" menu item. Nice for giving the user more choices.

Blunder: Not giving text files special status. Face it, dammit. Text files matter more.

Ok, I read about a new programming language NML. Its sources are in files named with a ".nml" extension.
Even firefox suffers from Apple's precedent here -- instead of giving me the choice of treating NML as if it *might* be a text file, it just asks whether to save it, or open with ... no choices.
DAMMIT, just let me see what's in tha damn thing!! I can tell better than you can, whether it might just simply be plain text.
No, actually, YOU could do it. It is all or mostly ascii or valid unicode? Does it have line-ender characters every so often, like, say, within every few hundred characters? than DAMMIT offer a decent text editor as one of the preferred options, no matter what the filename extension says. These things are supposed to be for OUR benefit, Shit!

Now, maybe I'm biased from thirty-plus years of Unix use, but dammit, text files, as streams of characters, ARE more relevant to what I care about on the computer than just about ANYTHING else. JUST LET ME SEE THE DAMN THING. If I don't like that, or it turns out to be gibberish, I am perfectly capable of closing that window!!!

Printer margins in 2-up mode.

This might just be a minor printer driver issue, but it has persisted for a long time. PLEASE allow me to choose margin sizes, percentage magnification, etc., when doing 2-up printing. Your drivers (or your printer-partners' drivers) ALL SUCK. (Well, maybe it's just the cheap and sucky drivers for the cheap printers that I've been able to afford.)

Speaking of firefox ... but I suppose that's a different entry.

It sure would be nice to make it a better Mac OS X client. Here are my two trivial improvements:

Fix the text selection behavior. If I select a string of text, and then hit the left-arrow button, then the cursor should be *at the left edge of where that selection was*. Otherwise, it is not a Mac Application.
I'm not sure what lame rules it does use, but ... well, they're wrong.
the dock-context menu currently has
- show in finder
- hide
- quit
It needs to have "New Window"
Why? Say I have a couple of Ffox windows full of tabs full of stuff I'm sorta reading. Then I cmd-M minimize them and do some work. Now, when I have a work-related question that I need to use FFox to solve, I just want a new ffox window to come up. Instead, if I click on the Ffox in the dock, then one of my old surfing windows-full-of-tabs slithers out of its crate, and whatever cow orker is peering over my shoulder has to ask about all the interesting stuff in there, instead of getting a clean-slate starter spot.
To get the effect I most often want, I have to cmd-Tab as many times as necessary to get to Ffox, then hit cmd-N. Feels like n different operations (with n unpredictable) when it should be one (right click on Ffox dock icon, and glide the cursor up to select the nonexistent (but should-exist) "New Firefox Window" menu item).
(feature request): when the user changes the text size, if some text on the page is selected, then do your darnedest to keep (at least the start of) that selected text visible.
my workaround for this is :
- select some text
- cmd-+ (often as many as three times) to repair some resolution-challenged bozo's teeny tiny text
- shift-down-arrow (extends the selection, which has the side effect of bringing that end of the selection into view)
It shouldn't have to be that cumbersome.

Fixing Steve Yegge's rants

Thu, 22 Feb 2007 05:04:35 GMT

I am among many who find Steve Yegge's rants quite entertaining, but who also find them long enough to print rather than read online. The problem with this is that there's a bug somewhere, in the CSS, in Mac OS X, or in Firefox, whose result is that printing one entry out leads to one page containing only a useless header page, one page of content, cut off as it falls off the page, and one useless page of comment entry form. With some help from Eric Meyer and a bit of binary debugging, I tracked it down to a CSS property that says

   overflow: hidden;

which makes me suspect that Firefox is doing exactly what it was told to do -- hiding the "rest" of the page(s) because the entry overflowed what would fit on one (printed) page. Since I don't really grok javascript, greasemonkey, or hoodwink'd yet, I wrote a shell/ruby script to fix the rants to make them printable. Finding the things to fix is made vastly easier by the excellent Firebug plugin for Firefox, which is roughly a WYSIWYG CSS editor and validator for remote web pages. Anyway, meanwhile, here's that script. It's brittle, but works for today:

#!/bin/sh
# Later, make it ruby -i.bak

# That first one is really the only thing needed to fix the printing problem.
# (Which was that it would only print one page of the rant.  S.Y. could
#  work around this bug by publishing normal-sized blog entries, but
#  I'm not holding my breath.)  The other gsub lines remove the sidebar
#  and widen the main text.
ruby         -p -e 'gsub( /overflow: *hidden;/ ) {|m| "/* #{m} */" }'      
                -e 'gsub( /width: *67%;/, "width: 95%" )'                  
                -e 'gsub( /width: *25%;/, "width: 0%; display: none; " )'  
            "$@"

Sorry, I can't do much about the content, but I find them entertaining enough that I'm not tempted to try. :-) Usage: save the page, and then run this script with the name of that saved file as an argument.

M-expressions to Forth, Landin, SECD, Danvy, and Oleg

Tue, 20 Feb 2007 08:25:39 GMT

My mention a few days ago of the Lisp 1.5 manual was related to an intent "to mess around some with M-expressions". Namely, I thought it would be nice to write up a moderately minimal implementation in a more modern, concise, widely-available language. But then I got sidetracked into thinking about minimal forth implementations, thinking about what a forth-like language would be like if the stack were a stack of lisp-ish cons cells, and finally decided that some of the early lisp guys must have done something similar. This eventually led me to read Olivier Danvy's 2003 paper "A Rational Deconstruction of Landin's SECD Machine". I had only vaguely ever heard of the SECD machine before, but it does indeed look like what I was wondering about as described above. Danvy's reconstruction without the "D" seems simplest to me. So this sidetrack will probably remain a thorn in my side until I can interpret some of Oleg's basic lambda-calculus expressions in some form.

Haskell library docs and IDE-like website features

Mon, 19 Feb 2007 07:51:12 GMT

As a perennial almost-fluent Haskell reader, I still find a couple of things making Haskell code harder to read than it should have to be. One of them is operator precedence, though I think I mostly have a handle on it. As I commented (on JJ's critique of Haskell syntax):

I do think that operator precedence in Haskell is one of the harder things to get used to for beginners. Here's a feature I'd like to see in a Haskell IDE: visually parenthesize code (upon request, or by default for novices) by putting the background of the innermost parts in one shade, and holding the next outer parts together with a slightly lighter shade, fading out to match the background color at the outermost level. Do this in particular with the unfamiliar operators -- the ones that do not exist in the more popular languages.

I think you could do this with CSS in an HTML page that contains Haskell source code. And along similar lines: Cale Gibbard wrote an excellent wiki entry about How To Use Monad Transformers. What I found hardest to follow was the times when he would use a library function with which I was (actually, still am) unfamiliar. In this case, none of lift, liftIO, the =<< operator, nor tell were explained (though tell looks clear from the context, but I remain uneasy about it after looking at its type). I think it would be cool if instructive Haskell pages had pop-up (aka "tooltip") links attached to most usages of library functions, so that if you hover over the name, you'd get a pop-up showing the function's type and a brief description in English of what it does. These website feature ideas are probably old-hat to you folks who actually use IDEs, but it seems like a strange omission for stuff on the web whose purpose is instruction. Unfortunately, looking at some of the Haskell library docs, it does appear that most of those "brief description in English" texts are not actually written yet.

Haskell read/show hex

Wed, 14 Feb 2007 09:35:28 GMT

Someone, somewhere wondered about converting integers to and from Hexadecimal in Haskell. Their weblog had yet another "sign up for a new account in order to comment" form, and, well, I'm all accounted out, so my reply is here:

import Numeric

read_h :: String -> Integer           -- inferrable
read_h = fst . head . readHex

main = let iVal = 123456
           hstr = showHex iVal ""
           hiv  = read_h hstr in
        do 
          putStrLn $ show iVal
          putStrLn hstr
          putStrLn $ show hiv

The weird thing about it was that I kept trying to assign to iVal inside the "do" section, and I never did figure out how to do it that way. Seems like it ought to be easy, but it wasn't being easy for me. Part of the issue is that there doesn't appear to be a simple "read one hex value from a string" function. Instead, there's this parser thing (readHex), that returns a List of Pairs. That's what the "fst . head . readHex" is about -- head takes the first part of the List; and then fst takes the first element of the Pair. (I think the second element of the Pair is the rest of the string that didn't get parsed.)

Learning and Teaching via Programming

Wed, 14 Feb 2007 07:45:24 GMT

Joe Gregorio mentioned that John Panzer wrote about Software development as knowledge acquisition. For decades, I've heard that the best way to learn about a subject is to teach it to someone. So, putting these suggestions together with a few of my own, we have:

Programming as learning (see above)
teaching as learning (google search tinyurl link)
and my own occasional assertion that the most understandable programs are written with the mindset of programming as "teaching a person how this program solves that problem"

There's some semi-related tangent here, but it'll have to wait until it resurfaces. Oh, yes, and as SICP puts it (in the online Preface to the First Edition):

Thus, programs must be written for people to read, and only incidentally for machines to execute.

Forth, Yoda on

Mon, 12 Feb 2007 16:38:44 GMT

On pragprog last week, Ged Byrne wrote:

Yoda forth program? if say ." a powerful ally is the forth " then

And on the python list about six years ago:

William Tanksley: Always doing things backwards, Forth programmers are.
Greg Ewing: Ah, that explains it ... household programmers Forth of in Yoda up grew.
Kragen Sitaker: household programmers Forth of of Yoda up grew in, think I. This silly is but.

And someone with way too much time on his hands wrote an in-depth analysis of "Yodish". Just thought I ought to bring these things together.