--
David B. Lamkins <http://www.teleport.com/~dlamkins/>

(1) Providing a firewall between interface and implementation, much as
    CLOS provides a layer that DEFSTRUCT does not, so that if you
    reimplement the internals, you don't have to reimplement the callers.
    For example, when you talk to a CORBA object, you don't know if it's
    really on your machine or if it's just a little communication station
    that every time you talk to it calls out over the network to its home
    base and finds out what to respond.  (Of course, you probably find out
    by latency or net protection errors, but no equivalent system not based
    on CORBA does any better.)

(2) Providing (some) flexibility of hosting your object anywhere on the
    net.  It does have a model of being able to address a particular object
    owned by a particular (actual or virtual) process on a particular machine.

CORBA was designed by people (some with a Lisp background) who did
understand object-oriented programming and who had a serious intent to
do a multi-language binding without leaving some languages out.  It
does a credible job of creating a system that is at least capable of
being cast into many languages and hiding a reasonable amount of messy
details so you don't have to know the location (sort of), language, or
low-level data format details (wordsize, byte order, endianness, etc.)
of the other objects you're working with.  The fact that it hides the
language and other details is a plus for Lisp since clients don't have
to know how you got them the answers, just that you did.

I have taken a course in CORBA but not to date programmed it, so my
knowledge is from having heard it explained and seeing demonstrations
done.  If I'm in error on any of this, someone should correct me.
CORBA *is* communication over a network.  Whether it also offers such
communication as a first class service a different matter, sort of
like how Lisp doesn't offer pointers as a datatype even though it's
all pointers, or how a database isn't about file access even though
all it does is access files.  My impression is that to the extent
CORBA offers network access other than itself, it's as a layered
service someone put atop it, not by virtue of its intended nature.
But, nevertheless, just as someone could reasonably make the claim
that applications don't need files for a great many applications if
they have databasees, I suspect CORBA people could reasonably make the
claim that you don't need the raw net for many things if you have
CORBA.  CORBA is one structured piece of a network puzzle, and it
would be the entire piece if everyone used it exclusively.  To the
extent that they don't, of course, you need other things or layered
CORBA componentware.  (And I suppose if someone left out the
componentware you could offer the service of connecting to the net
from your machine via a CORBA program that accessed your machine via
the net... :-)

Anyway, it's all about packaging.  As far as I know, all of the
systems we're talking about not having socket libraries do have
foreign function call and that, I assume, implicitly supports
sockets--so it's really just about the raw power.  Just about the
packaging.

--
David B. Lamkins <http://www.teleport.com/~dlamkins/>

There's currently something called OpenLisp but I have not checked it:

http://www.ilog.fr:8001/Eligis/index.html

A number of lawyers jumped in to the discussion saying just how much
of the crap in those licenses was really enforcable. But still, the
point remains.

Christopher

In general, the GNU project decided a couple of years ago that they wanted
to make Scheme the basis of their extension languages across the board, and
they developed the GUILE implementation to support this effort.  Using it
for Emacs would be consistent with this plan.

  dealing with networking problems is so complex that an application really
  cannot afford to trust a pre-packaged solution that does not give very
  good access to the error conditions.  I've spent hundreds of hours giving
  Allegro CL's socket package and my protocol on top of it graceful failure
  modes.  it's really hard work.  judging from what I see from people who
  just use some random pre-packaged library, this is not an area that
  people tend to worry about, hence we get very dangerous solutions that
  work in a perfect world, but not in the hostile world we actually live
  in.  what little I know about CORBA has not shown me a condition system
  that is capable of what I need from a basically unreliable universe where
  your application no longers dies when the machine dies, it may get wedged
  in some zombie state when some machine you didn't know about dies, like a
  router, a firewall, or simply someone messing up routing tables, etc.
  stuff like happens all the more often the more you are interconnected,
  and a distributed object system is no good if it doesn't deal with such
  problems gracefully, in my opinion.

  while I'm sure consumers want anything for free if they could get it, I'm
  a little concerned that people think there's business sense in providing
  all of these "necessities" for free.  you could argue increased sales and
  make such freebies into marketing vehicles, but you really can't argue
  that it's part of the standard and that vendors have to provide it.  in
  all this concern for user's needs, I frankly see much too little concern
  for whoever is _actually_ going to pay for them, given that the users are
  not even remotely interested in doing so.

  I'm probably among the old school of "free software" in that I respect
  that people will want to get paid for their efforts, that one has to
  expect to pay real money to develop software, and that it should cost
  money to have it supported, but that the _freedom_ of access to the
  source code should not therefore necessarily be reduced.  I do not think
  the drive for "free as in gratis software" is healthy, and I actually
  think that the more people demand from the vendors without giving them
  any sort of incentive to do fulfill their demands, the less willing they
  will be in fulfilling them.  catering to thankless, non-paying demanders
  is not good business.

  besides, it's not as if this is rocket science.  if you want it for free,
  I say: drum up the people who are willing to do it for free, license it
  so people can actually use it, and _chip_in_, don't just _demand_ that
  others do stuff for you.  programming is, after all, about bringing new
  stuff into existence that you see a need for.

  of course, I'm so happy that I don't _have_ to do a lot of work myself
  that I'm fully willing to pay for access to it.  I guess this makes me a
  heretic, because the people I tell this to have these weird ideas that
  I'm opposed to free software and "summarize" my position as "make, buy,
  or shut up".  apparently, the concept of creating something yourself to
  give it away is _completely_ foreign to these whining losers, and then I
  have even more reason to believe that they have no concept of how to make
  the vendors do what they think is a smart thing to do, namely create
  something they need and just give it to them.

  how hard _can_ it be to write, say, a de facto standard socket interface
  for Common Lisp and make implementations for all Common Lisps available
  to the Lisp community for free?  those who want it the most sound like
  it's an insult _not_ to provide them with something that trivial.

  in brief: if you think free software is so great, make sure it wins by
  actually making the effort to make it available to everybody.  meanwhile,
  I want to get paid well for my work.  my give-it-away-to-thankless-losers
  time is history, but I'm sure there's business sense to _some_ people to
  do all this stuff for free or you wouldn't demand it of others, right?
  nobody can be so egoistic and self-centered as to completely ignore what
  it takes to create something they want, can they?

  BTW, I think free software is wonderful, as long as it doesn't mean that
  people demand to get what I'm doing for them without compensating me, and
  I cannot in good conscience demand anything like that from others, either.

  yeah, I'd love to get everything for free, too, like great food, a socket
  interface, great new hardware, CORBA support, fast Internet connectivity,
  and of course entire Common Lisp systems, but I'm a little more realistic
  than to expect to be able to _demand_ it.  if somebody goes ahead and
  makes any of this stuff available for free, I'll be looking for attached
  strings and then I'll be happy if it's _actually_ free.  in practice,
  however, nothing is ever truly devoid of costs, and I sometimes prefer to
  pay money and get off the hook.  but that's just me, I guess.

  however, I seem to recall several important speeches on copyright issues
  for contributed stories to a "Lisp Lore Library" or something, and I fail
  to see how software doesn't incur the same conditions and concerns.

  unfortunately, memory management and data matters quite a lot.

faa

You're arguing that a manager will prefer to optimize relatively small
recurring expenses for software acquisitions, upgrades and support.  And
what if in so doing, (s)he increases the larger -- but less tangible --
costs of development salaries, lost time to market, customer support costs,
etc?  Commercial development practices virtually guarantee that a manager
will behave in such a manner.  The rush to market guarantees that no one
will keep track of life-cycle expenses.  So the manager focuses on the
things that are controllable, like cost items that are down in the noise
dollar-wise, but can be tracked just by pulling an invoice.  Can you say
"micro-management?"

I certainly agree with you that most managers behave in this manner.  But I
don't approve of the behavior, and don't agree that the industry should
(continue to) cater to this style of management.

One -- the more common -- minimizes personal risk in the way you've
described.  My cynical summary of this approach is this: "Don't think too
much about solving the real problem, because you probably won't succeed.
Instead, choose the approach that any 'reasonable' person in your position
would choose.  That way you are blameless if you fail, because anyone else
would have failed the same way."  I think that that this is the management
style to which you refer.

The other management approach -- thought by many in this industry to be the
stuff of myth -- accepts a challenge with the desire to succeed.  These
managers evaluate everything that could help them achieve the desired
result.  Sometimes they go with "standard", and with "stable" at other
times.  They educate both their staff and their superiors as to what they
are attempting to accomplish by choosing a particular approach.  If they
succeed, they usually succeed in a big way.  And if they fail, they rarely
fail worse than their "keep a scapegoat handy" counterparts.

(BTW, in twenty years, working for six companies, reporting to more managers
than I can keep track of, I've had exactly two managers that used the latter
style.)

--
David B. Lamkins <http://www.teleport.com/~dlamkins/>

  fire up GUILE, CLISP, and any other Common Lisp implementations you have
  at hand.  run them for a while.  do real stuff.  watch how much system
  memory the heaps consume.  watch GUILE lose.  fire up 100 copies of each
  of them, and watch code space being insignificant compared to heap space.

  the U in GUILE is for Ubiquitous.  there's going to be _many_ copies of
  the GUILE heap on a system, one in each process, just like the C library.
  in contrast, you're unlikely to exhibit the same behavior with a Common
  Lisp system, which users load stuff into instead of running a new process
  with its own heap all the time.

  the problem with retrofitting a Lisp or Scheme onto Unix is that Unix
  really is a C programming environment, and using the C mindset when
  building Lisp or Scheme applications or systems on top of it loses.  the
  same is true of any other programming language with an environment that
  takes the role of Unix for C.

Not doing so is short-sighted, as KMP has correctly pointed out with
very good arguments.

Note also that at this point, giving away these freebies is *not* (or
it shouldn't be) a marketing gimmick. It is the only way to expand
your user base. Assuming that that is what you want to do.

Cheers

Yes, while replying to a similar side message from Dorai Sitaram, I
finally realized that both of you are correct. My apologies for not
seeing it sooner.

One way might be for the fluid-let to look at its own continuation,
and if that continuation is some sort of magic "fluid-let frame" that
contains a "restore" of the variable it's about to change, just pass
that continuation on to the body of the fluid-let without building a
new "restore" frame. And by hanging a *set* of variables on the magic
continuation, you could even handle things like the following with a
small stack (though there are some subtleties to worry about in case
one of those intermediate functions, like "perverse-func" below, captures
*its* continuation):

        (define *x* 0)
        (define *y* 1)
        (define *z* 2)

        (let loop ((n 0))
          (fluid-let ((*x* (1+ *x*)))
            (some-func)
            (nuther-func)
            (fluid-let ((*y* (* *y* 2)))
              (perverse-func)
              (stuff-other)
              (fluid-let ((*z* (expt *y* *x*)))
                (format #t "~s ~s ~s~%" *x* *y* *z*)
                (if (> *x* 10000000)
                  (list *x* *y* *z*)
                  (loop (1+ n)))))))

+---------------
| It is probably unreasonable to expect this if fluid-let is implemented
| in terms of dynamic-wind (maybe not, though.  If the dynamic-wind were
| tail-called, and it's entry and exit thunks satisfied certain properties,
| perhaps....)
+---------------

Well, I haven't thought that part completely through, but those "certain
properties" would have to be *awfully* restrictive if you're going to be
able guarantee that you can "fold" multiple logical invocations of the
"after" thunks into *one* invocation. [Folding multiple "restore"s of
a variable is *trivial*, by comparison...]

-Rob

Erik> * Kent M Pitman <pit...@world.std.com>
Erik> | (Of course, you probably find out by latency or net protection errors,
Erik> | but no equivalent system not based on CORBA does any better.)

Erik> dealing with networking problems is so complex that an application really
Erik> cannot afford to trust a pre-packaged solution that does not give very
Erik> good access to the error conditions.  

mm ... not everybody will (have to) go to that level. The networking part of
CORBA is provided by the ORB (Object Request Broker), and if the ORB gets
things wrong (which is sadly not too uncommon), you raise hell with the ORB
vendor. Depending on the ORB, you have more or less access to error
conditions and the like. From what I have seen, all this is at a higher
abstraction level than socket libraries.

Erik> what little I know about CORBA has not shown me a condition system
Erik> that is capable of what I need from a basically unreliable universe where
Erik> your application no longers dies when the machine dies, it may get wedged
Erik> in some zombie state when some machine you didn't know about dies, like a
Erik> router, a firewall, or simply someone messing up routing tables, etc.
Erik> stuff like happens all the more often the more you are interconnected,
Erik> and a distributed object system is no good if it doesn't deal with such
Erik> problems gracefully, in my opinion.

yes, absolutely. CORBA provides some of this functionality: a client will
simply get an exception (which it can and should handle) if the server cannot
be reached for whatever reason; it needn't die or zombify or anything. In
addition, IDL (the lingua franca) allows user-defined exceptions on any
user-defined methods.

Apart from this I think CORBA is the right kind of framework and abstraction
for doing distributed objects (even if imperfectly/incompletely
implemented).

Kent> You cut out the part of my discussion where I mentioned if it's not free
Kent> it doesn't really address the issue.

no, i sort of latched on to the CORBA word. But anyway, there are very many
free ORBs out there (see http://adams.patriot.net/~tvalesky/freecorba.html) ,
most of them only dealing with C++ and Java, but there is at least one that
can do Common Lisp (ILU, see ftp://ftp.parc.xerox.com/pub/ilu/ilu.html) (I
have no experience with this, though).

I think this is not too bad, and wouldn't be surprised if it gets better.

Craig> Philip Lijnzaad <lijnz...@ebi.ac.uk> writes:

yes, I was trolling a bit here. This is currently far removed from reality,
but the principle holds: in an ideal world CORBA, could theoretically do
this. No other technology can make this claim.

Craig> I prefer my
Craig> ALIEN interface in CMUCL immensly to CORBA and the IDL bullshit when I
Craig> want to talk to a C or other language Library.  I would not
Craig> want to talk to my FFT library via CORBA.  I would rather use RMI with
Craig> all of it's problems,

This is another java compatibility thread I'm afraid ...

Craig> if I wanna ship Java classes around,

instances or classes? Currently, CORBA only provides access to remote
instances; it doesn't ship them around by default.  But you can implement you
objects such that they can be shipped off-site (using the LifeCycle
specification).  There's a new spec called objects-by-value which offers
the shipping of object state by default, too. Not implemented yet, of
course.

Craig> rather than wait for some molasses like RFP approval proccess from the
Craig> OMG to decide how they wanna pack them up.

OK, the standardization process can be a bit tedious, but it is very open,
not too slow, and seems to have enough momentum. It certainly didn't
stop the KDE and Gnome folks to use CORBA as their infrastructure.

I don't talk about eclipsing, but maintain IF you can use CORBA, THEN sockets
are not overly necessary anymore. I know of no one who actually mixes the
two. But I concede that CORBA would be lost without, e.g. http.  Still
interesting to note that Java's RMI now uses CORBA's iiop protocol. This
unifies rmi/corba against DCOM, usoft's version of distributed computing.

Craig> I would argue that you have CORBA on the brain.  It's ok, I did too once.

I'm not married to CORBA, but thought that it could be illuminating to
mention CORBA as an alternative in the foreign function interface debate.

                                                                      Philip

David> CORBA and FFI address two different problems.  CORBA will not replace
David> FFI capability.  What are you going to do when you want to call an
David> entry point in a library?  Wrap the library so you can make a CORBA
David> call?  

yes, that would be the idea.

David> The last time I looked (about a year and a half ago) a CORBA
David> method invocation cost a _lot_ more than a simple function call.

yes, that's still the case. For many purposes, this would be good enough.

not subsume, but use them (iiop is based on tcp/ip, so it uses IP addresses,
ports and tcp transport). Turns out many people prefer the higher abstraction
layer of CORBA over sockets, and I would argue that this is a Good
Thing. Based on numerous posts in comp.object.corba, people who have used
CORBA  and sockets vastly prefer CORBA over sockets. This includes myself,
although I have no great experience with sockets.

                                                                      Philip

I only realised this when I was talking to someone the other day and
rashly said that sockets are obviously not hard in CL, when what I
meant was they're not hard to do in a portable way if you already have
some support for them...

Of course a CLOSified stream system would make this much easier (:-).

Anyway, Alpha *is* a new lisp processor made with modern technology!
Lots of tag bits on a 64bit machine, and you can probably get really
good parallel tag checking given multiple execution units.

Really, I think yearning after the magic hardware fix is a huge
mistake.  The interesting thing about LispM's was always the software
I think (well, unless you collect odd microcoded machines, like
me...).