Sugar

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Sugar

Ingvar von Schoultz
The following would let people create syntax sugar for their
favorite paradigms.

Suppose we want the word |Constructor| to become a syntax-sugar
keyword. We inform the compiler at the top of the scope:

     use sugar Constructor;

We define |Constructor| as a function:

     sugar function Constructor (...)
     {   ...
     }

Now we can use |Constructor| as a keyword:

     Constructor Example (...)
     {   ...
     }

This has become syntax sugar for creating a new function named
Example() and passing it to the above function Constructor():

     const Example = Constructor
     (   function Example (...)
         {   ...
         }
     );

Sugar keywords are also intended for expression constructs:

     use sugar func;
     ...
     x = func (...) {...}

This desugars to:

     x = func (function (...) {...})

In this case the name for the new function is optional. The sugar
function can of course do whatever it wants with the new function,
including calling it.

We can combine several sugar keywords:

     use sugar frozen, Constructor, inherits;
     ...
     frozen Constructor Child (...)
     inherits new Parent (...)
     {   ...
     }

This desugars to:

     const Child = Constructor
     (   frozen(),
         function Child (...)
         {   ...
         },
         inherits (new Parent (...))
     );

However, the desugaring shown here is inefficient, and I've chosen
it for its simplicity, a real desugaring will be different. Here,
frozen() and inherits() return objects that Constructor() recognizes
and acts on.

If the parser needs stable rules that don't depend on the meaning of
individual keywords, it can look for the first "(", "{" or ";". Then,
if the preceding identifier is a sugar keyword, an anonymous function
is created, otherwise this identifier becomes the name of the newly
created function.

The nearest sugar keyword before that first "(", "{" or ";" becomes
the main, enclosing sugar-function call.

All sugar keywords are called as functions. Anything else, like
|new  Parent (...)| above, is an expression whose value becomes
an argument to the nearest preceding sugar function.

--
Ingvar von Schoultz

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar

Dave Herman-2
> The following would let people create syntax sugar for their
> favorite paradigms.

I really have to suggest you learn about macros before trying to
reinvent them. This reading list is a good start:

     http://library.readscheme.org/page3.html

Dave

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar

Ingvar von Schoultz
Dave Herman wrote:
>> The following would let people create syntax sugar for their
>> favorite paradigms.
>
> I really have to suggest you learn about macros before trying to
> reinvent them. This reading list is a good start:
>
>     http://library.readscheme.org/page3.html

The idea is to avoid the unsolved problems of macro hygiene.
That's why the arrangement has only function calls, no macros.

--
Ingvar von Schoultz

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar

Felix-54
In reply to this post by Dave Herman-2
Dave Herman wrote:
>> The following would let people create syntax sugar for their
>> favorite paradigms.
>
> I really have to suggest you learn about macros before trying to
> reinvent them. This reading list is a good start:
>
>      http://library.readscheme.org/page3.html

ingvar-sugar isn't a macro system.  it's pretty similar to python's
@decorator syntax.  http://www.python.org/dev/peps/pep-3129/
_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Sugar unrelated to macros -- Was: Re: Sugar

Ingvar von Schoultz
In reply to this post by Ingvar von Schoultz
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



Ingvar von Schoultz wrote:

> Dave Herman wrote:
>>> The following would let people create syntax sugar for their
>>> favorite paradigms.
>> I really have to suggest you learn about macros before trying to
>> reinvent them. This reading list is a good start:
>>
>>     http://library.readscheme.org/page3.html
>
> The idea is to avoid the unsolved problems of macro hygiene.
> That's why the arrangement has only function calls, no macros.

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar unrelated to macros -- Was: Re: Sugar

Brendan Eich-2
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 <[hidden email]> 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.

/be


Ingvar



Ingvar von Schoultz wrote:
Dave Herman wrote:
The following would let people create syntax sugar for their
favorite paradigms.
I really have to suggest you learn about macros before trying to 
reinvent them. This reading list is a good start:


The idea is to avoid the unsolved problems of macro hygiene.
That's why the arrangement has only function calls, no macros.

_______________________________________________
Es-discuss mailing list


_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar unrelated to macros -- Was: Re: Sugar

Dave Herman-2
> 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.

Dave

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar unrelated to macros -- Was: Re: Sugar

Brendan Eich-2
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.

/be
_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar unrelated to macros -- Was: Re: Sugar

Ingvar von Schoultz
In reply to this post by Brendan Eich-2
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
> <[hidden email] <mailto:[hidden email]>> 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.

--
Ingvar von Schoultz

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Sugar

Yuh-Ruey Chen
In reply to this post by Ingvar von Schoultz
Ok, I'm really confused about the exact semantics of this new syntax. Can you give explicit rules? As far as I can tell, this "sugar function" can either desugar to a (const declaration + assignment + function call + anonymous function) or just (function call + anonymous function), and I'm not sure whether a specific sugar function usage desugars to the former or the latter.

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss