abjects

Francois-Rene Rideau fare@ens.fr
Fri, 29 Dec 1995 17:51:42 +0000 (GMT)


Dear Novy,
   here is a (late) reply to your abjects article.
   A text version of it (instead of just postscript) would have been a good
idea.

> Abject is an abbreviation of an abstract object.
   Firstly, the name is not well chosen, because in all latin languages like
french, english, italian and spanish, "abject" is a strongly deprecative
adjective, that means vile and despicable.


> It's an elementary
> concept based on the structural composition like ordinary objects.
> It completely replaces the concept of a function.
   You didn't quite expand on "composition". I only saw just an example of
it, that doesn't describe the alphaconversion mechanisms if any.

> Abjects are pure in
> the sense of the pure functions, i.e. there is no side-effects.
   If the industry does not use pure functional languages, it is that most
industrial applications, database management, robot (hey, a czech word !)
control, data acquisition, etc, are mostly I/O with very simple computations.
Industries' languages were designed with immediate use in mind, not long term
utility.
   Pure functional programming is way cool, as you can specify objects with
a clean semantics, so you really know what you're doing. It is undoubtly
a better way of specifying programs than BASIC-like imperative programming.
   Now, side effects is a most important phenomenon in computations, that
cannot be completely concealed, except if you have really infinite resources
(time, space... money), which will not seemingly ever be the case. Trying to
put aside this aspect of the problem will only have it drawback more violently
as you reach the limits of your resources unprepared.
   So to conclude the debate with pure/impure programming, I'd say that both
aspects are important to support, and that bridges between them must be made
easily crossable with automatic change of view on a program.

> This paper is still highly unfinished. Comments, criticism etc are
> welcome.
   You say that functional programming is a toy for academicians: sure
its potential is not as exploited in the industry as it could be, but I'm
pretty sure there still are industrial applications written in LISP; e.g.
until recently, AutoCAD was only programmable in AutoLISP.
   You say that types are an a priori knowledge, yes it is. And that's
precisely what's good: it allows you to prove things about programs, like
safety versus some kinds of crashing. Various type systems will provide
more or less information.
   You say that it restricts the set of possible values, yes it does;
but this is definitely a good thing, if your type system is expressive
enough.
   You say that type systems make functional languages less homogeneous.
I suppose you call "homogeneous" a type system such that it can be
described with a limited number of simple "homogeneous" rules, that have
few "exception" cases. Then functional languages have much more homogeneous
type systems than C or any such imperative language. Type systems in the ML
family are built by abstract interpretation, and even for LISP, where the
"type system" is at abstraction level zero, it provides non-trivial
information.
   You say there is no distinction between type and value, but this is a
confusing assertion. What I'd say is that a most expressive type system
would be a separated topology, like types in model theoretical logic.
What I'd say is that typing is expressing knowledge, and having a
finer type topology means being able to separate more concepts.
   I'd also say that trivially fine (discrete) type systems end up as being
useless because they need full computation to bring any information,
and that to express any concept, the type system must be generic enough
to include any other type system as a closed subset.
   "Physical structure modeling" seems a very confuse concept. I don't quite
grasp what it is. I don't understand what you say about lambda-calculus
either.
   The type system you propose seems to be a subset of non-negative
propositional calculus only "=" as a constructor with infinitely many
variables. It isn't quite expressive.
   Unfortunately, your intuition already serves as a base to most "OO"
languages. BETA and SELF seems no more expressive than that already.

   I hope I do not appear overcritical.

> Best Regards,
   Merry Christmas and Happy new year !

> Marek Novy
PS: How are things going in Czechia ?

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"