Antonio pointed me to one of his projects called ObjShell. It was little shocking – in objShell were the basic ideas of Monad, in a sense. ObjShell was research project done at the University of Pisa and was once present at MSR Cambridge.

This is the project page:

http://medialab.di.unipi.it/Project/ObjShell/

ObjShell isn’t very complete and requires much work before it is usable, but the core idea is that it wraps is a valuable one. Let me quote from the docs (added later: Antonio has a follow up post to this one and on reading it one may have a different perspective - I must say ObjShell could use some more documentation).

Shells issues discussed above may be addressed by component technologies leading to a new generation of shell that allow to access components that support arbitrary interfaces. Next generation shells must allow to combine system components that expose different interfaces. Moreover there must be the possibility of separate process and components having one process that executes methods of several components.

Figure 2. A new shell that allow combine general components.

Figure 2 shows the new role of the shell: instantiating and linking components to obtain an assembly that is able to solve a problem. The goal is to provide a suitable language that is able to offer such generality and at same time offer a convenient syntax for expressing components' composition.

ObjShell has been designed for supporting a new archiecture that offer both generality and flexibility of syntax for expressing commands.

The central idea behind ObjShell is that there can be a better model of composition than stringing together processes bound by text streams. ObjShell aims to have the shell provide an environment that allows plugging together of components. In the present build of ObjShell, it allows the usage of COM components over which the shell acts like the glue.

So the user of the shell uses the shell as an environment to plug together components to get a task done. You might have heard some of the old unix docs describing text as the universal interface – shells like this one try to replace that with a more programmatic interface and thus provide a better model for composition.

Monad is similar in this respect that it tries to provide a better model of composition – however Monad is closer to traditional shells in that it does not directly leverage a component model like COM or .Net, instead leverage components called Cmdlets which are .net components which follow certain rules (by rules I mean then inherit from a certain class / implement a certain interface / have certain attributes etc). Also Monad provides for glue between components by providing streams of .Net objects, to replace text streams in the old world.

(rewritten:) ObjShell interacts with users using 'Readers'. A reader reads an input stream and manipulates it into valid jascript that is executed internally. The jscript in turn makes teh calls on the objects and returns results. You coudl think of it being similar to intercative shells of languages like Python and Ruby where the shell displays a prompt at which you could type instructions of the language and the shell responds. ObjShell is different in that it goes a step further and allows you to type commands in a more shell-like syntax instead of compelling you to write javascript and  make method calls. (/rewritten)

There is a discussion with Jeffrey Snover, Architect of Monad on the MSDN show. There is this interesting part in the show (other than all the other cool things) where he calls Monad the third great pillar of composition. That is an episode worth watching.

Thinking of composition and command lines I have been thinking of my own work with Netshortcut. While the initial release of NS (which is what is available now for download) is on a different tangent, the plans for the new NS bring it close to the world of command shells. It however takes a different approach from Monad and ObjShell.

I do wish Antonio and team continue work on ObjShell to create a .Net version. It is will be a nice future where windows has different command shells to choose that offer different fundamental models of abstraction and composition built around the same object model called .Net.

Prev:

Msh/Monad: Cmdlet parameter binding
Introductory entry about Monad

Other:

Pooja: Monad Session at Bangalore User Group Meeting (lots of examples here)
Pooja: On getting the Monad installer to work on Win2k

Almost every macro demonstrates a flaw

in the programming language,

in the program, or in the programmer.

        - Bjarne Stroustrup

I find it unbearably restrictive

to program in languages without macros ...

        - Paul Graham

It took me some good time today getting my mind around macros in scheme. The discussion in Dorai Sitaram’s book is a not very descriptive. I had a look at Prof Kent Dybvig’s chapter about syntax and figured that that is something I want to look at only later.

However after a bit of mucking up I think this would work.

(require (lib "defmacro.ss"))

(define-macro let* (lambda (args . code)

        (if (null? args)

                `(begin ,@code)

                `(let

                        ,(list (car args))

                        (let*

                                ,(if (null? (cdr args))

                                        ()

                                        (cdr args))

                                ,@code)))))

(display

        (let*

                ((a 2)(b (+ a 10)))

                (+ a b)))

Thinking in scheme needs some getting used to.

I have been looking at a bit of scheme in my free time. Not strangely, most of the code I seem to write seems to be very C like.

(define rev1 (lambda (ls)

        (let loop ((res ()) (ls ls))

                (if (null? ls) res

                        (begin

                                (set! res (cons (car ls) res))

                                (loop res (cdr ls)))))))

(define rev2 (lambda (ls)

        (let loop ((left ls)(right ())(temp ()))

                (cond ((null? left) right)

                        (else

                                (set! temp (cdr left))

                                (set-cdr! left right)

                                (loop temp left ()))))))

(print (rev2 '(1 2 3 4 5)))

I understand that learning the language is very different from learning to program with it. For now I am learning the language from Dorai Sitaram’s “Teach Yourself Scheme in Fixnum Days”

Annie’s song is playing right now.

The sky looks gray now, like the color of old memory.

Annie's Song

You fill up my senses

Like a night in a forest

Like the mountains in springtime

Like a walk in the rain

Like a storm in the desert

Like a sleepy blue ocean

You fill up my senses

Come fill me again

Come let me love you

Let me give my life to you

Let me drown in your laughter

Let me die in your arms

Let me lay down beside you

Let me always be with you

Come let me love you

Come love me again

You fill up my senses

Like a night in a forest

Like the mountains in springtime

Like a walk in the rain

Like a storm in the desert

Like a sleepy blue ocean

You fill up my senses

Come fill me again

John Denver

A few days back I found what seemed to be a book about Ruby. This was being discussed on the Ruby mailing list. It’s called “A Little Ruby” or more precisely “A Little Ruby. A Lot of Objects”. You can find it here:

http://web.archive.org/web/20030618203059/visibleworkings.com/little-ruby/

(Someday it will be available here: http://www.visibleworkings.com/little-ruby/ )

Instead of writing the whole thing myself or copy paste it, I ask you to simply go read the book. That is my blog entry for the day.

The “Little Ruby” book is a conversation between two people where some sublime ideas about the design philosophy of the Ruby language are discussed. The book itself is a pleasure to read and more importantly, to think about. (It is an incomplete book, only 3 chapters – the author Brain Marick said on the Ruby list that he hopes to complete it sometime).

Reading “Little Ruby” put in a phrase in my thinking – “Model of Computation”, I don’t know if this sounds sober, but I think this is what I am really looking for.

In all my tinkering around languages, compilers, runtimes and other things – I am looking for a Model of Computation, a fundamental set of programmatic thought abstractions that are beautiful and can encompass various forms of programming.

The Little Ruby book talks about a model of computation where all computation is simply built around the idea of passing messages to objects. It is a simple concrete idea with which the rest of the Ruby world is built (apart of syntactic sugar). I don’t know if you are used to thinking in this way – but it is a powerful form of thought.

Let me quote from one of the conversation toward the end of the third chapter (the last chapter that is written so far):

“A language that provides lots of features

will always be missing that one feature you

need.”

“But a language that chooses the right

simple rules for you to combine lets you

build the features you need.”

This is the basic idea of composition – small integral units that compose to produce powerful behavioral entities. Have you ever thought why a unix command shell guy never really thought much of a Win/Dos user – because somewhere the way the shell forces you to thinking terms of composition of small do-one-thing-well tools and create powerful meta-tools, is a greater thought pattern.

You might have heard this being said about tools in the old unix culture (I say ‘old’ because I have different opinions of ‘unix’ culture as it is now)

"This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."

--Doug McIlroy

The “Little Ruby” book is inspired by the old book “The Little LISPer”. Something that is now on my reading list – I can’t seem to get a copy of this anywhere. The present edition of the book is called “The Little Schemer”. The book is co written by Prof Daniel P Friedman of Indiana University and Prof Matthias Felleisen of Rice University. The Little Schemer discusses a different model of computation from what the “Little Ruby” describes.

I did not know this then, but sometime last year I was in email correspondence with Prof Friedman. That time, had I known that he is author of a respected LISP text book, I might have been frightened off the prospect of asking this -  but in one of the mails I had asked “why Lisp?”

Roshan,

The most fundamental building block of computation is composition. If the language does not support composition in a trivial way, then I have no use for it.  ML, Haskell, LISP, and Scheme each give a kind of composition.  Composition is the building block of Category Theory, which is a unifying tool that helps clarify much of mathematics. and logic.  So, thinking that it would be okay to use a language that does not support composition is impossible for me.

(I quote this here presently without his permission, I believe he would be ok though).

I didn’t understand him then. But now after a year, I think I am closer to understanding him.

What would a unified model of computation be? Can such a thing exist? Can we think of all computation using a set of minimal and powerful abstraction such that every other form of computation can be built out of it. Can this be one that is easy and fun to use that we could interact with this force on a day to day basis.

And what forms the underlying foundation for computation then might also form the underlying basis for other systems of organized thought as well. This is like the dream of Grand Unified Field Theory in physics. Can something like that exist in the computational systems as well?

I don’t know enough to guess. But however I believe that as long we keep pursuing computing in a way that is fun and simple, we are probably on the right track.

To end this entry I want to quote from the preface of the little ruby:

Welcome to my little book. In it, my goal is to teach you a way to think about computation, to show you how far you can take a simple idea: that all computation consists of sending messages to objects. Object-oriented programming is no longer unusual, but taking it to the extreme - making everything an object - is still supported by only a few programming languages.

Can I justify this book in practical terms? Will reading it make you a better programmer, even if you never use "call with current continuation" or indulge in "metaclass hackery"? I think it might, but perhaps only if you're the sort of person who would read this sort of book even if it had no practical value.

The real reason for reading this book is that the ideas in it are neat. There's an intellectual heritage here, a history of people building idea upon idea. It's an academic heritage, but not in the fussy sense. It's more a joyous heritage of tinkerers, of people buttonholing their friends and saying, "You know, if I take that and think about it like this, look what I can do!"

As a closing note, sometime last year I was looking to do research under someone working with the SSCLI code base and work on virtual machines and runtimes. I wanted to do my Masters.

At that time the best way I could describe what I wanted to do was to say that I was looking runtimes and virtual machines research with a specific interest in SSCLI. Now, maybe I can describe myself a little better.

The only way I could think of doing this that time was to ask around in online forums and mailing lists about universities doing work with Rotor. That accompanied by a barrage of mails to everyone who I thought might know, or point me in the right direction. One name that came up was of Prof Ralf Johnson of UIUC. Right now I was looking for Brian Marick (author of little ruby) on Google, Brian is research student doing his PhD under Prof. Johnson.

India Advocates Day(s) 2004 happened a few weeks back (29 and 30th May) – MVPs, Microsoft Regional Directors and a select few Student Champs are invited. The event this year was at the luxurious Park Hyatt at Goa.

Images from the Park Hyatt - IAD 2004 venue.

Pooja at IAD.

Me - Self picture at the Hyatt beach

MVP crowd - also (first from left) Abhishek Kant - India MVP lead and
(fourth from left) Shu-Fen Cally Ko - Regional Director for MVP Program and Community - Asia Pacific and Greater China Region

IAD conferencing

Churches of Old Goa - Bom de Jesus

I just had to drop these links at the expense of a separate entry, for them.

http://primates.ximian.com/~miguel/archive/2004/Jun-08.html

http://primates.ximian.com/~miguel/archive/2004/May-31.html

(The Marcelo in the last picture on this entry is Marcelo Tosatti – Maintainer of the Linux kernel)

There are reasons why many of my friends who work non Linux technologies are generally treat work on Linux as user hostile and generally immature. I personally think that while the majority of the Linux crowd may have their head in the clouds, the serious programmers are the same sort of the free style systems hackers that we idealize – despite the difference in technologies. I appreciate these folk for their spirit and sometimes for sheer smartness.

With some things cleared up and some ground work done, here is one of the first the things I want to talk about in Monad – the new Microsoft Command Shell(msh).

In my first article I talked about ‘cmdlets’ and that they return .Net objects. Here is one other smart and subtle thing they did with Monad – Parameters to cmdlets come not only on the command line but can also come from objects in the input object pipeline.

Some basic stuff on cmdlets and parameters which might help set the stage for understanding things. A command-let can define fields/member variables as part of the command let class. These fields can then be decorated by attributes so that they can be treated as parameters to the commandlet.

In code it actually looks like this:

[CmdletDeclaration( "demo", "cmdlet" )]

public class HelloWorld : Cmdlet

{

        [ParsingPromptString("Enter a string to echo: " )]

        [ParsingParameterMapping(0)]

        [ParsingMandatoryParameter]

        [ParsingAllowPipelineInput]

        private string message;

(This snippet is a modified version of code from the beta documentation)

Now this might look a little over decorated with attributes, but the thing I want you to notice is that that is a member called ‘message’ which simply has a few attributes applied. Applying those attributes causes ‘message’ of type System.String to be a parameter required for our command let.

Unlike traditional command line exes, the responsibility of parsing the command line options and assigning them to internal variables is not the responsibility of the program but is automatically done for you by the Monad shell.

Which is to say that by the time code that you write in the cmdlet is executed, values are already assigned to the parameter variables by the shell. (Not strictly, but almost).

The shell can let you assign parameter values either by specifying them at a certain postion in the command line – for example argv[1] will be the value for ‘message’, argv[2] will be the value for something else and so on. Or the shell lets you  specify the parameter name and then the value

> demo-cmdlet –message “hello world” -< parameter name >  < value >

The other good thing (which is new and what this log entry was about) is that the value for a parameter can be extracted from an object on the pipeline if the object has a field/member of the same name. (The types have to be consistent)

So if I have a command let that generates an object of type foobar that has a member of name ‘message’, I can pipe the output to the commandlet that required a parameter of name ‘message’ and it would all work.

> create-foobar | demo-cmdlet

Would create foorbar instances that get piped to demo-cmdlet which uses the ‘foobar.message’ as its message parameter.

Where would this be used?

For an example there is a command-let called ‘get-process’. It lists the running processes on the system. To be more precise it returns a collection of process instances which get standard formatted to the console.

MSH 5 C:/>get-process

ProcessName                  Id   HandleCount   WorkingSet

-----------                  --   -----------   ----------

CcmExec                     288           480     14008320

cmd                         804            22      1421312

csrss                       464           669      4743168

dfssvc                      316            70      3260416

DWRCS                      1444            44      2560000

explorer                   3520           366     20926464

FrameworkService           1544           303      9367552

Idle                          0             0        16384

Similarly to see all the instances of notepad that are running I would simply say

MSH 16 C:/>get-process note*

ProcessName                  Id   HandleCount   WorkingSet

-----------                  --   -----------   ----------

notepad                    3912            16      1912832

notepad                    4044            16      1912832

notepad                    3056            16      1912832

Now there is a cmdlet called stop-process which can terminate a process if you pass it the process id as a parameter. The parameter name that stop-process expects is called ‘Id’.

MSH 11 C:/>command stop-process

Command: stop-process

Command Parameters:

        Id                    : Int32[]         : Optional

        ProcessName           : String[]        : Optional

So with all the earlier talk you can conclude that if I simply wanted to kill all the instances of notepad that are running I could type

MSH 11 C:/>get-process note* | stop-process

Now isn’t that clean? Just to add a bit of garnishing to that, Monad defines ‘ps’ as an alias to get-process and ‘kill’ as an alias to ‘stop-process’.

So now you can say

MSH 11 C:/>ps note* | kill

Cool? This works on Monad today.

Prev:

Introductory entry about Monad 

Next:

ObjShell: A precursor of Monad?

Folk, after a few mails we got confirmation from Jeffrey Snover himself, architect of Monad, clearing up any NDA issues. We are free to blog, write articles, talk about it etc etc.

Among other things watch out for the next .Net show on MSDN, they are covering Jeffrey Snover talking about Monad. Here is a blog entry by Robert Hess:

http://blogs.msdn.com/theshow/archive/2004/05/19.aspx

Also there is a build of Moand that might be made available in July which is more complete in the shell language than the present build is. That’s a lot to look forward to.

Meanwhile on a personal front this, gives us the personal freedom to explore Monad and talk about it