From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user Subject: Re: guile-json 0.2.0 released Date: Thu, 4 Apr 2013 11:11:41 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bf19894ddfbf304d9855bab X-Trace: ger.gmane.org 1365066723 26694 80.91.229.3 (4 Apr 2013 09:12:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Apr 2013 09:12:03 +0000 (UTC) Cc: guile-user To: =?ISO-8859-1?Q?Aleix_Conchillo_Flaqu=E9?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Apr 04 11:12:29 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UNgDc-0005fw-VH for guile-user@m.gmane.org; Thu, 04 Apr 2013 11:12:29 +0200 Original-Received: from localhost ([::1]:41482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNgDE-0001sv-02 for guile-user@m.gmane.org; Thu, 04 Apr 2013 05:12:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNgCz-0001sX-MJ for guile-user@gnu.org; Thu, 04 Apr 2013 05:11:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNgCt-0001Mw-DD for guile-user@gnu.org; Thu, 04 Apr 2013 05:11:49 -0400 Original-Received: from mail-wg0-f47.google.com ([74.125.82.47]:43622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNgCt-0001Mn-3J for guile-user@gnu.org; Thu, 04 Apr 2013 05:11:43 -0400 Original-Received: by mail-wg0-f47.google.com with SMTP id y10so2413024wgg.2 for ; Thu, 04 Apr 2013 02:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y6qFF1tPEqtfu25Oaf4r7aO44pt6kbdBbqj6pNyBz8w=; b=CiBumOmUAo87GGUm+Ge8SMNQRZbcjHJalrrWUcconwO0Htq6n3B54XmqXoWGHBSQHp lgiikXAZRzAMoPd8MmSZYEO94k1Z/2TGxzO3oCqW+tBNWC6KQjI3sUV3q5rWCEZAzH+Y KeykNopKYc2Ay047cgeyJc9pCs0qvFVW6AYqV8XjNh/OzAfFKdLgShGaeJgw9TbKmdUD CjhI6z7KtuG5HiQW3komkMMpg2y+p9BSIshNgjJw/ac4jTN3k9/a+WmCgAp9KjpgqlRT dm+XhwGdfmYqJL/kUVb66y3nw2Sj5xTgTIqUjYIQVQ45YOHGD6wfRfZCuzhng54LzijE YOlQ== X-Received: by 10.194.89.169 with SMTP id bp9mr8068990wjb.57.1365066701991; Thu, 04 Apr 2013 02:11:41 -0700 (PDT) Original-Received: by 10.194.60.100 with HTTP; Thu, 4 Apr 2013 02:11:41 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.125.82.47 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10228 Archived-At: --047d7bf19894ddfbf304d9855bab Content-Type: text/plain; charset=ISO-8859-1 Hi! I'm glad that you've made a great piece of work to integrate guile with the rest of the world. I see you implemed it using guile's hash tables and lists, which seems sound. The problem lies within the way guile deals with hash tables. Actually, there are several problems that need to be addressed: - firstly, guile's hash tables are maps, not dictionaries, so they are insensitive to order. This behaviour is desired if we want to use them to represent sets or maps; however, PHP arrays, and -- as I presume -- JavaScript objects -- store the information about the order of their elements. Lisp-style sollution would be to store them as assoc lists, which in turn have linear access time. - secondly, there is no default notation to create hash tables nor sets; using them forces a programmer to drop homoiconicity, as their default print representation is # or something even uglier. I think that this is done properly in Clojure. - thirdly, refering to hashes (as well as assoc lists, goops' object slots, vector/array elements) is truly cumbersome. I once wrote a hash-read-extension that allowed to refer to hashes/arrays/slots... using uniform notation #[object key], and to allow for nested references like #[ ... #[#[object key1] key2 ] ... ] using simpified notation #[object : key1 : key2 : ... ]. The implementation is rather inefficient when it comes to performance, but makes coding much more efficient, and it can be found here, if anyone's interested: https://bitbucket.org/panicz/slayer/src/33cf0116da95dea6928ab1011994569b5a5181ad/extra/ref.scm?at=goose-3d One could ask: why can't vectors, arrays, objects and hashes simply be applicable? (Of course, it is possible to implement applicable collections even now, but at a cost of loosing their print representation) I think the issue with applicable goops objects emerged before, when someone wanted to implement python in guile, and wanted to provide a __call__ metod. - lastly, guile's support for hash tables is limited -- there ain't even a built-in function that would return the size of a hash-table. My implementation is inefficient (linear time), and it looks like this: (define (hash-size hash-map) (length (hash-values hash-map))) Some time ago I saw here someone who was using the print representation of a hash-table to read the number of its elements, but it seems like a nasty hack, and it stopped working once the print representation changed. Sorry if I was a little off topic :) Be the avant-garde! M. --047d7bf19894ddfbf304d9855bab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!
I'm glad that you've made a great pi= ece of work to integrate guile with the rest of the world. I see you implem= ed it using guile's hash tables and lists, which seems sound.
The problem lies within the way guile deals with hash tables. Actually, the= re are several problems that need to be addressed:

- firstly, guile's hash tables are maps, not dictionaries,= so they are insensitive to order. This behaviour is desired if we want to = use them to represent sets or maps; however, PHP arrays, and -- as I presum= e -- JavaScript objects -- store the information about the order of their e= lements. Lisp-style sollution would be to store them as assoc lists, which = in turn have linear access time.

- secondly, there is no default notation to= create hash tables nor sets; using them forces
a programme= r to drop homoiconicity, as their default print representation is #<hash= -table 1c8a940 1/31> or something even uglier. I think that this is done= properly in Clojure.

- thirdly, refering to hashes (as well as a= ssoc lists, goops' object slots, vector/array elements) is truly cumber= some. I once wrote a hash-read-extension that allowed to refer to hashes/ar= rays/slots... using uniform notation #[object key], and to allow for nested= references like #[ ... #[#[object key1] key2 ] ... ] using simpified notat= ion #[object : key1 : key2 : ... ]. The implementation is rather inefficien= t when it comes to performance, but makes coding much more efficient, and i= t can be found here, if anyone's interested:
One could ask: why can't vectors, arrays, objects and = hashes simply be applicable? (Of course, it is possible to implement applic= able collections even now, but at a cost of loosing their print representat= ion)

I think the issue with applicable goops obj= ects emerged before, when someone wanted to implement python in guile, and = wanted to provide a __call__ metod.

- lastly, guile's support for hash tables is limited -- there ain't= even a built-in function that would return the size of a hash-table. My im= plementation is inefficient (linear time), and it looks like this:
(define (hash-size hash-map)
=A0 (length (hash-va= lues hash-map)))

Some time ago I saw here so= meone who was using the print representation of a hash-table to read the nu= mber of its elements, but it seems like a nasty hack, and it stopped workin= g once the print representation changed.

Sorry if I was a little off topic :)
<= div style>Be the avant-garde!
M.

=
--047d7bf19894ddfbf304d9855bab--