chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Fix line numbers in error messages inside


From: Felix
Subject: Re: [Chicken-hackers] [PATCH] Fix line numbers in error messages inside modules
Date: Fri, 11 May 2012 13:45:13 +0200 (CEST)

From: Peter Bex <address@hidden>
Subject: [Chicken-hackers] [PATCH] Fix line numbers in error messages inside 
modules
Date: Sun, 6 May 2012 21:37:32 +0200

> Hi hackers,
> 
> While working on some code I noticed that all error messages of code
> that goes wrong inside modules always show the line number of the
> module definition's start.  This is really annoying, especially in
> large modules this doesn't help (and most code nowadays is in modules).
> 
> Example:
> 
> $ cat /tmp/test.scm
> (module foo (bar)
>   (import chicken scheme)
> 
>   (define (bar)
>     (print (+ 'a 1))))
> 
> (import foo)
> (bar)
> $ csc -scrutinize /tmp/test.scm
> 
> Warning: in toplevel procedure `foo#bar':
>   (/tmp/test.scm:1) in procedure call to `+', expected argument #1 of type 
> `number', but was given an argument of type `symbol'
> 
> $ /tmp/test
> 
> Error: (+) bad argument type: a
> 
>         Call history:
> 
>         /tmp/test.scm:8: foo#bar          
>         /tmp/test.scm:1: +              <--
> 
> As you can see, all references to "+" mention line 1, while the actual
> code is several lines lower (line 5).

I see. Hm.

> 
> The reason this happens is that the compiler strips all syntax off
> entire modules and then walks the contents, which means all contents
> have been copied to fresh cons cells, while the line number database
> holds the old cons cells.

Yup.

> 
> Besides this annoying aspect, I think stripping entire modules is bad
> practice.  If anything goes wrong by not stripping them, we should fix
> that properly (by fixing the syntax env or wherever it goes wrong).
> However, we don't have a single test that fails when not stripping them!
> Compilation should also be faster by not running strip-syntax over
> entire modules.

If the module form is the result of a macro-expansion, then (at least)
the export list will be invalid, as these need to be pure, unaliased
names. I have applied your patch and modified the processing of ##core#module
to strip the export list. Installing s48-modules and installing/running
prometheus seems to work ok.


cheers,
felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]