guile-devel
[Top][All Lists]
Advanced

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

Re: unknown location: definition in expression context in subform optnam


From: Mark H Weaver
Subject: Re: unknown location: definition in expression context in subform optname-from of "_^"
Date: Thu, 26 Jan 2012 19:10:55 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Bruce Korb <address@hidden> writes:

> On 01/25/12 20:22, Mike Gran wrote:
>>> From: Bruce Korb<address@hidden>
>>
>>>>   unknown location: definition in expression context in subform 
>>>> optname-from
>>> of "_^"

The other interesting thing here is that the error message above says
"_^" instead of the full string "A-Z_^".  That suggests that the string
literal was not properly read.

Bruce, are you sure that the following expression was passed directly to
'eval' or 'primitive-eval'?

(define optname-from   "A-Z_^")

    Mark


PS: As a side note to the Guile developers: the error message here is
    misleading, because in the call to 'syntax-violation' within the
    'define*' cases of 'expand-expr', the bound identifier is passed as
    the 'subform' and the bound value is passed as the 'form'.
    Unfortunately, there is no way to fix this without changing the
    values that 'syntax-type' returns for 'define*' forms.

>>>>   Scheme evaluation error.  AutoGen ABEND-ing in template
>>>>           /old-home/ROOT/usr/local/share/autogen/aginfo.tpl on line 163
>>>>   Failing Guile command:  = = = = =
>>>>
>>>>   (define opt-name       "")
>>>>   (define extra-ct       0)
>>>>   (define extra-text     "")
>>>>   (define optname-from   "A-Z_^")  ;;<<<=== is something
>>> wrong here?  What, exactly?
>>>>   (define optname-to     "a-z--")
>>>>   (make-tmp-dir)
>>>
>>> what is the message trying to say?
>>
>> For some reason, it thinks that you're not at the top level, but
>> instead in the middle of some expression.
>>
>> It might be saying that you've missed a close parenthesis
>> on a define somewhere above.
>
> The answer, then, is "I don't know".  The text handed off to the read/process
> loop is exactly what you see above, modulo I added the comment.
> Since an entire s-expression is read before processing, there cannot
> have been a left-open s-expression from another call to
> ag_scm_eval_expression_from_file_line.  I'd have choked there.
>
> I tried it twice last night and it failed this way both times.
> I just retried it and it worked correctly.  It is an inexplicable
> transient error.  An irreproducible result.  Thank you!
>
> Cheers - Bruce



reply via email to

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