From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.user Subject: Re: guile-json 0.2.0 released Date: Fri, 5 Apr 2013 08:17:42 +0800 Message-ID: References: <871uaqha98.fsf@taylan.dyndns.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1365121078 26829 80.91.229.3 (5 Apr 2013 00:17:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Apr 2013 00:17:58 +0000 (UTC) Cc: guile-user To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Apr 05 02:18:26 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 1UNuMM-0000Vg-E4 for guile-user@m.gmane.org; Fri, 05 Apr 2013 02:18:26 +0200 Original-Received: from localhost ([::1]:60253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNuLx-0003rT-1B for guile-user@m.gmane.org; Thu, 04 Apr 2013 20:18:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNuLk-0003qQ-Ff for guile-user@gnu.org; Thu, 04 Apr 2013 20:17:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNuLf-0002FG-Ic for guile-user@gnu.org; Thu, 04 Apr 2013 20:17:48 -0400 Original-Received: from mail-ia0-x22b.google.com ([2607:f8b0:4001:c02::22b]:43847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNuLf-0002FA-AD for guile-user@gnu.org; Thu, 04 Apr 2013 20:17:43 -0400 Original-Received: by mail-ia0-f171.google.com with SMTP id z13so2735536iaz.2 for ; Thu, 04 Apr 2013 17:17: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:content-transfer-encoding; bh=Zb4HWLIArmxbD9T7vEm6yDUWeBbh2XuQVW2+d4i3f1o=; b=P9g7XxhVyr7QOsRmVWjm294xYw8HV0c3bgV4i0RjBw/tB3t0WtVGlFdUjJABrxqPeH gK5SpQ6PYhnXIXEZ2ReOOU9NkmR++EhYmUs6GPPhzbJwOg7A4oP1PirN+Z8YgIz2GyEH eyP20SCibVIvwQUm4HMC/LVlE8gWP7OBPdGqYIugbpQnMV/aoxJrikJ4cMbU2WhnzWmf dAcqjfWwuzPTSd8ONw5rqOFOBB7rjOi1r6eMqz5JUbkfc2Tl7ALVaPHzK/fntAB0H4Da VWxgO8YCRi6MFhQ8SfVEfOQyyjqz1bA5kz17f5vS2LdGKGoFWSLwtGU3M6ggyYbz7WBx AwAw== X-Received: by 10.50.195.134 with SMTP id ie6mr244660igc.6.1365121062768; Thu, 04 Apr 2013 17:17:42 -0700 (PDT) Original-Received: by 10.64.26.168 with HTTP; Thu, 4 Apr 2013 17:17:42 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c02::22b 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:10237 Archived-At: On 4 April 2013 20:06, Panicz Maciej Godek wrote: > There are, however, situations, when one wants to have an ordered set, > and it's good to have choice. Clojure, for instance, offers such choice, = and > from the perspective of a programmer it's better to have a choice. > Note that Scheme provides the essential building blocks to create such an ordered map data type. It is rather simple, at most a few dozen lines. Further, you can define the ordering semantics to precisely suit your use case. No doubt for every user of an ordered map they have something else in mind, i.e. insertion-order, key-order, when to perform the ordering (bulk insert followed by sort, or sort as inserted). One of the main distinguishing points of Scheme is that it does not attempt to provide absolutely everything you could ever need ready to use, but instead gives a powerful set of well-defined tools so that you can construct solutions to any problem. >From the perspective of a Schemer, its better to have _tools_. If you want a language where absolutely every feature possible is living in the box ready to go, then you have plenty of choices for those. Rather than just adding feature atop feature, the objective is to isolate the few core functions that truely add utility to the programming environment, then provide those. >> >> > - 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. >> >> That is not what homoiconicity means. There are more data types that >> lack a proper external representation; most notably procedures. For >> transmission of data, converting to an alist and back is probably good >> enough; this can also be used as a "hack" for having "literal" >> dictionaries in code: (alist->dictionary '(...)) >> Hash tables are not just a set of (key, value) pairs, they also include the particular hash and equality procedures that are used with them. These could be arbitrary procedures, and procedures can not generally be converted to a string and back again, so, by extension, neither can hash tables even if you could do that for their content. It would be misleading to provide a write format that appears to be read syntax. > Of course it can. However it's not convenient. I use emacs+geiser and whe= n I > want to see the content of a variable -- if it's a list or some other bas= ic > type -- I just point a cursor on it and I get the value in a minibuffer. > When I want to see the content of hash-table, I need to explicitly evalua= te > (hash-map->list cons my-hash-table), which seems unnecessary When a > hash-table is nested, it turns into a nightmare. So hook your tools to do that automatically when the value at point is a hash table. You can take on the arbitrary performance penalty. Please, no patches to change geisers current behaviour. > On the other hand, what are the argumets against making hash-tables, vect= ors > et al. applicable, assuming that "programming languages should be designe= d > not by piling feature on top of feature, but by removing the weaknesses a= nd > restrictions that make additional features appear necessary"? > Erm, your quote seems to argue against your own position? Any applicable (=E2=80=9Cmessage passing=E2=80=9D) interface is going to wr= ap procedures that perform the lookup, update, etc.. Since those procedures must be present anyway, it is those procedures provided by the Guile API. This is the more natural interface. Again, you have the tools to build a message passing interface from the tools provided. It is a trivial task, but does not add value to the set of tools provided. >> > - 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))) >> Question: what _value_ does that information add to your algorithm? Regards