unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Mark H Weaver <mhw@netris.org>
Cc: Bruce Korb <bruce.korb@gmail.com>, guile-devel@gnu.org
Subject: Re: unknown location: definition in expression context in subform optname-from of "_^"
Date: Sun, 29 Jan 2012 21:28:24 +0100	[thread overview]
Message-ID: <87aa56z21j.fsf@pobox.com> (raw)
In-Reply-To: <878vkrkuz7.fsf@netris.org> (Mark H. Weaver's message of "Sat, 28 Jan 2012 23:12:28 -0500")

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/



  parent reply	other threads:[~2012-01-29 20:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-26  3:56 unknown location: definition in expression context in subform optname-from of "_^" Bruce Korb
2012-01-26  4:22 ` Mike Gran
2012-01-26  5:31   ` David Kastrup
2012-01-26 21:05   ` Bruce Korb
2012-01-26 21:21     ` Mike Gran
2012-01-26 21:37       ` Bruce Korb
2012-01-27  0:10     ` Mark H Weaver
2012-01-27  0:56       ` Bruce Korb
2012-01-27  2:26         ` Mark H Weaver
2012-01-27  2:44           ` Bruce Korb
2012-01-27  2:59             ` Noah Lavine
2012-01-27  3:36               ` Bruce Korb
2012-01-28  7:02                 ` Mark H Weaver
2012-01-28 16:58                   ` Bruce Korb
2012-01-28 19:03                     ` Andy Wingo
2012-01-28 19:47                       ` Mark H Weaver
2012-01-28 22:58                         ` Andy Wingo
2012-01-29  4:12                           ` Mark H Weaver
2012-01-29 17:40                             ` Bruce Korb
2012-01-29 18:06                               ` Mike Gran
2012-01-29 20:28                             ` Andy Wingo [this message]
2012-01-29 21:14                               ` Bruce Korb
2012-01-29 21:32                               ` Mark H Weaver
2012-01-28 22:59                         ` Andy Wingo
2012-01-27  6:27               ` Mark H Weaver
2012-01-27  6:19             ` Mark H Weaver
2012-01-27 14:04               ` Bruce Korb
2012-01-27 14:32                 ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87aa56z21j.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=bruce.korb@gmail.com \
    --cc=guile-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).