But what about macros?!? 
Author Message
 But what about macros?!?

For the past couple of days I've been playing with Mindy, and as I
mentioned in a previous post I've become quite enamoured of Dylan.
After reviewing the DIRM and the design notes, however, I have run
across what I consider to be a significant omission from the language:
there's nary a word in any of these documents about macros!

Now, I know that recent proclamations from preeminent members of the
C++ community are bemoaning the existance of the C/C++ preprocessor,
but even a feeble, text-substitution-based preprocessor has its
uses...  My C++ code makes heavy use of a package of assert()-like
macros to do Eiffel-like interface verification during program
development.  This extra overhead is all quietly preprocessed away
when the code is ready for production use.  Is any consideration being
given by the design group to this (and similar) issue(s)?

Ideally something like the hygenic macro system of Scheme would be
included in the language (I've longed for this in C++ as well).  The
use of infix notation, however, would appear somewhat problematic in
this regard.

Please, no flames about the evil of macros.  I know they're evil-- I
want them anyway!
--
// Kaelin Colclasure ---------------------------------------------------------

// Voice: (314)567-8463                      717 Office Parkway
//   Fax: (314)432-5391                      St. Louis, MO 63141



Tue, 01 Apr 1997 07:14:07 GMT  
 But what about macros?!?

   Please, no flames about the evil of macros.  I know they're evil-- I
   want them anyway!

I'm not sure why the C/C++ people think macros are evil.  I guess if
you do anything badly enough, it will seem like a bad idea.  Anyway,
former Lispers know the value of macros, and a good many of the Dylan
designers share this heritage.

A macro design is currently being worked on, and should be made public
in the not-too-distant future.  It still isn't as powerful and
flexible as Lisp macros, but I think we'll get there eventually,
despite the difficulty of doing macros in infix.  And the design will
be hygienic.

-- Scott

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

Principal Research Scientist            Phone:     412 268-2575
School of Computer Science              Fax:       412 268-5576 (new!)
Carnegie Mellon University              Latitude:  40:26:46 N
5000 Forbes Avenue                      Longitude: 79:56:55 W
Pittsburgh, PA 15213                    Mood:      :-)
===========================================================================



Tue, 01 Apr 1997 12:43:41 GMT  
 But what about macros?!?


      Please, no flames about the evil of macros.  I know they're evil-- I
      want them anyway!

   I'm not sure why the C/C++ people think macros are evil.  
                    ^^^^^^^^^^^^^^^^
Hey now, lets not start calling people names here... ;-)

   I guess if
   you do anything badly enough, it will seem like a bad idea.  Anyway,
   former Lispers know the value of macros, and a good many of the Dylan
   designers share this heritage.

I have witnessed discussions in comp.lang.lisp and comp.lang.scheme
which argued against using macros.  My personal opinion is that the
persons making these arguments simply never took the time to
understand the macro system, but--  I think it's safe to say that at
least a few otherwise enlightened individuals still think macros are
evil.

Any time you give individual programmers the ability to tweak syntax
to their tastes, somebody somewhere is likely to pucker up in disgust.
I'm sure you recall the heated arguments for using { } instead of
keyword ... end keyword; in Dylan.  Given a reasonably capable macro
system, would you care to bet on how long it will take for someone to
implement this?  This is the mirror image of the pathological C macro
set (ie. #define BEGIN {, etc.) which has helped to cast cpp in such
bad light.

   A macro design is currently being worked on, and should be made public
   in the not-too-distant future.  It still isn't as powerful and
   flexible as Lisp macros, but I think we'll get there eventually,
   despite the difficulty of doing macros in infix.  And the design will
   be hygienic.

I'm delighted to hear this.  Can you provide any vague hints as to
what it will look like?  Will macros be written in Dylan, or in an
R4RS-esque pattern language?  Will there be explicit support for
conditional compilation?

By the way, my personal thanks to you and all of the members of the
Gwydion team...  Keep up the good work!

   -- Scott

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

   Principal Research Scientist         Phone:     412 268-2575
   School of Computer Science              Fax:       412 268-5576 (new!)
   Carnegie Mellon University           Latitude:  40:26:46 N
   5000 Forbes Avenue                   Longitude: 79:56:55 W
   Pittsburgh, PA 15213                 Mood:      :-)
   ===========================================================================

--
// Kaelin Colclasure ---------------------------------------------------------

// Voice: (314)567-8463                      717 Office Parkway
//   Fax: (314)432-5391                      St. Louis, MO 63141



Wed, 02 Apr 1997 01:36:00 GMT  
 But what about macros?!?


      Please, no flames about the evil of macros.  I know they're evil-- I
      want them anyway!

   I'm not sure why the C/C++ people think macros are evil.  
                    ^^^^^^^^^^^^^^^^
Hey now, lets not start calling people names here... ;-)

   I guess if
   you do anything badly enough, it will seem like a bad idea.  Anyway,
   former Lispers know the value of macros, and a good many of the Dylan
   designers share this heritage.

I have witnessed discussions in comp.lang.lisp and comp.lang.scheme
which argued against using macros.  My personal opinion is that the
persons making these arguments simply never took the time to
understand the macro system, but--  I think it's safe to say that at
least a few otherwise enlightened individuals still think macros are
evil.

Any time you give individual programmers the ability to tweak syntax
to their tastes, somebody somewhere is likely to pucker up in disgust.
I'm sure you recall the heated arguments for using { } instead of
keyword ... end keyword; in Dylan.  Given a reasonably capable macro
system, would you care to bet on how long it will take for someone to
implement this?  This is the mirror image of the pathological C macro
set (ie. #define BEGIN {, etc.) which has helped to cast cpp in such
bad light.

   A macro design is currently being worked on, and should be made public
   in the not-too-distant future.  It still isn't as powerful and
   flexible as Lisp macros, but I think we'll get there eventually,
   despite the difficulty of doing macros in infix.  And the design will
   be hygienic.

I'm delighted to hear this.  Can you provide any vague hints as to
what it will look like?  Will macros be written in Dylan, or in an
R4RS-esque pattern language?  Will there be explicit support for
conditional compilation?

By the way, my personal thanks to you and all of the members of the
Gwydion team...  Keep up the good work!

   -- Scott

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

   Principal Research Scientist         Phone:     412 268-2575
   School of Computer Science              Fax:       412 268-5576 (new!)
   Carnegie Mellon University           Latitude:  40:26:46 N
   5000 Forbes Avenue                   Longitude: 79:56:55 W
   Pittsburgh, PA 15213                 Mood:      :-)
   ===========================================================================

--
// Kaelin Colclasure ---------------------------------------------------------

// Voice: (314)567-8463                      717 Office Parkway
//   Fax: (314)432-5391                      St. Louis, MO 63141



Tue, 01 Apr 1997 22:36:17 GMT  
 But what about macros?!?

   Any time you give individual programmers the ability to tweak syntax
   to their tastes, somebody somewhere is likely to pucker up in disgust.

Of course macros can be abused.  The Lisp philosophy, which I hope
will carry forward into Dylan, is that the programming environment
should empower the programmer.  The idea is to make it easy to do the
right thing, not to make it hard or impossible to do the wrong thing.
If you want to be hog-tied and gagged by your programming languge, use
Ada instead, or ML if just being strongly handcuffed will suffice.

(We've had some complaints that this newsgroup is too quiet, now that
the butthead folksinger controversy has simmered down.  Not that I
would ever say anythign deliberately provocative...)

      A macro design is currently being worked on...

   I'm delighted to hear this.  Can you provide any vague hints as to
   what it will look like?  Will macros be written in Dylan, or in an
   R4RS-esque pattern language?  Will there be explicit support for
   conditional compilation?

The first version you see will be a pattern-substitution macro system.
This is fairly powerful, and handles about 90% of what you might want
to do, but stops short of allowing the user to write arbitrary Dylan
procedures to massage the code at compile-time.  Full procedural
macros will come along eventually, but (obviously) only for those
systems that are written in Dylan or have some other way of
interpeting Dylan programs at compile-time.

   By the way, my personal thanks to you and all of the members of the
   Gwydion team...  Keep up the good work!

Thanks.  The best is yet to come.

-- Scott

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

Principal Research Scientist            Phone:     412 268-2575
School of Computer Science              Fax:       412 268-5576 (new!)
Carnegie Mellon University              Latitude:  40:26:46 N
5000 Forbes Avenue                      Longitude: 79:56:55 W
Pittsburgh, PA 15213                    Mood:      :-)
===========================================================================



Wed, 02 Apr 1997 08:29:00 GMT  
 But what about macros?!?

   Any time you give individual programmers the ability to tweak syntax
   to their tastes, somebody somewhere is likely to pucker up in disgust.

Of course macros can be abused.  The Lisp philosophy, which I hope
will carry forward into Dylan, is that the programming environment
should empower the programmer.  The idea is to make it easy to do the
right thing, not to make it hard or impossible to do the wrong thing.
If you want to be hog-tied and gagged by your programming languge, use
Ada instead, or ML if just being strongly handcuffed will suffice.

(We've had some complaints that this newsgroup is too quiet, now that
the butthead folksinger controversy has simmered down.  Not that I
would ever say anythign deliberately provocative...)

      A macro design is currently being worked on...

   I'm delighted to hear this.  Can you provide any vague hints as to
   what it will look like?  Will macros be written in Dylan, or in an
   R4RS-esque pattern language?  Will there be explicit support for
   conditional compilation?

The first version you see will be a pattern-substitution macro system.
This is fairly powerful, and handles about 90% of what you might want
to do, but stops short of allowing the user to write arbitrary Dylan
procedures to massage the code at compile-time.  Full procedural
macros will come along eventually, but (obviously) only for those
systems that are written in Dylan or have some other way of
interpeting Dylan programs at compile-time.

   By the way, my personal thanks to you and all of the members of the
   Gwydion team...  Keep up the good work!

Thanks.  The best is yet to come.

-- Scott

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

Principal Research Scientist            Phone:     412 268-2575
School of Computer Science              Fax:       412 268-5576 (new!)
Carnegie Mellon University              Latitude:  40:26:46 N
5000 Forbes Avenue                      Longitude: 79:56:55 W
Pittsburgh, PA 15213                    Mood:      :-)
===========================================================================



Wed, 02 Apr 1997 05:29:23 GMT  
 But what about macros?!?
[Kaelin Colclasure]

|   Any time you give individual programmers the ability to tweak syntax to
|   their tastes, somebody somewhere is likely to pucker up in disgust.
|   I'm sure you recall the heated arguments for using { } instead of
|   keyword ... end keyword; in Dylan.  Given a reasonably capable macro
|   system, would you care to bet on how long it will take for someone to
|   implement this?  This is the mirror image of the pathological C macro
|   set (ie. #define BEGIN {, etc.) which has helped to cast cpp in such
|   bad light.

well, macros aren't only parameterized string substitution, but cpp does
only that.  you can do BEGIN ... } in cpp, and that's truly evil.  a true
macro language should be able to operate on the language itself, not just
on individual tokens.

then there's common lisp reader macros.

|   Will macros be written in Dylan, or in an R4RS-esque pattern language?
|   Will there be explicit support for conditional compilation?

with a prefix language, conditional compilation can encompass expressions,
instead of textual blocks of code.  common lisp uses #- and #+.  haven't
seen anything as clean in any scheme implementation.  compare this to C's
gross #ifdef mess.

lisp is a strange attractor.  it might take a few iterations before you get
there and stay with it, but you will.

#<Erik>
--
Microsoft is not the answer.  Microsoft is the question.  NO is the answer.



Wed, 02 Apr 1997 19:50:49 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. A macro involving two sub-macros - where the 2nd macro needs results from the first

2. macro -vs- macro/codeblock

3. Help with macros writing macros in Bigloo

4. syntax-rules macros with sub-macros

5. Scheme macro source: rewriter-widget, a widely applicable macro interface

6. Macros defining macros with define-syntax

7. symbol-macros and regular macros

8. Question about a macro-defining macro

9. Macro-Defining Macros

10. macro macros

11. Local macro within a macro?

12. how much macro is too much macro

 

 
Powered by phpBB® Forum Software