Sugar unrelated to macros -- Was: Re: Sugar
On Aug 28, 2008, at 3:26 PM, Ingvar von Schoultz wrote:
Macros and functions are very, very different. My proposal has only regular, run-of-the-mill functions. They don't have
"do have", right?
parentheses around the arguments, but this detail doesn't make them in any way related to macros and their problems.
If you mean hygiene, that is not a practical problem so much as a
theoretical one. Dave knows a lot about this topic, so I'll defer to
him.
I find it disconcerting that this list will so easily brush off proposals with some vague comment about something never proposed.
Please cut the "this list" collective guilt assignment. Felix
<felix8a at gmail.com> replied identifying your idea with Python
decorators, and you did not reply to him. Was his reply either
disconcerting or a brush-off? No. Keep your arguments with
individuals focused on individuals with whom you have a bone to pick,
or better yet, avoid ad hominem (ad listinem ;-) arguments altogether.
Dave, your claim that I'm proposing macros will make many people ignore and never see the real proposal.
Macros and functions are very, very different. My proposal has only regular, run-of-the-mill functions. They don't have parentheses around the arguments, but this detail doesn't make them in any way related to macros and their problems.
Sorry, I didn't mean to come across so dismissive. I'm not trying to ignore you, I just don't have time to keep up with everything. This isn't my day job. :)
Since you made that incorrect claim without reading, could you please consider commenting on the /actual/ proposal?
I'll try.
If you mean hygiene, that is not a practical problem so much as a theoretical one. Dave knows a lot about this topic, so I'll defer to him.
No, hygiene is most certainly a practical problem! Hygiene is about preventing very subtle bugs that are intermittent and extremely hard to track down.
Meta-programming facilities don't have to be called macros to have problems with variable capture, and those who aren't familiar with macros tend to stumble over those bugs without realizing it. That's not meant as disparaging, it's just not a very widely understood area. So I'm very wary of meta-programming facilities that are proposed in an email. Language features are subtle and require lots of careful attention, and meta-programming facilities are especially so. That's why I was skeptical.
But I will have to try to read the proposal more carefully and see what I think.
On Aug 28, 2008, at 5:35 PM, Dave Herman wrote:
If you mean hygiene, that is not a practical problem so much as a theoretical one. Dave knows a lot about this topic, so I'll defer
to him.No, hygiene is most certainly a practical problem!
Lack of hygiene is a problem. My statement in reply to Ingvar's
citing "problems" with macro systems was that, if he meant by
"problems" anything like "implementing hygienic macros", then
building such systems is a solved problem for certain languages --
albeit without complete formalization in theory. This is not to say
hygiene being supported in Scheme transfers to JS, of course.
Ingvar's sugar proposal seems free of capture problems, at a glance,
even if sugar definitions nest. But a more complete proposal would be
needed to be sure. I was making a few assumptions from the examples.
Brendan Eich wrote:
On Aug 28, 2008, at 3:26 PM, Ingvar von Schoultz wrote:
Macros and functions are very, very different. My proposal has only regular, run-of-the-mill functions. They don't have
"do have", right?
No, they don't have parentheses:
use sugar frozen, Constructor, inherits;
...
frozen Constructor Child (...)
inherits new Parent (...)
{ ...
}
This desugars to:
const Child = Constructor
( frozen(),
function Child (...)
{ ...
},
inherits (new Parent (...))
);
All the sugar-keyword functions are user defined. The desugaring above is simplified. The functions frozen() and inherits() return objects that Constructor() recognizes and acts on.
This sugar is not only useful for creating classes and constructors, it's also useful in expressions.
parentheses around the arguments, but this detail doesn't make them in any way related to macros and their problems.
If you mean hygiene, that is not a practical problem so much as a theoretical one. Dave knows a lot about this topic, so I'll defer to him.
You have stated firmly that macros will not be included before unsolved hygiene problems have been researched. I'm hoping that regular functions will be more palatable.
It's a great feature of JavaScript that it accommodates so many paradigms. With this sugar you'd get clearer syntax for many different paradigms.
I find it disconcerting that this list will so easily brush off proposals with some vague comment about something never proposed.
Please cut the "this list" collective guilt assignment. Felix <felix8a at gmail.com <mailto:felix8a at gmail.com>> replied identifying your idea with Python decorators, and you did not reply to him. Was his reply either disconcerting or a brush-off? No. Keep your arguments with individuals focused on individuals with whom you have a bone to pick, or better yet, avoid /ad hominem/ (/ad listinem/ ;-) arguments altogether.
Uff, I'm sorry, I shouldn't have said it that way.
I was thinking back to the hoisting proposal, which was brushed off over and over with vague talk about things I had never proposed, never discussing my real proposal. But this was in part my own fault for being so verbose (though I thought I wasn't clear enough, and needed to explain /more/... a vicious circle).
But indeed I shouldn't have said it that way above. Sorry.
Felix's reply was certainly not a brush-off, very much the contrary. I appreciated it. I wanted to answer, but couldn't think of anything interesting to add to what he said.
Dave Herman wrote:
Sorry, I didn't mean to come across so dismissive. I'm not trying to ignore you, I just don't have time to keep up with everything. This isn't my day job. :)
Wow, I thought it was the day job for most people involved.
Since you made that incorrect claim without reading, could you please consider commenting on the /actual/ proposal?
I'll try.
I'm glad. I've worked hard at making the text brief and clear, so hopefully the reading will be easy.
Lack of hygiene is a problem. My statement in reply to Ingvar's
citing "problems" with macro systems was that, if he meant by
"problems" anything like "implementing hygienic macros", then
building such systems is a solved problem for certain languages --
albeit without complete formalization in theory. This is not to say
hygiene being supported in Scheme transfers to JS, of course.
My mistake; I see what you're saying.
I might not go so far as to say designing and implementing hygienic macros is a /solved/ problem (there's a wide design space) but I do think it's acquired too much mystique. In some ways, what I'm hoping to do with my research is demystify hygiene.
Ingvar's sugar proposal seems free of capture problems, at a glance,
Yes, I believe it doesn't have capture problems.
even if sugar definitions nest. But a more complete proposal would be
needed to be sure. I was making a few assumptions from the examples.
Agreed, especially Re: the effects it would have on the parser.
Dave Herman wrote:
Brendan Eich wrote:
But a more complete proposal would be
needed to be sure. I was making a few assumptions from the examples.Agreed, especially Re: the effects it would have on the parser.
Unfortunately I'm not sufficiently competent about the subject to evaluate the effects on the parser.
Maybe I should mention that if it's important for the compiler, the desugaring of multiple-keyword expressions can use a much simpler strategy:
use sugar a, b, c, d, e;
...
a b c Name (...) d e new Parent (...) {...};
might desugar into:
a (b (c (function Name (...) {...}, d (e (new Parent (...))))));
The desugaring that I showed in the thread starter is very likely not the best, I chose that mainly because it helped make the explanation clear.
In many aspects of this proposal, many variations are possible, with different tradeoffs. I think it would be a good idea to let it mature step by step while discussions evolve.
Speaking of completeness, the sugar functions need more information. This:
use sugar word;
...
word Example (x)
{ ...
}
might be desugared into this:
const Example = word
( this,
arguments,
function() {return x},
function Example (x)
{ ...
}
);
Passing |arguments| would allow control-structure keywords better functionality, but it would break encapsulation and undeprecate |arguments|, so it's very debatable.
If the Ruby blocks that Chen is proposing should become available, the above problem would disappear.
If there are no Ruby blocks, then in compensation the desugaring might be expanded to detect and propagate return statements when applicable. But that's worthwhile only if people will use control- structure keywords, or other keywords where such a functionality is desirable.
Another issue is the fact that classes are data types.
So it all depends on many things, and should probably mature gradually as discussions evolve.
Dave, your claim that I'm proposing macros will make many people ignore and never see the real proposal.
Macros and functions are very, very different. My proposal has only regular, run-of-the-mill functions. They don't have parentheses around the arguments, but this detail doesn't make them in any way related to macros and their problems.
Since you made that incorrect claim without reading, could you please consider commenting on the /actual/ proposal?
I find it disconcerting that this list will so easily brush off proposals with some vague comment about something never proposed.
Ingvar