unknown location: definition in expression context in subform optname-from of "_^"

unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

Hi,

Say, what???  I don't understand.

> ice-9/psyntax.scm:866:30: In procedure dobody:
> ice-9/psyntax.scm:866:30: Syntax error:
> unknown location: definition in expression context in subform optname-from of "_^"
> 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?

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mike Gran]

> From: Bruce Korb <bruce.korb@gmail.com>

>>  unknown location: definition in expression context in subform optname-from 
> of "_^"
>>  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 following would give the same error:

(define (func x) 
   (1+ 
    (define optname-from "A-Z_^"))

But if that were true, you'd expect it to bork on one of the other
lines in your code snippet as well.

You could try having EMACS re-indent the whole buffer to see if you
slipped a paren.  Otherwise, I don't know.

-Mike

Re: unknown location: definition in expression context in subform optname-from of "_^"

[David Kastrup]

Mike Gran <spk121@yahoo.com> writes:

> You could try having EMACS re-indent the whole buffer to see if you
> slipped a paren.

What's wrong with M-x check-parens RET ?

-- 
David Kastrup

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

On 01/25/12 20:22, Mike Gran wrote:
>> From: Bruce Korb<bruce.korb@gmail.com>
>
>>>   unknown location: definition in expression context in subform optname-from
>> of "_^"
>>>   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

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mike Gran]

>To: Mike Gran <spk121@yahoo.com> 
>> 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!

Sorry.  Maybe Andy and Ludo have a better answer.
 
If I can help by trying to compile and run the code on my boxes,
let me know.
 
Thanks,
 
Mike

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

Hi Mike,

On Thu, Jan 26, 2012 at 1:21 PM, Mike Gran <spk121@yahoo.com> wrote:
>>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!
>
> Sorry.  Maybe Andy and Ludo have a better answer.
>
> If I can help by trying to compile and run the code on my boxes,
> let me know.

Thanks for the reply.  "irreproducible results" are, by their very nature,
basically undebuggable.  I'm going to remember this, but otherwise
pretend it didn't happen.

Thanks!  Cheers - Bruce

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Bruce Korb <bruce.korb@gmail.com> writes:

> On 01/25/12 20:22, Mike Gran wrote:
>>> From: Bruce Korb<bruce.korb@gmail.com>
>>
>>>>   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

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

On 01/26/12 16:10, Mark H Weaver wrote:
>>>>>    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'?

I am completely certain.  Unfortunately, though the string now looks like this:

(define opt-name       "")
(define extra-ct       0)
(define extra-text     "")
(define optname-from   "A-Z_^")
(define optname-to     "a-z--")
(make-tmp-dir)

(if (exist? "preserve-case") (begin
   (set! optname-from "_^")
   (set! optname-to   "--") ))

Upon careful examination of the entire, not-clipped string,
I know at one point those "set!" used to be "define".
Then I got bit, went through several fixup cycles and an old version
must have been copied into place.  Sorry for the bother.

> 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.

Too bad.  I do prefer clue-ful error messages and "unknown location"
just wasn't the helpful clue I needed.  Perhaps just use "improper location"?
"invalid location"?  Just not "unknown location".  It sounds like Guile is out
in the weeds and cannot really tell me what's awry.

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Bruce Korb <bruce.korb@gmail.com> writes:

> On 01/26/12 16:10, Mark H Weaver wrote:
>>>>>>    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'?
>
> I am completely certain.  Unfortunately, though the string now looks like this:
>
> (define opt-name       "")
> (define extra-ct       0)
> (define extra-text     "")
> (define optname-from   "A-Z_^")
> (define optname-to     "a-z--")
> (make-tmp-dir)
>
> (if (exist? "preserve-case") (begin
>   (set! optname-from "_^")
>   (set! optname-to   "--") ))
>
> Upon careful examination of the entire, not-clipped string,
> I know at one point those "set!" used to be "define".
> Then I got bit, went through several fixup cycles and an old version
> must have been copied into place.  Sorry for the bother.

Okay, in that case, this all makes perfect sense.  The error was
actually referring to the (define optname-name "_^") that was within the
'if', and indeed that would be a non-top-level definition within
expression context and thus illegal.

>> 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.
>
> Too bad.  I do prefer clue-ful error messages and "unknown location"
> just wasn't the helpful clue I needed.  Perhaps just use "improper location"?
> "invalid location"?  Just not "unknown location".

That part of the error message (where "unknown location" was printed)
would normally contain the filename, line number, and column number.
In this case, Guile did not have source location information for that
expression because it came from a C string.  That's why it wrote
"unknown location".

> It sounds like Guile is out in the weeds and cannot really tell me
> what's awry.

The message "definition in expression context" accurately conveys the
nature of the error, though I agree that it is rather terse and likely
to confuse Scheme beginners.  Perhaps we should rephrase it.

However, the 'in subform optname-from of "_^"' portion is definitely not
correct, and it would be good to fix that.  It would have been far more
helpful if it printed the entire definition form.  I'll look into it.

    Thanks,
      Mark

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

On 01/26/12 18:26, Mark H Weaver wrote:
>> Too bad.  I do prefer clue-ful error messages and "unknown location"
>> just wasn't the helpful clue I needed.  Perhaps just use "improper location"?
>> "invalid location"?  Just not "unknown location".
>
> That part of the error message (where "unknown location" was printed)
> would normally contain the filename, line number, and column number.

Then either it ought to have printed the location, or there are new
wrinkles in the file/line number stuff that I need to know about.
That is precisely why I hate having this function in my code:

SCM
ag_scm_c_eval_string_from_file_line(
     char const * pzExpr, char const * pzFile, int line)
{
     SCM port = scm_open_input_string(AG_SCM_STR02SCM(pzExpr));

     if (OPT_VALUE_TRACE >= TRACE_EVERYTHING)
         fprintf(pfTrace, TRACE_EVAL_STRING, pzFile, line, pzExpr);

     {
         static SCM    file      = SCM_UNDEFINED;
         static char * pzOldFile = NULL;

         if ((pzOldFile == NULL) || (strcmp(pzOldFile, pzFile) != 0)) {
             if (pzOldFile != NULL)
                 AGFREE(pzOldFile);
             AGDUPSTR(pzOldFile, pzFile, "scheme source");
             file = AG_SCM_STR02SCM(pzFile);
         }

         {
             SCM ln = AG_SCM_INT2SCM(line);
             scm_set_port_filename_x(port, file);
             scm_set_port_line_x(port, ln);
         }
     }

     {
         SCM ans = SCM_UNSPECIFIED;

         /* Read expressions from that port; ignore the values.  */
         for (;;) {
             SCM form = scm_read(port);
             if (SCM_EOF_OBJECT_P(form))
                 break;
             ans = scm_primitive_eval_x(form);
         }

         return ans;
     }
}

Every evaluation comes from here and in this instance, "pzFile"
pointed to "/path/to/aginfo.tpl" and "line" was set to 163.
Therefore, the location should *NOT* have been unknown and
in fact, the displayed line number ought to have been 171.

Why that failed I would very much want to know so that I can
fix this ag_scm_c_eval_string_from_file_line() thingy.

> The message "definition in expression context" accurately conveys the

Yes, it does.  I was thrown off by the "unknown location" stuff.

Thank you for your help!!

Regards, Bruce

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Noah Lavine]

Hello,

>        /* Read expressions from that port; ignore the values.  */
>        for (;;) {
>            SCM form = scm_read(port);
>            if (SCM_EOF_OBJECT_P(form))
>                break;
>            ans = scm_primitive_eval_x(form);
>        }
>
>        return ans;
>    }
> }
>
> Every evaluation comes from here and in this instance, "pzFile"
> pointed to "/path/to/aginfo.tpl" and "line" was set to 163.
> Therefore, the location should *NOT* have been unknown and
> in fact, the displayed line number ought to have been 171.
>
> Why that failed I would very much want to know so that I can
> fix this ag_scm_c_eval_string_from_file_line() thingy.

I am not an expert, but this is my guess about what's happening: you
get the form from the file with scm_read. scm_read returns a regular
s-expression, not a syntax object. Then you pass this form to
scm_primitive_eval_x. scm_primitive_eval_x has a plain syntax-object
with no way to know where it came from, so it prints "unknown
location".

The reason the standard Guile interpreter knows where things came from
is that it parses files as syntax, not s-expressions, and syntax
objects have embedded file and line information.

But note that I didn't say that you could do this. I don't know of an
interface to this functionality (although I believe this example shows
that we need one).

Noah

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

On 01/26/12 18:59, Noah Lavine wrote:
> Hello,
>
>>         /* Read expressions from that port; ignore the values.  */
>>         for (;;) {
>>             SCM form = scm_read(port);
>>             if (SCM_EOF_OBJECT_P(form))
>>                 break;
>>             ans = scm_primitive_eval_x(form);
>>         }
>>
>>         return ans;
>>     }
>> }
>>
>> Every evaluation comes from here and in this instance, "pzFile"
>> pointed to "/path/to/aginfo.tpl" and "line" was set to 163.
>> Therefore, the location should *NOT* have been unknown and
>> in fact, the displayed line number ought to have been 171.
>>
>> Why that failed I would very much want to know so that I can
>> fix this ag_scm_c_eval_string_from_file_line() thingy.
>
> I am not an expert, but this is my guess about what's happening: you
> get the form from the file with scm_read. scm_read returns a regular
> s-expression, not a syntax object. Then you pass this form to
> scm_primitive_eval_x. scm_primitive_eval_x has a plain syntax-object
> with no way to know where it came from, so it prints "unknown
> location".

Nope.  My code is parsing a text file, keeping track of file and line.
The "pzExpr" argument is, indeed, an array of UTF-8/ASCII text
from a file and line number known and also passed in.

So, I am getting the "form" from that read on the string port
and my expectation is that Guile advances the line/column numbers
set in the calls above.  If this is not true, then I need explicit
instructions on *exactly* what I need to do in order for the
"unknown location" to be a known location.

> But note that I didn't say that you could do this. I don't know of an
> interface to this functionality (although I believe this example shows
> that we need one).

It has been an issue I've been arguing for years and years and years,
ever since the trivial 1.6(4?) methodology (fiddling with obviously correct,
but very wrong to do, Guile internal data structures) became disabled.
Look in the email archives for ag_scm_c_eval_string_from_file_line.
http://lists.gnu.org/archive/html/guile-devel/2005-11/msg00052.html
I made the name very long so it would be easy to Google for.  :)

So I will repeat my request (and, please forgive the irritation,
because I have, after all, been asking for a really long time):

I need to be able to locate a guile scheme expression in my ASCII
text input and hand it off to Guile, telling it the file name and
line number and column number of where I found the string.  In this way,
when there is an evaluation error, something more sensible than
"unknown location" is displayed for the location information.

Thank you for reconsidering.

Regards, Bruce

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Hi Bruce,

Bruce Korb <bruce.korb@gmail.com> writes:
> On 01/26/12 18:26, Mark H Weaver wrote:
>>> Too bad.  I do prefer clue-ful error messages and "unknown location"
>>> just wasn't the helpful clue I needed.  Perhaps just use "improper location"?
>>> "invalid location"?  Just not "unknown location".
>>
>> That part of the error message (where "unknown location" was printed)
>> would normally contain the filename, line number, and column number.
>
> Then either it ought to have printed the location, or there are new
> wrinkles in the file/line number stuff that I need to know about.

Your code looks good to me, and should allow source locations to be
properly reported in error messages.

It turns out that this was simply a bug in Guile.  For this type of
error (definition in expression context), we would _always_ say "unknown
location", even when compiling a module from a file in the normal way.

I have produced a patch to fix these error messages, and will post it as
soon as I have thoroughly tested it (within a couple of hours), in the
hopes that it may be included in 2.0.4.

>         {
>             SCM ln = AG_SCM_INT2SCM(line);
>             scm_set_port_filename_x(port, file);
>             scm_set_port_line_x(port, ln);
>         }

Ideally, you would also call 'scm_set_port_column_x' here.  Otherwise,
the column numbers of errors on the first line will not be reported
properly.  This is not crucial, but I thought I'd mention it.

    Regards,
      Mark

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Hi Noah,

Noah Lavine <noah.b.lavine@gmail.com> writes:
> I am not an expert, but this is my guess about what's happening: you
> get the form from the file with scm_read. scm_read returns a regular
> s-expression, not a syntax object.

Actually, source location information is not stored in syntax objects.
Instead, it is associated with each raw s-expression using a weak-key
`eq?' hash table.  This is done automatically by 'read' if the
'positions' read-option is enabled (the default).  Note that this
strategy implies that source location can only be associated with
parenthesized expressions, not atoms.  See 'Source Properties' in the
Guile manual for details.

    Best,
     Mark

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

On 01/26/12 22:19, Mark H Weaver wrote:
>> Then either it ought to have printed the location, or there are new
>> wrinkles in the file/line number stuff that I need to know about.
>
> Your code looks good to me, and should allow source locations to be
> properly reported in error messages.
>
> It turns out that this was simply a bug in Guile.

That's a relief to me!  (I'd still advocate adding it to Guile. :)

> I have produced a patch to fix these error messages, and will post it as
> soon as I have thoroughly tested it (within a couple of hours), in the
> hopes that it may be included in 2.0.4.

Excellent.

> Ideally, you would also call 'scm_set_port_column_x' here.  Otherwise,
> the column numbers of errors on the first line will not be reported
> properly.

All I can do is set the first line column to zero.
I don't track the columns.

     scm_set_port_column_x(port, SCM_INUM0); // yes?

Thank you!

Regards, Bruce

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Bruce Korb <bruce.korb@gmail.com> writes:
>> Ideally, you would also call 'scm_set_port_column_x' here.  Otherwise,
>> the column numbers of errors on the first line will not be reported
>> properly.
>
> All I can do is set the first line column to zero.
> I don't track the columns.

In that case, don't bother.  The column number is surely initialized to
zero by default anyway.

    Thanks,
      Mark

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Hi Bruce,

In case you didn't see the other thread here on guile-devel: the bugs
with this error message (and a few others) have been fixed on the
stable-2.0 branch, such that with Guile 2.0.4 the error message would
have been something like this:

  /old-home/ROOT/usr/local/share/autogen/aginfo.tpl:171:2: definition in expression context, where definitions are not allowed, in form (define optname-from "_^")

Bruce Korb <bruce.korb@gmail.com> writes:
> I need to be able to locate a guile scheme expression in my ASCII
> text input and hand it off to Guile, telling it the file name and
> line number and column number of where I found the string.

I agree that we should add a function or two to handle this more
conveniently.  Let's talk about it after 2.0.4 has been released, and
hopefully we can get it into 2.0.5.

    Thanks,
      Mark

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

Hi Mark,

On Fri, Jan 27, 2012 at 11:02 PM, Mark H Weaver <mhw@netris.org> wrote:
> Hi Bruce,
>
> In case you didn't see the other thread here on guile-devel:

I read some of it.

> ... with Guile 2.0.4 the error message would
> have been something like this:
>
>  /old-home/ROOT/usr/local/share/autogen/aginfo.tpl:171:2: definition in expression context, where definitions are not allowed, in form (define optname-from "_^")

That's waay too cool !!! :)  Thank you.  Actually, I think I can, with
that, drop my own
file/line numbers when complaining about Guile complaints then!!

> Scheme evaluation error.  AutoGen ABEND-ing in template>         /old-home/ROOT/usr/local/share/autogen/aginfo.tpl on line 163

> Bruce Korb <bruce.korb@gmail.com> writes:
> > I need to be able to locate a guile scheme expression in my ASCII
> > text input and hand it off to Guile, telling it the file name and
> > line number and column number of where I found the string.
>
> I agree that we should add a function or two to handle this more
> conveniently.  Let's talk about it after 2.0.4 has been released, and
> hopefully we can get it into 2.0.5.

Maybe less cumbersome than scm_c_eval_string_from_file_line ;)

Super!

Thank you again!   Regards, Bruce

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Andy Wingo]

Hi,

On Sat 28 Jan 2012 17:58, Bruce Korb <bruce.korb@gmail.com> writes:

>> Bruce Korb <bruce.korb@gmail.com> writes:
>> > I need to be able to locate a guile scheme expression in my ASCII
>> > text input and hand it off to Guile, telling it the file name and
>> > line number and column number of where I found the string.
>>
>> I agree that we should add a function or two to handle this more
>> conveniently.  Let's talk about it after 2.0.4 has been released, and
>> hopefully we can get it into 2.0.5.
>
> Maybe less cumbersome than scm_c_eval_string_from_file_line ;)

Didn't we settle on eval-string, with the #:file and #:line kwargs?  See
eval-string in the manual.

Cheers,

Andy
-- 
http://wingolog.org/

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> writes:

> On Sat 28 Jan 2012 17:58, Bruce Korb <bruce.korb@gmail.com> writes:
>
>>> Bruce Korb <bruce.korb@gmail.com> writes:
>>> > I need to be able to locate a guile scheme expression in my ASCII
>>> > text input and hand it off to Guile, telling it the file name and
>>> > line number and column number of where I found the string.
>>>
>>> I agree that we should add a function or two to handle this more
>>> conveniently.  Let's talk about it after 2.0.4 has been released, and
>>> hopefully we can get it into 2.0.5.
>>
>> Maybe less cumbersome than scm_c_eval_string_from_file_line ;)
>
> Didn't we settle on eval-string, with the #:file and #:line kwargs?  See
> eval-string in the manual.

I guess the code to use that from C would look something like this:

  SCM
  scm_c_eval_string_from_file (const char *string,
                               const char *file_name,
                               long line, long column)
  {
    static SCM eval_string_var, file_keyword, line_keyword, column_keyword;
    static int initialized = 0;
    SCM args[7];
  
    if (!initialized)
      {
        eval_string_var = scm_c_public_variable ("ice-9 eval-string",
                                                 "eval-string");
        file_keyword   = scm_from_latin1_keyword ("file");
        line_keyword   = scm_from_latin1_keyword ("line");
        column_keyword = scm_from_latin1_keyword ("column");
        initialized = 1;
      }
    args[0] = scm_from_locale_string (string);
    args[1] = file_keyword;
    args[2] = scm_from_locale_string (file_name);
    args[3] = line_keyword;
    args[4] = scm_from_long (line);
    args[5] = column_keyword;
    args[6] = scm_from_long (column);
    return scm_call_n (SCM_VARIABLE_REF (eval_string_var), args, 7);
  }

This seems very awkward.  Is there an easier way?

    Mark

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Andy Wingo]

On Sat 28 Jan 2012 20:47, Mark H Weaver <mhw@netris.org> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Sat 28 Jan 2012 17:58, Bruce Korb <bruce.korb@gmail.com> writes:
>>
>>>> Bruce Korb <bruce.korb@gmail.com> writes:
>>>> > I need to be able to locate a guile scheme expression in my ASCII
>>>> > text input and hand it off to Guile, telling it the file name and
>>>> > line number and column number of where I found the string.
>>>>
>>>> I agree that we should add a function or two to handle this more
>>>> conveniently.  Let's talk about it after 2.0.4 has been released, and
>>>> hopefully we can get it into 2.0.5.
>>>
>>> Maybe less cumbersome than scm_c_eval_string_from_file_line ;)
>>
>> Didn't we settle on eval-string, with the #:file and #:line kwargs?  See
>> eval-string in the manual.
>
> I guess the code to use that from C would look something like this:

It can look a little better, if you don't consider columns:

  http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00048.html

See the end of the mail.

Cheers,

Andy
-- 
http://wingolog.org/

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Andy Wingo]

Also:

  http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00091.html

Andy
-- 
http://wingolog.org/

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> writes:
> On Sat 28 Jan 2012 20:47, Mark H Weaver <mhw@netris.org> writes:
>> Andy Wingo <wingo@pobox.com> writes:
>>> Didn't we settle on eval-string, with the #:file and #:line kwargs?  See
>>> eval-string in the manual.
>>
>> I guess the code to use that from C would look something like this:
>
> It can look a little better, if you don't consider columns:

We should not design our APIs based on what suboptimal, inefficient code
would look like.  Instead, we should consider what ideal, efficient code
is needed to accomplish a given task using our APIs.  The best code will
provide the columns, and avoid the wasted effort of repeatedly interning
keywords.

Our current API encourages sloppiness by making it tedious to do the
right thing.  We provide a very convenient interface to evaluate a C
string without source information, thus encouraging coders to use that
even if source information is conveniently available to them.  It seems
to me that we should provide equally convenient means of doing the right
thing.

I propose that we add a single new function:

  SCM scm_eval_string_from_file (SCM string, SCM module, SCM file_name,
                                 long line, long column, int compile_p);

Where 'module' can be SCM_UNDEFINED, in which case 'current-module' is
used (and neither set nor restored).  This provides maximum flexibility
regarding the encodings of the strings, allows the user to cache the
file_name if desired, and yet allows most of the needless complications
to be hidden within this helper function while remaining efficient.

In short, this single function allows code to do the ideal thing
relatively painlessly.  Typical usage might be something like this:

  SCM
  my_eval (const char *string, const char *file_name,
          long line, long column)
  {
    return scm_eval_string_from_file
      (scm_from_locale_string (string), SCM_UNDEFINED,
       scm_from_locale_string (file_name), line, column, 0);
  }

What do you think?

    Mark

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

Hi Mark,

On Sat, Jan 28, 2012 at 8:12 PM, Mark H Weaver <mhw@netris.org> wrote:
> In short, this single function allows code to do the ideal thing
> relatively painlessly.  Typical usage might be something like this:
>
>  SCM
>  my_eval (const char *string, const char *file_name,
>          long line, long column)
>  {
>    return scm_eval_string_from_file
>      (scm_from_locale_string (string), SCM_UNDEFINED,
>       scm_from_locale_string (file_name), line, column, 0);
>  }
>
> What do you think?

I think it is what I've wanted for years.  Thank you!!
Any of these variations would make me happy.

Cheers - Bruce

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mike Gran]

> From: Bruce Korb <bruce.korb@gmail.com>

> On Sat, Jan 28, 2012 at 8:12 PM, Mark H Weaver <mhw@netris.org> wrote:
>>  In short, this single function allows code to do the ideal thing
>>  relatively painlessly.  Typical usage might be something like this:
>> 
>>   SCM
>>   my_eval (const char *string, const char *file_name,
>>           long line, long column)
>>   {
>>     return scm_eval_string_from_file
>>       (scm_from_locale_string (string), SCM_UNDEFINED,
>>        scm_from_locale_string (file_name), line, column, 0);
>>   }
>> 
>>  What do you think?
> 
> I think it is what I've wanted for years.  Thank you!!
> Any of these variations would make me happy.

FWIW, looking at Andy's C functions that call eval-string, they
seem simple enough.  But I never would have come up with that on my own.
When I'm doing C, I tend to focus on C API.

I'm agnostic on whether there should be a new C function for this,
but, if there isn't, the code from
http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00091.html
should make its way into the manual as a reminder that you can do
better than scm_c_eval_string.

Thanks,
Mike

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Andy Wingo]

Greets,

On Sun 29 Jan 2012 05:12, Mark H Weaver <mhw@netris.org> writes:

> Andy Wingo <wingo@pobox.com> writes:
>> On Sat 28 Jan 2012 20:47, Mark H Weaver <mhw@netris.org> writes:
>>> Andy Wingo <wingo@pobox.com> writes:
>>>> Didn't we settle on eval-string, with the #:file and #:line kwargs?  See
>>>> eval-string in the manual.
>>>
>>> I guess the code to use that from C would look something like this:
>>
>> It can look a little better, if you don't consider columns:
>
> We should not design our APIs based on what suboptimal, inefficient code
> would look like.

I think you are begging a question here.  The principle is good enough,
but it admits to a number of interpretations.

I would note a few salient points here.

  * There is previous discussion here:
    http://thread.gmane.org/gmane.lisp.guile.devel/11709/focus=11848

  * Bruce's original problem statement says nothing about columns.

  * The eval-string introduced in 2.0.1 does add a #:column facility.
    It also adds #:module, #:lang, and #:compile?.

  * All things being equal, writing Guile functionality in Scheme is
    better than in C.  (Note the caveat, please.)

    As a corrolary, for it to make little difference to C code what
    language something is implemented in, it needs to be easy to call
    Scheme from C without creating C bindings.  (Note that there is a
    difference between "easy" and "familiar"; Rich Hickey's "Simple Made
    Easy" presentation deals with this point at some length.)

The proposed scm_c_eval_string_from_file_line does not allow for #:lang.
It also has a trailing boolean argument, which is something of an
antipattern.

A function with all possible options is impossible to read and write.
Invocations of scm_eval_string_from_file_line are already almost
impossible to read, e.g.:

>     return scm_eval_string_from_file
>       (scm_from_locale_string (string), SCM_UNDEFINED,
>        scm_from_locale_string (file_name), line, column, 0);

Keyword arguments suit this task much better.  (Also note that
SCM_UNDEFINED is more typically used to indicate the absence of a
parameter, and as such can only appear at the end of an arg list.)

> Our current API encourages sloppiness by making it tedious to do the
> right thing.  We provide a very convenient interface to evaluate a C
> string without source information, thus encouraging coders to use that
> even if source information is conveniently available to them.  It seems
> to me that we should provide equally convenient means of doing the right
> thing.

This is true.  IMHO a comment in the header and a note in the manual
about how to do the right thing from C is the right thing, while
encouraging people to use Scheme.  We probably need to add more
scm_call_N implementations and a scm_call_varargs (...., SCM_UNDEFINED).

You asked what I thought :)

Regards,

Andy
-- 
http://wingolog.org/

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Bruce Korb]

Hi Andy,

On Sun, Jan 29, 2012 at 12:28 PM, Andy Wingo <wingo@pobox.com> wrote:
>  * Bruce's original problem statement says nothing about columns.

That's because I, personally, in my application, didn't put forth the effort
originally (~15 years ago) and it's "too hard" to retrofit.

>  * The eval-string introduced in 2.0.1 does add a #:column facility.
>    It also adds #:module, #:lang, and #:compile?.

It was only recently I dropped support for Guile 1.4 and I still support 1.6.
Translation: I may be dead before 1.8 could be desupported.

>  * All things being equal, writing Guile functionality in Scheme is
>    better than in C.  (Note the caveat, please.)

Is Guile intended as the be-all and end-all in application languages,
or as an "extension language".  It was initially billed as an "extension
language", tho, I confess, it's been over a decade since I started using it.

>    As a corrolary, for it to make little difference to C code what
>    language something is implemented in, it needs to be easy to call
>    Scheme from C without creating C bindings.  (Note that there is a
>    difference between "easy" and "familiar"; Rich Hickey's "Simple Made
>    Easy" presentation deals with this point at some length.)

Amen.

> The proposed scm_c_eval_string_from_file_line does not allow for #:lang.
> It also has a trailing boolean argument, which is something of an
> antipattern.

Something of precisely what I, personally, needed, with little to no
concern over being applied to variations on a theme.  It was presented
more as a "Here's my problem, here's my hack around it, *please*
come up with something better."  And you have.  Thank you.
I look forward to using it and getting that cruft out of my code.

> Keyword arguments suit this task much better.

Indeed.  I certainly agree that that is better for supporting so many
variations.

>> Our current API encourages sloppiness by making it tedious to do the
>> right thing.  We provide a very convenient interface to evaluate a C
>> string without source information, thus encouraging coders to use that
>> even if source information is conveniently available to them.  It seems
>> to me that we should provide equally convenient means of doing the right
>> thing.
>
> This is true.

Amen.  "vehement agreement" here. :)

Regards, Bruce

Re: unknown location: definition in expression context in subform optname-from of "_^"

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> writes:
> Keyword arguments suit this task much better.

Okay, I have a fresh idea for your consideration.

Let's provide a more general facility to make keyword arguments more
convenient to use from C, while avoiding repeatedly interning them.  I
propose a new macro SCM_KEYWORD, which would be defined something like
this:

#ifdef __GNUC__
# define SCM_KEYWORD(name)                       \
  ({ static SCM keyword = SCM_BOOL_F;            \
     if (SCM_UNLIKELY (scm_is_false (keyword)))  \
       keyword = scm_from_utf8_keyword (#name);  \
     return keyword; })
#else
# define SCM_KEYWORD(name) scm_from_utf8_keyword (#name)
#endif

Furthermore, at some point in the future we could provide an optional
alternative mechanism, where SCM_KEYWORD would expand into a simple
global variable reference, and we'd provide a snarfing script to scan
the sources for SCM_KEYWORD and produce an initialization routine for
all these global keywords.

It might be good to do something similar for looking up and caching
scheme procedures as well.

What do you think?

    Mark