Re: guile-json 0.2.0 released

[taylanbayirli@gmail.com (Taylan Ulrich B.)]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:
> I agree. But Adam Smith would say that it's the market who says what's
> right and what's wrong ;)

I don't know Adam Smith, but I know that I disagree with this particular
quote, at least at face value.  I will continue to disregard adoption
rates while considering a programming language as a role-model.  The
reasons for that are way beyond the scope of this discussion I'm afraid.

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

I don't intend to discuss the usefulness of SRFI-105 in general, but it
offers a relatively clean solution to the problem you mentioned, so I
see no reason not to use it to solve that problem.  {object[key]} does
not look much worse than e.g. #[object key] (and {object[key][key]}
looks better than #[[object key] key] IMO), is already implemented in
Guile, and actually has a chance to become standard.

I would use SRFI-105 for now, and/or depending on how important it is to
me, would work on a good general interface for making applicable objects
in Guile.