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/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
