Re: define-void-function or define-procedure ?

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 10/19/11 3:14 PM, "David Kastrup" <address@hidden> wrote:
>
>>
>>>
>>> I am not enthused about this particular consequence of
>>> auto-exporting Scheme expressions.  I currently don't see a better
>>> way of handling it, and it has flagged more bad code than false
>>> positives when I tried it.  But I would be quite surprised if it did
>>> not trigger regressions with existing previously valid and
>>> reasonable code.
>
> I think if we're finding bad code, it's probably an improvement.  But
> to the extent that we break valid code, it's a problem.

"previously valid".  But of course any change that non-trivially changes
rather than _merely_ extends functionality needs quite more
consideration.  Most of my changes so far I have been able to just sneak
in under the radar because they would only affect fringe code
negatively, code that nobody writes.

>>An afterthought, however: we do have an inordinate amount of
>>user-level commands that need to be called from Scheme rather than
>>with Lilypond syntax.  That does not make sense.  Void music functions
>>have been around for eternities, just a bit inconvenient to define,
>>but reasonably documented.
>
> I think that there has been some feeling in the past that defining
> void functions and using lilypond mode to handle these commands is
> just syntactic sugar.

I quite disagree since Lilypond functions have type-checked arguments
and "work fine" with convert-ly.  convert-ly does not touch Scheme code,
and so Scheme code can be reasonably considered to be effectively not
part of the language.

Now of course my current project is trying to break the barriers between
Scheme and Lilypond mode, but my main motivation is that people can
avoid having to use Scheme for a whole task that is 95% doable in
Lilypond.  If you can just squeeze the required 5% of Scheme into
Lilypond constructs not specifically designed for that, the amount of
Scheme knowledge you need before being able to do something useful is
much less.  And the probability of your code being able to survive
convert-ly passes with correct results increases.

One "I want to do that eventually" project of mine is to have #{ ... #}
parsed at compile time so that no motivation for using (markup ...) over
#{ \markup { ... } #} remains.  For user level code, I consider the
second choice quite preferable already.

Perhaps one good idea would be to have all music functions be trivially
callable in Scheme.  That way, arguments would get typechecked, and
there would be no compatibility excuses for not providing music
functions.  Old code would continue working without convert-ly hassles,
but one would change the implementation and rip out the old docs right
away.

The one thing needing consideration are the "parser location" args since
they might get used for syntax errors and #{ ... #}.  So either they
need to be required parts of the function signature, or the boilerplate
checking the arguments and rerouting the call picks them from the
context of the calling #(...) construct or from the environment of the
music function definition, if all else fails.

Or one does not provide a pure Scheme wrapper for any function that
actually uses parser and location.  Not sure whether one can wheedle
this information from Guile.

>>Maybe we need a user interface meister that tries to maintain a bit of
>>coherency and sanity when new features get added.
>
> It seems to me that you are functioning as the UI meister right now.

Not really.  I am tearing my hairs and providing infrastructure mostly,
but not actually interfering significantly with existing interfaces.

I won't be able to root out all existing bad examples to a degree where
newcomers will feel bad about providing awkward code.

So my focus is on trying to make it easy to do better.  Most people are
happy when the thing they have been concocting is able to do the job for
them.  So it needs to be easy, hopefully a total no-brainer, to do it
nice on first try.

So I am not acting as much as UI meister, but rather trying to be a good
UI manager in the sense that a good manager is one that manages not
having to manage things.

A UI meister would exercise authority, tell people not to do bad things.
I try making it hard to do bad things even without a UI meister
exercising his iron grip.  And once it is hard enough, I shout and
holler and stomp my feet without bad conscience.  When I get to see bad
things.  But most of the time I am too lazy to pay attention.

> And you're doing a great job of it -- not just trying to get new
> interfaces to be sane, but pointing out where there is insanity in the
> existing interfaces.

Drive-by shootings.

-- 
David Kastrup