Re: [sc-users] Re: string formatting notation

> The difference is, in asStringPrec, sclang's C code has total control over
> the format string, and it can guarantee validity and avoid crashes. When JMc
> added .format(), he did not open up C-style formatting strings because the
> *user* provides the format string, making it impossible for the C code to be
> sure sprintf() wouldn't crash.

>
> SC's error handling is a lot more solid now, so it may be feasible to wrap
> sprintf() in a try block so that failure produces an error in the language,
> rather than crashing the sclang process. Nobody has investigated this, but
> you would have to do this to make it viable. It isn't sufficient only to
> avoid a buffer overrun.

All you have to do is use snprintf and fail on a nonzero return code. It's really that simple.

http://en.cppreference.com/w/c/io/fprintf

You would not get a throw from sprintf anyway. It's a C function; C functions don't throw, because there are no exceptions in C. They produce UB or crash when their preconditions are violated.

> if legibility is the criterion, then, when do the embedded
> expressions become unwieldy? I'm guessing that point will be when the
> _expression_ reaches about 20-30 characters.

Here's a (nonsensical) example in Swift. One thing that's been hard to convey in this discussion is just how much the syntax highlighting makes a difference. Not sure if this image will go through? Here's an ad hoc hosted link: https://ibb.co/dgshKm

To me, the first and third interpolated elements are no issue for me, but the middle (about 40 chars) is definitely causing some trouble.

-Brian

On Sun, Dec 24, 2017 at 7:11 PM, <jamshark70@xxxxxx> wrote:

>> We haven't relayed the call
>> to sprintf() because of the risk of crashing the language with bad input.
>
> asStringPrec uses sprintf() under the hood. There is absolutely no reason
> not to make it available, as long as you know how to avoid a buffer
> overrun.

The difference is, in asStringPrec, sclang's C code has total control over
the format string, and it can guarantee validity and avoid crashes. When JMc
added .format(), he did not open up C-style formatting strings because the
*user* provides the format string, making it impossible for the C code to be
sure sprintf() wouldn't crash.

SC's error handling is a lot more solid now, so it may be feasible to wrap
sprintf() in a try block so that failure produces an error in the language,
rather than crashing the sclang process. Nobody has investigated this, but
you would have to do this to make it viable. It isn't sufficient only to
avoid a buffer overrun.

> But, I find it funny that you think giving access to gnarly printf-style
> format strings over this notation is worth it. (What does "f+0.8%" do
> again?)

I do realize that's inconsistent with my concerns about legibility... but,
it would be a minimal change of interface to gain a vast amount of
functionality basically for free -- and, an established vast amount of
functionality with decades of testing behind it, instead of us trying to
roll something new that would certainly introduce bugs.

I'm not /a priori/ opposed to embedding code within strings -- this is, in
fact, how my live-coding framework supports generator functions.

/snare = "|-| \ins("", "-", 1, 0.5)|";

A concrete benefit is that the generator -- \ins() -- knows the time span
within the bar over which is allowed to operate (here, beat 3.5 - end of
bar) based on its position within the string. The embedding is not merely
for convenience; it conveys musical information to the downstream object,
and the way it does this is closely related to the way (Western) musicians
think about meter. So I get crucial functional information in a way that's
more intuitive to manipulate in performance than, say, Pseq-ing subpatterns.

I'm not certain that the benefit of string interpolation is quite this
significant. But I'm open enough to the idea to spend an hour this morning
prototyping it, so I can try it out, see how it feels for myself.

hjh

--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/