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: 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/



reply via email to

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