Reasons for rejecting CLOS 
Author Message
 Reasons for rejecting CLOS


+---------------
| There is a great temptation in standards work to standardize things
| that are not tested, but it's pretty risky.
+---------------

Too true. Unfortunately, the groups which standardize communications
hardware, protocols, & data formats seem to have forgotten this. Ethernet
and HIPPI were about the last to have a working implementation *before*
standardization. In that arena at least, the usual case these days is
design-by-standardization-committee, *then* implementation. (*sigh*)

Some have attributed this trend to a competitive/political principle
whimsically called by your truly "maximum mutual disadvantage". That is,
if there are no working implementations before the standard gets written,
then no one vendor has a head-start advantage over another.

Common Lisp is indeed fortunate to have been hammered out before this
trend became as strong as it is today...

-Rob

-----

Applied Networking               http://www.*-*-*.com/
Silicon Graphics, Inc.          Phone: 650-933-1673
1600 Amphitheatre Pkwy.         FAX: 650-933-0511
Mountain View, CA  94043        PP-ASEL-IA



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS
On Mon, 10 May 1999 02:53:28 GMT,

Dobes> (defmethod learn (kb (f my-fact) tl) ... )
...
Dobes> On the other hand, (LEARN KB F TL) is no longer equivalent to
Dobes> KB->(LEARN F TL),

why not? If learn(f,tl) is defined for a number of different types, you have
the same situation.

Dobes> and maybe instead decides to have side effects on F
Dobes> instead of KB

it could have done that all along, and the same is true for the single
dispatch

Dobes> (we don't know, and there is no way to find out) while
Dobes> still using the same generic function.  

generic functions are like interfaces; they specify an API.

Dobes> The other approach means that we do know, given an object's API,
Dobes> whether it is that object or another that is most likely to be
Dobes> operated on.

do you mean: the object that is most likely to have its state changed. I
don't know what the prevalent coding style in CLOS is (any takers?), but
would be surprised if people randomly change the state on just any of the
argument objects that takes their fancy. I suppose I would use explicit
setf's for most state changes, and would have most generic's not change the
state of any of their objects, operating non-destructively where possible.

BTW, your 'most likely to be operated on' also suggests that you can't do
without additional rules in the form of stylistic conventions; same as in
CLOS.

                                                                      Philip
--
The mail transport agent is not liable for any coffee stains in this message
-----------------------------------------------------------------------------

+44 (0)1223 49 4639                 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           | Cambridgeshire CB10 1SD,  GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:

> Command Line parameters...... on a Mac?

MacOS X?


Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:

>  #!/bin/sh
>  /usr/bin/cmucl -core /usr/local/lib/myprog.core -eval "(startup)"

>or

>  #!/bin/sh
>  /usr/bin/cmucl -eval '(load "/usr/local/lib/myprog/main.fasl")'

>*is* a real executable file.

In Linux 2.2.X with the binmisc module, any .x86f file is a binary file.

pvaneynd:~$ less /usr/doc/cmucl/examples/Demos/register-lisp-as-executables.sh
#!/bin/sh
echo ':lisp:E::x86f::/usr/bin/lisp-start:'  > /proc/sys/fs/binfmt_misc/register
# this should only work for root under linux 2.1.XX or later
# now you can do "chmod a+x hello.x86f" and
# ./hello.x86f
# from your favorite shell.

pvaneynd:~$ less /usr/doc/cmucl/examples/Demos/lisp-start                      
#!/bin/sh
/usr/bin/lisp -load $1

There is even a demo of how to use a lisp-server to wait for commands, so you
avoid the startup-delay of cmucl...

pvaneynd:~$ less /usr/doc/cmucl/examples/Demos/Start-up-server.lisp
(in-package :user)

(format t "THIS A A HUDGE SECURITY RISC. CHANGE THE PASSWORD!!!~%~%")
(setf mp::*idle-process* mp::*initial-process*)
(mp::start-lisp-connection-listener :port 6789 :password "Clara")

;;; now you can telnet in and do:
#|
$telnet localhost 6789
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Enter password: "Clara"

CMU Common Lisp Experimental 18a+ release x86-linux 2.2.0 cvs, \
running on slartibartfast
Send bug reports and questions to your local CMU CL maintainer,



type (help) for help, (quit) to exit, and (demo) to see the demos

Loaded subsystems:
    python 1.0, target Intel x86
    CLOS based on PCL version:  September 16 92 PCL (f)
* (+ 1 1)

2
* (quit)
Connection closed by foreign host.
|#

Groetjes, Peter

--




Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

| Some have attributed this trend to a competitive/political principle
| whimsically called by your truly "maximum mutual disadvantage".

  it started when some new suits at ISO wanted ISO to be more visible in
  the market and feared "competition" from fairly stupid companies that
  pushed their highly inferior "de facto" standards.  there used to be
  directives that made it virtually impossible to have "invention by
  committee" in ISO -- but these were changed.

  this is another case where competition should only be engaged in by
  people motivated by a sense of their own strength, not fear of the
  perceived strength of random others, and should not be engaged in at
  all by people who believe in sports-style competition, where there is
  one winner and everybody else are necessarily losers until they can
  beat the winner.  this is not one of those things the market can sort
  out, either, except that those who portray themselves as losers if
  they aren't the only winner will hopefully vanish completely when they
  are no longer winners.

#:Erik



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS
: >

: > > > Which of the methods below don't you like?
: > >
: > > >   (DEFMETHOD TYPE-INTERSECTION ((X MEMBER-TYPE) (Y MEMBER-TYPE))
: > > >     ..)
: >
: > How do you want them to be implemented, then? Something like this?
: >
: >     (defun type-intersection (x y)
: >       (cond
: >         ((member-type-p x)
: >          ...)
: >         ((numeric-type-p x)
: >          ...)
: >         ((enumerated-type-p x)
: >          ...)
: >         ((structured-type-p x)
: >          ...)
: >         ...))
: >
: > If you really think this is a good way to write code, then I don't
: > understand why you're interested in OO at all.

: What is type-intersection supposed to do?

: I doubt I'd implement it as above, but I don't even know what its for.

The compiler wants to keep track of what it knows about the type
of various expressions. If it's compiling

  ;; Return a symbol in the keyword package whose name is X. (a
  ;; handy utility for manipulating keyword arguments, structure slot
  ;; names, and so forth)
  (DECLAIM (FTYPE (FUNCTION ((OR STRING SYMBOL)) KEYWORD) KEYWORDIFY))
  (DEFUN KEYWORDIFY (X)
    (INTERN (IF (SYMBOLP X)
              (SYMBOL-NAME X)
              X)
            (FIND-PACKAGE :KEYWORD)))

then it should be able to prove to itself that the first argument to
INTERN is necessarily a STRING, so that it can compile it as some
internal %INTERN-A-STRING% primitive operation without any further
type checking.  It knows that the type of SYMBOL-NAME is STRING. Since
as per KMP's suggestion I made sure that the DECLAIM preceded the
DEFUN, it knows that the type of X before the IF is (OR STRING
SYMBOL). Then since the SYMBOLP branch wasn't taken, the type of X in
the other SYMBOLP-is-false branch of the IF must be

  (TYPE-INTERSECTION (MAKE-TYPE '(OR STRING SYMBOL))
                     (TYPE-COMPLEMENT (MAKE-TYPE 'SYMBOL))).

Finally it can deduce that the type of the return value from the IF is
the union of the types of both branches

  (TYPE-UNION (MAKE-TYPE 'STRING)
              (TYPE-INTERSECTION (MAKE-TYPE '(OR STRING SYMBOL))
                                 (TYPE-COMPLEMENT (MAKE-TYPE 'SYMBOL)))).

So to get the right answer we want

  (TYPE-INTERSECTION (MAKE-TYPE '(OR STRING SYMBOL))
                     (TYPE-COMPLEMENT (MAKE-TYPE 'SYMBOL)))
  => #<TYPE STRING>

and

  (TYPE-UNION (MAKE-TYPE 'STRING) (MAKE-TYPE 'STRING))
  => #<TYPE STRING>.

It turns out that the natural way to implement these functions, and
related type-manipulation functions, is with multiple dispatch,
i.e. doing method dispatch based on the type of more than one argument
of a generic function, not just the first argument. It would also be
possible to implement it with big TYPECASE statements instead, as
Gareth McCaughan wrote above, but it would be ugly and hard to
maintain.

Incidentally, this may have been an unfortunate example to focus on in
that the arguments in question represent a compiler's knowledge of
types, and we're also arguing about dispatching on the type of generic
function arguments, and having to keep track of the distinction
between the two -- ahem -- types of types probably makes it
unnecessarily hard to think about the problem. Oh well..

Also incidentally, all this is only a cartoon version of the way that
the system actually works inside the particular compiler I'm working
with, for a number of reasons, because e.g. the real compiler mostly
manipulates classes instead of types, and because it uses its own
twisty little object system instead of CLOS. But it is a real
application, and if it were written de novo in ANSI Common Lisp
instead of ported from pre-ANSI "Spice Lisp", it would appropriate to
write it in CLOS.

  Bill Newman



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:

> It turns out that the natural way to implement these functions, and
> related type-manipulation functions, is with multiple dispatch,
> i.e. doing method dispatch based on the type of more than one argument
> of a generic function, not just the first argument. It would also be
> possible to implement it with big TYPECASE statements instead, as
> Gareth McCaughan wrote above, but it would be ugly and hard to
> maintain.

(I'd just like to mention, for the benefit of anyone joining the
thread here, that I said that precisely in order to point out
how horrible it would be. I wouldn't dream of suggesting that
this kind of thing should be done with CASE or TYPECASE or COND
unless it turns out to give a huge performance win, which seems
unlikely.)

--
Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:

> You know, I guess I can see the C++ philosophy of "if you can get it to
> compile it's probably right" but my taste is for expressive power over
> being protected from myself by a dumbed-down language.

That is more the philosophy of modern pure functional languages with
expressive type-systems.  I've had the nice opportunity to work with
one of those, and it mostly really works the way that "if you can get
it to type-check (i.e. compile), it's probably right".  Quite nice in
a way, though to static for my "taste".  But C++ doesn't even come
anywhere near that.  If I get my C++ code to compile (which really
isn't that problematic, unless you use templates, when usually all
hell breaks loose ;), it's usually time to start debugging...

Regs, Pierre.

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]



Sat, 27 Oct 2001 03:00:00 GMT  
 
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software