[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unknown location: definition in expression context in subform optnam
From: |
Andy Wingo |
Subject: |
Re: unknown location: definition in expression context in subform optname-from of "_^" |
Date: |
Sun, 29 Jan 2012 21:28:24 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
Greets,
On Sun 29 Jan 2012 05:12, Mark H Weaver <address@hidden> writes:
> Andy Wingo <address@hidden> writes:
>> On Sat 28 Jan 2012 20:47, Mark H Weaver <address@hidden> writes:
>>> Andy Wingo <address@hidden> 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 "_^", (continued)
- Re: unknown location: definition in expression context in subform optname-from of "_^", Noah Lavine, 2012/01/26
- Re: unknown location: definition in expression context in subform optname-from of "_^", Bruce Korb, 2012/01/26
- Re: unknown location: definition in expression context in subform optname-from of "_^", Mark H Weaver, 2012/01/28
- Re: unknown location: definition in expression context in subform optname-from of "_^", Bruce Korb, 2012/01/28
- Re: unknown location: definition in expression context in subform optname-from of "_^", Andy Wingo, 2012/01/28
- Re: unknown location: definition in expression context in subform optname-from of "_^", Mark H Weaver, 2012/01/28
- Re: unknown location: definition in expression context in subform optname-from of "_^", Andy Wingo, 2012/01/28
- Re: unknown location: definition in expression context in subform optname-from of "_^", Mark H Weaver, 2012/01/28
- Re: unknown location: definition in expression context in subform optname-from of "_^", Bruce Korb, 2012/01/29
- Re: unknown location: definition in expression context in subform optname-from of "_^", Mike Gran, 2012/01/29
- Re: unknown location: definition in expression context in subform optname-from of "_^",
Andy Wingo <=
- Re: unknown location: definition in expression context in subform optname-from of "_^", Bruce Korb, 2012/01/29
- Re: unknown location: definition in expression context in subform optname-from of "_^", Mark H Weaver, 2012/01/29
- Re: unknown location: definition in expression context in subform optname-from of "_^", Andy Wingo, 2012/01/28
- Re: unknown location: definition in expression context in subform optname-from of "_^", Mark H Weaver, 2012/01/27
- Re: unknown location: definition in expression context in subform optname-from of "_^", Mark H Weaver, 2012/01/27
- Re: unknown location: definition in expression context in subform optname-from of "_^", Bruce Korb, 2012/01/27
- Re: unknown location: definition in expression context in subform optname-from of "_^", Mark H Weaver, 2012/01/27