gmane.comp.lang.erlang.general

Howard Yeh | 16 Aug 21:41

Re: How to get the line number of current executable code?

On 8/16/08, Richard Carlsson <richardc <at> it.uu.se> wrote:

 >  If you're actually running in interpreted mode (debugging mode), you
 >  do get the current line, but it's a couple of orders of magmitude
 >  slower, so you don't want to do that for all your code.

How do I run the vm in debugging mode?

 In the AST transformation code for my pet lisp frontend, it's often
 hard to tell where a pattern match failed, b/c there can be many
 matches within a single function.

 It would be /very/ helpful if running in debugging mode gives me the
 line #. I can live with performance penalty at development time...

headers

Richard Carlsson | 17 Aug 10:37

Re: How to get the line number of current executable code?

Howard Yeh wrote:
> How do I run the vm in debugging mode?

Not the vm as such, more like a meta-interpreter:

http://www.erlang.org/doc/apps/debugger/index.html

    /Richard

headers

Thomas Lindgren | 17 Aug 11:51

Re: How to get the line number of current executable code?

--- On Sat, 8/16/08, Howard Yeh <hayeah <at> gmail.com> wrote:
>  In the AST transformation code for my pet lisp frontend,
> it's often
>  hard to tell where a pattern match failed, b/c there can
> be many
>  matches within a single function.
> 
>  It would be /very/ helpful if running in debugging mode
> gives me the
>  line #. I can live with performance penalty at development
> time...

I'm not sure if this helps in your case, but if you're satisfied with getting line numbers in your
exceptions, try smart_exceptions from jungerl. It's a parse transform, so it works without the debugger.

Best,
Thomas

headers

Howard Yeh | 17 Aug 19:25

Re: How to get the line number of current executable code?

On 8/17/08, Thomas Lindgren <thomasl_erlang <at> yahoo.com> wrote:
>
> I'm not sure if this helps in your case, but if you're satisfied with getting line numbers in your
exceptions, try smart_exceptions from jungerl. It's a parse transform, so it works without the debugger.
>

Ah, thanks for the pointer.

So you are basically providing a fall through case for M-F-A-line
error report whenever there's branching? It sounds like a good way to
do it.

I've read somebody (Joe?) saying that pattern matchings in erlang are
like mini contracts. Early failure from failed match is a good thing.
So I am wondering if Thomas's code transfomer is compatible with the
Erlang philosophy (I think it is). But I may be missing the obvious.

As mentioned, I am playing around with my pet lisp frontend. Having
seem Thomas's smart exception, it seems that it makes sense to provide
special syntatic support for matching failure. Something like,

(case X
  <cases>*
  : "expected such and such input")

The last line is a syntatic sugar for a universal pattern that throws
a {badmatch...}, but with M-F-A/line and reason. Ditto with function
clauses et al.

Robert V. probably wouldn't like it : )

(Continue reading)