Dylan and Java [was: Harlequin Dylan - Update] 
Author Message
 Dylan and Java [was: Harlequin Dylan - Update]

Jeff -

  thanks for the comments.  Responses follow.

  Note that some of the problems you point out are inherent in the
format of the comparison.  We're trying to make large points in a
small amount of space, and it's often the case that we can't include
enough supporting detail to really make things clear.  That said,
things can be improved.


Quote:
>Under Java for "Objects", we find

>  Most data are objects. However, functions and numbers are not
>  objects, and must be coerced to object types before they can
>  participate in the object system.  Classes are special objects that
>  lack many of the capabilities of other objects.

>But (1) numbers and the like can participate in the object system
>to some extent w/o being wrapped as objects,

We're not really sure what you mean by this.  Can you give an
example?

Quote:
>(2) Classes are objects (I don't know what lack of "capabilities"
>makes them so "special"), and

Perhaps this is poorly worded in the current document.

While it's true that Java classes are objects, there's a limited
number of things you can do with these objects.  For example, you
can't define methods that are applicable to the class object itself,
rather than to its instances.  Classes in Java aren't objects
the way other instances are.

Do you see the sort of distinction we're trying to get at?
Any suggestions on how to express it more clearly?

Quote:
>(3) there aren't any functions, so of course functions are not
>objects.

Setting aside the fact that static methods on classes are
essentially functions, it would be clearer to change the
text here to read "methods" rather than "functions".

Quote:
>(BTW, if Java is such a "safe" language, how come I get segmentation
>violations?)

You'll have to take that up with your Java vendor.  We have plenty
of our own segmentation violations to worry about!

Quote:
>Under "Syntax", we find:

>  Java uses a C-like syntax that relies heavily on punctuation to
>  implement a variety of features. The syntax will be familiar to
>  those who have programmed in C or C++, but may be difficult for
>  others to understand until they have been trained in Java.

>What is this "relies heavily on punctuation" about?  

In C and Java it is common to use punctuation where Dylan would use
a word.  For example incrementation, vector instatiation, for loops,
and curly braces vs begin/end pairs.

For a beginner coming to the language, C and Java can look pretty
formidable. Dylan uses more English words, which can help the beginner
get oriented to what the code is doing.

Quote:
>Under "Scoping", I'm not sure what the issue of "encapsulation and
>compilation" having to follow class boundaries is about.  What is
>the difference that one ought to care about (so to speak)?

In Dylan, you can define classes and their methods where they
naturally belong according to the program structure, whereas
in Java you are absolutely locked in to defining methods within
the class definition.

The advantages of the Dylan approach come out, for example,
when you want to implement two closely related classes that
don't inherit from each other but want to share internals,
and then expose a very precise interface to outside clients.

The Dylan approach is also necessary if you want clean
multimethods.

Quote:
>"Exceptions": In Java RuntimeExceptions are not "checked" and can
>be used in much the same way as Dylan exceptions.

This is true.  However, subclassing RuntimeException is considered
poor programming style in Java.  You're encouraged to use
checked exceptions.  We could say something like "most exceptions in
Java are checked", but I think that's unnecessary given the space
considerations, and given that Gosling and Arnold are content to
say, "Java uses checked exceptions to manage error handling" in
their book "The Java Programming Language."

Thanks again for the comments.

Quote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<




Mon, 17 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]

Quote:
> Jeff -

>   thanks for the comments.  Responses follow.

>   Note that some of the problems you point out are inherent in the
> format of the comparison.  We're trying to make large points in a
> small amount of space, and it's often the case that we can't include
> enough supporting detail to really make things clear.

Yes, I understand.

I was trying to think: what about this maybe looks wrong or unfair
from a Java point of view?  Or, in other words: what might cause a
Java programmer to perhaps dismiss the comparison or think it was
biased?

However, I'm far from the best person to say how things look from a
Java point of view, so, for that and other reasons, I could well be
wrong about how things are best presented.

Quote:
> >Under Java for "Objects", we find

> >  Most data are objects. However, functions and numbers are not
> >  objects, and must be coerced to object types before they can
> >  participate in the object system.  Classes are special objects that
> >  lack many of the capabilities of other objects.

> >But (1) numbers and the like can participate in the object system
> >to some extent w/o being wrapped as objects,

> We're not really sure what you mean by this.  Can you give an
> example?

Well, I found that one could go quite far without realizing
that numbers weren't objects.  For instance, you can write a
method definition such as foo(int i).  You might even see
something like

   ...
   foo(String s) { ... }
   foo(int i) { ... }
   ...

Of course, if you define snib(Object a) and then try to call snib(1),
or try to put an int where an Object has to go, you'll find that
Object doesn't include int.

(You can't define new methods that apply to ints, but you can't
define new methods that apply to Vectors either (for example).)

Quote:
> >(2) Classes are objects (I don't know what lack of "capabilities"
> >makes them so "special"), and

> Perhaps this is poorly worded in the current document.

> While it's true that Java classes are objects, there's a limited
> number of things you can do with these objects.  For example, you
> can't define methods that are applicable to the class object itself,
> rather than to its instances.  Classes in Java aren't objects
> the way other instances are.

> Do you see the sort of distinction we're trying to get at?

Not really.  It seems to me that classes _are_ objects in a fairly
straightforward and obvious sense.  For instance, you can do such
things as

  Object x = Class.forName("foo");
  String s = x.toString();

or

  void aMethod(Class c) { ... }

The sense in which classes "aren't objects the way other instances
are" seems relatively hard to find, and I'm not quite sure what it is.

Looking around for restrictions and lacks, I find the following:
The class Class lacks a constructor, though you can in a sense make a
new Class object by loading a class dynamically.  The class Class is
final, so you can't extend it and hence can't define new kinds of
classes.  

I suppose the latter (that you can't define subclasses of Class) might
be what you have in mind when saying "you can't define methods that
are applicable to the class object itself", but what it _sounds_ like
you're saying there is that you can't define new methods of the class
Class, which I think is really a general problem, rather than
something about classes.  I can't define methods that are applicable
to Strings or Vectors (or indeed any class whose definition I can't
edit) either: instead I have to define a subclass and put my methods
there; and then they will work only for instances of the subclass.

But maybe I've overlooked something?

Quote:
> Any suggestions on how to express it more clearly?

Well, it sounds like the real "importance" of this issue has to
be some useful things you can do with classes in Dylan but not
in Java.  Dylan may have better reflective or meta-programming
abilities, or something like that.

BTW, a point of comparison might be what can be done dynamically
to define new classes, methods, or whatever at run-time.  Java
has an ability to load classes given their name as a string,
and then make instances of them.

Quote:
> >(3) there aren't any functions, so of course functions are not
> >objects.

> Setting aside the fact that static methods on classes are
> essentially functions, it would be clearer to change the
> text here to read "methods" rather than "functions".

While it's true that static methods are essentially functions, (and
I'd even say the same about non-static methods), in Java the basic
model is objects-with-methods.  The thing that's closest to the
Lisp idea of a function (or closure) is an instance of an anonymous
class that defines a method named something like "call" or "apply".

So I think it's better (though not perfect) to say Java doesn't have
functions -- instead you use objects or classes that have appropriate
methods -- rather than saying it has functions but they aren't
objects.  (But I don't think saying "Java doesn't have functions"
is the right way to put it either.  I think the point has to be:
what does functions-as-objects give you that isn't available,
or isn't available without annoying awkwardness, in Java.)

Quote:
> >Under "Syntax", we find:

> >  Java uses a C-like syntax that relies heavily on punctuation to
> >  implement a variety of features. The syntax will be familiar to
> >  those who have programmed in C or C++, but may be difficult for
> >  others to understand until they have been trained in Java.

> >What is this "relies heavily on punctuation" about?  

> In C and Java it is common to use punctuation where Dylan would use
> a word.  For example incrementation, vector instatiation, for loops,
> and curly braces vs begin/end pairs.

I'm not sure what vector instantiation case you have in mind.
Presumably not "new Vector()".

Syntax comparision is complicated by a number of factors, such as
the large number of programmers who are familiar with C and C++.
I'm pretty sure a fairly long message could be written just on
syntax.  But here I think the bottom line is that the Java - Dylan
comparison table seemed to be suggesting that there's a greater
difference between the languages (Java relies _heavily_ ... a
_variety_ of features, my emphasis) than there actually is.

Consider, in Dylan := vs = vs ==, :: [so that one might say "i ::
<integer>" vs "int i" or "Integer i"], #t and #f [vs true and false in
Java], #"...", #(...) and #[...], while: and until: (note the colon),
=> in case and select, the semicolon-comma transition in select, ? and
?? in macros, and the $ * ! ? and <...> name conventions.

Sure, Java has the ?-: if-expression syntax and {...} and probably
a few other things.  But also lacks some of Dylan's uses of punctuation,
and the two languages are very similar at a number of points.  For
instance, they both have the same two ways of writing comments,
and they both have the required parens after "if" (which they
both exploit to avoid having "then").

Quote:
> For a beginner coming to the language, C and Java can look pretty
> formidable. Dylan uses more English words, which can help the beginner
> get oriented to what the code is doing.

It's hard to know what works for beginners.  I always thought Logo had
some odd constructs, but children seemed able to learn it.  I think
Dylan probably is easier in some ways for beginners, but I don't think
there's all that much difference for programmers who are not longer
quite beginners; and it can be argued that for instance { ... } is
better than words because (for one reaons) when you're looking for
words (such as variable names) { ... } is easier to ignore.

Quote:
> >Under "Scoping", I'm not sure what the issue of "encapsulation and
> >compilation" having to follow class boundaries is about.  What is
> >the difference that one ought to care about (so to speak)?

> In Dylan, you can define classes and their methods where they
> naturally belong according to the program structure, whereas
> in Java you are absolutely locked in to defining methods within
> the class definition.

That's a good point but it never occurred to me that that's what
the table ('s author(s)) might have in mind.

Quote:
> The advantages of the Dylan approach come out, for example,
> when you want to implement two closely related classes that
> don't inherit from each other but want to share internals,
> and then expose a very precise interface to outside clients.

Good point.

Quote:
> The Dylan approach is also necessary if you want clean
> multimethods.

I agree (thouhg some feel that isn't really an object-oriented
way to do things).

Quote:
> >"Exceptions": In Java RuntimeExceptions are not "checked" and can
> >be used in much the same way as Dylan exceptions.

> This is true.  However, subclassing RuntimeException is considered
> poor programming style in Java.  You're encouraged to use
> checked exceptions.

I think this idea that it's poor style full stop is clearly wrong.
Some kinds of exceptions ought to be checked, but others are
naturally what Java calls "runtime exceptions".  It's wrong to
suppose the Java implementors can reasonably resort to runtime
exceptions but nothing a user could implement could reasonably
do the same.  I suspect the idea that it's "poor style" reflects
a limited idea of the sorts of things people will write.

So ... I kind of suspect Java programmers will (eventually) realize
that it is sometimes reasonable to use runtime exception.

Quote:
>  We could say something like "most exceptions in
> Java are checked", but I think that's unnecessary given the space
> considerations, and given that Gosling and Arnold are content to
> say, "Java uses checked exceptions to manage error handling" in
> their book "The Java Programming Language."

In many cases, that reasoning would be ok, but I'm not sure
that's the best way to see things when you're explicitly
contrasting checked in Java and unchecked in Dylan.  I think
it would be better to say something that made it clear
(in a not very ...

read more »



Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]



Quote:
>So I think it's better (though not perfect) to say Java doesn't have
>functions -- instead you use objects or classes that have appropriate
>methods -- rather than saying it has functions but they aren't
>objects.  (But I don't think saying "Java doesn't have functions"
>is the right way to put it either.  I think the point has to be:
>what does functions-as-objects give you that isn't available,
>or isn't available without annoying awkwardness, in Java.)

And I suspect that purists would say that the Java style is "more
object-oriented".

Quote:
>> In C and Java it is common to use punctuation where Dylan would use
>> a word.  For example incrementation, vector instatiation, for loops,
>> and curly braces vs begin/end pairs.

>I'm not sure what vector instantiation case you have in mind.
>Presumably not "new Vector()".

I'm guessing he means:

int a[] = {...}

But wouldn't the Dylan equivalent use #(...)?

Quote:
>It's hard to know what works for beginners.  I always thought Logo had
>some odd constructs, but children seemed able to learn it.  I think
>Dylan probably is easier in some ways for beginners, but I don't think
>there's all that much difference for programmers who are not longer
>quite beginners; and it can be argued that for instance { ... } is
>better than words because (for one reaons) when you're looking for
>words (such as variable names) { ... } is easier to ignore.

I've programmed in PL/I, which is heavily into words, and Lisp, C, and
Perl, which make heavy use of punctuation.  While C can be overly terse, I
think I agree with Jeff that once you get familiar with a language it's
better to use punctuation to indicate program structure.  When you're
looking for bracketing constructs, they stand out, but they're easy to
ignore when you're just looking at individual statements.

However, good programming environments can help.  If the program editor
fontifies keywords, they're easy to see when you care about them.  And of
course you want the contents of begin/end blocks to be indented.

If you want to see a language that's really designed to be easy for
beginners to learn, take a look at AppleScript, Apple's scripting language
for the Macintosh.  It's designed to look very much like natural language,
even to the extent that there are many ways to say the same thing to make
it more natural; for instance, the equivalent of "structure.slot" is "slot
of structure" or "structure's slot".  Actually, AppleScript does something
that Dylan was originally intended to do: it has multiple dialects,
referring to the external language that the programmer sees vs. the
internal representation.  What I described above is the English dialect,
but there are foreign language dialects and also a "programmer" dialect
that's supposed to be more like traditional programming languages (I don't
know what it actually looks like).  However, AppleScript isn't object
oriented.

--

GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.



Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]


Quote:

> > >Under Java for "Objects", we find

> > >  Most data are objects. However, functions and numbers are not
> > >  objects, and must be coerced to object types before they can
> > >  participate in the object system.  Classes are special objects that
> > >  lack many of the capabilities of other objects.

> > >But (1) numbers and the like can participate in the object system
> > >to some extent w/o being wrapped as objects,

> > We're not really sure what you mean by this.  Can you give an
> > example?

> Well, I found that one could go quite far without realizing
> that numbers weren't objects.  For instance, you can write a
> method definition such as foo(int i).  You might even see
> something like

>    ...
>    foo(String s) { ... }
>    foo(int i) { ... }
>    ...

This isn't really participating in the object system per-se, this is just
static overloading.

I don't particularly mind that "value types" are not objects in Java, what
I do mind is that I can't create my own new value types, as I can in Ada,
Eiffel, and dare I say it, C++.

The Dylan view is that this distinction between value types and objects is
just an efficiency hack to be resolved by type inference. I'm still
skeptical, but I think the Java solution sucks compared to the other two
options.

-- Brian



Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]

Quote:
> This isn't really participating in the object system per-se, this is just
> static overloading.

It depends on what "participating in the object system" means, and
you aren't the only one who will be interpreting it.

Quote:
> I don't particularly mind that "value types" are not objects in Java, what
> I do mind is that I can't create my own new value types, as I can in Ada,
> Eiffel, and dare I say it, C++.

I'm not sure why I'd want new value types.  Why not create new Object
types?  But don't like it that I can't create subclasses of value types
(which is perhaps what you had in mind?)

Quote:
> The Dylan view is that this distinction between value types and objects is
> just an efficiency hack to be resolved by type inference. I'm still
> skeptical, but I think the Java solution sucks compared to the other two
> options.

I agree that it sucks compared to Dylan.  I'm not sure what other
option you have in mind, but I'm reluctant to say anything sucks
compared to C++.

-- jd



Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]


Quote:
> > This isn't really participating in the object system per-se, this is just
> > static overloading.

> It depends on what "participating in the object system" means, and
> you aren't the only one who will be interpreting it.

Granted. The Java books I started with (Java in a Nutshell and the one by
Arnold and Gosling) made it clear that the set of "basic types" (int,
char, float, ...) are value types, not reference types, and hence not
"polymorphic". If you are used to other statically typed OO languages
(Eiffel, Sather, Ada 95, or C++, for example) this distinction is
familiar, i.e., roughly, Eiffel's expanded classes, Sather's immutable or
value types, Ada 95 tagged and untagged (really separate from ref vs
value, so this is inaccurate), etc.

Quote:
> > I don't particularly mind that "value types" are not objects in Java, what
> > I do mind is that I can't create my own new value types, as I can in Ada,
> > Eiffel, and dare I say it, C++.

> I'm not sure why I'd want new value types.  Why not create new Object
> types?  But don't like it that I can't create subclasses of value types
> (which is perhaps what you had in mind?)

Efficiency, as I make clear below. I don't want to have to have a cadre of
PhDs doing research on how to do unboxing of user defined types like
"Complex" or "Interval" in my numerical linear algebra libraries, when I
know perfectly well that Complex isn't going to be used polymorphically.
If you don't care about scientific computing, that's fine, but I do, and
thus far languages that have to do unboxing due to uniform representation
have not fared well against languages that do not in terms of raw speed.

Quote:
> > The Dylan view is that this distinction between value types and objects is
> > just an efficiency hack to be resolved by type inference. I'm still
> > skeptical, but I think the Java solution sucks compared to the other two
> > options.

> I agree that it sucks compared to Dylan.  I'm not sure what other
> option you have in mind, but I'm reluctant to say anything sucks
> compared to C++.

Personally, I think all programming languages suck in one way or another.
But what I meant was this; if you adopt a uniform "everything is an
object" view, as in Dylan (and Smalltalk, and ...), that seems OK to me,
if you separate objects and basic types for efficiency, like Java and
BETA, then I'd appreciate being able to define my own new "basic types",
and not be stuck with some limited set, 'cuz that sucks. While Java
sucks compared to C++ in that respect, C++ IMO has so many other
misfeatures that it blows Java away in terms of total suckiness, though
C++ is far more useful for writing numerical libraries.

-- Brian



Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]

Quote:


> X-Newsgroups: comp.lang.dylan
> Date: Fri, 30 Jan 1998 12:43:52 -0800
> X-Trace: 886193036 26488 bpr  206.184.139.132
> Xref: cnn.cam.harlequin.co.uk comp.lang.dylan:8595
> X-Mail-News: ignore


> > > This isn't really participating in the object system per-se, this is just
> > > static overloading.

> > It depends on what "participating in the object system" means, and
> > you aren't the only one who will be interpreting it.

> Granted. The Java books I started with (Java in a Nutshell and the one by
> Arnold and Gosling) made it clear that the set of "basic types" (int,
> char, float, ...) are value types, not reference types, and hence not
> "polymorphic". If you are used to other statically typed OO languages
> (Eiffel, Sather, Ada 95, or C++, for example) this distinction is
> familiar, i.e., roughly, Eiffel's expanded classes, Sather's immutable or
> value types, Ada 95 tagged and untagged (really separate from ref vs
> value, so this is inaccurate), etc.

> > > I don't particularly mind that "value types" are not objects in Java, what
> > > I do mind is that I can't create my own new value types, as I can in Ada,
> > > Eiffel, and dare I say it, C++.

> > I'm not sure why I'd want new value types.  Why not create new Object
> > types?  But don't like it that I can't create subclasses of value types
> > (which is perhaps what you had in mind?)

> Efficiency, as I make clear below. I don't want to have to have a cadre of
> PhDs doing research on how to do unboxing of user defined types like
> "Complex" or "Interval" in my numerical linear algebra libraries, when I
> know perfectly well that Complex isn't going to be used polymorphically.
> If you don't care about scientific computing, that's fine, but I do, and
> thus far languages that have to do unboxing due to uniform representation
> have not fared well against languages that do not in terms of raw speed.

FWIW, a couple years ago, Harlequin and CMU came to a preliminary
agreement about a new type of class, called a value (or as cmu called
them functional) class, which would (i think) give you what you want.
hopefully after we get this first release out we can revisit some of
our old future designs and get them out in the near future.  BTW, we
also have a design for `repeated slots' which allow a user to define
a class with an inlined vector component.

jonathan bachrach
(speaking unofficially)



Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]

Brian Rogoff makes a number of good points of which I'll address only
one.  (And, anyway, I pretty much agree with the rest.)

Quote:

> > > This isn't really participating in the object system per-se, this is
> > > just static overloading.

> > It depends on what "participating in the object system" means, and
> > you aren't the only one who will be interpreting it.

> Granted. The Java books I started with (Java in a Nutshell and the one by
> Arnold and Gosling) made it clear that the set of "basic types" (int,
> char, float, ...) are value types, not reference types, and hence not
> "polymorphic".

Right, but Java books (such as Arnold and Gosling) have a section
(or more than one) telling you how "which method" is determined,
and much of that is about overloading.  This all appears to be
part of method selection, even though the type of the arguments are
determined statically.

(The books usually don't make it very clear that it's the
textually-evident declared type that matters here, perhaps because
the aythors aren't fully aware as they write this that the other
possibility -- dynamic on all the args, not just the one before the
dot -- is not only possible but actual in CLOS and a number of other
systems.)

Anyway, it seems to me that you have to resort to a fairly narrow,
technical definition of "participate in the object system" in order to
make these types not participate.  And then it seems to me that in
this kind of language comparision it's not a good idea to have points
that are technically correct, strictly speaking, where this relies on
some terminology familiar to those used to certain languages, plus a
little reasoning, that can be used to argue that it's (strictly
speaking) correct -- if there is, perhaps, some other way of making
the point for which this whole issue is unlikely to ever come up.

In short, what is the real importance, or, as the pragmatists say,
cash value of this point about value types sometimes having to be
converted to object types?  Saying they have to be coerced before they
"can participate in the object system" doesn't tell me.

-- jd



Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]

Quote:

> [re the use of functor classes instead of first-class functions in Java]
> And I suspect that purists would say that the Java style is "more
> object-oriented".

They will, and have.  But isn't this just a mistake?  How can it be "more object
oriented"  to have methods that aren't objects?


Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]


Quote:
> > Granted. The Java books I started with (Java in a Nutshell and the one by
> > Arnold and Gosling) made it clear that the set of "basic types" (int,
> > char, float, ...) are value types, not reference types, and hence not
> > "polymorphic".

> Right, but Java books (such as Arnold and Gosling) have a section
> (or more than one) telling you how "which method" is determined,
> and much of that is about overloading.  This all appears to be
> part of method selection, even though the type of the arguments are
> determined statically.

That's true, although I suppose my experience with C++ made me realize
that its only the object before the dot that contributes run-time type
information to the dispatching process. In Ada 95, which is also single
dispatch, but has function call syntax, which arguments are dispatching
is usually clear at the call site.

Quote:
> (The books usually don't make it very clear that it's the
> textually-evident declared type that matters here, perhaps because
> the aythors aren't fully aware as they write this that the other
> possibility -- dynamic on all the args, not just the one before the
> dot -- is not only possible but actual in CLOS and a number of other
> systems.)

It's actually much worse, in the "Java in a Nutshell" book, the dot
notation is touted as being *the* significant feature of OO.

Quote:
> Anyway, it seems to me that you have to resort to a fairly narrow,
> technical definition of "participate in the object system" in order to
> make these types not participate.  And then it seems to me that in
> this kind of language comparision it's not a good idea to have points
> that are technically correct, strictly speaking, where this relies on
> some terminology familiar to those used to certain languages, plus a
> little reasoning, that can be used to argue that it's (strictly
> speaking) correct -- if there is, perhaps, some other way of making
> the point for which this whole issue is unlikely to ever come up.

OK, I'll try to make clear any language-specific terminology in the
future. In particular, I'd like to do away with the terminology "object
system" and use "type system" instead, since in Java we clearly have a
hybrid system, so it doesn't make sense to talk about float objects, but
it does make sense to talk about an object of the Float class.

-- Brian



Tue, 18 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]

Quote:

> > [re the use of functor classes instead of first-class functions in Java]
> > And I suspect that purists would say that the Java style is "more
> > object-oriented".

> They will, and have.  But isn't this just a mistake?  How can it be "more
> object oriented"  to have methods that aren't objects?

I think the idea is that it's more o-o to use objects that have
appropriate methods than to use functions (e.g. as arguments, or
to store in data structures).  But, of course, functions (or
method objects) in Java would be objects that had a "call"
method (or something like that).  So I suspect the Java advocate
could say something like this: you can create the function objects
you want in Java, but you can give them whatever methods you want.

(So in a sense what java lacks is (b) something that produces functions
objects without you explicitly constructing them, and (b) a pre-defined
function class / interface.)

We might compare the situation in Java to that in T (a dialect of
Scheme).  In T I can write something like

   (object <method definition for when it's called as a function>
     <other method definition>*)

This differs chiefly from Java in having a special syntax for the
<method definition for when it's called as a function> and in
using such function+ objects for lots of built-in purposes.

The big cop out in Java is the failure to have functions (IMHO)
but the restriction that instances of anonymous classes can refer
only to final vars.  Java provides only the kind of closure you
could trivially provide for just about any Lisp in a couple
of minutes by writing a simple macro.  Given that they have a
compiler doing a significant transformation of the code (to
implement inner classes) they could have done a lot better
than that.

But the real annoyance is people claiming Java has closures but
with a different (more o-o) syntax.  I never guessed from that
that there was this "final" restriction, but some of the people
who said that kind of thing must have known there was, and that
closures in, say, Common Lisp or Scheme were not restricted in
that way.  Moreover, they were saying it to reassure Lispish
folk who would be concerned about how exact the equivalence was.

So, in short, they lied.

-- jd



Wed, 19 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]



..

Quote:
> Given that they have a
>compiler doing a significant transformation of the code (to
>implement inner classes) they could have done a lot better
>than that.

    While the compiler may be doing some non-trival transformations.
    the JVM required no modifications. Which is primarily why inner
    classes are so "limited". Changes that would require mods to the JVM
    are sacrosanct.

    Inner Classes are just "syntact sugar" for doing what you already
    could do anyway... with laborious effort.  Which is true of about
    95% of all language features. :-)

--

Lyman S. Taylor            "It's not *OUR* fault....."

                                        'Lovely Angels'



Wed, 19 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]


Quote:

> > > I'm not sure why I'd want new value types.  Why not create new Object
> > > types?  But don't like it that I can't create subclasses of value types
> > > (which is perhaps what you had in mind?)

> > Efficiency, as I make clear below. I don't want to have to have a cadre of
> > PhDs doing research on how to do unboxing of user defined types like
> > "Complex" or "Interval" in my numerical linear algebra libraries, when I
> > know perfectly well that Complex isn't going to be used polymorphically.
> > If you don't care about scientific computing, that's fine, but I do, and
> > thus far languages that have to do unboxing due to uniform representation
> > have not fared well against languages that do not in terms of raw speed.

> FWIW, a couple years ago, Harlequin and CMU came to a preliminary
> agreement about a new type of class, called a value (or as cmu called
> them functional) class, which would (i think) give you what you want.
> hopefully after we get this first release out we can revisit some of
> our old future designs and get them out in the near future.  BTW, we
> also have a design for `repeated slots' which allow a user to define
> a class with an inlined vector component.

That sounds about right, "value" would be a hint to the compiler that
there is no need to tag/box/whatever the data; whether a compiler does
the right thing or not is just a quality of implementation issue.

-- Brian

- Show quoted text -

Quote:

> jonathan bachrach
> (speaking unofficially)



Thu, 20 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]



Quote:
>But the real annoyance is people claiming Java has closures but
>with a different (more o-o) syntax.  I never guessed from that
>that there was this "final" restriction, but some of the people
>who said that kind of thing must have known there was, and that
>closures in, say, Common Lisp or Scheme were not restricted in
>that way.  Moreover, they were saying it to reassure Lispish
>folk who would be concerned about how exact the equivalence was.

>So, in short, they lied.

I may have been one of these people.  But:

* Closures are being touted as important for *functional programming*.
If you restruct the term to "pure" functional programming (as many do),
then requiring captured variables to be final is hardly a restriction.

* If an inner class needs to capture and update an outer variable,
you can always encapulate it in some other object (such as a one-element
array).

* If you are compiling from a functional language, it is easy enough
for a compiler to make these transformations.  I know - I've done it.

* I had forgotten or was unaware of the "final" restrictions, but
I was hardly lying.  Accusing people of lying is hardly productive
or civilized net-discussion.  If were are referring to me, I want
an apology.

The bottom lines remains:  You can simulate closures with objects, and
you can simulate objects with closures.  The rest is a matter of
syntactic sugar, convenience, and taste, not power.  Inner classes
make it easier to simulate closures with objects, but they are not
the same - though they have similar "power".

--
        --Per Bothner



Thu, 20 Jul 2000 03:00:00 GMT  
 Dylan and Java [was: Harlequin Dylan - Update]



Quote:

>> > Efficiency, as I make clear below. I don't want to have to have a cadre of
>> > PhDs doing research on how to do unboxing of user defined types like
>> > "Complex" or "Interval" in my numerical linear algebra libraries, when I
>> > know perfectly well that Complex isn't going to be used polymorphically.

  If it isn't going to used polymorphically then seal the domain of the
  application methods, don't define setter functions, and in general
  treat it as an immutable data structure all in a library by itself.
  It shouldn't take "a carde of PhDs" to unbox  that.   :-)

Quote:
>> FWIW, a couple years ago, Harlequin and CMU came to a preliminary
>> agreement about a new type of class, called a value (or as cmu called

                         ^^^^^^^^^^^^^

Quote:

>That sounds about right, "value" would be a hint to the compiler that

    If it is a new class/type I not sure how that would be a "hint".
    That wouldn't the adjective  register in C, a suggestion.  It would
    be an actual type.

    Is this a new branch on the object hierarchy:

                              object
                                 |
                    ....  |------|---------| .....  
                         ...   value      ...

    or the by-product of type constructor like LIMITED?

--

Lyman S. Taylor            "It's not *OUR* fault....."

                                        'Lovely Angels'



Fri, 21 Jul 2000 03:00:00 GMT  
 
 [ 24 post ]  Go to page: [1] [2]

 Relevant Pages 

1. (fwd) harlequin's dylan-corba mailing list switching to MIT's info-dylan

2. Harlequin Dylan Update

3. Harlequin Dylan - Update

4. HARLEQUIN DYLAN and C FFI

5. Small d2c and Harlequin Dylan incompatibility

6. first attempt at Harlequin-Dylan

7. Functional Objects to take over Harlequin Dylan

8. Harlequin Dylan 2.0 beta 2 is now available

9. Future of Harlequin Dylan

10. ODBC database with Harlequin Dylan

11. using winInet with harlequin dylan

12. Beginners problem with Harlequin Dylan

 

 
Powered by phpBB® Forum Software