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!