Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(08 Jan 2013 01:33 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Noah Lavine
(11 Jan 2013 02:46 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alaric Snell-Pym
(11 Jan 2013 10:05 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(11 Jan 2013 13:03 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Eli Barzilay
(11 Jan 2013 14:30 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(11 Jan 2013 14:50 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Eli Barzilay
(11 Jan 2013 15:06 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(12 Jan 2013 02:11 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Eli Barzilay
(12 Jan 2013 02:15 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(12 Jan 2013 02:50 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Aaron W. Hsu
(12 Jan 2013 03:38 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(12 Jan 2013 11:33 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Aaron W. Hsu
(15 Jan 2013 19:17 UTC)
|
Re: [Scheme-reports] auxiliary syntax Eli Barzilay (16 Jan 2013 07:12 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(16 Jan 2013 08:16 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Eli Barzilay
(16 Jan 2013 08:28 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(16 Jan 2013 14:11 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Eli Barzilay
(16 Jan 2013 14:30 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(16 Jan 2013 14:38 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alaric Snell-Pym
(11 Jan 2013 15:01 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Eli Barzilay
(11 Jan 2013 15:16 UTC)
|
Re: [Scheme-reports] auxiliary syntax
John Cowan
(11 Jan 2013 15:19 UTC)
|
Re: [Scheme-reports] auxiliary syntax
Alex Shinn
(12 Jan 2013 01:53 UTC)
|
On Friday, Alex Shinn wrote: > On Sat, Jan 12, 2013 at 11:15 AM, Eli Barzilay <eli@barzilay.org> 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@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports