[Prev][Next][Index][Thread]

Re: Sealed as Source Annotation

[comp.lang.java removed because, for some reason, the system I posted this
from doesn't carry it.  The following is getting pretty Dylan-specific in
any case but feel free, Mark, to forward it to c.l.j if you think they'd
want to read it.]

On 17 Jul 2000, Mark K. Gardner wrote:
> To more directly state my purpose in asking about internal vs.
> external annotations, I am seeking to understand the pros and cons in
> abstract terms. ...

Yes, I got this point :-)  I may yet go back and reply to some of your
earlier messages but in any case I wanted to point out something an XML
wizard pointed out to me once.  Maybe it'll be obvious to everyone but it
was a minor revalation to me at the time :-)

If your langauge allows both inline (internal) and stand-off (external) 
markup, and you have a good enough (read-write) processor for it (and the
syntax is reasonably tractable, I suppose), then inline and stand-off
markup can be isomorphic.  The XML(/SGML) community's terms for converting
between the two are "knitting" and "unknitting", IIRC.  [Hmm ... some joke
about "knit one, Perl two" is lurking there, I'm sure ;-)]

This is ignoring the fact that running your source through some mutant
version of "lint" all the time in order to understand it may be
unacceptable -- but hey, Dylan would like to live in a world of wonderful
development environments, no ;-?

It also gets much more complicated, I'm sure, if you have the source and
annotations (text and markup) stored (at a given point in time, not
necessarily always) in stand-off form, and you change one but not the
other.  Keeping track of what the "knitted" version looks like and means
could stretch your brain, if not your tools.  And it gets even worse if
you have several different (and possibly not mutually exclusive) sets of
markup.

[BTW, that last is partly what this mechanism is for.  In XML and SGML,
marked-up ranges have to nest -- they can't overlap.  But if you want to
mark up different sets of information, the text ranges covered by each
set's tags might overlap.  So you may have to use some linking convention
(like the W3C's XLink) to point at start/end points of each range for a 
given semantic set from a separate file.  Hope that makes sense -- I *am*
typing this at nearly midnight so it might not ;-)]


> On Fri, 14 Jul 2000 12:31:06 +1200, Bruce Hoult <bruce@hoult.org> wrote:
> >...
>
> ... [In] Apple's 1992 book "Dylan: an Object-Oriented Dynamic Language".
> ... the only mention of sealing concerned sealing classes (pg 94):
> 
>   seal /class/ => /class/
> 
>     seal makes the /class/ read-only and, in addition, new subclasses
>     cannot be created from the /class/.

BTW, it seems to me that Dylan already has (at least) three kinds of
annotation which may be

  - external only: module/library exports (A recent thread mentioned
    that the language designers did try to get an internal(-only?)
    syntax/mechanism for this.)

  - internal only: class sealing

  - internal or external: domain sealing (Indeed, you can seal domains
    over types which are solely from imported libraries, although this is
    bad practice if your code is to be reused, as you don't know that some
    other also-reused library won't do the same, which would be an error.
    It's fine in not-for-reuse, "EXE-targeted" libraries, though, I
    think.)

I wonder whether or not there are good semantic reasons for these cases,
or other reasons (good or bad), such as "syntactic simplicity", "we didn't
have time in the language design" etc.

> ... I am, as of yet, still undecided about the need for separate
> compilation [1] and it isn't apparent to me that external 
> annotations won't achieve the same effect. ...
> 
> [1] There are indications that separate compilation may be unnecessary
> with today's machine resources. As one data point [... SmallEiffel]

As a counter-point, we might want to get our lovely dynamic langauges into
resource-constrained devices such as set-top boxes, mobile 'phones etc.
So it might be nice to have the *option* to do *either*.

Another conceivable reason (dunno if it's a good one) for wanting separate
compilation is the ability to deliver a reusable "component" to someone
else, without source code.  Note only does this prevent them changing your
code (or reading it to generate "bug-compatible" client code :-), it
may make it much harder for them to copy your implementation, if you're
supplying that component commercially.  There may be various other,
non-performance-related reasons.  As a veteran fence-sitter [I should show
you my war wounds -- no, maybe I should just get some sleep %-)] I'd like,
as I said, to have the option of either.

I suppose you might also usefully combine separate compilation and
external annotations to deliver components which can be used in a number
of ways with little or no extra compilation/linking/etc.

> The purpose of the above discussion is to point out that one does not
> necessarily to have to separate compilation nor is it necessary to
> have internal annotations to achieve good performance. As I believe
> both the existing Dylan compilers, Gwydion and FD, assume separate
> compilation, the point is moot as far as Dylan is concerned. The same
> can be said for Java.

I believe Fun-D allows whole-program compilation, although it may not
expose a (G)UI for it, or have a complete model of how to do it well.

I also know that at one point we talked about being able to impose
project-specific boundaries on which client libraries to recompile when
you recompile the top-level library of your project.  You can think of
this as using delivered components which consist of multiple libraries.
This is intended to solve the "recompile Linux when recompiling
hello-world" problem mentioned elsewhere :-)

> >...
> >Thus Dylan programmers only have this problem when they want to extend 
> >someone *else's* sealed class [whose source they can't recompile, for
> >some reason]
> 
> This is precisely when I have had difficulty with internal
> annotations. If the writer of the library (package in Java or module
> in the Dylan context) did not forsee a need to extend a class, I am
> unable to reuse those bits that will work unchanged and to redefine
> those bits that do not. ...

It might well be that there are other ways to trade off efficiency against
extensibility and I'm glad to hear that people are researching them.

> >> Additionally, having the annotations external to the source
> >> naturally leads to allowing specific instances to be sealed while
> >> leaving others unsealed.
> >
> >I'm sorry.  I don't understand your intent.  Do you propose that 
> >particular *instances* of some class might be sealed/final, but that 
> >other objects of that class will not be?  How would that work?  ...
> 
> My thinking on this point is still a bit abstract. Thinking back to my
> experience with Concurrent Aggregates (see [2]), site specific
> optimizations were very important in obtaining "maximum performance".
> ...

Ah, so you mean "specific instances" of function calls, not of classes,
right?  (The latter might make sense in languages where you can, say, add
slots to individual instances -- which you could do in the Dylan described
in the Apple book you mention).  If so, I can see why Bruce was confused.

> ...
> Mark (who is awaiting your though provoking comments)

I hope your thoughts are provoked; now I just need something
sleep-provoking ...

Good--- uh, morning :-)
Hugh
Follow-Ups: References: