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

[Scott Wilson <s.d.wilson@xxxxxxxxxx>]

If you want expressions and don’t care about security then the whole thing can be implemented using a search and interpret.

> On 23 Dec 2017, at 13:39, <jamshark70@xxxxxx> <jamshark70@xxxxxx> wrote:
> 
> brianlheim wrote
>> I hope you believe me when I say I don't believe in making SuperCollider
>> more complex for the sake of adding interesting language features. ...
>> 
>> ... a generic debate of pro-change / anti-change.
> 
> Likewise, I'm not arguing against this because I'm opposed to change. I'm
> arguing against it because I'm not convinced that its value is so high as to
> justify the costs that Scott pointed out.
> 
> I *might* be convinced at some point in the future. The current proposal
> doesn't quite convince me.
> 
> 
>> I've argued strongly for this idea because I wanted it to get a fair
>> hearing, not because I'm interesting in making things easier for myself.
> 
> Said with tongue in cheek: Motivation doesn't really say anything about
> technical merit.
> 
> I think I am giving it a fair hearing. I've explained about my criteria for
> code readability and given examples where the proposed approach fails pretty
> hard to be legible. I've agreed that simple uses of f"" strings are
> straightforward to read and stated a concern that the readability argument
> falls apart when you scale up to moderately complex cases (and I agree,
> syntax highlighting would help, but shouldn't highlighting be an optional
> aid? If we need highlighting just to read the durned thing, there's
> something wrong). I think this is evaluating the approach on its merits, not
> summarily dismissing anything.
> 
> 
>> I have motivation to improve the language here, so if you want to suggest
>> something you think the community would make better use of, let me know!
> 
> To be honest, I'm not grossly dissatisfied with format(). format() could be
> improved by making it more like C's sprintf(). We haven't relayed the call
> to sprintf() because of the risk of crashing the language with bad input.
> Possibly exception handling might help?
> 
> Scott's POC replicates PHP's limitation of interpolating only variables, not
> expressions. So you couldn't do
> 
> f"next x = \(x + 1)"
> 
> You would need
> 
> var x = something, xPrint;
> ...
> xPrint = x + 1;
> f"next x = {xPrint}"
> 
> I wouldn't be happy with that restriction. I would be happier supporting
> expressions, with the risk of abuse.
> 
> 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/


_______________________________________________
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/