OIL review ?

[Laurent Martelli]

>>>>> "Jim" == Jim Little <jiml@inconnect.com> writes:

  Jim> Laurent Martelli wrote:
  >>  I think that I've implemented almost all the features that I
  >> wanted to have in OIL, so I believe that it's time for a
  >> review. Do you think it has flaws ? Is it missing important
  >> features ? (I am not talking about performance issues here, just
  >> functionnality).

  Jim> As I imagine you are also discovering, useful responses are
  Jim> hard to find on this list.  :) So I'd like to critique OIL.
  Jim> That's hard, though, because you haven't really issued a strong
  Jim> statement of what it's for.  But I'll do my best:

  Jim> On your web page, you state that your goal is to support an
  Jim> "open interpreter" that will support AOP.  I don't know what an
  Jim> open interpreter is, but it seems to me that OIL does not meet
  Jim> the goal of supporting AOP, other than in the most general (and
  Jim> not particularly useful) Turing-compatible sense.

This is perfectly true. For now, we only have an interpreter. In fact,
I'd like to have critism before we start opening it. By "opening the
interpreter", we mean providing generic means to specify the way it
interprets programs and specification. For the moment, it is not very
optimized, but we want to provide means to introduce special
optimizations. 

  Jim> In a previous email message to this list, you stated: "What I
  Jim> really want to achieve is separation of concerns :
  Jim> specification and implementation."  I don't see how OIL meets
  Jim> this goal, either.

You're rigth once again. It only allows users to specify. 

  Jim> It seems to me that what you do have is a system for lambda
  Jim> abstraction, not too much different than any other programming
  Jim> language that supports function calls.  OIL's uniqueness
  Jim> appears to lie in the fact that it's run-time extensible in
  Jim> that you define new lambda abstractions at runtime -- its
  Jim> interactive.  It's also persistent, which is nice.

One thing that I'd like to know is : "Does OIL allow us to compute
anything that is computable". I think it does, but since I haven't
done a formal proof of this statement, I cannot be sure. 

  Jim> I see some things that could potentially be problems, but
  Jim> without knowing what your concrete goals for OIL are, it's hard
  Jim> to say if they're really problems or not.  Without that overall
  Jim> vision of where OIL is going, though, I can't see how OIL is
  Jim> much different than an interactive Lisp -- and I'm not a Lisp
  Jim> guru, but I believe that such things are already available.

I'd say that the main difference is that all objects but variables are
immutable. And the fact that bindings are not part of the core
semantics of the language. 

  Jim> So in summary, I'd say my biggest critique of OIL is not the
  Jim> system itself but the lack of published direction.  Without
  Jim> that, it's impossible to say if OIL is feature-complete or not,
  Jim> because I don't know what the feature set is supposed to be! :)

For the moment, it is supposed to be able to compute anything that is
computable.

  Jim> Jim

  Jim> PS: I'm not trying to be harsh, but I AM trying to provide
  Jim> useful feedback -- something which is SORELY LACKING on this
  Jim> list, HINT HINT folks!!  (And I'm sure Brian would agree with
  Jim> me on that point, even though we seem to disagree on everything
  Jim> else.  ;) )

I have to thank you very much. This was helpful. It showed me that my
question was not precise enough. 

-- 
Laurent Martelli
martelli@iie.cnam.fr