> On Sat, 6 Jul 2013 21:22:48 +0200, Peter Bex <address@hidden> wrote:
> On Sat, Jul 06, 2013 at 11:49:44AM -0700, J Altfas wrote:
> > > On Sat, 6 Jul 2013 12:22:12 -0400, Frank
> > <address@hidden> wrote:
> >
> > > Hi,
> > > Is there a way to get line numbers in the error output of the
> > > interpreter?
> > >
> >
> > I would add that this would be extremely helpful in compiled code
> > error output as well.
>
> AFAIK in compiled code, all errors have line numbers. If not, please
> post a use case where it breaks.
>
Of course, you are right. I didn't express very well what I meant. Yes the line numbers are there (and very accurate too), but that's not always particular informative regarding the origin of the error. Here is one (and maybe not the best possible) example:
Error: (string-append) bad argument type - not a string: ()
Call history:
httm.scm:42: indent-sz
httm.scm:42: make-string
httm.scm:87: ##sys#print
httm.scm:87: ##sys#print
httm.scm:87: ##sys#print
httm.scm:87: ##sys#write-char-0
httm.scm:90: html-eol
httm.scm:87: ##sys#print
httm.scm:87: get-output-string
httm.scm:83: tloop
httm.scm:94: htmatch
httm.scm:39: ->string
httm.scm:39: common#strcat
httm.scm:39: attrloop
httm.scm:39: ->string
httm.scm:39: common#strcat <--
True enough, string-append chokes when feeding it a non-string, but the issue is the trace showing the series of calls bouncing around in a loop in httm, whereas the error's instigator (where the not-a-string was wrongly supplied) was maybe several frames up in the series of procedural calls.
Which leads to the idea that what Chicken really needs is a full-fledged debugger. I realize it's been a subject often discussed, yet still seems to be an elusive goal.
But that doesn't stop a guy from dreaming...
Jules Altfas.