Adlai said we should make an emergency release of Sheeple, since he added effective reply function caching. I agreed. If you do -any- sort of semi-serious data crunching using Sheeple, stay the hell away from 3.0.2!
Tag Archives: lisp
Sheeple 3.0.2
It’s taken a while to get this release out — we kept adding stuff on — but it’s finally out. Even though it’s a minor version bump, there’s some important API changes with this new version, including the complete removal of ADD-PROPERTY. Originally, I thought it would be a good idea to force users to add a property manually before being allowed to set a value. Then I realized that the Python community has had this ability for a very long time. The freenode Pythonistas seemed to pretty consistently agree that it had never caused serious problems. Thus, A-P is gone, and (SETF PROPERTY-VALUE) is now used to both add a property, and to set a value on existing ones.
There is also now a manual! A pretty one in both PDF and HTML form, which can be found at our new project page on common-lisp.net. There’s also some mailing lists on that page you might want to sign up for if you feel like tracking Sheeple development.
Things have slowly been ramping up. Ever since I gave that talk at the TC Lispers meeting, a few other people have given Sheeple a whirl. I’m pleased that their experiences have been good, even though Sheeple is still a bit unstable. Of particular note is Patrick Stein’s Wooly, a GL-based GUI toolkit using Sheeple objects.
Development has slowed down a bit since I started working at Clockwork, but I’ve been working with Adlai lately towards a native-Sheeple MOP. So far, the basics of object creation have been taken care of, and a property MOP should be up and running soon. We’ve also decided to rename persistent-sheeple, but that will get announced once we have enough of a MOP to hook up our objects to CouchDB.
Release: Sheeple 3.0
Sheeple 3.0 is finally out!
After months in development, it’s finally done. A major rewrite of the entire Sheeple system, this new version boasts a completely new, cleaned up, and serious’d interface, reworked, lightweight objects, and efficient property access (right now, matching CCL’s slot-value performance.) You can download a tarball here, or use asdf-install to grab the latest version.
I’m really excited about this release. I would write more about it and all the goodies it has, but I have a presentation to finish. Expect more in a later post.
Introducing: ChanL
For the longest time, I wanted to start learning about issues related to concurrency, and how to handle them in Lisp. I kept reading around to learn about different approaches to writing concurrent code, and studied up on things like Software Transactional Memory, futures/promises, and Erlang-style actors. After boggling to understand all these different approaches, I was left with a bit of disappointment: None of them seemed to be the right combination of generalized+clean+easy.
STM caught my eye for a while, but it still has its issues, and I’m still not sure how I feel about the whole “thrash until you can agree on something” issue — it seems to me like it’s just the same as wrapping code in (with-lock-held …). Futures/promises looked easy enough for simple one-shot tasks, but that’s not necessarily what you want to do when you write heavily-parallel code: Sometimes you want threads constantly yielding values. Erlang-style actors are, of course, one of the big success stories when it comes to people trying to write heavily-parallel code. It just seems so damn ugly — and it -is- nice to be able to share data sometimes.
Then, magic happened: I came across something called Communicating Sequential Processes, through Rob Pike’s Google Tech Talk on Newsqueak. It was really amazing, it seemed to be just what I needed: a relatively low-level synchronisation mechanism that works naturally with the concept of multiple parallel threads/processes. I’m totally sold on Rob’s point of view here: don’t try to pretend you’re not parallelizing code (hear that, STM? That’s right). Instead, make the parallelization part of your interface. Deadlocks are a bug — find them.
Continue reading
Sheeple continued: Dispatch
In the last entry, I wrote a bit about the basics of how object instantiation and property/slot access works in Sheeple. In this entry, I’ll introduce a whole different realm of Sheeple: the method dispatch system. If you’re familiar with Javascript, it might already be obvious to you how polymorphic method dispatch can be implemented with the small bit of Sheeple we know so far:
SHEEPLE-USER> (add-property *sheep* 'foo (lambda () (print "Method called!"))) #<Sheep #x15031356> SHEEPLE-USER> (foo *sheep*) #<Anonymous Function #x1506C446>
For those confused: the above equivalent in javascript would be:
sheep.foo = function () { alert("Method called!"); }
sheep.foo -> function object
And there you have it. Actually calling the function is just a matter of using Lisp’s version of adding () at the end of a variable:
SHEEPLE-USER> (funcall (foo *sheep*)) "Method called!"
In JS:
sheep.foo(); => an alert pops up. The method was called.
Introduction to Sheeple
For a few months now, I’ve been working on something I call Sheeple. What is Sheeple? From the
official description:
Sheeple is a Dynamic, CLOS-like, Delegative Prototype-based Object-Oriented Programming
Framework (or “POOP Framework”) that strives to optimize application flexibility, minimize cost
while increasing value, maximize programmer resources, and empower application implementers to
better assist them in leveraging modern paradigms in order to proactively achieve next-generation
synergy in tomorrow’s web 3.0 world. It is implemented in (mostly) ANSI Common Lisp. Sheeple is
fully buzzword compliant.
Now that doesn’t really say much of anything, but it’s
amusing, specially since some actual (professional!) projects actually describe things in such a
way.
What does it actually do, though?
Well, Sheeple is a library for Common Lisp that implements a Prototype-based object-oriented language very similar to Common Lisp’s standard CLOS. It does things like multiple dispatch, multiple inheritance and such.
One goal I had while designing it was to have it be as practical as possible. Javascript is making waves around the internet these days — not just because it’s the de-facto standard browser-scripting language, but because it’s prototype-based.
The idea of having a prototype-based language instead of using classes for OO is nothing new. Even so, it seems like there’s still debate about the merits of using prototypes instead of classes. In fact, some prototype-based languages, specifically Javascript, have libraries that implement classes!
Even though there are various languages to choose from, there are still few languages that provide what I would consider full facilities. Cecil seems to be one of those ‘full’ languages, but I really ended up disliking its approach — it was too complicated, and there were too many obvious minefields. Sheeple is an attempt at providing the kind of massive framework CLOS provides for class-based OO, but with prototypes, while remaining easy-to-use, straightforward, and most importantly, convenient. Whether it’s successful at this right now (it’s still in development after all), and whether it will ever be is a different question. ;)
Continue reading