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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
