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: [PATCH] Improved source properties and errors; => within case Date: Wed, 08 Feb 2012 11:16:40 -0500 Message-ID: <87bop98fmf.fsf@netris.org> References: <87haz18zet.fsf@netris.org> <87fwel1vxr.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1328717925 5646 80.91.229.3 (8 Feb 2012 16:18:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Feb 2012 16:18:45 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 08 17:18:44 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 1RvAEB-0001qq-9D for guile-devel@m.gmane.org; Wed, 08 Feb 2012 17:18:39 +0100 Original-Received: from localhost ([::1]:43829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvAEA-0006Fm-PX for guile-devel@m.gmane.org; Wed, 08 Feb 2012 11:18:38 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:44242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvADz-0006FY-AV for guile-devel@gnu.org; Wed, 08 Feb 2012 11:18:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvADq-0001e3-Il for guile-devel@gnu.org; Wed, 08 Feb 2012 11:18:27 -0500 Original-Received: from world.peace.net ([96.39.62.75]:50648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvADq-0001dd-3T for guile-devel@gnu.org; Wed, 08 Feb 2012 11:18:18 -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.72) (envelope-from ) id 1RvADf-0000JI-Jz; Wed, 08 Feb 2012 11:18:08 -0500 In-Reply-To: <87fwel1vxr.fsf@pobox.com> (Andy Wingo's message of "Wed, 08 Feb 2012 11:06:08 +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:13826 Archived-At: Hi Andy, thanks for the quick review! Andy Wingo writes: > Patch set looks good to me. Please push. Great, thanks! Of course I'll fix the following issues first. > On Wed 08 Feb 2012 10:09, Mark H Weaver writes: > >> The way that source properties are stored means that Guile can only >> -associate source properties with parenthesized expressions, and not, for >> -example, with individual symbols, numbers or strings. The difference >> -can be seen by typing @code{(xxx)} and @code{xxx} at the Guile prompt >> -(where the variable @code{xxx} has not been defined): >> +associate source properties with parenthesized expressions and non-empty >> +strings, and not, for example, with individual symbols or numbers. The >> +difference can be seen by typing @code{(xxx)} and @code{xxx} at the >> +Guile prompt (where the variable @code{xxx} has not been defined): > > This isn't quite right; #*101010101 should probably get source info, no? Yes, and indeed this patch _does_ add source info for bitvectors, but I forgot to mention that in the doc. I'll fix it. > And is it useful to have an exception for empty strings? I would think > that it would be fine to return fresh empty strings. The compiler would > DTRT. I don't care much though. Currently 'read' returns the shared global 'scm_nullstr' for empty strings. We could remove that optimization though. Maybe we should. What do you think? > Perhaps: "Everything but numbers, symbols, characters, and booleans get > source information." Dunno. and keywords, and maybe some other things we're forgetting. Good idea. Another option is to explain it in terms of the core problem: only types for which 'read' reliably returns a fresh object can have source properties. I'll think on this some more. >> + (syntax-case whole-expr () >> + ((_ clause clauses ...) >> + #`(begin > > (This is in `cond'). Why is the begin needed here? It's needed because the 'loop' returns a _list_ of expressions (of length zero or one), to enable more graceful handling of the base case. The outer 'loop' is guaranteed to return a list of length one, so I need to either take the 'car' or wrap it in a 'begin'. >> + #`((let ((t test)) >> + (if t t #,@tail))))) > > Use `or' here. I can't, because if it's the last clause, 'tail' will be '(), which would generate (or test) which would be incorrect. (or test) would return #f is 'test' is false, but we actually want to return *unspecified* in that case. >> + (syntax-case whole-expr () >> + ((_ expr clause clauses ...) >> + (with-syntax ((key #'key)) >> + #`(let ((key expr)) >> + #,@(fold > > (In `case'.) Likewise here, it would be good to avoid this use of an > implicit `begin', of possible. Hmm. I don't know if this is what you meant, but it occurs to me that as I've currently implemented them, both (cond (else (define x 5) x)) and (case 1 (else (define x 5) x)) are allowed. I'll have to make sure that those raise errors. I guess that means I'll have to insert a '#f' like I did for local-eval. Do you see a better way? Thanks! Mark