String delimiters [WAS Re: common code patterns]

[Alex Tweedly]

While we (i.e. you) are thinking about string delimiters, could we 
PLEASE have some decent way to do multi-line strings.

Whether it's like Python's triple-quote, or Perl's heredoc, or .... just 
some way to do them without either escaped '\n's or non-embedded CRs.

Thanks

Alex.


On 14/08/2017 10:35, Mark Waddingham via use-livecode wrote:
> 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.
>