common code patterns

[Mark Waddingham]

On 2017-08-14 11:14, Monte Goulding via use-livecode wrote:
> Hmm… so say merge(“ string “, resolve escapes) = ` string ` ? I’ve got
> to say I wasn’t thinking of interpolation as I thought that merge does
> that sufficiently well.

Seeing 'special tokens' as syntactic sugar is definitely the way to go I 
think - it means that these escaping / interpolation operations are 
available for direct use form code, as well as when they are embedded 
(as tokens) in code.

Merge does do interpolation reasonably well, but it does not do 
escaping. In contrast format does escaping and formatting, but not 
interpolation. Escaping, formatting and interpolation are all part of a 
'similar' idea - and they are unified into a single thing in many other 
languages so it would perhaps make sense for them to be so in LiveCode 
too.

Of course, strictly speaking they are separate operations - 
interpolation requires more machinery than formatting which requires 
more machinery than escaping. However, cognitively, being able to do 
them all in a single unified string format does perhaps have a lot of 
value - and makes what is a 'slightly more complex' set of operations, 
'slightly easier' to grok.

[ Indeed, 'under the hood' the best way to look at it is that 
interpolation is transformed to format which then uses unescaping before 
filling in the placeholders ]

>> 
>> However, there are other options too - at the end of the day is 
>> 'format("...")' actually too onerous on occasions you want escaping?
> 
> Yes, unless you can use it in a constant or variable declaration which
> would be unusual and a bit too special casey for me:
> 
> constant kSomething = format(“this\tis\todd”)

I'm not sure I see why it would be 'special-casey' in particular. The 
mechanism we need to do this is universal - i.e. would apply to constant 
inputs to any pure/constant function. There is of course (as always) a 
slight 'yak-shave' here with regards constants 
(http://quality.livecode.com/show_bug.cgi?id=19413) - as anything after 
an initializer is currently treated as a literal, and *not* an 
expression.

The thought I'm having along this line is that 'easy things should be 
easy' and 'hard things should be possible'. i.e. The complexity of the 
syntax should reflect the complexity of the operation. There seems to be 
significant value in *just* having " and ' be plain strings - which 
suggests that perhaps escaping/interpolation should require slightly 
different syntax (and be perhaps slightly more verbose).

> Sure if you it’s a priority. The PR is only up there because I got
> interested in something on a rainy Sunday arvo. It’s not like we
> haven’t got other stuff to do and this bike shed seems to be rather
> large ;-)

It is certainly 'important' as far as working out what the best approach 
is. After all, if we can break things down into small bite-sized chunks 
heading towards what a generally considered reasonable goal, then it 
means it is more likely to happen over time (particularly as each 
bite-sized chunk probably has other fringe benefits). The idea(s) and 
such have been hanging around for long enough, it would be good to 
actually figure out the whys and wherefores - and choose some colors for 
all the bike-sheds which don't cause anyone too much nausea!

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps