Language Design (Re: Dylan type-safety ) 
Author Message
 Language Design (Re: Dylan type-safety )

OTOH, it is worth remembering that a penguin is a bird, and so is a roast
chicken.  Neither one can fly, nevertheless, the generic bird can fly.
This needs to be a legal form of inheritance, yet it is nice to have
features of the "All men are mortal" kind.
Perhaps there should be a way to allow "Universal truths" to be asserted,
separate from the standard inheritance?  Or as an adjunct to it?

Or perhaps types should be allowed to identify "optional characteristics"
(expected, but not a part of the core of the class definition).  So the
defining characteristic of Mammilla would be "lactates and has hair ", and
just about everything else would be "optional extras".

Quote:
-----Original Message-----


Date: Friday, July 30, 1999 3:52 AM
Subject: Re: Dylan type-safety



>> >You don't need such annotations with a language with a class system
>> featuring
>> >multiple inheritance and inherently polymorphic function calls.

>> I'm not sure what you're saying here -- do you consider all forms of
static
>> type-checking worthless?  We could discuss that issue at great length I'm
>> sure.  For the purpose of this thread, I'm just trying to figure out
whether
>> Dylan _has_ static type-checking of various sorts, not whether or not
static
>> type-checking is important.

>I am certainly not saying static type checking is worthless (it's vital), I
am
>saying that Dylan has static type checking if one chooses to use it, and
that
>this is useful for RAD and for working a bit more dynamically if one wishes
to.
>For example:

>let pingu = make( <penguin> );
>let pinga :: <penguin> = make( <penguin> );
>let home :: <igloo> = make( <penguin> );        // This won't compile
>let school = make( <penguin> );

>// Assuming the correct method...

>walk( pingu );
>walk( pinga );
>walk( igloo );        // Won't compile
>walk( school );    // Run-time error if it compiles

>> >This is a compiler requirement, not a language
>> >requirement.

>> It's both.  ...  The language needs to allow you to annotate your code so
>> that the compiler can decide effectively what code to accept and what
code
>> to reject.  That's the essence of static typing, in my opinion.

>I agree, and it's already there. See the example, above.

>> >... ( I work programming Java 4.5 days a week ).

>> I'm sorry if you hate your job.

>LOL! I simply meant I have used Java more than a little.

>> >Dylan is designed for you to be able to rapidly get going with dynamic
>> slots, then home in on more type safe definitions as you decide what you
want.

>> Of course I know that this was the goal of Dylan's design.  I'm trying to
>> figure out how well it meets this goal.  To that end, I've tried to
express
>> the goal in more thorough, explicit terms.  If we go back to the sort of
>> vague, propagandistic language you're using here, I don't think we'll
have a
>> productive discussion.

>I am no more using propagandistic language than you are when re-desribing
>aDylan's design goals in terms designed to explain the strengths of other
>languages then finding it lacking in the terms of the redescription, but
let's
>be explicit:
>It is possible to write an un-typed statement in Dylan that can later be
>re-written as a typed statement. The Develop article gives good, brief,
specific
>examples of this, which is why I mention it, not because I think copies of
the
>Harlequin book or the DRM are hard to find.

>> At the very least, some changes in the intuitive semantics of the
language
>> will be required.  For instance, according to Bruce, declaring a generic
>> function with a <bird> argument does not amount to a contract that all
>> concrete subclasses of <bird> must provide an implementing method.

>As others have observed, you can{*filter*}up in any language if you try.
Changing
>Java or C++ so you have to initialize a field would stop an awful lot of
Null
>Pointers, but lead to an awful lot of wasted dummy objects. I am not
convinced
>that altering the intuitive semantics of Dylan to disallow one  programmer
error
>would be productive or even syntactically enforcible.

>> >Dylan is as
>> >type-safe as you make it

>> I disagree.  Using today's language definition, interpretation of the
>> definition, and compilers, some very simple errors are not caught at
>> compile-time.  Again, if Bruce is successful in the changes he's trying
to
>> make, then we can continue this discussion.

>The difference between the language and the implementation is a key one, so
I'll
>have to bow out here.

>- Rob.



Fri, 18 Jan 2002 03:00:00 GMT  
 Language Design (Re: Dylan type-safety )

Quote:

>OTOH, it is worth remembering that a penguin is a bird, and so is a roast
>chicken.  Neither one can fly, nevertheless, the generic bird can fly.
>This needs to be a legal form of inheritance, yet it is nice to have
>features of the "All men are mortal" kind.
>Perhaps there should be a way to allow "Universal truths" to be asserted,
>separate from the standard inheritance?  Or as an adjunct to it?

>Or perhaps types should be allowed to identify "optional characteristics"
>(expected, but not a part of the core of the class definition).  So the
>defining characteristic of Mammilla would be "lactates and has hair ", and
>just about everything else would be "optional extras".

Check out Cecil's predicate types.  The idea of predicate-based types
has been around for a while (I did a version that I intended to use in CLIM
using the CLOS MOP almost ten years ago -- and the idea wasn't new
then -- but it was too slow to be useful), but the Cecil folks appear to
have
gotten it to work pretty well.

Look at http://www.cs.washington.edu/research/projects/cecil/www/ --
it's a got a stack of papers that describe a body of excellent work.



Fri, 18 Jan 2002 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Dylan type-safety

2. Evolution toward greater SAFETY in language design

3. Evolution toward greater SAFETY in language design

4. Hi all - new to smalltalk [type services and type-safety]

5. Type restrictions / type safety in Smalltalk?

6. Ada95 language design question (accessibility rules and type extensions)

7. tagged types extensions - language design question

8. Eiffel Type-Safety Reference

9. breaking Eiffel's type safety?

10. Realising type-safety

11. Realising type-safety

12. Eiffel type safety.

 

 
Powered by phpBB® Forum Software