Interim Manual: a few notes 
Author Message
 Interim Manual: a few notes

Hello,

I must say that I kind of like Dylan as it appears in the Interim
Manual. Allow me to make some notes on some design (and not) choiches
which I do not particularly agree with.

Besides the fact that macros MUST be there in some form, here are
other points which I want to note. Let's proceed with order:

1 - #optional (i.e. &optional) parameters are missing.
2 - before, after and around methods
3 - file formats
4 - module and libraries declarations
5 - foreign function interface

1 - #optional (i.e. &optional) parameters are missing.

Why are they not there? It would not seem to be that big a problem to
introduce them.

2 - before, after and around methods

Once again, they are very useful, and I can think of situations where
the use of 'next-method' is not enough. I suppose they hinder the
efficiency of the function invocation, but I do not see why, given
that the applicable methods must be computed somehow.

3 - file formats

SARCASTIC MODE ON
I did not know that there where people from the COBOL community
designing Dylan.

The section on the "Syntax of Dylan Files" would drive up the wall any
programmer who has learned to program *after* COBOL and fortran.

Here are some pearls of the Jurassic definitions in the Manual

"A keyword begins on a new line, and cannot be preceded by
whitespace."

"The header cannot contain comments."

"Blank lines may not appear in the header..."
SARCASTIC MODE OFF

It would seem that this part of a file should resemble the 'resource
fork' of a MAC file.
I am sure that it could have been defined in a better way.

4 - module and libraries declarations

I understand that Dylan assumes the Common Lisp model of "packages are
symbol repositories". I think that this approach assumes the notion of
"developing environment" a la` Lisp.

I wrote on this subject in the Lisp groups some time ago.

The main problem is that in this way a module or library definition fails to
provide two (IMHO) important supporting tools to the programmer and
the compiler. The reason for this is the lack of type information
associated with the symbols.

Suppose I could write

        define module some-stuff
           exports pi :: <real>,
                   pi/4 :: <real>,
                   i-dont-know-what-i-am,
                   popeye :: <sailor>
        end module

I would at the same time

a) give the compiler the opportunity to do less work in loading
   modules and inferencing the type of the symbols used
b) it would provide better documentation to the reader of the module
   definition

5 - foreign function interface

I believe that one of the major obstacles toward the acceptance of
Dylan is the "reusability" issue. As an example, nobody would want to
give up Motif just because it is written in C.

CL suffers a lot from this "non integration" with the C
mainstream. The situation is made worse by the lack of a standardized
foreign function interface.

I believe that the definition of a standard FFI for Dylan would be an
act of foresight that could save the day later on.

Thanks for your patience (and endurance) :)

--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab            | room: 1220 - tel. #: (212) 998 3370

...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
                                Bertholdt Brecht



Sun, 01 Dec 1996 08:44:05 GMT  
 Interim Manual: a few notes

Quote:


> Newsgroups: comp.lang.dylan
> Subject: Interim Manual: a few notes
> Date: 15 Jun 1994 00:44:05 GMT
> Organization: Courant Institute of Mathematical Sciences
> 5 - foreign function interface

> I believe that one of the major obstacles toward the acceptance of
> Dylan is the "reusability" issue. As an example, nobody would want to
> give up Motif just because it is written in C.

> CL suffers a lot from this "non integration" with the C
> mainstream. The situation is made worse by the lack of a standardized
> foreign function interface.

> I believe that the definition of a standard FFI for Dylan would be an
> act of foresight that could save the day later on.
> Marco Antoniotti - Resistente Umano

I agree.  This is especially important to those of us who use and develop
cross platform code libraries with C/C++ interfaces.  If the FFI is left
up to each implementer, interfacing Dylan with such libraries will be a
non-trivial task, since the FFI will be different on each platform, and
will most likely be significantly different (as seems to be true for
Lisp).

If Dylan is seriously intended to be a crossplatform language in anything
more than just an academic sense, it needs a standard FFI.  In fact, if
Dylan does not have a standard FFI, it should probably NOT be touted as
crossplatform, at least not for real-world software development.

--tomd



Sun, 01 Dec 1996 17:41:03 GMT  
 Interim Manual: a few notes

Quote:
> 5 - foreign function interface

> I believe that one of the major obstacles toward the acceptance of
> Dylan is the "reusability" issue. As an example, nobody would want to
> give up Motif just because it is written in C.
> I believe that the definition of a standard FFI for Dylan would be an
> act of foresight that could save the day later on.

Hear! hear!


Sun, 01 Dec 1996 22:19:19 GMT  
 Interim Manual: a few notes
Excerpts from 15-Jun-94 Interim Manual: a few notes by Marco

Quote:
> 1 - #optional (i.e. &optional) parameters are missing.

 Use keywords. I find them more pleasant, even if they are more verbose.

Quote:
>3 - file formats       [beginning of file information]

>SARCASTIC MODE ON
>I did not know that there were people from the COBOL community
>designing Dylan.

 I doubt the Dylan designers care. It's three lines at the top of the
file, and not even that if you're using a decent environment. (Yeah,
we've heard that before... All together now: "The environment will take
care of it!") The intention is that it'll only be used if you don't have
a nifty environment.

Quote:
>5 - foreign function interface

 This is a Hard Problem(tm), but I think the Dylan people really want it
and are willing to work for it. Dylan isn't going anywhere if people
have to reinvent the wheel to use it.

-Nick Kramer



Sun, 01 Dec 1996 23:44:48 GMT  
 Interim Manual: a few notes

Quote:

>1 - #optional (i.e. &optional) parameters are missing.

>Why are they not there? It would not seem to be that big a problem to
>introduce them.

&OPTIONAL parameters are evil.  They cause no end of headaches and
should be left out of the language:

1. If there is more than one optional parameter, you lose if you want
to specify only, say, the second parameter.  Use keyword parameters
instead.

2. Optional and keyword parameters interact badly.  C.f. questions 3-0
and 3-1 in the Lisp FAQ on READ-FROM-STRING.

3. It is easy to extend an interface by adding new keyword parameters.
Optional parameters get in the way of doing this.

4. Keyword arguments are self-documenting.  Optional arguments are
not.  It is easy to get their ordering screwed up.

5. Parsing lambda lists is enough of a pain already without having to
deal with yet another special case for optional parameters.

--David Gadbois



Mon, 02 Dec 1996 05:20:40 GMT  
 Interim Manual: a few notes

         Path: news.cambridge.apple.com!news.media.mit.edu!bloom-beacon.mit.edu!paperboy.osf.org!think.com!hsdndev!wupost!cs.utexas.edu!not-for-mail

         Newsgroups: comp.lang.dylan
         Date: 15 Jun 1994 16:20:40 -0500
         Organization: CS Dept, University of Texas at Austin
         Lines: 27

         Nntp-Posting-Host: peaches.cs.utexas.edu


         >
         >1 - #optional (i.e. &optional) parameters are missing.
         >
         >Why are they not there? It would not seem to be that big a problem to
         >introduce them.

         &OPTIONAL parameters are evil.  They cause no end of headaches and
         should be left out of the language:

I _really_ wish we could keep this kind of judgement ("evil") out
of the discussions in this mail-group. Our discussions get religious
enough in tone as it is without over-extending the meaning of English
words in this way. Unless David Gadbois really means to suggest that, for
instance, a devout Catholic programmer should include "I used
optional arguments" in confession?

I don't think I'm being excessively PC in this request. I had to
stop myself from responding to his mail with a sarcastic
"Well, thy will be done O Lord." I had to remind myself that he
probably didn't mean that programmers who like optional arguments
(such as myself) are evil. Maybe he doesn't even think we're
dumb (just misguided?)

At any rate, snappy judgement calls tend to evoke heated responses,
of which we surely have more than we need, in this group anyway.

Cheers

Caro



Mon, 02 Dec 1996 07:04:20 GMT  
 Interim Manual: a few notes

Quote:


> > CL suffers a lot from this "non integration" with the C
> > mainstream. The situation is made worse by the lack of a standardized
> > foreign function interface.

>  I agree.  This is especially important to those of us who use and develop
>  cross platform code libraries with C/C++ interfaces.  If the FFI is left
>  up to each implementer, interfacing Dylan with such libraries will be a
>  non-trivial task, since the FFI will be different on each platform, and
>  will most likely be significantly different (as seems to be true for
>  Lisp).

My concern is that integration with C/C++ works in both directions. It is
just as important (for me at least) to be able to hand a C/C++ programmer a
chunk of code which he/she can call use as it is for me to call C/C++ code.

Will I be able to tell my C/C++ co-workers that my writing a component in
Dylan won't cause them any extra grief? Will it be possible to package up
software written in Dylan and sell it to C/C++ programers? I've long done
lisp development in shops which were largely C based, and have found this
to be a major impediment. Specifically, it should be possible to deliver
Dylan objects which can be linked into C/C++ executables. Without this
capability, Dylan will be a hard sell in the environments I've worked in.

I don't recall any discussion of this issue in this newsgroup. Does anyone
know if it Dylan implementations will be able to provide this functionality
at a reasonable implementation cost, or if it is a goal of the Dylan
language?

--Jon



Mon, 02 Dec 1996 07:30:15 GMT  
 Interim Manual: a few notes

Quote:


>     Date: 15 Jun 1994 16:20:40 -0500

>        &OPTIONAL parameters are evil.  They cause no end of
>        headaches and should be left out of the language:

>I _really_ wish we could keep this kind of judgement ("evil") out
>of the discussions in this mail-group.

I hope I am not being trolled here.  I used the word "evil" in the
hackish sense, and I would expect readers of this group to be able to
distinguish the usage from the m{*filter*}sense of the word.

From the hackers dictionary:

evil: adj. As used by hackers, implies that some system, program,
   person, or institution is sufficiently maldesigned as to be not
   worth the bother of dealing with.  Unlike the adjectives in the
   {cretinous}/{losing}/{brain-damaged} series, `evil' does not imply
   incompetence or bad design, but rather a set of goals or design
   criteria fatally incompatible with the speaker's.  This is more an
   esthetic and engineering judgment than a m{*filter*}one in the
   mainstream sense.  "We thought about adding a {Blue Glue} interface
   but decided it was too evil to deal with."  "{TECO} is neat, but it
   can be pretty evil if you're prone to typos."  Often pronounced
   with the first syllable lengthened, as /eeee'vil/.

Re-reading the definition, I take back my characterization of
&OPTIONAL arguments as evil.  There are actually losing.

--David Gadbois

Jargon insights available from:
gopher://ucs2.byu.edu/7waissrc%3a/Computing%20Information/WAIS%20Indexes/J/jargon



Mon, 02 Dec 1996 08:25:30 GMT  
 Interim Manual: a few notes
Excerpts from 15-Jun-94 Re: Interim Manual: a few n.. by Jon

Quote:
> Will I be able to tell my C/C++ co-workers that my writing a component in
> Dylan won't cause them any extra grief?
> Does anyone
> know if it Dylan implementations will be able to provide this functionality
> at a reasonable implementation cost, or if it is a goal of the Dylan
> language?

 The answer is yes. It's been acknowledged many times that the Dylan
foreign function interface has to be able to go both ways (so to speak).

-Nick Kramer



Mon, 02 Dec 1996 12:17:51 GMT  
 Interim Manual: a few notes
         Path: news.cambridge.apple.com!news.media.mit.edu!grapevine.lcs.mit.edu!uhog.mit.edu!europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!not-for-mail

         Newsgroups: comp.lang.dylan
         Date: 15 Jun 1994 19:25:30 -0500
         Organization: CS Dept, University of Texas at Austin
         Lines: 36

         Nntp-Posting-Host: peaches.cs.utexas.edu


         >

         >    Date: 15 Jun 1994 16:20:40 -0500
         >
         >        &OPTIONAL parameters are evil.  They cause no end of
         >        headaches and should be left out of the language:
         >
         >I _really_ wish we could keep this kind of judgement ("evil") out
         >of the discussions in this mail-group.

         I hope I am not being trolled here.  I used the word "evil" in the
         hackish sense, and I would expect readers of this group to be able to
         distinguish the usage from the m{*filter*}sense of the word.

Is that a reasonable assumption? Is knowing hacker jargon a
prerequisite to being a good programmer? Even if there's a one-to-one
mapping between "hackers" and "programmers" there are plenty of
non-Americans in this group. I know some very fine programmers in
Germany whose English is more than good enough to follow and
contribute to this mail-group but would not have made this
distinction. So I could propose that you were asking to be hassled.

I guess I'm fatigued at the hackish proclivity to hijack the English
language. Yes I was aware that you did not "really" mean evil in the
m{*filter*}sense of the word. I thought I made that clear with a possibly
lame but well-meant joke. (Sorry I forgot to highlight it with a
smiley-face.) I have read the hacker's dictionary. And
my problem with "evil" in this discussion comes right out of the
hackers definition:

                        .  Unlike the adjectives in the
                        {cretinous}/{losing}/{brain-damaged} series, `evil' does not imply
                        incompetence or bad design, but rather a set of goals or design
                        criteria fatally incompatible with the speaker's.

It's the whole attitude embodied in the use of the word in that way,
the general dismissing of something because someone else's criteria
don't match the speaker's. So often the person I've heard using "evil"
in this way, the hackish way, hasn't understood what the
designer-of-evil's priorities _are_.  That's something going on a lot
in this mail group and I wish it weren't, cause I really doubt that
it helps current and would-be Dylan implementors work out _their_
priorities. For instance, I imagine that a number of the people
using &optional in Lisp are doing so for reasons of speed. Well,
speed is in theory an issue for Dylan implementors. Will they make
keyword args so fast that no one will need to use optionals ever
again? Is that a good use of their devo energies, if speed-needs
can be met by optionals? Etc etc. I honestly think it will be easier
for the implementors to give _more_ of us more of what we want, whatever
that is, if we keep in mind that probably everyone on this list
has different set of priorities and a different reason for wanting
Dylan, and that the more judgement-hurling that goes on, the harder
it will be to sort them out.

Caro



Mon, 02 Dec 1996 12:21:14 GMT  
 Interim Manual: a few notes
: 3 - file formats

: It would seem that this part of a file should resemble the 'resource
: fork' of a MAC file.
: I am sure that it could have been defined in a better way.

I guess the source file format was intended to be a portable
interchange format for exchanging Dylan source programs among
different implementations/environments/platforms.  Of course
there are people who hate the "it will be handled by the
environment" argument, but I think modern programming languages
all need some kind of decent environment to be used well.
We need an Emacs mode, at least. :)

----------

"Ay, fashion you may call it.  Go to, go to." -- Hamlet



Mon, 02 Dec 1996 13:39:51 GMT  
 Interim Manual: a few notes


   >
   >1 - #optional (i.e. &optional) parameters are missing.
   >
   >Why are they not there? It would not seem to be that big a problem to
   >introduce them.

   &OPTIONAL parameters are evil.  They cause no end of headaches and
   should be left out of the language:

   1. If there is more than one optional parameter, you lose if you want
   to specify only, say, the second parameter.  Use keyword parameters
   instead.

When implemented naively, keyword arguments are painfully slow.  If
implemented efficiently (by translating keywords into fixed-position
arguments), the compiler needs to know the lambda list of functions in
the execution environment of a module at compilation time.  This
introduces extraneous compilation dependencies.  For instance, if you
change the keywords accepted by a function, potentially all of its
callers need to be recompiled.

Optional arguments are not exactly God's gift to humanity, but they
suffer from fewer efficiency problems.  Of course, they must be used
with care to avoid problems similar to those of keyword arguments.
However, the necessary discipline is easier to achieve with optional
arguments than with keyword arguments, since any changes are more
obvious to the programmer.

If both optional arguments and keyword arguments are supported, the
language definition can warn that keywords might be much slower, and
naive keyword implementations will then be sufficient.  It is good to
have a language which, even when implemented naively, is still
reasonably efficient.  It puts less burden on the programmer to
translate between written code and executed code, and means more
uniform performance across implementations.  This is one of the
reasons people like C.

-- Harley Davis
--

------------------------------------------------------------------------------
motto: Use an integrated object-oriented dynamic language today.

------------------------------------------------------------------------------
nom: Harley Davis                       ILOG S.A.

tel: +33 1 46 63 66 66                  94253 Gentilly Cedex, France



Mon, 02 Dec 1996 17:34:20 GMT  
 Interim Manual: a few notes
I have been working my way through the interim manual via WWW. So far I
like what I see except for the naming conventions; I HATE them but then
again, they are not mandatory, so who cares.

Is there a postscript version of the manual available for ftp?
---
+-------------------------------+---------------------------------------+

|  The World Bank               | Fax   : (202)522-3377                 |
|  Washington, D.C. 20433       | phone : (202)473-0199                 |
+-------------------------------+---------------------------------------+



Mon, 02 Dec 1996 20:19:12 GMT  
 
 [ 40 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Interim release of manuals? comments please

2. Dylan Interim Reference Manual now available

3. Dylan Interim Manual available via WWW

4. Dylan Interim Reference Manual now available

5. Few random notes

6. A few notes

7. Gwydion URL to explain project, Hyperlinked Dylan Manual + Design Notes

8. Gwydion URL to explain project, Hyperlinked Dylan Manual + Design Notes

9. Fortran Notes/Manual Online

10. Summiteers: Few new Ada sales if few new Ada hires

11. APL+Win Interim Release 2.02

12. Product Scope 32 Bookmarks - Version 3_8c Interim Release

 

 
Powered by phpBB® Forum Software