Re: Fret-diagram properties refactoring

[Carl Sorensen]

Carl D. Sorensen <c_sorensen <at> byu.edu> writes:

> As a temporary work-around, would it be OK for me to move all of the
> fret-diagram specific properies into a fret-diagram-details property,
> and document them all under fret-diagram-details in
> define-grob-properties.scm?

OK, so I _finally_ got around to trying this change, and I ran into a major
roadblock.  As you may recall, the plan was to make a property
fret-diagram-details whose value would be an alist, and then I could retreive
the details and handle them using the same routines we use on props.  The
problem ...

Alist values in Scheme must be atoms, they can't be lists.  An alist is defined
as '((Key1 . Value1) (Key2 . Value2) (Key3 . Value3))

So I can't define a property fret-diagram-details whose value is an alist. 
Actually, I can define that property, but I can't get the property value out,
because it doesn't recognize the "pair"

'(fret-diagram-details . ((prop1 . val1) (prop2 . val2))) as a pair.

Instead, Scheme recognizes it as a list

'(fret-diagram-details (prop1 . val1) (prop2 . val2))

which is _not_ an alist.

I've tried everything I can think of, without success, to use a list as the
"value" part of an alist-pair.  I think it won't work.

Any suggestions on (a) how to make this work, or (b) another method of defining
subproperties that will allow us to move the fret-diagram specific properties
out of the general namespace?  I think that a wholesale redefinition of props to
a hash table, rather than an alist, would work, but that would be a _major_ job.

I'd certainly welcome any help that any of you can give me.  I'm stumped.

Carl