Re: [Scheme-reports] auxiliary syntax

[Eli Barzilay <eli@x>]

On Friday, Alex Shinn wrote:
> On Sat, Jan 12, 2013 at 11:15 AM, Eli Barzilay <eli@x> wrote:
> 
>     Just now, Alex Shinn wrote:
>     > I never thought I'd have to explain this on a Scheme or Lisp
>     > related list,
> 
>     I never thought that I'd need to explan hygiene or its benefits
>     or how scope works on a Scheme related list, let alone the list
>     where the supposed future of the language is discussed.
> 
> Sorry, I did not mean that in a snarky way.
> 
> And again and again - I'm not arguing against hygiene!

No, you're not arguing against it in general, you just have one
particular case where you want to avoid it...  And if it wasn't
clear, IMO your case is not a real need, and could be done just as
well without breaking hygiene.  I'm not going to go over your existing
package, but if you thin it down to a toyish example I can express why
I don't think breaking hygiene is needed via code.

But before you say it: I'm not arguing against abolishing unhygienic
macros.  They're obviously there, and they're obviously are going to
stick around.  They provide information that is otherwise unavailable
(what's the actual concrete name that was used?).  In fact, I'm using
a macro system that provides me with even less hygienic information:
for example, a macro that depends on the shape of the parens that was
used for it, or a macro that depends on its line+col position, or
maybe one that expands differently if it's in a file from a specific
directory, or even one that depends not only on the unhygienic name
that is used but also on how it was typed (eg, making `foo' and `f\oo'
behave differently).

Yes, all of these things are usually a bad idea to use.  If you see
people use them, then you'd expect them to really know what they're
doing, or you'd semi-automatically conclude that they're just wrong in
using these things.  I put unhygienic macros in a similar category:
people jump on them *WAY* too often, in unjustified ways.  So far, you
have tried to justify your use in some vague quasi-explanations.  A
concrete example would be nice.


> I've implemented several hygienic macro systems from scratch and
> studied several others.  I program exclusively with hygienic macros,
> and for a long time have been advocating people switch as well since
> as we both know you can't mix hygienic with unhygienic.

OK, I should be impressed, I assume.  I have written a phd
dissertation on quotations, and had a very detailed explanation on
various options including using flat strings.  Does that get you
impressed enough to assume that when I talked about strings it was a
bit more than being unaware of the advantages of sexprs?

To make this point better, I'll start with a side-comment: if you
really want to use strings, then you don't really lose any of the
advantages of sexprs -- you're working with a raw macro system anyway,
so you just need to use `read' and forget about the strings.  This
makes it a practical experiment.  But you obviously missed my point:
doing such an experiment should demonstrate how it is to have a macro
that deals only with its own DSL -- not one that gets composed with
the rest of the language, or IOW, not one that is an *extension* of
the language.  For these kinds of macros, breaking hygiene might make
sense in the same way that strings make sense: the macro's language is
completely unrelated to the host language.  The use of hygienic
identifiers over symbols becomes a minor point, possibly one that
doesn't buy you much (maybe having user-renamable keywords is one),
and forces you to work harder for doing it hygienically for an
advantage you don't care about.

But the thing is that such macros are very rare -- and what I said
earlier that they don't have much place in Scheme since they show very
little of the power of real macros.  They're exactly the kind of
macros that you can easily implement in any language as a simple
pre-processor.  IOW, they're the kind of macros that I don't care
much about.  If you had such a macro then making it unhygienic is not
a big problem since there's no confusion -- much like having its body
put in a string.

Real macros, the interesting kind, are macros that extend the language
in various ways: the bind things for parts of their bodies, they allow
expressions from the host language (including other macros) in some
positions, etc etc.  Making these kind of macros unhygienic is what
can be a problem -- since with these guys you can end up with a
position that can be either an expression or a keyword, and therefore
not obeying lexical scope can be a real problem with them.  A classic
example of that is `cond' & its `else' -- it's not a macro that
"really, really wants to just match `else' unhygienically but it can't
because it has an ambiguous syntax".  On the contrary: the fact that
its syntax is "ambiguous"[*] is exactly what makes it much more
sensible to require that it obeys lexical scope -- that it does its
keyword matching hygienically.  ([*] It's not really ambiguous of
course, for each choice of a hygienic or a non-hygienic match you get
deterministic meaning.  What's ambiguous here is that without knowing
this choice, you can't tell that meaning.)


> This discussion isn't about an unhygienic macro, but about selective
> "unhygienic" literal matching, although that name is misleading.
> Rather, it's a type of low-level macro that looks at symbol names,
> and how we could potentially do the same thing with high-level
> macros.

Yes, once you have a good low level macro system, you can have a bunch
of rally wild "high-level" macors.  Here's a cute exercise for the
enthusiastic reader:

  (define-syntax if*
    (syntax-rules/indent ()
      [(if C
           T
           ...
         E
         ...)
       (if C (begin T ...) (begin E ...))]))

  (define (foo x)
    (if (< x 10)
        (display "small\n")
        (* x 2)
      (display "big\n")
      x))

  > (+ (foo 5) (foo 15))
  small
  big
  25

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports