[nem-en] Debugging macros again

[Kamil Skalski]

The biggest problem here is when to consider macro "transparent" and
when show that message is related to it. We have many "core" macros,
which would just blur the image totally, if we begun mentioning them
in error messages, like  'if', 'while', 'for', even operators like +=
etc.

The other way would be to show part of the expression, which caused
the error - the user could immediately see the core of the problem.
This might however also blur the information badly.

2007/1/8, Andrei Varanovich <dotnetby at gmail.com>:
> 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
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


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