From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.user Subject: Re: guile-json 0.2.0 released Date: Fri, 5 Apr 2013 09:18:09 -0400 Message-ID: References: <871uaqha98.fsf@taylan.dyndns.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec53042e354530904d99cec25 X-Trace: ger.gmane.org 1365278560 28723 80.91.229.3 (6 Apr 2013 20:02:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Apr 2013 20:02:40 +0000 (UTC) Cc: Guile Mailing List To: Daniel Hartwig Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Apr 06 22:02:40 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 1UOZJp-00023j-TV for guile-user@m.gmane.org; Sat, 06 Apr 2013 22:02:34 +0200 Original-Received: from localhost ([::1]:46909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UO6XX-0000KY-K3 for guile-user@m.gmane.org; Fri, 05 Apr 2013 09:18:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UO6XK-0000KB-NG for guile-user@gnu.org; Fri, 05 Apr 2013 09:18:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UO6XH-00044m-3U for guile-user@gnu.org; Fri, 05 Apr 2013 09:18:34 -0400 Original-Received: from mail-pa0-f51.google.com ([209.85.220.51]:48282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UO6XG-00044Z-QT for guile-user@gnu.org; Fri, 05 Apr 2013 09:18:31 -0400 Original-Received: by mail-pa0-f51.google.com with SMTP id jh10so2025560pab.24 for ; Fri, 05 Apr 2013 06:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=eVrsMvRVUP/mNckX3iHAEAUoLIEu6eq0Z/jrroksejE=; b=kDSqnK05+oFfDkExfPTBYXqp9p+7aZiYBVbEQ6IE7GTxgl/rUoYzmHFsCAGW5VYug5 wk81pBbVrRtP4jTDXvkrRldhcjk0YIDydnqEc3Y8KitTrkuZuUaEGsUT8B6AMz/U9GWV uIm9485N2MoVhgu3LjtNJtzPDbSr4qMbejqdzKGiw+6TX537FdKv5pSxRBlXpN75bK+m AbEn0cAeVosEiyAIZDwhVwwozYU2Ea7BR2rl5lSRj+ccnUZr/hQ6EZB0gJS15svlTLe/ yo4hm51+CnYMVY+YObJ5vKLqamzUk+Trv4cx33gPK5niN/tL/+ShNoZmuo4PsiKT5Wv+ nj5g== X-Received: by 10.68.1.231 with SMTP id 7mr14390897pbp.124.1365167909914; Fri, 05 Apr 2013 06:18:29 -0700 (PDT) Original-Received: by 10.68.157.42 with HTTP; Fri, 5 Apr 2013 06:18:09 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: Az_HGemYMbXKPJe1X1afnjT18_M X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.51 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:10241 Archived-At: --bcaec53042e354530904d99cec25 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Fri, Apr 5, 2013 at 5:35 AM, Daniel Hartwig wrote: > > On 05/04/2013 10:47 AM, "Noah Lavine" wrote: > > Although hash tables in general do include arbitrary procedures, in > Guile's implementation there are only three to choose from, so it should be > possible to represent them in syntax. > > > I think you miss the hashx procedures. > Yes, you're right. My mistake. > > For exactly this reason, I believe that actually "hash table" is a bad > name for the data structure. I think of Guile's hash tables as a generic > dictionary structure with average O(1)-time lookup, insertion and deletion. > > Where do you get your definition of 'hash table' that the guile type does > not apply? > That was a bad way to put it. I think of the Guile type as defined by an interface, not a particular implementation, so I think "dictionary" is better than "hash table". But it certainly is a hash table on the inside. > > In the rare case, when dictionary lookups are time- or space-critical > and must be optimized, *then* it's worth it to design custom hash functions > and implement hash tables from vectors and similar things. > > That's what the current data type is anyway, and can be used with custom > hash? I'm not sure I follow the distinctions you are making. > I may have explained it poorly last time. I agree that in general, there are many different variants on a hash table, and as you say, they cannot all be written down easily - you can have different hash procedures, different ways to handle collisions, and different policies on when to grow and shrink the table (and maybe more things). However, I think that it's worth having a printed representation for one particular sort of hash table, even though that privileges one sort of hash table over another, because it makes things very convenient in the common case where you don't care about performance enough to customize your hash table. In the performance-critical case, where you are customizing the features of your hash, you can write a custom serializer too. Basically, I think that while it is impossible to serialize all of the things meant by "hash table", it is worthwhile to have a syntax form that means "I want to store these objects in a hash-like dictionary structure, and I don't need to worry too much about performance." I think the gain in convenience is large, and the case where you can't use this is pretty rare. Best, Noah --bcaec53042e354530904d99cec25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

On Fri, Apr 5, 2013 at 5:35 AM, Daniel Hartwig = <mandyke@gmail.co= m> wrote:


On 05/04/2013 10:47 AM, "Noah Lavine" <noah.b.lavine@gmail.com> wrote= :
> Although hash tables in general do include arbitrary procedures, in Gu= ile's implementation there are only three to choose from, so it should = be possible to represent them in syntax.
>

I think you miss the hashx procedures.

<= /div>
Yes, you're right. My mistake.

> For exactly this reason, I believe that actually "hash table&q= uot; is a bad name for the data structure. I think of Guile's hash tabl= es as a generic dictionary structure with average O(1)-time lookup, inserti= on and deletion.

Where do you get your definition of 'hash table' that the = guile type does not apply?

That was a bad way to put i= t. I think of the Guile type as defined by an interface, not a particular i= mplementation, so I think "dictionary" is better than "hash = table". But it certainly is a hash table on the inside.

> In the rare case, when dictionary lookups are time- or space-critic= al and must be optimized, *then* it's worth it to design custom hash fu= nctions and implement hash tables from vectors and similar things.

That's what the current data type is anyway, and can be used w= ith custom hash?=A0 I'm not sure I follow the distinctions you are maki= ng.

I may have explained it poorly last time. I agree that i= n general, there are many different variants on a hash table, and as you sa= y, they cannot all be written down easily - you can have different hash pro= cedures, different ways to handle collisions, and different policies on whe= n to grow and shrink the table (and maybe more things). However, I think th= at it's worth having a printed representation for one particular sort o= f hash table, even though that privileges one sort of hash table over anoth= er, because it makes things very convenient in the common case where you do= n't care about performance enough to customize your hash table. In the = performance-critical case, where you are customizing the features of your h= ash, you can write a custom serializer too.

Basically, I think that while it is im= possible to serialize all of the things meant by "hash table", it= is worthwhile to have a syntax form that means "I want to store these= objects in a hash-like dictionary structure, and I don't need to worry= too much about performance." I think the gain in convenience is large= , and the case where you can't use this is pretty rare.

Best,
Noah

--bcaec53042e354530904d99cec25--