From: taylanbayirli@gmail.com (Taylan Ulrich B.)
To: Panicz Maciej Godek <godek.maciek@gmail.com>
Cc: guile-user <guile-user@gnu.org>
Subject: Re: guile-json 0.2.0 released
Date: Fri, 05 Apr 2013 00:21:51 +0200 [thread overview]
Message-ID: <8738v63pj4.fsf@taylan.dyndns.org> (raw)
In-Reply-To: <CAMFYt2bLWKj26oe1USKe_77UHrj50Pj2MsGEJMxSRG0mPew68Q@mail.gmail.com> (Panicz Maciej Godek's message of "Thu, 4 Apr 2013 14:06:50 +0200")
Panicz Maciej Godek <godek.maciek@gmail.com> 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
next prev parent reply other threads:[~2013-04-04 22:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 7:08 guile-json 0.2.0 released Aleix Conchillo Flaqué
2013-04-04 9:11 ` Panicz Maciej Godek
2013-04-04 10:15 ` Taylan Ulrich B.
2013-04-04 12:06 ` Panicz Maciej Godek
2013-04-04 22:21 ` Taylan Ulrich B. [this message]
2013-04-04 22:59 ` Aleix Conchillo Flaqué
2013-04-05 7:35 ` Panicz Maciej Godek
2013-04-04 23:39 ` Daniel Hartwig
2013-04-07 11:40 ` Panicz Maciej Godek
2013-04-07 20:38 ` Taylan Ulrich B.
2013-04-08 1:51 ` Daniel Hartwig
2013-04-08 2:11 ` Daniel Hartwig
2013-04-05 0:17 ` Daniel Hartwig
2013-04-05 2:47 ` Noah Lavine
2013-04-05 9:35 ` Daniel Hartwig
2013-04-05 13:18 ` Noah Lavine
2013-04-05 9:41 ` Panicz Maciej Godek
[not found] ` <CAPjoZodAaHLfPGb+XiUhoMJD7J4_kYrjRmYP+p1S5w5yuPgLEg@mail.gmail.com>
[not found] ` <CAPjoZoc12W4usGnkwSZG2zNqe8xF6C4hWWZgq+-Nc8HMg_Xw4Q@mail.gmail.com>
2013-04-04 15:11 ` Nala Ginrut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8738v63pj4.fsf@taylan.dyndns.org \
--to=taylanbayirli@gmail.com \
--cc=godek.maciek@gmail.com \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).