pathnames [Re: files, printers, etc. [Re: The feel of a Lisp

[Chris Bitmead uid(x22068)]

>> >You could write:
>> >
>> >(*employees* 'pictures #(picture of Lionel))
>> >(*employees* 'names "Lionel B. Snell")
>> >(*employees* 'surname "Snell"
>> >
>> >The directory objects "pictures", "names", and "surname" are all in
>> >fact accessors for one database-like object.
> 
>> So what's the deal with this very un-lispish syntax? Why not do things
>> the way it's always been done...
>> 
>> (search-by-picture *employees* #(picture of Lionel))
>> (search-by-name *employees* "Lionel B. Snell")
>> (search-by-surname *employees "Snell")
>> 
>> ;;people older than 50
>> ((lambda (list) (mapcar list (lambda (item) (- (date) (birthday item)) < 50)))
>> 		*employees*)
>
>Those are source code. 

Too right it's source code. This is lisp remember - code is data and
data is code.

The other point is that this is all supposed to be OO. Everything is a
message. It allows for polymorphism and customisation. Simple linear
lists are set in stone.

>My syntax is designed as what the user types in - 
>it's in a linear format, with specificity increasing to the right, that's
>common amongst humans, and is familiar from:
>
>http://www.ibm.com/blah/blah/blah/
>/bin/ls
>MyPtr->FieldPtr->Field
>struct.struct_field.field
>
>to name but a few :-)

Well mine is in functional format with specificity increasing from
inner to outer, that's common to lisp programmer humans.

(get-on-bus (go-to-bus-stop (leave-house (get-dressed (wake-up person)))))

If someone wants an interface suitable for dumb users, then that's a
different issue. I don't want to compromise the programming interface
to suit Joe Average. Joe needs something more poweful anyway. Joe
average has a hard time finding all the files he's got in his DOS
directories and needs all the smart CLOS methods he can get to find
the one he wants. Personally I'd make it graphical. You click on an
object, it shows you methods. You click on a method, and it prompts
you for arguments. You enter the arguments and it returns you the
resulting set of objects. You continue until you get the right object.

>Now, I feel that the user-level object system is there purely to aid
>the user in choosing an object. 

That's not why the POS is there. It is there to make the separation
between memory and disk completely seamless.

The object system (CLOS), is there to aid the user to choose an
object. This is fortunate, because CLOS can offer as many different
interfaces and methods for choosing objects as is deemed appropriate.

>Indeed, if an application wants all
>employees above 50, it would access the directory object of employees
>directly and ask it as you have written. But the pathparser would be
>used to convert the user's typings or selecting-from-list-boxes into
>a reference.

If an application wants to present a different interface then that is
the choice of the application. Most probably it will be graphical. You
will be asked to drag a document icon into a container icon for
example.

>*.* may become a popular name for a CWD, except it looks like a DOS
>wildcard :-)

Gggrrrrr..

>> I can't see how. What exactly is the symbols 'Public and 'Hello
>> supposed to be then?
>
>They are just one path to the object. Since we're just using symbols
>to access things, I'm assuming that we're using an underlying filer
>architecture that just binds symbolic names to stuff. 'Public 'Hello!
>may be one path to the object containing my text used to greet new friends,
>but "'Private 'Work-in-progress 'Publications 'NewUserHello" may be another.

So you're resricting the whole POS so that it can only be keyed on
symbols?

(search-by-picture *employees* #(picture of Lionel))
(search-by-name *employees* "Lionel B. Snell")
(search-by-surname *employees "Snell")

The question remains... What are you going to do to solve this^^^ ?