[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A few questions regarding markup
Re: A few questions regarding markup
Sun, 15 Nov 2009 22:02:16 -0700
On 11/14/09 1:29 AM, "David Kastrup" <address@hidden> wrote:
> Ok, I am digging through harp-pedals.scm and looking at
> Now from the definition of define-builtin-markup-command it looks to me
> like you can specify default properties and those are let to the
> specified default values (#f if unspecified) or the respective
> properties from the list.
> Now the harp-pedal command defines the property signature
> ((size 1.0)
> (thickness 0.5))
The property signature is a documentation-only convention. It has no
functionality except for producing documentation. To the extent that
it is inconsistent with the defaults in chain-assoc-get, it is in error.
> So far, so fine. It
> then calls make-harp-pedal without passing it those let-bound
> variables. As far as I understand Scheme and its closures, this means
> that the defaults specified in this manner are ignored.
Yes -- the defaults aren't really specified with the property signature;
they're simply documented.
> make-harp-pedal then starts off with
> (let* ((size (chain-assoc-get 'size props 1.2))
> (details (chain-assoc-get 'harp-pedal-details props '()))
> Which looks rather like defaulting to a size of 1.2 if none is
> specified, conflicting with the documented default value which is
Yes, that is correct.
> That does not really make much sense.
> Is my understanding of the code correct so far?
> Now there are several possible remedies I can see.
> a) don't use chain-assoc-get in this manner, consistently. Instead pass
> everything from the defined markup function into the helper function
> explicitly, as extra arguments. This would involve fixing the current
> definition of harp-pedal and its helpers. The ultimate solution would
> be to never even pass props on, but rather only the defaults picked from
> it. Advantage would be that the documentation would be consistent with
> declaring which values are possibly used with which defaults, no white
> lies permitted. Disadvantage is maintenance of the passed argument list
> with possibly many values, from all defined markup commands.
But all the default values can be overridden by properties that are set
elsewhere in the code. And we don't want to add defaults to the call, in
case there are values added to props.
chain-assoc-get is, in my opinion, a very nice mechanism for handling
default values and keeping the code from breaking/segfaulting if the props
list gets messed up. I would not be in favor of modifying the
> b) fixup props also by let-binding, binding the default values to the
> end of the property chain. This requires a copy of the property chain.
> Consing overhead. Disadvantage is that access to the fixed property
> chain can access values not declared in the documentation.
I guess this is possible, but I don't really like the overhead.
> c) fixup props by let-binding, binding any undefined default values to
> the start of the property chain. No copying overhead, but lookup
> overhead. But could probably be combined with the lookup that happens
> anyway for let-binding the default values.
I'd have to see a sample of this to see what it might look like.
> d) make the duplicate default values consistent but don't touch the
This is my recommended step right now.
> e) redesign everything
> Option d) appears simplest but most error-prone.
> Other than that, I think one should go for a). Likely cleanest.
> Disadvantage is that that makes the code diverge from what one would use
> for define-markup-command rather than define-builtin-markup-command.
I strongly disagree with going for a). In my opinion there are two
The simple is option d).
The complex is to modify the documentation generator so that instead of
reading values from the documented properties, it scans through the actual
markup function code looking for chain-assoc-get calls on props and reading
the key and the default value from the code. I think this is correct
because it modifies the documentation code to be consistent with the
functional code, rather than modifying the functional code to be consistent
with the documentation code.
The current documentation code is a bit of a hack, as you correctly observe,
but it works.
> So one should probably add this default-let behavior to the
> define-markup-command macro as well.
We already have a fine way of defining defaults for properties, so I don't
think we need to add the documentation overhead to define-markup-command.
I appreciate your look at this system with new eyes. I think there's
something that could be done here.