Harlequin Dylan - Update 
Author Message
 Harlequin Dylan - Update

Greetings from the Harlequin Dylan project.

As I recently promised to this newsgroup, here
is an update of what's happening with Harlequin
Dylan.

First, we have just issued a press release with
all of the latest product information. You can
find the release at the following URL.

< http://www.*-*-*.com/ ;

We also have begun adding new Dylan-related material
to our website. There you will find an all-new white
paper on Dylan, a comparative analysis with Java and
other good things. Let us know if there's anything
you'd like added in this area.

< http://www.*-*-*.com/ ;

The beta test continues, and we have been getting
tremendous feedback from our initial test group.
They have been leading the way in showing us where
the environment succeeds, as well as where we need
to make some changes and improvements.

The beta testers' recommendations are already being
incorporated into the environment, with improvements
in speed, usability and stability on the way. The
Dylan community will directly benefit from their
hard work. Thank you!

If you have not yet done so, please visit the beta
sign-up page. Should there be a subsequent test phase,
it is expected to be much wider in scope and you will
have a chance to make your mark on Dylan.

< http://www.*-*-*.com/ ;

That's all for the moment.

Regards,

Tom Borgman
Harlequin Dylan Support



Sun, 16 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update

In-Reply-To: Tom Borgman's message of Wed, 28 Jan 1998 11:28:18 -0500

I have just read the Dylan - Java comparison on

http://www.harlequin.com/products/ads/dylan/dvj.shtml

and have some questions about it.

Let me first point out that I have been forced to use Java and am no
great fan of that language.  Just for instance: "write once, run
everywhere" is a lie; Java lacks some features that I want in an OO
language (e.g. proper ("dynamic") message selection based on > 1
argument rather than Java's hybrid "dynamic before the dot, static
after"); and Java threads are a nightmare.  Anyway, ...

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, (2) Classes are objects
(I don't know what lack of "capabilities" makes them so "special"),
and (3) there aren't any functions, so of course functions are not
objects.

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

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?  Also, Dylan has
one of the same annoying features, unseen outside of C and PL/I:
the required parens around conditions in "if" etc.

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)?

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

-- jd



Sun, 16 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update


Quote:
>I have just read the Dylan - Java comparison on

>http://www.harlequin.com/products/ads/dylan/dvj.shtml

>and have some questions about it.

>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,

How so?  A Java 'char' for example has no superclasses and cannot be
subclassed.  A char cannot be stored in a Java vector.  The only way
to get these features is to use a Char, which is a wrapper around a
char.

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

Again, how so?  Can you pass a Java class as an argument to a method?
No.  Can you store a class in a variable?  Nope.

In Dylan you can do these things.  As an example, make() is a Dylan
generic function which takes a class as the first argument, and
creates an object of that class.  The compiler provides a default
method for make() which instantiates an object, but you can add your
own methods to change make()'s behavior.

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

Only if you don't consider Java methods to be functions.  In Java, you
cannot pass methods as arguments, which makes many tasks more
difficult.  As a workaround, you typically provide an interface with
an 'execute' method, and pass an instance of a class which implements
that interface.  A good example is the Java Runnable interface which
is used to start threads.

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

Because your Java Virtual Machine implementation is buggy, or you're
using unsafe features (like foreign functions).  You can't blame these
crashes on the language.

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?  

main(p,c){for(;~(c=c==9&&p-1&7?c:getchar())&&putchar(c^9?c:32);p=c^10?p+1:1);}

(Well, that's C, but I suspect you get the point.)  C's syntax, and
thus Java's, tends toward using terse symbols, whereas Dylan tends
toward more wordy syntax.  It's a matter for debate which is better
for an experienced programmer, but I suspect that for a beginner it's
much easier to guess what a line of Dylan means than a line of Java.

Quote:
>Also, Dylan has
>one of the same annoying features, unseen outside of C and PL/I:
>the required parens around conditions in "if" etc.

Those parens do feel a little out of place at first, but I think
they're the right way to go.  The alternative for dylan would be to
provide some kind of keyword to end the condition, e.g.:

  if foo = 7 then
    do-stuff();
  end if;

however, you'd have to have some terminating keyword for every macro
which takes a condition, e.g.:

  for foo in blah do
    ...
  end for;

  block exit in                 // Is in the right terminator?
    ...
  end block;

Every different construct of this type would need a different
terminating word, and you'd never be able to remember the appropriate
word.  I think parens are preferable.

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 Java, if you want to limit the access others have to the internals of
a class, you can use the private keyword.  However, suppose you have
two exported classes which need to cooperate intimately - class A may
need to access functionality of class B that you don't want to expose
to the world.  In Java, there's no way to hide this functionality yet
let A access it.

On the other hand, Dylan's module system lets you control access to
functionality in more flexible ways.  The above example is easy in
Dylan: put class A and B into a module, and only export the
functionality you want exposed.

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

Yes, but defining your own RuntimeExceptions is not exactly
recommended programming practice (is it possible?).  In any case,
Java's checked exceptions (i.e. having to declare which exceptions a
function may throw) has its advantages - you are guaranteed you'll
never get an unexpected exception.  However, it would interact badly
with Dylan's other features.

Where Dylan comes out ahead is that it allows resuming execution at
the point the exception was thrown.  For example, a routine to open a
file could throw a resumable exception when the file can't be found.
A handler for that exception could then change the filename to open
and resume the exception.

Seth LaForge
Harlequin, Inc.



Mon, 17 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update

Greetings from the Harlequin Dylan project.

As I recently promised to this newsgroup, here
is an update of what's happening with Harlequin
Dylan.

First, we have just issued a press release with
all of the latest product information. You can
find the release at the following URL.

< http://www.harlequin.com/news/press/dylan_0198.html >

We also have begun adding new Dylan-related material
to our website. There you will find an all-new white
paper on Dylan, a comparative analysis with Java and
other good things. Let us know if there's anything
you'd like added in this area.

< http://www.harlequin.com/products/ads/dylan/ >

The beta test continues, and we have been getting
tremendous feedback from our initial test group.
They have been leading the way in showing us where
the environment succeeds, as well as where we need
to make some changes and improvements.

The beta testers' recommendations are already being
incorporated into the environment, with improvements
in speed, usability and stability on the way. The
Dylan community will directly benefit from their
hard work. Thank you!

If you have not yet done so, please visit the beta
sign-up page. Should there be a subsequent test phase,
it is expected to be much wider in scope and you will
have a chance to make your mark on Dylan.

< http://www.harlequin.com/products/ads/dylan/betaprog_form.html >

That's all for the moment.

Regards,

Tom Borgman
Harlequin Dylan Support



Mon, 17 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update



Quote:
>What is this "relies heavily on punctuation" about?  Also, Dylan has
>one of the same annoying features, unseen outside of C and PL/I:
>the required parens around conditions in "if" etc.

Just to set the record straight, I don't think PL/I shares C and Dylan's
"required parens around conditions".  It's been 11 years since I did much
PL/I programming, but I think this memory is correct.  PL/I is probably one
of the most difficult languages to parse, because keywords are not reserved
words and there's relatively little required punctuation (fortran may also
be up there, mainly because whitespace is not significant).

--

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.



Mon, 17 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update

I don't want to sound like a Java apologist, but a handful of points here
need correction.

Quote:

> Can you pass a Java class as an argument to a method?
> No.  Can you store a class in a variable?  Nope.

Err, you can.
    Class aClass = Class.forName( "String" );
    proc( aClass );
    Object obj = aClass.newInstance();

and so forth.

Quote:
> In Java, you cannot pass methods as arguments

Well, there is the reflection API in 1.1, so this is strictly false. But
it's relatively new and often considered a "power feature", not for casual
use.

Quote:
> In Java, if you want to limit the access others have to the internals of
> a class, you can use the private keyword.  However, suppose you have
> two exported classes which need to cooperate intimately - class A may
> need to access functionality of class B that you don't want to expose
> to the world.  In Java, there's no way to hide this functionality yet
> let A access it.

> On the other hand, Dylan's module system lets you control access to
> functionality in more flexible ways.  The above example is easy in
> Dylan: put class A and B into a module, and only export the
> functionality you want exposed.

The Java solution is similar to the Dylan one. You put A and B into a
package and give the feature "package access". Indeed, this is the default
access type. It is Java's answer to C++'s "friend", or Eiffel's selective
export. (I hate it, but it is there.)

Quote:
> Yes, but defining your own RuntimeExceptions is not exactly
> recommended programming practice (is it possible?).

It's possible. My Java code relies on it. It's not always appropriate, but
when it *is* appropriate it's surely recommended.

   Dave Harris, Swansea, UK   | "Weave a circle round him thrice,

                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



Mon, 17 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update

Quote:



> >What is this "relies heavily on punctuation" about?  Also, Dylan has
> >one of the same annoying features, unseen outside of C and PL/I:
> >the required parens around conditions in "if" etc.

> Just to set the record straight, I don't think PL/I shares C and Dylan's
> "required parens around conditions".  It's been 11 years since I did much
> PL/I programming, but I think this memory is correct.  PL/I is probably one
> of the most difficult languages to parse, because keywords are not reserved
> words and there's relatively little required punctuation (Fortran may also
> be up there, mainly because whitespace is not significant).

You may be right, but I did a fair amount of essentially "subset G"
PL/I programming at one time, and I have somehow retained this memory
of the parens being required.

But since neither of us is consulting a definitive source, I think
we'll have to regard this one as unresolved.

-- jd



Mon, 17 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update


Quote:



>> >What is this "relies heavily on punctuation" about?  Also, Dylan has
>> >one of the same annoying features, unseen outside of C and PL/I:
>> >the required parens around conditions in "if" etc.

>> Just to set the record straight, I don't think PL/I shares C and Dylan's
>> "required parens around conditions".  It's been 11 years since I did much
>> PL/I programming, but I think this memory is correct.  PL/I is probably one
>> of the most difficult languages to parse, because keywords are not reserved
>> words and there's relatively little required punctuation (Fortran may also
>> be up there, mainly because whitespace is not significant).

>You may be right, but I did a fair amount of essentially "subset G"
>PL/I programming at one time, and I have somehow retained this memory
>of the parens being required.

>But since neither of us is consulting a definitive source, I think
>we'll have to regard this one as unresolved.

Do I take that to mean that neither of you is signing up to do the
Dylan PL/I comparison? ;-)

  -Andrew

p.s. responses to Jeff's other responses will be coming soon.

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




Mon, 17 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update


Quote:
>I don't want to sound like a Java apologist, but a handful of points here
>need correction.

Fair enough.

Quote:

>> Can you pass a Java class as an argument to a method?
>> No.  Can you store a class in a variable?  Nope.

>Err, you can.
>    Class aClass = Class.forName( "String" );
>    proc( aClass );
>    Object obj = aClass.newInstance();

>and so forth.

Interesting - I didn't know about this.  Looking at the Java 1.1 docs,
I see that you can even get Class objects from an instance as well as
by name.

Quote:
>> In Java, you cannot pass methods as arguments

>Well, there is the reflection API in 1.1, so this is strictly false. But
>it's relatively new and often considered a "power feature", not for casual
>use.

And, again looking at the 1.1 API, inner classes do make it easier to
simulate first-class functions.  It's still not as convenient at in
Dylan, but better than in 1.0.

Seth



Tue, 18 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update

Quote:
> >> In Java, you cannot pass methods as arguments

> >Well, there is the reflection API in 1.1, so this is strictly false. But
> >it's relatively new and often considered a "power feature", not for casual
> >use.

> And, again looking at the 1.1 API, inner classes do make it easier to
> simulate first-class functions.  It's still not as convenient at in
> Dylan, but better than in 1.0.

I'd say that "simulate first-class functions" goes too far towards
suggesting that what one really wants is first class functions.
I happen to think that first-class functions are great, but Java
has a consistent and not unreasonable way of doing things.
Writing an anonymous class with one method may be a bit more
verbose than writing an anonymous function definition, but it
gives you more flexibility for some things, and it is pretty
obviously object-oriented.

My main complaint about what Java does here is the restriction
that your "function" instances can refer only to final variables
in the enclosing scope.  I can recall reading a number of times
that the anonymous class way of doing functions was just
closures with a differtent syntax, but the "final" restriction
makes that false and, since some of the people who said  they're
the same must have known of this restriction, I'm sometimes
inclined to say they lied.

The big lie, though, is all the Java books that repeat the claim that
you can write once, run everywhere.  The counter-slogan -- write once,
debug everywhere -- has already taken off, which shows there's still
some sanity amidst the hype.

-- jd



Tue, 18 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update

----------

--
-->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 Java, if you want to limit the access others have to the internals of
--a class, you can use the private keyword.  However, suppose you have
--two exported classes which need to cooperate intimately - class A may
--need to access functionality of class B that you don't want to expose
--to the world.  In Java, there's no way to hide this functionality yet
--let A access it.
--
--On the other hand, Dylan's module system lets you control access to
--functionality in more flexible ways.  The above example is easy in
--Dylan: put class A and B into a module, and only export the
--functionality you want exposed.
--
This is actually misleading a bit.  For this scenerio in Java, you could put
these classes in the same package and declare the ivars 'protected'.  When
ivars are declared 'protected', other classes in the same package can access
those variables.

Sam Griffith Jr.




Tue, 18 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update


Quote:

>The big lie, though, is all the Java books that repeat the claim that
>you can write once, run everywhere.  The counter-slogan -- write once,
>debug everywhere -- has already taken off, which shows there's still
>some sanity amidst the hype.

Do you think this is because the implementations are immature, or because
of a more fundamental flaw in the design?

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




Tue, 18 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update


Quote:

> >The big lie, though, is all the Java books that repeat the claim that
> >you can write once, run everywhere.  The counter-slogan -- write once,
> >debug everywhere -- has already taken off, which shows there's still
> >some sanity amidst the hype.

> Do you think this is because the implementations are immature, or because
> of a more fundamental flaw in the design?

In my opinion, the former. Even more important, the supporting libraries
are changing so rapidly that programmers are forced to do the same dance
they did with C++, always staying a few generations behind the current Sun
implementation. This isn't conjecture, I lived through this. Applications
written for the Hot Java Screensaver that made use of RMI, JMAPI, etc...
would not run on Netscape or IE. Thats not a flaw of the design, just the
reality of keeping the VMs and libraries of all of those browsers in sync.

-- Brian



Tue, 18 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update


Quote:


> >I have just read the Dylan - Java comparison on

> >http://www.harlequin.com/products/ads/dylan/dvj.shtml

> >and have some questions about it.

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

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

> Again, how so?  Can you pass a Java class as an argument to a method?
> No.  Can you store a class in a variable?  Nope.

Classes in Java seem like first class objects to me. I pass them as
arguments, return them as results, assign them to variables, and store
them in arrays, just like any other value in the language. And while in
Java 1.0.2 there was no direct syntax to reference a class value, there is
now. Plus there's a lot of reflective hooks for classes, methods, and
slots in Java 1.1. In fact, if my own reflection on the subject doesn't
fail me, Java's reflection suite exceeds what is provided in the most of
the seed versions of Apple Dylan in my possession. So, regarding class
issues, Java's not all that bad. Now if Java would just support
multi-methods...

/ Gary

--
Gary Beaver



Tue, 18 Jul 2000 03:00:00 GMT  
 Harlequin Dylan - Update


viously object-oriented.

Quote:

> My main complaint about what Java does here is the restriction
> that your "function" instances can refer only to final variables
> in the enclosing scope.  I can recall reading a number of times
> that the anonymous class way of doing functions was just
> closures with a differtent syntax, but the "final" restriction
> makes that false and, since some of the people who said  they're
> the same must have known of this restriction, I'm sometimes
> inclined to say they lied.

This is also one of my main complaints about inner classes. Another
problem is that anonymous inner-classes are  either private or
package-visible classes (I can't remember which). Therefore, you cannot
return an instance of an anonymous inner class and use the return value in
a different package. You end up with some kind of instantiation or
security error -- I can't remember exactly as it's been awhile since I got
burned by the lack of syntax to declare visibility for anonymous classes.

/ Gary

--
Gary Beaver



Tue, 18 Jul 2000 03:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Dylan and Java [was: Harlequin Dylan - Update]

2. Harlequin Dylan Update

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

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