Re: guile-json 0.2.0 released

[Daniel Hartwig]

On 4 April 2013 20:06, Panicz Maciej Godek <address@hidden> wrote:
> 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.
>

Note that Scheme provides the essential building blocks to create such
an ordered map data type.  It is rather simple, at most a few dozen
lines.  Further, you can define the ordering semantics to precisely
suit your use case.  No doubt for every user of an ordered map they
have something else in mind, i.e. insertion-order, key-order, when to
perform the ordering (bulk insert followed by sort, or sort as
inserted).

One of the main distinguishing points of Scheme is that it does not
attempt to provide absolutely everything you could ever need ready
to use, but instead gives a powerful set of well-defined tools so
that you can construct solutions to any problem.

>From the perspective of a Schemer, its better to have _tools_.  If you
want a language where absolutely every feature possible is living in
the box ready to go, then you have plenty of choices for those.


Rather than just adding feature atop feature, the objective is to
isolate the few core functions that truely add utility to the
programming environment, then provide those.


>>
>> > - secondly, there is no default notation to create hash tables nor
>> > sets; using them forces
>> > a programmer to drop homoiconicity, as their default print
>> > representation is #<hash-table 1c8a940 1/31> or something even uglier.
>> > I think that this is done properly in Clojure.
>>
>> That is not what homoiconicity means.  There are more data types that
>> lack a proper external representation; most notably procedures.  For
>> transmission of data, converting to an alist and back is probably good
>> enough; this can also be used as a "hack" for having "literal"
>> dictionaries in code: (alist->dictionary '(...))
>>

Hash tables are not just a set of (key, value) pairs, they also
include the particular hash and equality procedures that are used with
them.  These could be arbitrary procedures, and procedures can not
generally be converted to a string and back again, so, by extension,
neither can hash tables even if you could do that for their content.

It would be misleading to provide a write format that appears to be
read syntax.

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

So hook your tools to do that automatically when the value at point is
a hash table.  You can take on the arbitrary performance penalty.
Please, no patches to change geisers current behaviour.

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

Erm, your quote seems to argue against your own position?

Any applicable (“message passing”) interface is going to wrap
procedures that perform the lookup, update, etc..  Since those
procedures must be present anyway, it is those procedures provided by
the Guile API.  This is the more natural interface.

Again, you have the tools to build a message passing interface from
the tools provided.  It is a trivial task, but does not add value to
the set of tools provided.

>> > - lastly, guile's support for hash tables is limited -- there ain't
>> > even a built-in function that would return the size of a hash-table.
>> > My implementation is inefficient (linear time), and it looks like
>> > this:
>> > (define (hash-size hash-map)
>> > (length (hash-values hash-map)))
>>

Question: what _value_ does that information add to your algorithm?


Regards