Re: Automatically sort alist grob-properties in IR. (issue 102760044)

[dak]

On 2014/05/28 06:07:28, Mark Polesky wrote:

https://codereview.appspot.com/102760044/diff/1/scm/document-backend.scm
> File scm/document-backend.scm (right):


https://codereview.appspot.com/102760044/diff/1/scm/document-backend.scm#newcode22
> scm/document-backend.scm:22: (apply eq? #t (map pair? x))))
> On 2014/05/28 00:00:58, dak wrote:
> > (apply eq? #t (map pair? x)) is horribly contorted and subject
> > to limitations in argument list length.  Use (every pair? x)
> > which has the advantage of short-circuit evaluation.

> Ah, that's the procedure I was looking for, thanks!  Sorry, I didn't
know about
> that one.

> > Also, it seems like a stretch to assume that every list with
> > pair members will tolerate sorting.

> Do you mean that
> 1) the order of keys in some alists may be significant?

An alist is not an opaque data structure.  It is a list structure that
is *used* as an alist.  There are list structures that are not intended
to be an alist which perfectly well meet the definition of an alist.
For example,
'((lambda (a b c) (+ a (- b c))) (+ 3 4) (- 1 2) (/ 4 5))
is an alist with keys lambda, +, -, / and values ((a b c) (+ a (- b
c))), (3 4), (1 2) and (4 5), but you'll likely rather regard it as a
quoted expression evaluating to 26/5.

What you may be considering an alist is not necessarily one.

> > You do not even restrict this to lists with symbols in the car
> > and explicitly sort lists with non-symbols.
> > That seems like a bad idea.

> Not trying to be annoying (really), but why?

> https://codereview.appspot.com/102760044/diff/1/scm/lily-sort.scm
> File scm/lily-sort.scm (right):


https://codereview.appspot.com/102760044/diff/1/scm/lily-sort.scm#newcode112
> scm/lily-sort.scm:112: ((and (number? (car a)) (number? (car b)))
> On 2014/05/28 00:00:58, dak wrote:
> > Can you point to any "alists" where the keys are numbers?  This
seems rather
> > fishy to me.

> Accidental.glyph-name-alist:
> '((0 . accidentals.natural)
>    (-1/2 . accidentals.flat)
>    (1/2 . accidentals.sharp)
>    (1 . accidentals.doublesharp)
>    (-1 . accidentals.flatflat)
>    (3/4 . accidentals.sharp.slashslash.stemstemstem)
>    (1/4 . accidentals.sharp.slashslash.stem)
>    (-1/4 . accidentals.mirroredflat)
>    (-3/4 . accidentals.mirroredflat.flat))

This one is a good counterexample for a different reason.  You _are_
aware that access to an alist element takes execution time proportional
to its position in the list?  There is a reason this kind of alist is
sorted with the most frequently accessed elements placed at the front.
So we don't want a different order in execution, and if you try
following the actions of the code while looking at the IR (it's called
"internals" for a reason), you'll get puzzled.

> Finally, for what it's worth, here's the list of all alist
grob-properties:
> http://www.markpolesky.com/norobots/alist-grob-properties.txt

Containing MetronomeMark.round-up-exceptions which is not an alist.
More seriously, when any properties are added later on that happen to
match your alist? test by accident, they'll get sorted, leading to quite
confusing entries.

Also when debugging, it will be _totally_ confusing if the data does not
correspond with the actual content.  If you consider alphabetic sorting
important for whatever reason for some properties and the performance
characteristics of the use case don't speak against it, it makes more
sense to sort the actual definitions rather than make a diverging
representation of the properties in the IR.

https://codereview.appspot.com/102760044/