Re: guile-json 0.2.0 released

[Taylan Ulrich B.]

Panicz Maciej Godek <address@hidden> writes:

> Well, I see why the representation based on hash tables is adequate
> for JSON. 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.
>
> [...snip...]
>
> Of course it can. However it's not convenient. I use emacs+geiser and
> when I want to see the content of a variable -- if it's a list or some
> other basic 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 evaluate (hash-map->list cons my-hash-table), which seems
> unnecessary When a hash-table is nested, it turns into a nightmare. If
> there was a more reader-friendly representation of hashes, it would be
> far more convenient. I could come up with some representation myself,
> and use it in my programs, but I guess that this problem is more
> serious and requires more attention.
>
> All in all, you don't write vector->list and list->vector to get a
> nice printable representation of vectors -- there was an issue, and it
> has been solved. Racket has its printable representation of hashes,
> which is much nicer than the one of guile (although still not
> perfect).

How important these matters are is very subjective I guess.  To be
honest, I don't have a strong opinion at all, but was writing what I
believe would be the stance of most Guile developers.  If you believe
these features to be important for the larger Guile user-base, you might
want to bring that to the attention of developers (perhaps already
achieved with these mails), or send patches. :)

> Judging by the speed at which subsequent Reports on algorithmic
> language Scheme are released, schemers don't seem know the word
> "urgent" :) Which is good.
> However, I think it is an important matter. I also think that it is no
> good for scheme implementations to diverge from one another, if there
> is no good reason for that.

Yet you seem to be recommending highly non-standard features.  Or did I
misinterpret something?

> Note that easy-to-use hash tables are what win the market for PHP,
> despite many drawbacks of that language.

What I know about PHP associative-arrays is that they are created by
using the pseudo-function array(), with an alternative syntax, and are
in many ways indistinguishable from normal arrays, which I seem to
remember had bit me already one of the few times I had to use PHP.  As
someone with a generic sense for consistency and orthogonality, I found
all that very distasteful.  If PHP wins "the market" with such an
implementation, then there's probably something wrong with the market.
(There is, indeed, I believe.)

> I know of no other implementation of Scheme than Guile which supports
> SRFI-105. And I guess that the implementators will remain reluctant
> with regard to it, as it introduces more randomness to the way the
> code can be written.

It's a relatively young SRFI.  It's very well-thought-out though in my
opinion, and offers a *generic* solution to the kind of problem you
described.  It doesn't introduce "randomness," it introduces
well-defined extensions to the reader-syntax.  I'd urge you to read it
if you haven't already.

> On the other hand, what are the argumets against making hash-tables,
> vectors et al. applicable, assuming that "programming languages should
> be designed not by piling feature on top of feature, but by removing
> the weaknesses and restrictions that make additional features appear
> necessary"?

I don't have any arguments against that; in fact I just learned what it
means for an object to be applicable.  Seems like a nice idea on the
surface, and I can't think of any immediate draw-backs.  I'm not sure if
it might be confusing to have more than two types of applicable objects
(syntax-keywords and procedures), and I could probably only answer that
question for myself after having written some code using that feature.
Would be interested in hearing other people's opinion on this...

> Plainly, the size is kept in the internal representation of the hash
> table:
>
> typedef struct scm_t_hashtable {
> unsigned long n_items; /* number of items in table */
> ...
>
> cf.
> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/hashtab.
> h;h=82ed22e66eb1f5045793cfc55cca0be040d4aab1;hb=HEAD#l66
>
> It would be really cheap&easy to get it from there. I just wanted to
> show that hash-tables are neglected in Scheme in general, and in Guile
> in particular.

That sounds nasty indeed.  It's late for me today; if no one's quicker
than me, tomorrow I might see that I implement hash-size in C as my
first Guile-contribution. :P

Regards,
Taylan