To be fair, the FOOP operator, :, does not provide any truly new functionality to newLISP. However, it does make prototyping much more concise and expressive.

The basics

Prototyping is accomplished using a source context (a lexical closure) and the new keyword. Using the commonly contrived example of the Rectangle object:

(context 'Rectangle)
(set 'x nil)
(set 'y nil)
(define (area) (* x y))
 
(context MAIN)
(new Rectangle 'my-rectangle)
(set 'my-rectangle:x 10)
(set 'my-rectangle:y 20)

FOOP uses the convention of (object member member ...) for storing object instances. Instance data, apart from the members, is encapsulated within the context, so all of the methods may access contextually set variables. Although not built into the interpreter, the functional convention,

(define (Class:Class) (cons (context) (args)))

…is typically used to create new contexts for FOOP. Using Class, the above example would be written as:

(new Class 'Rectangle)
(set 'my-rectangle (Rectangle 10 20))

Methods are attached via the normal syntax for declaring foreign context functions, but with the assumption of the argument being the (object member member ...) convention and implicit indexing:

(define (Rectangle:area self)
    (* (self 1) (self 2)))

All of the normal operations that apply to contexts remain applicable for contexts created in this fashion. One interesting element of FOOP is that the methods and namespace are separate from the object’s properties. Therefore, an arbitrary list of values can be consed by a cloned context to create a new instance.

Constructors are easily overridden using default functors. In fact, Class:Class merely automates the creation of a default functor for a new context.

So, if we wanted a Rectangle with default x and y values:

(define (Rectangle:Rectangle (x 10) (y 10))
    (list (context) x y))

Solving problems with FOOP

Although FOOP would not be considered a true object oriented system by purists (who would call it prototyping), it is an excellent substitute for a true type system. For example, here is a simple interface for probing and validating command-line arguments:

;; In case Class is not yet defined, attempt to define
(catch
  (define (Class:Class)
    (cons (context) (args))))
 
;; Declare our classes
(new Class 'Option)
(new Class 'Switch) ; Option's identifying token
(new Class 'Required) ; Defines option as required
(new Class 'Predicate) ; Lambda to validate and option's value
 
;; Define a method to find this option in (main-args)
(define (Option:get self , loc val)
  (set 'switch (last (assoc (self Switch))))
  (if (set 'loc (find switch (main-args)))
    (cond
      ((and (starts-with switch "--")
            (catch (nth (+ 1 loc) (main-args)) 'val))
        val)
      ((starts-with switch "--") true)
      ((starts-with switch "-") true)
      (true nil))
    nil))
 
;; Define a predicate to validate the value of our option.
;; In case the option does not come with a value, we skip the predicate
;; part and validate solely based on the value of Required.
(define (Option:valid? self , val req pred req? pred?)
  (set 'val (:get self))
  (set 'req? (assoc (self Required)))
  (set 'pred? (assoc (self Predicate)))
  (set 'req (if req? (true? val) true))
  (set 'pred (if pred? ((last pred?) val) true))
  (and req pred))

The Option class is made up of several other classes, Switch, Required, and Predicate. Switch is the token to identify the option in the command-line arguments. Switches that begin with — can take an optional value, such as --url http://www.artfulcode.net. Required is another empty class that only needs to be a boolean value. Predicate optionally stores a lambda that will be used to validate the value found in (main-args).

Here is a sample of how we might use Option:

(set 'url (Option
    (Switch "--url")
    (Required true)
    (Predicate
        (lambda (val) (true? (regex {^http://.*?$} val 17))))))

For a single on/off switch, we can do:

(set 'some-option (Option
    (Switch "-s")
    (Required nil)))

To get the values and validate them:

artful:~ newlisp test.lsp --url http://www.artfulcode.net -s
 
(url:get) ; => "http://www.artfulcode.net"
(some-option:get) ; => true
 
(url:valid?) ; => true
(some-option:valid?) ; => true

And for non-validating values:

artful:~ newlisp test.lsp --url "Hello world"
 
(url:get) ; => "Hello world"
(url:valid?) ; => nil

newLISP 9.3′s new association list processing functions make accessing member cells a snap – (assoc (object key)). Obviously, this is more expressive and concise than a lot of recursive parsing of (main-args). The trade-off is the same as with any use of OOP: contexts are more expensive than list processing, especially when creating many small context instances.

This is obviously a contrived example and could be solved more efficiently quite easily, but it does a good job of illustrating FOOP.

What makes it functional?

That’s tough to quantify. However, if we want to shorten the class declarations in the code above to simplify our code, we could use use the higher order functions map and curry:

(map (curry new Class) '(Option Switch Required Predicate))

Other examples might be to compose custom classes as needed using macros, updating a list of class instances using map, or currying class constructors to extend classes.

What next?

There are better and more extensive tutorials available in video form courtesy of Michael Michaels of neglOOk available on the newLisp website.

download

Submit article

My previous experience with Java was as a less experienced programmer and I had some difficulty with the type system. I learned on dynamically typed languages. My first experience with static typing was in modern functional languages, where type was inferred automatically by the compiler. Explicit type declarations felt archaic and overly wordy.

My experience this time around, however, was more positive. This is primarily due to three factors.

NetBeans

NetBeans is Sun’s Java IDE. Because it is mostly limited to Java, its syntax formating is excellent. It takes a lot of code to abstract the ability of an IDE to format multiple languages (in particular, the ability to format both C-style languages and Lisp-style languages using the same application primitives presents difficulty). NetBeans has the Apple advantage in this; one language to support means that it can have excellent support for that language. Of course, this means that projects that use multiple languages are more difficult to develop using NetBeans, so perhaps this tradeoff is not worth it.

Java’s self-documentation is very nice, too. NetBean’s code-hinting is superior to most, although it can get in the way.

The GUI builder is also extremely nice. Swig and AWT can be a real trial in a language as wordy as Java (although I think Sun prefers us to call it “explicit.”)

Classes

I initially had some difficulty writing entire programs in objects. Most languages I use that are object oriented are multi-paradigm. Classes are available, but then utilized within functional or procedural code. Because of this, I tend to regard classes as a sort of extra-powerful type struct, only to be used when a type becomes complex enough that the extra work of encapsulated it within a class becomes advantageous.

It’s (unfortunately) common to see new Lisp programmers try to simulate OO in Lisp using closures and hashes (especially if they’ve read a few Paul Graham essays). I don’t particularly see that OO improves Lisp; closures and templates provide roughly the same functionality. Exactly replicating closures in OOP or objects in functional programming would be moot. They are different styles; Java-style programming is as uncomfortable in Lisp as Lisp-style programming is in Java.

While writing my initial applications, though, I realized something: classes are a formalized closure syntax. They are a function that builds functions and closes over their variables.

This freed me to use a style of abstraction in Java that felt much more comfortable to me without the drawback of attempting to use the wrong paradigm for the language. I could now program using classes and objects in a manner consistent with how I mentally model my applications.

Something I missed quite a bit was pattern matching. It is very helpful to declare local variables based on the pattern of the argument(s) passed to a function, but that would not be useful in Java, since the primary type mechanism in Java is the class rather than the list. Method overloading provides much of the same functionality, but idiomatic of Java.

Write once, run everywhere

Lisp pioneered the virtual machine. Lisp is compiled into code that is run within the Lisp interpreter. But Lisp is not commonly installed on computers, so distribution of Lisp software becomes a real challenge. One of the advantages of having a huge amount of money behind a language is that Java is installed on virtually every computer a program may end up on.

It’s common in Lisp to have to code various parts of the program differently depending on the operating system and Lisp distribution. For example, very few Lisps support multi-threading on OSX. It makes it agonizing to write threaded software for a multi-platform application.

Java does not have this problem. A feature is available on all platforms or none at all. While this means that the language sometimes suffers from the lack of a particular feature, it also means that there is a guarantee against discovering too late that a feature used in the core of your program will not limit its utility on other operating systems.

Conclusion

Java is better than I had given it credit for. With NetBeans taking care of checking your work for you, I am beginning to suspect that the many buggy Java programs are due to poor programming rather than a problem inherent in Java itself.

I still have some doubts as to how useful it would be for a very large project; my experience has been that object orientation and inheritance results in unnecessary complexity.

For small projects and GUI applications, though, Java seems to be a fair choice.

Submit article

I tend to agree with this thinking. OO is not the singular technique for code abstraction. It is useful because it maps closely to how the brain conceptualizes entities. Spot is a dog. Spot barks. Spot wags. Spot contains a mutable state that describes him, and he responds to certain inputs. Spot is an instance of canine, which in turn is an instance mammal, ad infinitum.

OO is a conceptually precise way to program, but it comes with a complexity and redundancy. As my mantra states, expressiveness > efficient > elegant > idiomatic. Redundancy and complexity get in the way of expressiveness.

The article at Irrational Exuberance mentions antiobjects as a way of avoiding some of the overhead and complexity problems of OO without abandoning OO completely. The context used is that of programming a MUD (with which I am just as guilty of wasting my teen years as the author). The program defines Player and Item, with individual items subclassing Item. A player can use an item. The author shows how the methods for equipping an item can be stored in the player object or the item object, and that the latter (an example of using antiobjects) was more efficient.

In fact, the latter is more expressive as well. It is not the person that determines how the item is used, but the item itself that describes its use (in the context of the game). A player would not eat a sword. This adds a logical constraint that does not mimic the real world – a player could eat a sword. It’s got iron in it. Very important for you, iron. Practically a health food.

But in the context of the program, that would be ridiculous and would require a heck of a lot of extra coding work, adding an enormous amount of complexity to the program. That’s a lot of work just to get a little extra iron in your diet.

One option the author did not explore at all is that OO might be overkill for the job. In a MUD, players and items are not overly complex concepts. A player had experience, level, items… and not much else (in many of them, at any rate). For something this simple, here is an approach that is at least as expressive, simpler, and easier to maintain. Although the author is using Ruby, this example is written in newLisp (using contexts as dictionaries), because it is seldom wise to miss an opportunity to write something in newLisp ;)

;;; 'item is a hash of tables
(context 'items "sword" '((use "wielded")))
(context 'items "chest-armor" '((use "torso")))
(context 'items "leg-armor" '((use "lets")))
 
;;; 'Player is a hash prototype. Defined using
;;; this syntax for clarity and simplicity.
(context 'Player)
(set 'inventory '())
(set 'wielded nil)
(set 'torso nil)
(set 'legs nil)
(context MAIN)
 
;;; Player actions
 
(define (own player item)
  "Adds item to player's inventory."
  (push item player:inventory))
 
(define (equip player item)
  "Equips an item from a player's inventory."
  (if (find item (context player "inventory"))
    (and
      (context player (lookup 'use
        (context items (string item))) item)
      (println "You equipped your " item))
    (println "You have no " item)))
 
;;; Now let's test it
 
(new 'Player 'Joe)
(own Joe 'sword)
(equip Joe 'sword)
(equip Joe 'leg-armor)

Including whitespace, comments, and examples at the end, the example is 35 lines. It also includes logic to verify that the player has an item in inventory and messages to the player in response to commands. Not bad. Expressive, efficient, and concise. And, because this version does not require the replication of many very similar objects, we are not wasting memory and avoiding a lot of introspecting code to keeps everything aligned.

Albert Einstein said, “Everything should be made as simple as possible, but not simpler.” OO is predicated on the concept of a program as a microcosm of the universe. This puts a lot of responsibility on a programmer’s shoulders. As a programmer, there is a tendency to want to create objects as extensible as possible; it becomes necessary to constrain each object to avoid unnecessary complexity. In many instances, that sort of extensibility is like sand-blasting a soup cracker. There are simpler abstraction techniques that reduce code complexity and redundancy and incidentally result in faster software.

Submit article