[nem-bug] [Nemerle 0001019]: Feature request: Extension macros

[feedback at nemerle.org]

A NOTE has been added to this issue.
======================================================================
<http://nemerle.org/bugs/view.php?id=1019> 
======================================================================
Reported By:                VladD2
Assigned To:                
======================================================================
Project:                    Nemerle
Issue ID:                   1019
Category:                   Compiler (parser/macros engine)
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
======================================================================
Date Submitted:             05-20-2007 19:47 CEST
Last Modified:              05-22-2007 23:16 CEST
======================================================================
Summary:                    Feature request: Extension macros
Description: 
For many tasks will be useful Extension macros. For example Extension
macros will be useful for implementing DLinq (Linq to SQL) functionality.

I think syntax of Extension macro should be:
macro MacroName[T](this : Info[TypeForExtending[T]][..., argExprN])
{
  ...
}
where [..., argExprN] is a any numbers of parametr
or:
macro MacroName[T](this : Info[TypeForExtending[T]], params paramArray :
array[PExpr])
{
  ...
}
or:
macro MacroName[T](this : Info[TypeForExtending[T]], params paramArray :
list[PExpr])
{
  ...
}



Example:
macro Where[T](this : Info[IQueryable[T]], lamdaExpr)
{
  def linqExpr = ToLinqExpression(lamdaExpr);
  <[ System.Linq.Queryable.Where($(this.PExpr), $linqExpr) ]>
}

Info give information about type of "this" parametr and in PExpr/TExpr
representation.

using:
SomeMethod(queryable : IQueryable[Customer])
{
  queryable.Where(c => c.Name.StartsWith("J"))
}

I think Extension macros is possible implement under Extension methods. We
can create one Extension method for each Extension macro and replace method
call to macro call when type of first parametr be known.
======================================================================

----------------------------------------------------------------------
 malekith - 05-21-07 22:21 
----------------------------------------------------------------------
Somewhat problematic is, that we type all the parameters before deciding
the extension method, so we would somehow need to undo this (which can be
problematic, if for example some of the parameters contain type errors).

----------------------------------------------------------------------
 VladD2 - 05-22-07 22:17 
----------------------------------------------------------------------
In fact all macros are a "generic".
We can interpret Extension macro as method which has one typed parameter
and some number of parameters which typed as object.

----------------------------------------------------------------------
 VladD2 - 05-22-07 22:22 
----------------------------------------------------------------------
And if some of the parameters contain type errors we can stop compiling and
print errors. 
What a problem?

----------------------------------------------------------------------
 nazgul - 05-22-07 22:25 
----------------------------------------------------------------------
The problem Michal describe is not in "choosing" macro for execution, but
for parameters, which should be passed to it. Normal macros take PExpr,
but after running method overloading resolution we have only TExpr (ok, we
have also original PExpr, but we would like to avoid typing parameters,
since macro may want to transform them).

The solution would be to first check for defined macros on a type, before
performing resolution. But this causes the problem, that we do not always
know the type of 'obj' expression (in obj.method_or_macro()) and sometimes
only after performing the resolution process the exact type is inferred,
like:

[].Find (x => x == 1);

without analysing parameters we do not know the type of [], which is list
[FREE]

----------------------------------------------------------------------
 VladD2 - 05-22-07 22:53 
----------------------------------------------------------------------
Maybe forbid type erors in parametrs of EM (extension macros)?
In fact EM should emulate regular methods and it's prohibition reasonable.

----------------------------------------------------------------------
 VladD2 - 05-22-07 23:16 
----------------------------------------------------------------------
It add IntelliSense support for EM.
And in the future we can change our decision if find other way.

Issue History
Date Modified  Username       Field                    Change              
======================================================================
05-20-07 19:47 VladD2         New Issue                                    
05-21-07 22:21 malekith       Note Added: 0001905                          
05-22-07 22:17 VladD2         Note Added: 0001906                          
05-22-07 22:22 VladD2         Note Added: 0001907                          
05-22-07 22:25 nazgul         Note Added: 0001908                          
05-22-07 22:53 VladD2         Note Added: 0001909                          
05-22-07 23:16 VladD2         Note Added: 0001910                          
======================================================================