Re: guile-json 0.2.0 released

[Panicz Maciej Godek <godek.maciek@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7449 bytes --]

2013/4/5 Taylan Ulrich B. <taylanbayirli@gmail.com>


> > 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. :)


Well, actually I was hoping to bring attention of developers :)
After the discussion I agree that ordered hashes aren't so important, but
the printable representation and read syntax for hashes (or at least some
sort of hashes) and unordered sets would be comfortable and I believe it
wouldn't hurt (although Daniel Hartwig in one of this posts' follow-ups
claims that it could be misleading, but I'm not sure if we understood each
other entirely)

> 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?


Well, I don't know how you interpreted that :) If it comes to applicable
objects, then I think that it should remain guile-specific, but it would
harmonize with the spirit of GOOPS. If it comes to syntax/representation of
hash tables, then it is non-standard, but mainly because it's not
standardized -- SRFI-69, which defines hash tables, says nothing about it's
display format, so the implementations are free to choose whichever format
they like. And if it is so, why shouldn't it be a useful and informative
format? And why couldn't it be made in such a way that it could become a
read-syntax at once?

> 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 agree. But Adam Smith would say that it's the market who says what's
right and what's wrong ;)
And when it comes to PHP, it's true that it's an extremely incoherent and
clumsy language, but fortunately it's semantics diverges towards that of
lexically scoped lisps, so php 5.3 allows to create closures. And if it
comes to collections, normal arrays are mixed with associative arrays,
which is sound in a way, because they share a common interface. And they
are way simpler than, for instance, in perl, although (or because) perl
forces a programmer to know what he's doing.

> 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.
>
>
I've read about it even before it became an SRFI draft, at David Wheeler's
website, so I know the idea quite well. When I say about randomness, I'm
not saying that it's not well-defined, but that it's conceptually or
cognitively incoherent. First, there's the idea of having an infix
notation. In a way I can understand it, because we're all educated to write
"two plus two" instead of "add two to two". But once the infix notation is
available, am I obliged to write {2 + 2}, or can I mix it with (+ 2 2)
freely? That's the unnecessary choice that I need to make. But I can
swallow that. However, since the infix notation is available, how will a
common infix expression like {2 * 3 + 4 / 5} behave? As expected? Nope. And
inside curly braces, do round parentheses behave as precedence operators,
or as they behave outside curly braces? And what about curly braces? Let's
look at some examples:
30. {(map - ns)} => (map - ns)
31. {map(- ns)} => (map - ns) as well
Why on earth would anyone want to write {(map - ns)} instead of (map - ns)?
And why is it cooler to write {f{x}} or {f(x)} instead of (f x)? Because it
somehow resembles the notation used by mathematicians? So it's because of
an idol! And why {f{- x}} maps to (f (- x)), while {f (- x)} maps to (f -
x), and not the other way around? And why do I have to remember that?!
I could go on like that. As you can see, a lot of arbitrary choices were
made in this SRFI, which were justified in this way or the other. And I
think that ony a few persons in the world will ever know all of those
justifications. For the remaining ones, reading code that uses "curly
infix" extensively will be a nightmare. Besides, it's so un-scheme if there
are a few people who know better than you how you are going to use the
language -- it would be sufficient if the reader transformed {...} into
(curly ...) or something like that, because then the programmer could
utilize the curly braces any way he wanted to using plain scheme macros,
whether it be an infix notation (either with or without precedence) or list
comprehensions, or lazy evaluation, or function composition, or
currying/binding, or indexing, or whatever.

> 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...


Me too, and that's why I posted this suggestion ;)
From David Wheeler's perspective, the advantage would be that, if he wished
to, he could make numbers also applicable, and have an infix notation in
round parentheses, if that's so important to him. From my perspective, it
would inrease the number of possible usages of langugage, and -- in
particular -- could help with array/hash indexing.

Best regards!
M.

[-- Attachment #2: Type: text/html, Size: 10235 bytes --]