Any way to get the current "Scope" of a macro?

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

Any way to get the current "Scope" of a macro?

Jordo Odroj
I was looking at: http://haxe.org/api/haxe/macro/context

The Context tells us the current location and class, but how can we
somehow get the tightest scope that the macro was invoked in?
For example:

function myFunc() {
    function yourFunc() {
        if(x==true) {                      // Start of the scope I
want to reason about.
             var y = false;
             var c = "SDF";
             MacroThing.call();
              var p = 0;                   // End of scope;
        }
    }
}

My goal is that, inside the macro, I want to reason about the content
in the scope.. For example, when someone invokes my macro, I want to
take the entire scope and wrap every statement in that scope inside of
a try catch (that is a made up example BTW).

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Any way to get the current "Scope" of a macro?

Nicolas Cannasse
Le 16/03/2011 02:14, Jordo Odroj a écrit :

> I was looking at: http://haxe.org/api/haxe/macro/context
>
> The Context tells us the current location and class, but how can we
> somehow get the tightest scope that the macro was invoked in?
> For example:
>
> function myFunc() {
>      function yourFunc() {
>          if(x==true) {                      // Start of the scope I
> want to reason about.
>               var y = false;
>               var c = "SDF";
>               MacroThing.call();
>                var p = 0;                   // End of scope;
>          }
>      }
> }
>
> My goal is that, inside the macro, I want to reason about the content
> in the scope.. For example, when someone invokes my macro, I want to
> take the entire scope and wrap every statement in that scope inside of
> a try catch (that is a made up example BTW).

You can't access the expressions outside of your macro, but you can give
your macro a full scope with :

if( x == true )
        MacroThing.call({
                var x = false;
                var c = "SDF";
                ...
        });

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Any way to get the current "Scope" of a macro?

Jordo Odroj
Cool. That should mostly work for my purposes.
Also, I posted a feature request on google code, about being able to
make macros look a little more "native", without the need for
parenthesis. If so, then it could be pretty cool looking:

if( x == true )
       MacroThing.call {
               var x = false;
               var c = "SDF";
               ...
       }                                      // no semicolon needed
(or whatever is easy to implement)

Is that the kind of thing that would be difficult to implement in the parser?


On Wed, Mar 16, 2011 at 1:07 AM, Nicolas Cannasse
<[hidden email]> wrote:

> Le 16/03/2011 02:14, Jordo Odroj a écrit :
>>
>> I was looking at: http://haxe.org/api/haxe/macro/context
>>
>> The Context tells us the current location and class, but how can we
>> somehow get the tightest scope that the macro was invoked in?
>> For example:
>>
>> function myFunc() {
>>     function yourFunc() {
>>         if(x==true) {                      // Start of the scope I
>> want to reason about.
>>              var y = false;
>>              var c = "SDF";
>>              MacroThing.call();
>>               var p = 0;                   // End of scope;
>>         }
>>     }
>> }
>>
>> My goal is that, inside the macro, I want to reason about the content
>> in the scope.. For example, when someone invokes my macro, I want to
>> take the entire scope and wrap every statement in that scope inside of
>> a try catch (that is a made up example BTW).
>
> You can't access the expressions outside of your macro, but you can give
> your macro a full scope with :
>
> if( x == true )
>        MacroThing.call({
>                var x = false;
>                var c = "SDF";
>                ...
>        });
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Any way to get the current "Scope" of a macro?

Heinz Hölzer-2
I like your proposal ;)

Am 16.03.2011 10:29, schrieb Jordo Odroj:

> Cool. That should mostly work for my purposes.
> Also, I posted a feature request on google code, about being able to
> make macros look a little more "native", without the need for
> parenthesis. If so, then it could be pretty cool looking:
>
> if( x == true )
>         MacroThing.call {
>                 var x = false;
>                 var c = "SDF";
>                 ...
>         }                                      // no semicolon needed
> (or whatever is easy to implement)
>
> Is that the kind of thing that would be difficult to implement in the parser?
>
>
> On Wed, Mar 16, 2011 at 1:07 AM, Nicolas Cannasse
> <[hidden email]>  wrote:
>> Le 16/03/2011 02:14, Jordo Odroj a écrit :
>>> I was looking at: http://haxe.org/api/haxe/macro/context
>>>
>>> The Context tells us the current location and class, but how can we
>>> somehow get the tightest scope that the macro was invoked in?
>>> For example:
>>>
>>> function myFunc() {
>>>      function yourFunc() {
>>>          if(x==true) {                      // Start of the scope I
>>> want to reason about.
>>>               var y = false;
>>>               var c = "SDF";
>>>               MacroThing.call();
>>>                var p = 0;                   // End of scope;
>>>          }
>>>      }
>>> }
>>>
>>> My goal is that, inside the macro, I want to reason about the content
>>> in the scope.. For example, when someone invokes my macro, I want to
>>> take the entire scope and wrap every statement in that scope inside of
>>> a try catch (that is a made up example BTW).
>> You can't access the expressions outside of your macro, but you can give
>> your macro a full scope with :
>>
>> if( x == true )
>>         MacroThing.call({
>>                 var x = false;
>>                 var c = "SDF";
>>                 ...
>>         });
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Any way to get the current "Scope" of a macro?

Nicolas Cannasse
In reply to this post by Jordo Odroj
Le 16/03/2011 10:29, Jordo Odroj a écrit :

> Cool. That should mostly work for my purposes.
> Also, I posted a feature request on google code, about being able to
> make macros look a little more "native", without the need for
> parenthesis. If so, then it could be pretty cool looking:
>
> if( x == true )
>         MacroThing.call {
>                 var x = false;
>                 var c = "SDF";
>                 ...
>         }                                      // no semicolon needed
> (or whatever is easy to implement)
>
> Is that the kind of thing that would be difficult to implement in the parser?


Yes, because it's not valid haXe syntax, and the parser does not know at
all about macros. Also, the idea of macros is to reuse haXe syntax, so
I'm not in favor of introducing macro-specific syntax.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Any way to get the current "Scope" of a macro?

Jordo Odroj
Yes, as is, I figured that would be hard for that very reason. Seems
like you can't even get past the parser, currently.
However, throughout all of my haxe coding the need for something like
this has come up several times, and not just limited to Macros. I
think there is a reasonable way to extend the syntax that is helpful
to accomplish this, not just with macros but all over the language.
Allow me to explain:

1. I love the haxe syntax. It's clear, doesn't rely on white space,
most important constructs are wrapped in brackets or parentheses (and
they are mandatory). I hope that never changes.
For instance, I never want to be able to say:
someMethod x y    // a method invocation.
That is one of the only things I hate about Ocaml.
However, give the following idea a chance.. I think this is really
mind blowing and could radically open up possibilities for the
language:

2. The using keyword currently means the following:
     You may *omit* the first parameter and precede the invocation of
the method with the first parameter followed by dot.
     instead of CallSomeFunc(firstParam, secondParam, thirdParam);
     you can say:
     firstParam.CallSomeFunc(secondParam, thirdParam);
     // Notice how no parenthesis are needed around the first
parameter "so long as it is obvious what the first parameter is*
     // If the first parameter was an addition expression, you would
need parentheses:
     (1+2).CallSomeFunc(firstParam, secondParam).
     // The dot helps us to avoid parentheses in many cases that
aren't complex expressions.


     But what if we also make using do something else - that is:
     With using: you may omit the *last* parameter from the invocation
and place the last parameter immediately *after* the invocation, and
parenthesis are not needed around that last parameter "so long as it
is obvious what the last parameter is"
     In terms of the last example, you could say:
     CallSomeFunc(firstParam, secondParam)(thirdParam);
     CallSomeFunc(firstParam, secondParam)("hello");
     CallSomeFunc(firstParam, secondParam)(1+2);
     CallSomeFunc(firstParam, secondParam)(someVariable);

     In these cases, parenthesis are needed, but sometimes they will not be.
     CallSomeFunc(firstParam, secondParam) {  field: "Value"};
     In this case, it is obvious what the last parameter was.


     Here is why this is very powerful, even when not discussing macros:
     It is so easy to create powerful programming constructs that
require very little code.


     Example: Suppose I want to create a new user-space language
construct that partitions an integer into positive, negative, and
zero.
     Class MyUtils {
         public static function intPartition<T>(int: i,   partitioner:
{neg: T, pos: T, z: T}) {
              if (i < 0) {
                    return neg;
              } else if(i==0) {
                    return z;
              } else {
                    return pos;
              }
         }
      }
With that small amount of code you could do:

=============================
using MyUtils;
var userInput : Int = getUserInput();

var message : String =
    intPartition(userInput) {
            pos: "You Entered a positive number",
            z: "You entered zero man!"
            neg: "You entered a negative number"
    };

Look at that! Now everyone and their mother can feel like they can be
a language designer, all thanks to Haxe!
Notice how in this case, all return values must be the same.

I already have a *million* uses for this.

Nicolas, I would love to take on this project. Do you think it could
be a good introduction to learning the haxe compiler? I would love a
few hints about where to look at in the Ocaml parser. I just need to
make this the equivalent of wrapping the last parameter into the
argument list. Once in AST form, it should be equivalent. I really
like the fact that we require you to "using" the class so that this is
something that is very intentional.

I hope you guys like this idea!

On Wed, Mar 16, 2011 at 3:31 AM, Nicolas Cannasse
<[hidden email]> wrote:

> Le 16/03/2011 10:29, Jordo Odroj a écrit :
>>
>> Cool. That should mostly work for my purposes.
>> Also, I posted a feature request on google code, about being able to
>> make macros look a little more "native", without the need for
>> parenthesis. If so, then it could be pretty cool looking:
>>
>> if( x == true )
>>        MacroThing.call {
>>                var x = false;
>>                var c = "SDF";
>>                ...
>>        }                                      // no semicolon needed
>> (or whatever is easy to implement)
>>
>> Is that the kind of thing that would be difficult to implement in the
>> parser?
>
>
> Yes, because it's not valid haXe syntax, and the parser does not know at all
> about macros. Also, the idea of macros is to reuse haXe syntax, so I'm not
> in favor of introducing macro-specific syntax.
>
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Any way to get the current "Scope" of a macro?

Jordo Odroj
I would describe this as: 'using' allows frontend *or* backend
currying to be automatically provided, and in both cases parenthesis
are not needed where it is obvious how to parse the curried parameter.

On Thu, Mar 17, 2011 at 2:20 AM, Jordo Odroj <[hidden email]> wrote:

> Yes, as is, I figured that would be hard for that very reason. Seems
> like you can't even get past the parser, currently.
> However, throughout all of my haxe coding the need for something like
> this has come up several times, and not just limited to Macros. I
> think there is a reasonable way to extend the syntax that is helpful
> to accomplish this, not just with macros but all over the language.
> Allow me to explain:
>
> 1. I love the haxe syntax. It's clear, doesn't rely on white space,
> most important constructs are wrapped in brackets or parentheses (and
> they are mandatory). I hope that never changes.
> For instance, I never want to be able to say:
> someMethod x y    // a method invocation.
> That is one of the only things I hate about Ocaml.
> However, give the following idea a chance.. I think this is really
> mind blowing and could radically open up possibilities for the
> language:
>
> 2. The using keyword currently means the following:
>     You may *omit* the first parameter and precede the invocation of
> the method with the first parameter followed by dot.
>     instead of CallSomeFunc(firstParam, secondParam, thirdParam);
>     you can say:
>     firstParam.CallSomeFunc(secondParam, thirdParam);
>     // Notice how no parenthesis are needed around the first
> parameter "so long as it is obvious what the first parameter is*
>     // If the first parameter was an addition expression, you would
> need parentheses:
>     (1+2).CallSomeFunc(firstParam, secondParam).
>     // The dot helps us to avoid parentheses in many cases that
> aren't complex expressions.
>
>
>     But what if we also make using do something else - that is:
>     With using: you may omit the *last* parameter from the invocation
> and place the last parameter immediately *after* the invocation, and
> parenthesis are not needed around that last parameter "so long as it
> is obvious what the last parameter is"
>     In terms of the last example, you could say:
>     CallSomeFunc(firstParam, secondParam)(thirdParam);
>     CallSomeFunc(firstParam, secondParam)("hello");
>     CallSomeFunc(firstParam, secondParam)(1+2);
>     CallSomeFunc(firstParam, secondParam)(someVariable);
>
>     In these cases, parenthesis are needed, but sometimes they will not be.
>     CallSomeFunc(firstParam, secondParam) {  field: "Value"};
>     In this case, it is obvious what the last parameter was.
>
>
>     Here is why this is very powerful, even when not discussing macros:
>     It is so easy to create powerful programming constructs that
> require very little code.
>
>
>     Example: Suppose I want to create a new user-space language
> construct that partitions an integer into positive, negative, and
> zero.
>     Class MyUtils {
>         public static function intPartition<T>(int: i,   partitioner:
> {neg: T, pos: T, z: T}) {
>              if (i < 0) {
>                    return neg;
>              } else if(i==0) {
>                    return z;
>              } else {
>                    return pos;
>              }
>         }
>      }
> With that small amount of code you could do:
>
> =============================
> using MyUtils;
> var userInput : Int = getUserInput();
>
> var message : String =
>    intPartition(userInput) {
>            pos: "You Entered a positive number",
>            z: "You entered zero man!"
>            neg: "You entered a negative number"
>    };
>
> Look at that! Now everyone and their mother can feel like they can be
> a language designer, all thanks to Haxe!
> Notice how in this case, all return values must be the same.
>
> I already have a *million* uses for this.
>
> Nicolas, I would love to take on this project. Do you think it could
> be a good introduction to learning the haxe compiler? I would love a
> few hints about where to look at in the Ocaml parser. I just need to
> make this the equivalent of wrapping the last parameter into the
> argument list. Once in AST form, it should be equivalent. I really
> like the fact that we require you to "using" the class so that this is
> something that is very intentional.
>
> I hope you guys like this idea!
>
> On Wed, Mar 16, 2011 at 3:31 AM, Nicolas Cannasse
> <[hidden email]> wrote:
>> Le 16/03/2011 10:29, Jordo Odroj a écrit :
>>>
>>> Cool. That should mostly work for my purposes.
>>> Also, I posted a feature request on google code, about being able to
>>> make macros look a little more "native", without the need for
>>> parenthesis. If so, then it could be pretty cool looking:
>>>
>>> if( x == true )
>>>        MacroThing.call {
>>>                var x = false;
>>>                var c = "SDF";
>>>                ...
>>>        }                                      // no semicolon needed
>>> (or whatever is easy to implement)
>>>
>>> Is that the kind of thing that would be difficult to implement in the
>>> parser?
>>
>>
>> Yes, because it's not valid haXe syntax, and the parser does not know at all
>> about macros. Also, the idea of macros is to reuse haXe syntax, so I'm not
>> in favor of introducing macro-specific syntax.
>>
>> Nicolas
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>

--
haXe - an open source web programming language
http://haxe.org