From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Maciek Godek" Newsgroups: gmane.lisp.guile.user Subject: Re: Me no understand scoping Date: Mon, 11 Aug 2008 00:30:07 +0200 Message-ID: References: <489074A9.1080508@wilsonjc.us> <49dd78620807310020i8b55067gd22f6ce361a04d7d@mail.gmail.com> <49dd78620807311437g7ab367bdxed293a3b8dbd5753@mail.gmail.com> <49dd78620808021043h66f6d953uff37c35d018afb80@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1218407426 7770 80.91.229.12 (10 Aug 2008 22:30:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Aug 2008 22:30:26 +0000 (UTC) Cc: guile-user@gnu.org To: "Andy Wingo" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Aug 11 00:31:16 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KSJRT-0000zv-OO for guile-user@m.gmane.org; Mon, 11 Aug 2008 00:31:16 +0200 Original-Received: from localhost ([127.0.0.1]:38775 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSJQX-0005c6-SM for guile-user@m.gmane.org; Sun, 10 Aug 2008 18:30:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSJQP-0005Zy-M9 for guile-user@gnu.org; Sun, 10 Aug 2008 18:30:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSJQO-0005Zi-QG for guile-user@gnu.org; Sun, 10 Aug 2008 18:30:09 -0400 Original-Received: from [199.232.76.173] (port=52366 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSJQO-0005Zf-JK for guile-user@gnu.org; Sun, 10 Aug 2008 18:30:08 -0400 Original-Received: from wf-out-1314.google.com ([209.85.200.170]:46394) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KSJQO-00014F-9z for guile-user@gnu.org; Sun, 10 Aug 2008 18:30:08 -0400 Original-Received: by wf-out-1314.google.com with SMTP id 28so1589890wfc.24 for ; Sun, 10 Aug 2008 15:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6oGhLZA3MJE3PPiEuVBe9bj1IgERZgzVe/jkVQelok8=; b=ewR92hSxkhxU6puypI89eSTjl2vgLKQulyfQY6dyzpoAlA7Xl7B0tg3IuNftPjPCnk KOW9HiEnfg1pptrvL3rdLZMhqoHeN+rGVQRmlCLxcnUROuoFXdVvzcIHdBcezoJaoaf6 WlpJuQbqVVlTXiqPCn/zNINCL4d1od07Qv0iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=q9mDGM3ir+K0WxTSM9PhChcP0S8/t7yn8WdLvK4szEzlbojHCnDUvwJz4s6E2o5oMu +x84d/8z+qb5u2fScFPFyr94UibWLPJftxI0Ol9LCI5GiEwkmYYFPcQyEX547PbAhA1j x3ayIfUX11wN5DFKX8wD8zmOo9OlGMlKfz2uc= Original-Received: by 10.142.12.18 with SMTP id 18mr1234023wfl.246.1218407407443; Sun, 10 Aug 2008 15:30:07 -0700 (PDT) Original-Received: by 10.142.164.4 with HTTP; Sun, 10 Aug 2008 15:30:07 -0700 (PDT) In-Reply-To: Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6736 Archived-At: Hello Andy! >> [Neil] >>> 1. IMO this could be really beautifully done in GOOPS, by defining >>> custom metaclasses and slot types. >> >> I've been considering that, and I'm still having doubts. >> The main reason is that there's no documented way >> of accessing GOOPS objects from C (except from using >> scm_c_eval_string etc.), or at least I couldn't find any >> documentation for that. > > You can use scm_slot_ref et al. See goops.h. I took a glimpse. The one thing that stinks to me is an immanent inefficiency which comes from the fact that the slots are looked up by their names and therefore aren't accessed directly. (I wrote a follow-up to Neil's post in this thread with an efficient solution) >> Besides (which is the matter of personal taste), I don't >> like the idea of using generics and trashing the global >> namespace with them. (I mean, the sole idea of generics >> is fine, but I wouldn't want to be forced to use them) > [...] >> I'm really trying to get close >> to the classical OOP notation: object.method() -- and >> it's probably why I explore the potential of using these >> "poor man's objects" > > I wrote about this notational issue a while back on my blog, > http://wingolog.org/; I'm offline at the moment, so unfortunately I > don't have a link. Search for "slot-ref". I think with-accessors is an > elegant solution to this problem. I've been looking for such thing for a month or so, it's brilliant (or at least on a good way to be -- I have to examine it in more detail). BTW I'm placing the link here for the others: http://wingolog.org/archives/2008/04/22/object-closure-and-the-negative-specification >> But the point is that I saw that there is a 'make-hash-table' function >> available in lisp -- and this lead me to the conclusion that it's probably >> because the scopes/closures/environments implicitly use hash >> tables to store their bindings (and the same mechanism was given >> explicitly to the programmer). > > This is false. Consider the closure: > > (let ((val 0)) > (lambda () > (set! val (1+ val)) > val)) > > Lexical scoping + closures was one of the fundamental ideas of scheme. > You can analyze this code /lexically/ to determine that we only need to > allocate storage for one variable. Wherever you see `val' in the body of > the lambda, you know /lexically/ that you are referring to a location > that is one step out in the stack frame, and the 0th location in that > frame, the frame created by `let'. So there is no need to store the > name, "val", at all! [...] > Do you see now why local-eval can't possibly work in the presence of > efficient compilation? Scheme does not give you the particular kind of > dynamism that you want. There is no hash table lurking inside a closure. Yeah, you've convinced me. I was stupid and irresponsible but now I can see clearly why local-eval shouldn't be abused. > On the other hand, modules do have hash tables, and modules are > evaluation environments; and they have been treated in some literature > as closures. Perhaps consider using modules as your first-class objects? Thanks a lot, I think it was the second thing I've been looking for. I'll read some more on that. >> And so I never stopped to believe that (define x 5) is more or >> less equivalent to (hash-set! global-scope 'x 5). > > At the top level it is; but s/global-scope/the current module/. > But internal defines are completely different. I've heard that in current implementation of guile they are only different in that they are not storing data in hash-tables but in assoc lists :) (That's what Ludovic says) Thanks a lot M.