Apple's Dylan environment and Lisp-like syntax 
Author Message
 Apple's Dylan environment and Lisp-like syntax

Will Apple's announced Dylan environment support Dylan Classic -- Lisp-like
-- syntax?

Kaveh

--
Kaveh Kardan



Fri, 22 Nov 1996 21:40:02 GMT  
 Apple's Dylan environment and Lisp-like syntax

Quote:

> Will Apple's announced Dylan environment support Dylan Classic -- Lisp-like
> -- syntax?

Short answer [looking at the book]:
No.

Medium answer [paraphrasing implementor {Straz?, St. Clair?, Shalit?}]:
Fairly early in the design process, it became clear that supporting two
syntaxes was a bad idea because of the cost;  the c-like syntax won out
because that's the mainstream that Dylan *needs* to fulfill its goals.

Long answer [talking out of my ass]:
Two syntaxes doesn't double the work-load; it quadruples it, or worse.
Nobody wants to wait that long for just a syntax issue.  Let's face it:
infix versus prefix is more a holy war than a real design issue.  If Dylan
does everything you want, but you have to get used to (x + y) instead of (+
x y); you're going to use Dylan.

Lisp hackers are generally, um, more flexible than c hackers [:-) :-) :-)]
;  they'll probably be willing to try Dylan and use infix so long as it
doesn't hamper them too much.  The majority find prefix notation too hard
to get used to after decades of mathematical brain-washing, er, training in
infix.

It is not unimaginable that after Dylan takes off, an extension of the
language to allow a lisp-like syntax could be added, if demand were high
enough.  Meanwhile, the benefits of Dylan are worth reading infix for those
who prefer prefix.

--
--
--



Sat, 23 Nov 1996 03:37:56 GMT  
 Apple's Dylan environment and Lisp-like syntax

Quote:

> Fairly early in the design process, it became clear that supporting two
> syntaxes was a bad idea because of the cost;  the c-like syntax won out
> because that's the mainstream that Dylan *needs* to fulfill its goals.

Early?  It was a relatively recent decision.

Quote:
> Long answer [talking out of my ass]:
> Two syntaxes doesn't double the work-load; it quadruples it, or worse.

It doesn't even double it.

Quote:
> Nobody wants to wait that long for just a syntax issue.  Let's face it:
> infix versus prefix is more a holy war than a real design issue.  If Dylan
> does everything you want, but you have to get used to (x + y) instead of (+
> x y); you're going to use Dylan.

That argument cuts both ways.


Sat, 23 Nov 1996 06:06:25 GMT  
 Apple's Dylan environment and Lisp-like syntax

Quote:



>> Will Apple's announced Dylan environment support Dylan Classic -- Lisp-like
>> -- syntax?

>Short answer [looking at the book]:
>No.

I was referring to Apple's announced product; I am aware that the standard
syntax is Algol-like.  A while back, when the syntax issue was hot, someone
from Apple posted that nothing prevented implementations from supporting
alternate syntaxes.

Is this something Apple has decided to do?

Kaveh

--
Kaveh Kardan



Sat, 23 Nov 1996 09:37:17 GMT  
 Apple's Dylan environment and Lisp-like syntax


   > Fairly early in the design process, it became clear that supporting two
   > syntaxes was a bad idea because of the cost;  the c-like syntax won out
   > because that's the mainstream that Dylan *needs* to fulfill its goals.

   Early?  It was a relatively recent decision.

   > Long answer [talking out of my ass]:
   > Two syntaxes doesn't double the work-load; it quadruples it, or worse.

   It doesn't even double it.

   > Nobody wants to wait that long for just a syntax issue.  Let's face it:
   > infix versus prefix is more a holy war than a real design issue.  If Dylan
   > does everything you want, but you have to get used to (x + y) instead of (+
   > x y); you're going to use Dylan.

   That argument cuts both ways.

The difference between writing  (+ x y)  and  x + y  is small.  The
difference between making a program that computes with (+ x y) and one that
computes with "x + y" is quite a bit larger.
--
John McCarthy, Computer Science Department, Stanford, CA 94305
*
He who refuses to do arithmetic is doomed to talk nonsense.



Sat, 23 Nov 1996 12:56:31 GMT  
 Apple's Dylan environment and Lisp-like syntax

   Date: 07 Jun 1994 04:56:31 GMT


      > Nobody wants to wait that long for just a syntax issue.  Let's face it:
      > infix versus prefix is more a holy war than a real design issue.  If Dylan
      > does everything you want, but you have to get used to (x + y) instead of (+
      > x y); you're going to use Dylan.

      That argument cuts both ways.

   The difference between writing  (+ x y)  and  x + y  is small.  The
   difference between making a program that computes with (+ x y) and one that
   computes with "x + y" is quite a bit larger.

This statement still seems to presuppose that the representation for
an infix expression is a string.  Nonetheless, even if some sort of
parse-tree representation for Dylan code is exposed as part of some
(possibly standard) extension to Dylan, it is almost certainly the
case that it will not be as simple as what we have in Lisp.

I strongly suspect that there are going to be plenty of jobs for which
Lisp and/or Scheme is still the right tool.  I also suspect that there
are tasks where Dylan will not displace Cobol or C.  The fact that
Dylan is not the right tool for _every_ job does not of necessity
diminish Dylan to the point of being useless for _any_ job.



Sat, 23 Nov 1996 13:13:16 GMT  
 Apple's Dylan environment and Lisp-like syntax


    The difference between writing  (+ x y)  and  x + y  is small.  The
    difference between making a program that computes with (+ x y) and one that
    computes with "x + y" is quite a bit larger.

It will be quite straightforward to read Dylan's infix notation into a
list-structured internal form pretty much equivalent to Lisp's, and to
print this back out as infix Dylan.  The internal notation may lack a bit
of the surface-level sugar of Lisp -- for example, "a + b + c" may turn
into "(+ a (+ b c))" rather than "(+ a b c)", but that probably makes it
better for program-manipulating programs.

Dylan's macro system (a program-manipulating program) will certainly be
working on the internal parse-tree rathr than the ASCII level, though for
user convenience you will usually refer to parts of that parse tree using
surface-pattern forms.

The only difference I can see between Dylan and Lisp in this respect is
that Lisp's syntax pretty much forces an obvious internal form on the
implementor; Dylan's syntax allows for some variation from one
implementation to another.  We could standardize the internal form, but
nobody is working on that right now.  Some early implementations are
sitting on top of CL, and will probably use a list-structured form
internally, while others (through bootstrapping magic) sit in of Dylan
itself and will probably choose to use Dylan objects for the parse tree.
But it would be very easy to convert from one of these formats to another,
so nothing would stop you from doing program hackery in your favorite
list-structured form and then quickly and easily converting this to the
internal format used by your implementation du jour.  So I don't really see
this as an issue.

What is an issue is that when you develop a Dylan application and compile
it for delivery, it won't have EVAL and all the supporting environment
around.  This is a key decision allowing us to get good runtime performance
for the vast majority of application programs that do not indulge in
runtime code-manipulation.  However, every Dylan implementation I know
about will have an interpreter (or the equivalent fast-incremental-compile-
and-execute machinery) in the development environmnet, and will allow you
to run programs there.  So your code-modifying programs will have to run in
the development environment or a significant subset of it.  But that's what
Lisp does now; it's simply not as agressive a Dylan in offering a
stripped-down delivery option for those who want that.

-- Scott

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

Senior Research Scientist               Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University              Latitude:  40:26:46 N
5000 Forbes Avenue                      Longitude: 79:56:55 W
Pittsburgh, PA 15213
===========================================================================



Sat, 23 Nov 1996 21:38:30 GMT  
 Apple's Dylan environment and Lisp-like syntax

   ...

   The difference between writing  (+ x y)  and  x + y  is small.  The
   difference between making a program that computes with (+ x y) and one that
   computes with "x + y" is quite a bit larger.
   --
   John McCarthy, Computer Science Department, Stanford, CA 94305
   *
   He who refuses to do arithmetic is doomed to talk nonsense.

I understand the issue that McCarthy is pointing out, but I also sympathize
with those who prefer the algol-like syntax.  A point that McCarthy
brushes over is the fact that even (+ x y) is a _string_.  It must
be translated into the list it represents.  The translation from string
to list is quite simple, thus, we come to think of the string as _being_
the list, which it is not.  The translation from (x + y) into some
unknown internal representation is, of course, not well defined.

Having a well defined class hierarchy to represent Dylan code would be
a boon to developers.  It would provide the same capabilities that McCarthy
is advocating, yet there could still be an infix syntax.  The translation,
on the other hand, would be a little more difficult than string to list
translation.

Of course, the standard internal representation could be in terms of lists.
Then the internal representation would be the one that lisp hackers really
wanted in the first place.

Joe Wilson

http://www.cis.ufl.edu/~jnw/



Sat, 23 Nov 1996 21:18:43 GMT  
 Apple's Dylan environment and Lisp-like syntax

   The only difference I can see between Dylan and Lisp in this respect is
   that Lisp's syntax pretty much forces an obvious internal form on the
   implementor;

How is this the case? A Scheme compiler I have written uses an object-oriented
internal representation.

   Dylan's macro system (a program-manipulating program) will certainly be
   working on the internal parse-tree rathr than the ASCII level, though for
   user convenience you will usually refer to parts of that parse tree using
   surface-pattern forms.

   Dylan's syntax allows for some variation from one
   implementation to another.  We could standardize the internal form, but
   nobody is working on that right now.

If macros work on the internal representation, doesn't having a standardized
macro system require you to standardize that representation (at least at some
level, if you want to have a sufficiently powerfull macro system)?

Question: The Lisp reader plays the role played by the lexer and parser in
languages with an Algol-like syntax. Lisp macros are essentially
source-to-source transformations (done at the level of parse trees). A
property of Lisp is that since the reader syntax is so uniform (some would say
uniformly bad), macros can be added without modifying the reader (i.e. lexer
and parser). (Yes I know that reader macros can be added and these are like
modifying the lexer and parser but macros and reader macros serve a mostly
orthogonal purpose.) The Dylan syntax on the other hand doesn't see
sufficiently uniform to allow macros to be added purely as
parse-tree-to-parse-tree transformations. I assume that Dylan macros will
thuse have to augment the lexer and the parser in addition to doing parse-tree
manipulations. Is this the case?

    Jeff (home page ftp://ftp.cs.toronto.edu/pub/qobi/qobi.html)
--

    Jeff (home page ftp://ftp.cs.toronto.edu/pub/qobi/qobi.html)



Sun, 24 Nov 1996 03:39:13 GMT  
 Apple's Dylan environment and Lisp-like syntax

       The only difference I can see between Dylan and Lisp in this respect is
       that Lisp's syntax pretty much forces an obvious internal form on the
       implementor;

    How is this the case? A Scheme compiler I have written uses an object-oriented
    internal representation.

Quibble, quibble.  Yeah, the Lisp reader can produce a player piano roll if
you really want it to.  Most implementors go with the "obvious" internal
list representation, and Lisp macros assume that format.  I guess Scheme
still doesn't have standard macros, so you've got more freedom.

    If macros work on the internal representation, doesn't having a standardized
    macro system require you to standardize that representation (at least at some
    level, if you want to have a sufficiently powerfull macro system)?

It's possible to refer to chunks of source code in the parse tree by
binding surface-level patterns to these chunks.  For example, the user
might use a pattern like "foo(?x ?y)" to bind X and Y to the first and
second argument-oids of FOO, without having to know the format of the parse
tree.  X and Y could then be used in producing the macro expansion.
Whether this will prove to be "sufficiently powerful" remains to be seen.

-- Scott

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

Senior Research Scientist               Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University              Latitude:  40:26:46 N
5000 Forbes Avenue                      Longitude: 79:56:55 W
Pittsburgh, PA 15213
===========================================================================



Sun, 24 Nov 1996 11:07:05 GMT  
 Apple's Dylan environment and Lisp-like syntax


Quote:
> Medium answer [paraphrasing implementor {Straz?, St. Clair?, Shalit?}]:
> Fairly early in the design process, it became clear that supporting two
> syntaxes was a bad idea because of the cost;  the c-like syntax won out
> because that's the mainstream that Dylan *needs* to fulfill its goals.

C-like? I thought it was Algol-like. That's be a big negative factor in
Dylan's image, for C/C++ programmers.

My own bias is a historical one, rather than "religious" one. Most of
the machines I've used have had C compilers, but not all had Pascal.
One platform was only supplied with C and an assembler as programming
tools. I had to write my own Forth and Lisp interpreters just to avoid
C and asm. Another platform for the same machine (P-system) had Pascal,
Basic, and fortran supplied with it.

The main (logical) reason for avoiding Pascal these days is the lack
of ISO standard compilers for certain platforms. I have some portable
Pascal source code, so that's one reason for me to use Pascal.

After using C++ for a few years, I hope I can still maintain a balanced
view of Dylan's syntax. It's possible, esp if the enviroment is worth
the effort. However, I'm far from typical of the C++ programmers I know,
as none of them would prefer Lisp to C++.

--
Martin Rodgers, WKBBG, London UK   AKA "{*filter*} Surfer"

Assuming that Clipper will need to be global to be effective, write

This is a shareware .signature  -- please pass it on!



Sat, 23 Nov 1996 18:30:50 GMT  
 Apple's Dylan environment and Lisp-like syntax

   What is an issue is that when you develop a Dylan application and compile
   it for delivery, it won't have EVAL and all the supporting environment
   around.  This is a key decision allowing us to get good runtime performance
   for the vast majority of application programs that do not indulge in
   runtime code-manipulation.  However, every Dylan implementation I know
   about will have an interpreter (or the equivalent fast-incremental-compile-
   and-execute machinery) in the development environmnet, and will allow you
   to run programs there.  So your code-modifying programs will have to run in
   the development environment or a significant subset of it.  But that's what
   Lisp does now; it's simply not as agressive a Dylan in offering a
   stripped-down delivery option for those who want that.

This is a good point.  However, you should know that some modern Lisps
are just as aggressive as what you describe for Dylan.  For example,
ours is.

-- Harley Davis
--

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

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



Sun, 24 Nov 1996 17:13:24 GMT  
 Apple's Dylan environment and Lisp-like syntax

Quote:
> It's possible to refer to chunks of source code in the parse tree by
> binding surface-level patterns to these chunks.  For example, the user
> might use a pattern like "foo(?x ?y)" to bind X and Y to the first and
> second argument-oids of FOO, without having to know the format of the parse
> tree.  X and Y could then be used in producing the macro expansion.
> Whether this will prove to be "sufficiently powerful" remains to be seen.

Suppose I want to define some new syntax -- which is what I want
macros for.  For instance, supose I want something like this:

  { f(x,y) | x in this, y in that }

to be the result of f mapped over the cartesian product of
this and that.  (This is what some functional languages call
"list comprehensions".)

How will the Dylan parser deal with this?  To what extent can I
define new syntax?  Or will I be struct with name(args) as with
C macros?

-- jeff



Mon, 25 Nov 1996 02:52:31 GMT  
 Apple's Dylan environment and Lisp-like syntax


:    The only difference I can see between Dylan and Lisp in this respect is
:    that Lisp's syntax pretty much forces an obvious internal form on the
:    implementor;

: How is this the case? A Scheme compiler I have written uses an object-oriented
: internal representation.

Agreed.  A programming language I've been working on (COWS for NeXTSTEP) uses
the same parenthetical syntax as Lisp but is entirely _string_ based.  It has
no lists at all.  Lisp-like syntax is very flexible.

+--------------------------------------------------------------+
| Sean Luke                             This signature no verb |


+------------------------oOO--(_)--OOo-------------------------+



Mon, 25 Nov 1996 04:49:29 GMT  
 Apple's Dylan environment and Lisp-like syntax
          The only difference I can see between Dylan and Lisp in this respect
          is
          that Lisp's syntax pretty much forces an obvious internal form on the
          implementor;

       How is this the case? A Scheme compiler I have written uses an
       object-oriented
       internal representation.

   Quibble, quibble.  Yeah, the Lisp reader can produce a player piano roll if
   you really want it to.  Most implementors go with the "obvious" internal
   list representation, and Lisp macros assume that format.  I guess Scheme
   still doesn't have standard macros, so you've got more freedom.

I wasn't refering to changing the reader. My Scheme compiler uses an unmodifed
Scheme reader. And macros operate on the list representation produced by
the reader. But after macro expansion, my compiler has a simple pass
(200 lines of code) to convert to an object-oriented representation used by
all subsequent phases of the compiler. This has numerous obvious advantages
like having variables references point to their environments, having
environments point to the expressions that create them, annotating expressions
with types, annotating those functions which are potentially recursive, those
lexical closures that are potentially upward, those expressions that can
potentially cause side effects (and to which variables), which functions can
potentially be called by which functions, what the expected lifetime of
storage allocted by each expression is, which expressions are known not to
allocate storage, ...

The point is that any good compiler for any language would likely adopt such a
strategy. This is not particular to Dylan.

    Jeff (home page ftp://ftp.cs.toronto.edu/pub/qobi/qobi.html)
--

    Jeff (home page ftp://ftp.cs.toronto.edu/pub/qobi/qobi.html)



Mon, 25 Nov 1996 05:17:48 GMT  
 
 [ 68 post ]  Go to page: [1] [2] [3] [4] [5]

 Relevant Pages 

1. Apple Dylan Environment Speed

2. Apple Dylan syntax

3. Apple's Dylan's FAQ postable?

4. apple's dylan technology release CD

5. Posting Apple's Dylan Ref Manual?

6. Apple's development environment

7. Apple Dylan and it's interface builder

8. Can't Edit Source folder names in Apple Dylan DR1

9. Has anyone tested Apple Dylan TR1 with Connectix Corp.'s 68k

10. HELP: Apple Dylan from MCL 3.9 won't run

11. Dylan's suit with apple

12. Apple's Development Environment...

 

 
Powered by phpBB® Forum Software