|From:||Panicz Maciej Godek|
|Subject:||Re: guile-json 0.2.0 released|
|Date:||Sun, 7 Apr 2013 13:40:48 +0200|
> 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 itHow important these matters are is very subjective I guess. To be
> has been solved. Racket has its printable representation of hashes,
> which is much nicer than the one of guile (although still not
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 algorithmicYet you seem to be recommending highly non-standard features. Or did I
> 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.
> Note that easy-to-use hash tables are what win the market for PHP,What I know about PHP associative-arrays is that they are created by
> despite many drawbacks of that language.
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 supportsIt's a relatively young SRFI. It's very well-thought-out though in my
> 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.
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,I don't have any arguments against that; in fact I just learned what it
> 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
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...
|[Prev in Thread]||Current Thread||[Next in Thread]|