[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Build failure with Scheme (again)

From: Carl D. Sorensen
Subject: RE: Build failure with Scheme (again)
Date: Sat, 26 Apr 2008 08:03:56 -0600

> -----Original Message-----
> From: Nicolas Sceaux [mailto:address@hidden
> Sent: Saturday, April 26, 2008 3:49 AM
> To: address@hidden
> Cc: lily-devel; Mats Bengtsson
> Subject: Re: Build failure with Scheme (again)
> Le 26 avr. 08 à 04:28, Han-Wen Nienhuys a écrit :
> > It would be cool if we could define the markups like
> >
> > (define-markup-command (bla layout properties width arg) (number?
> > markup?)
> >   ((line-thickness 0.0)
> >    (corner-radius 0.2))
> >
> >  ..
> > )
> >
> > where this defines that the bla command uses line-thickness and
> > corner-radius, and automatically extracts them from properties.   We
> > could then annotate the bla command automatically.
> >
> >
> > Nicolas, what do you think?
> (0.0 and 0.2 would be default values, in case the property
> are not already defined?)
> nicolas

This is a cool idea.  I like the fact that it gives a good way to document the 
default values of the properties, and it lets us define the properties that are 

This gets rid of two of the major problems with fret-diagrams properties.  
There remains only the third.  In order to preserve the global namespace (as 
well as to make overrides more convenient) we moved to fret-diagram-details as 
the primary property for fret diagrams, with all the other properties residing 
inside the details.  Under this syntax, the value of fret-diagram-details would 
show up as a big alist.  Coupled with the documentation of the individual 
elements of fret-diagram details which is in the docstring for the 
fret-diagram-interface, I think this would automatically create documentation 
that (a) described each of the properties, and (b) listed the default value for 
each of the properties.

One concern I have is that if we are going to move to this syntax, we need to 
develop some mechanism for ensuring that the defaults in the definition are 
actually used in the body of the markup command.  Perhaps the defaults in the 
definition are put into a default-props alist, so we can get values by 
something like

(let myprop (chain-assoc-get props 'myprop (chain-assoc-get default-props 
'myprop ())))

We really don't want to be declaring default values in the definition, then 
assigning different default values in the body.

Carl Sorensen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]