[nem-en] Debugging macros again

[Andrei Varanovich]

Yes, your point is quite clear. That's why I was talking about some hints.
May be it make sense to emit some additional information during the macro compilation phase to let the compiler know which macro generated the code related?


-----Original Message-----
From: devel-en-bounces at nemerle.org [mailto:devel-en-bounces at nemerle.org] On Behalf Of Kamil Skalski
Sent: Monday, January 08, 2007 11:21 PM
To: devel-en at nemerle.org
Subject: Re: [nem-en] Debugging macros again

We were thinking about it in the very beginnings, but unfortunately we
didn't came to any good solution. Compiler just knows that there is an
error, it doesn't know if the error originated in macro generated code
or in original source.
Though maybe we could add some heuristics and check inside location of
given chunk of code if this is source code or generated code... this
should work at least in some scenarios, though there is no information
which macro generated given code.

2007/1/8, Andrei Varanovich <dotnetby at gmail.com>:
> Hi,
>
> > Because it seems not so trivial to support correct error messages by
> > compiler without introducing new ones in the macro itself as well.  Vlad for
> > instance also had such an experience.
>
> Could you elaborate? This is the one thing I had never problems with
> (if I understand correctly what you mean)
>
> >>>
> Just a simple example (though, not the best one):
>
> Assuming we have a macro:
>
> macro TestMacro(myName)
>         {
>           WriteLine("Compile-time. myName = " + myName.ToString());
>           <[ WriteLine("Run-time.\n Hello, " + $myName) ]>;
>         }
>
> TestMacro(1 + 2);
> As a result:
> C:\Documents and Settings\Andrei\My Documents\Visual Studio 2005\Projects\NemerleTest1\NemerleTest1\macro.n(34,5): Error : each overload has an error during call:
> C:\Documents and Settings\Andrei\My Documents\Visual Studio 2005\Projects\NemerleTest1\NemerleTest1\macro.n(34,5): Error : overload #1, method System.String.op_Addition(left : string, right : string) : string
> C:\Documents and Settings\Andrei\My Documents\Visual Studio 2005\Projects\NemerleTest1\NemerleTest1\macro.n(34,5): Error : in argument #2 (right) of string.op_Addition, needed a string, got int: System.Int32 is not a subtype of System.String [simple require]
> C:\Documents and Settings\Andrei\My Documents\Visual Studio 2005\Projects\NemerleTest1\NemerleTest1\macro.n(34,5): Error : overload #2, method System.Int32.op_Addition(left : int, right : int) : int
> C:\Documents and Settings\Andrei\My Documents\Visual Studio 2005\Projects\NemerleTest1\NemerleTest1\macro.n(34,5): Error : in argument #1 of +.s, needed a int, got string: System.String is not a subtype of System.Int32 [simple require]
>
>
> I will write my thoughts about other stuff mentioned bellow a bit later (may be as a summary of our discussion on RSDN)
>
> Thanks,
> Andrei
>
> -----Original Message-----
> From: devel-en-bounces at nemerle.org [mailto:devel-en-bounces at nemerle.org] On Behalf Of Kamil Skalski
> Sent: Monday, January 08, 2007 10:21 PM
> To: devel-en at nemerle.org
> Subject: Re: [nem-en] Debugging macros again
>
> >
> > The most sexiest feature of Nemerle for me is it's macro subsystem. And
> > having such great VS add-in in place I'm near  applying my first Nemerle
> > solution to the production world.
> >
> > BUT: A situation with debugging macros (speaking more precisely the main
> > problem is  the code generated by them) is terrible for now.
> >
>
> Did you try the feature of generating the source code of generated
> method as a side-effect of generation?
> I usually just inspect the generated code with .NET inspector when it
> doesn't work as I expected.
>
> >
> >
> > My feeling about this is that may be it make sense to introduce some hints
> > (like these are using in LISP:
> > http://www.slac.stanford.edu/comp/unix/gnu-info/elisp_16.html#SEC181)
> > to make the code generated by macros more adopted for the human beings? :-)
> >
>
> Could you summarize how it could be done in our scenario? Isn't
> "stacktrace" from failed compilation a good approximation of this
> feature  (a very useful feature here is command line option
> -throw-on-error, which gives you the exact stack trace in
> macro/compiler when you signal error.
>
> >
> >
> >
>
>
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


-- 
Kamil Skalski
http://nazgul.omega.pl

_______________________________________________
https://nemerle.org/mailman/listinfo/devel-en