Info Dylan Digest Digest V1 #114 
Author Message
 Info Dylan Digest Digest V1 #114

Quote:
> Date: Sat, 18 Sep 1993 20:38:28 GMT

> Subject: What? No :before and :after methods?

> I'm wondering why Dylan doesn't include similar facilities. Obviously,
> there are a number of ways to get around this problem without using
> :before and :after methods, but it might be nice to have this feature
> in the language itself.

In general, we tried to be conservative in adding features to standard
Dylan.  Our operating principle is that it's easier to add something later
than to remove it later.  If a feature proves to be invaluable, market
forces will push it into particular implementations.

In the case of :before and :after methods, we found that many users from
non-CLOS backgrounds had a hard time understanding which methods would
fire in what order, given the presence of multi-methods, multiple-inheritance,
and method combination.  We thought it perhaps better to simplify.  Some
people disagreed with the decision.  I expect they may be added back in
the future.  Yours is another vote in their favor.

  -Andrew



Sat, 09 Mar 1996 01:23:54 GMT  
 Info Dylan Digest Digest V1 #114

Quote:
>If a feature proves to be invaluable, market
>forces will push it into particular implementations.

Depends on what you mean by 'invaluable'.  There are
many, many things that could be better in C, but which
will probably never appear widely because once the
standardization wagon gets going, it's nearly
impossible to get improvements in.  I watched many
pounds of ANSI C meeting minutes go by, and saw many,
many good, even obvious, things get shot down because
they were "invention" (even if they were already proven
in some implementation).  Most likely, too many
compiler vendors on the committee who were making too
little money from their compilers were determined to
shoot down anything that would cause them extra work.

Also, Dylan will be most useful if one can write
portable code in it.  Therefore, standardization is
important.  Therefore, getting features only into
"particular implementations" is not that interesting.

Often, your only chance at getting things right is
at the beginning, when you are the only source,
and when you don't have too many users.

--
  Dave Yost



Sat, 09 Mar 1996 01:34:49 GMT  
 Info Dylan Digest Digest V1 #114

Quote:


> Date: Mon, 20 Sep 1993 17:34:49 GMT

> Depends on what you mean by 'invaluable'.  There are
> many, many things that could be better in C, but which
> will probably never appear widely because once the
> standardization wagon gets going, it's nearly
> impossible to get improvements in.  I watched many
> pounds of ANSI C meeting minutes go by, and saw many,
> many good, even obvious, things get shot down because
> they were "invention" (even if they were already proven
> in some implementation).  Most likely, too many
> compiler vendors on the committee who were making too
> little money from their compilers were determined to
> shoot down anything that would cause them extra work.

I am continually amazed at the number of C++ compiler messages
that say something like: "Sorry, not yet implemented."
It might be best to keep Dylan simple enough that even the
laziest vendor can implement the entire base-level language.  
At least we would be more likely to be able to count on the features
documented in the language spec.  As it is, it appears that in
multiplatform C++ development, we have to write to the lowest
common denominator, and it's pretty low.  I surely hope that
the situation is better with Dylan, if and when there are
commercial implementations.

Not that I'm disgusted and discouraged ...

Tom



Sat, 09 Mar 1996 02:27:30 GMT  
 Info Dylan Digest Digest V1 #114

Quote:
> many, many things that could be better in C, but which
> will probably never appear widely because once the

I think the current situation with respect to altering Dylan in
the future is closer to postscript than to C.  Adobe has successfully
introduced significant improvements to Postscript after it was
in widespread use.

Also we shouldn't forget that C had a number of years of revision
and improvement-- the implementations associated with Unix v6, v7,
and then berkeley had successive improvements.  This was (i believe)
before the K&R C book appeared, and of course well before ANSI C.
The first C compiler i used did not have printf()!



Sat, 09 Mar 1996 04:22:18 GMT  
 Info Dylan Digest Digest V1 #114

< a bit deleted >

Quote:
>Also we shouldn't forget that C had a number of years of revision
>and improvement-- the implementations associated with Unix v6, v7,
>and then berkeley had successive improvements.  This was (i believe)
>before the K&R C book appeared, and of course well before ANSI C.
>The first C compiler i used did not have printf()!

But printf is not part of c.  It happens to be a c function call into
a library  most often (and required by ANSI) supplied with c. Maybe a
change along the line of not having uniq structure member names which
didn't break existing code but make code easier to write would be what
you had in mind?

bruce

--
"... make the suspension adjustable and they will adjust it wrong --
look what they can do with a Weber carburetor in just a few moments of
stupidity with a screwdriver."     - Colin Chapman



Sat, 09 Mar 1996 10:29:35 GMT  
 Info Dylan Digest Digest V1 #114


JL> I think the current situation with respect to altering Dylan in
JL> the future is closer to Postscript than to C.  Adobe has successfully
JL> introduced significant improvements to Postscript after it was
JL> in widespread use.

Such as? If you're thinking of Postscript Level 2, I don't buy it.
Look how long it's taken Apple to develop a Postscript Level 2 driver
for the Laserwriter. Okay, okay, that probably doesn't have anything
to do with Postscript itself, but I think that adding incremental
improvements over time is unlikely to happen.

Having a Dylan trademark might help, but how are you going to handle
it in these cases? Are there going to be multiple levels of Dylan
conformance? Multiple versions of the Dylan spec? {*filter*}like this just
confuses people. If you don't have some controlling body, then you
eventually have to produce a standard which merges all of the
incompatible extensions that people have made (a la ANSI C and Common
Lisp).

Only time will tell, but I think Apple is headed too far down the
Minimalist Path. What if I want to implement a version of Dylan for
the Macintosh that allows people to specify which CODE segment a given
method should end up in? Well, since #pragma, declaim, declare, etc.
aren't in the language I have to make something up. How much do you
want to to bet that I make up the same thing as the guy down the street?
How much do you want to bet that when Apple gets around to
standardizing this feature that they'll pick a standard that doesn't
leave anyone out in the cold?

Currently, there are just too many things missing from the language.

                                                        -- Scott

--
==============================================================================
Senior Technical Staff                          500 Oracle Parkway
System Management Tools Group                   Box 659405
Oracle Corporation                              Redwood Shores, CA. 94065
415-506-2493                                    FAX: 415-506-1099

==============================================================================



Sun, 10 Mar 1996 10:23:55 GMT  
 Info Dylan Digest Digest V1 #114


   > I'm wondering why Dylan doesn't include similar facilities.

   In the case of :before and :after methods, we found that many users from
   non-CLOS backgrounds had a hard time understanding which methods would
   fire in what order, given the presence of multi-methods, multiple-inheritance,
   and method combination.  We thought it perhaps better to simplify.  Some
   people disagreed with the decision.  I expect they may be added back in
   the future.  Yours is another vote in their favor.

Gee, are we voting?  Mark me down in favor as well!

Seriously, if you aren't going to base the OO part of Dylan on a
meta-object protocol in order to standardize extension, you should at
least stake out the well-understood ground of previous Lisp OO
systems.  I mean, I have been writing :BEFORE and :AFTER methods for
over 10 years in Lisp, right?  And for at least five of them CLOS has
even been computing class precedence lists in a rational fashion,
right?

At least we still have multiple inheritance.  I just read an article
in Byte a few months back about the evils of mixin-style programming.
How can you possibly tell what method is going to run?!



Mon, 18 Mar 1996 09:29:31 GMT  
 Info Dylan Digest Digest V1 #114
Actually I'd rather have the :before and :after methods.
I'd rather _not_ have multiple inheritance 'cuz of all the problems
everyone has with it.  It's soooo tempting to use it too!

--thomas--
--
Someone said to me recently, "I've got my _whole_ summer in this camera."
I think the philosophical implications of this statement are staggering.
What would happen if she took a picture of say... Yosemite Falls and it
just... disappeared?  :-)



Mon, 18 Mar 1996 06:02:04 GMT  
 Info Dylan Digest Digest V1 #114

Quote:

>Actually I'd rather have the :before and :after methods.
>I'd rather _not_ have multiple inheritance 'cuz of all the problems
>everyone has with it.  It's soooo tempting to use it too!

In introductory programming classes, people often have trouble with
the idea of recursion. What's more, I find it really tempting to use
recursion in my programs.

I do hope the Dylan designers are finally going to take the
opportunity to eradicate this unpleasant wrinkle from Lisp-like
languages. After all, millions of fortran programmers can't be wrong.

Sheesh.
                                                  -- Paul.

--
Rank Xerox EuroPARC, Cambridge     Computer Science, University College London

               "Opinionated bastards have feelings too"



Tue, 19 Mar 1996 00:30:24 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Info Dylan Digest Digest V1 #127

2. Info Dylan Digest Digest V1 #122

3. Info Dylan Digest Digest V1 #84

4. info-dylan-digest V1 #24

5. Info Dylan Digest V1 #191

6. Info Dylan Digest V1 #177

7. Info Dylan Digest V1 #149

8. Info Dylan Digest V1 #147

9. Scheme Digest V5 #114

10. Scheme Digest V4 #114

11. Info Dylan Digest V2 #43

12. Info Dylan digest V2 #682

 

 
Powered by phpBB® Forum Software