From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: unknown location: definition in expression context in subform optname-from of "_^" Date: Sat, 28 Jan 2012 23:12:28 -0500 Message-ID: <878vkrkuz7.fsf@netris.org> References: <4F20CEE7.4000403@gmail.com> <1327551746.85660.YahooMailNeo@web37907.mail.mud.yahoo.com> <4F21BFFC.8040300@gmail.com> <87d3a6ovhs.fsf@netris.org> <4F21F635.4020404@gmail.com> <8762fxq3rr.fsf@netris.org> <4F220F84.5090601@gmail.com> <4F221BD3.8090105@gmail.com> <87r4ykl36k.fsf@netris.org> <87obtnzm2p.fsf@pobox.com> <87d3a3lid6.fsf@netris.org> <87k44bzb7l.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327810418 15258 80.91.229.3 (29 Jan 2012 04:13:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 29 Jan 2012 04:13:38 +0000 (UTC) Cc: Bruce Korb , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jan 29 05:13:37 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RrM93-0003Mv-9B for guile-devel@m.gmane.org; Sun, 29 Jan 2012 05:13:37 +0100 Original-Received: from localhost ([::1]:45327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrM92-0003iL-2H for guile-devel@m.gmane.org; Sat, 28 Jan 2012 23:13:36 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:37313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrM8z-0003iG-Ry for guile-devel@gnu.org; Sat, 28 Jan 2012 23:13:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrM8y-0003xZ-Hu for guile-devel@gnu.org; Sat, 28 Jan 2012 23:13:33 -0500 Original-Received: from world.peace.net ([96.39.62.75]:51524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrM8y-0003xV-Ag for guile-devel@gnu.org; Sat, 28 Jan 2012 23:13:32 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RrM8s-0003YL-7W; Sat, 28 Jan 2012 23:13:26 -0500 In-Reply-To: <87k44bzb7l.fsf@pobox.com> (Andy Wingo's message of "Sat, 28 Jan 2012 23:58:06 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13727 Archived-At: Andy Wingo writes: > On Sat 28 Jan 2012 20:47, Mark H Weaver writes: >> Andy Wingo 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