On 02/04/2013 01:41 PM, Jacob Carlborg wrote:
> On 2013-02-01 18:53, bearophile wrote:
>
>> Maybe Jacob Carlborg is able to show what kind of syntax for pattern
>> matching the macros are able to create (no need to actually implement it
>> now).
>
> How would a pattern matching feature look like and behave?. I can see if
> that would be possible to implement using the AST macros I'm thinking
> about.
>

Well, ideally something like

ast.match{
    2*(?a)  => a+a,
    (?a)+2  => 2+a,
    (?e)    => e,
}

The following would be feasible today, hacking around the usual hygiene issues:

mixin(match!("ast",q{
    2*(?a)  => a+a,
    (?a)+2  => 2+a,
    (?e)    => e,
});

On 2013-02-05 01:29, Timon Gehr wrote:

> Well, ideally something like
>
> ast.match{
>      2*(?a)  => a+a,
>      (?a)+2  => 2+a,
>      (?e)    => e,
> }

Could you please elaborate how that would be, what the semantics would be. It doesn't look like any pattern matching I've seen in any other languages.

For example, which value does it match on?

-- 
/Jacob Carlborg

On 2013-02-05 01:15, Timon Gehr wrote:

> IMO macros should be fully hygienic by default, with opt-out options.

That's the opposite of how the macros in Scala works.

It's quite easy to say if it should be hygienic or not. The hard part is to figure out the details and how to break hygienicy, when there's need for it.

-- 
/Jacob Carlborg

On 02/05/2013 08:28 AM, Jacob Carlborg wrote:
> On 2013-02-05 01:15, Timon Gehr wrote:
>
>> IMO macros should be fully hygienic by default, with opt-out options.
>
> That's the opposite of how the macros in Scala works.
>

As far as my understanding goes, quasi-quoting is hygienic, and manual AST building provides both options.

> It's quite easy to say if it should be hygienic or not. The hard part is
> to figure out the details and how to break hygienicy, when there's need
> for it.
>

We could provide all nested scopes in an array as part of the context.

macro foo(Context context){
    return<[
        context.scopes[0].x++;
        context.scopes[1].x++;
    ]>;
}
int x = 2;
void main(){
    int x=0;
    foo();
    assert(x==1 && .x==3);
}

If manual AST building is supported, it could additionally do something along the following lines:


module macros;
int x=0;
macro foo(Context context){
    return SequenceExp(
        AssignExp(Symbol!x(), Constant(1)),
        AssignExp(Identifier("x"), Constant(2)),
    );
}

// ---
module m;
import macros;
int x=0;

void main(){
    foo();
    assert(macros.x==1 && x==2);
}

On 02/05/2013 08:26 AM, Jacob Carlborg wrote:
> On 2013-02-05 01:29, Timon Gehr wrote:
>
>> Well, ideally something like
>>
>> ast.match{
>>      2*(?a)  => a+a,
>>      (?a)+2  => 2+a,
>>      (?e)    => e,
>> }
>
> Could you please elaborate how that would be, what the semantics would
> be. It doesn't look like any pattern matching I've seen in any other
> languages.
>
> For example, which value does it match on?
>

Eg:

if ast == <[2*x]>, then the result will be <[x+x]>
if ast == <[y+2]>, then the result will be <[2+y]>

On 2013-02-05 01:29, Timon Gehr wrote:

> Well, ideally something like
>
> ast.match{
>      2*(?a)  => a+a,
>      (?a)+2  => 2+a,
>      (?e)    => e,
> }

When I think about it, it can't look like that. What's passed to a macro needs to be syntactically valid.

-- 
/Jacob Carlborg

On 02/05/2013 03:14 PM, Jacob Carlborg wrote:
> On 2013-02-05 01:29, Timon Gehr wrote:
>
>> Well, ideally something like
>>
>> ast.match{
>>      2*(?a)  => a+a,
>>      (?a)+2  => 2+a,
>>      (?e)    => e,
>> }
>
> When I think about it, it can't look like that. What's passed to a macro
> needs to be syntactically valid.
>

I'd prefer if it needn't be.

macro match(Context context, Ast ast, string code){
    ...
    if(...) context.error("invalid syntax", code[a..b]);
    // (slice of code describes exact location where error
    // is shown to user at the call site.)
    ...
}

On 2013-02-05 16:24, Timon Gehr wrote:

> I'd prefer if it needn't be.
>
> macro match(Context context, Ast ast, string code){
>      ...
>      if(...) context.error("invalid syntax", code[a..b]);
>      // (slice of code describes exact location where error
>      // is shown to user at the call site.)
>      ...
> }

The whole point of AST macros is that the compiler will do the lexing and parsing of the code. It will then just return an AST and it's up to the developer of the macro to implement the semantics.

If the code is just passed as a string to the macro you would then need to lex and parse in addition to implementing the semantics and we would be no better than the current situation with string mixins.

-- 
/Jacob Carlborg

On 02/05/2013 06:08 PM, Jacob Carlborg wrote:
> On 2013-02-05 16:24, Timon Gehr wrote:
>
>> I'd prefer if it needn't be.
>>
>> macro match(Context context, Ast ast, string code){
>>      ...
>>      if(...) context.error("invalid syntax", code[a..b]);
>>      // (slice of code describes exact location where error
>>      // is shown to user at the call site.)
>>      ...
>> }
>
> The whole point of AST macros is that the compiler will do the lexing
> and parsing of the code. It will then just return an AST and it's up to
> the developer of the macro to implement the semantics.
>

If it's just about lexing and parsing, you need a lexer and a parser, not a macro.

> If the code is just passed as a string to the macro

That's just one option. Not all macros need to add syntax.

> you would then need to lex and parse in addition to implementing the semantics

If one chooses to do so. Parser generators can be provided.

> and we would be no better than the current situation with string mixins.
>

We surely would be better.

On 2013-02-05 18:49, Timon Gehr wrote:

> If it's just about lexing and parsing, you need a lexer and a parser,
> not a macro.

Yeah, plus some syntax sugar.

> That's just one option. Not all macros need to add syntax.

True.

> If one chooses to do so. Parser generators can be provided.

Yes.

>> and we would be no better than the current situation with string mixins.
>>
>
> We surely would be better.



-- 
/Jacob Carlborg