The merge function is redundant?

[Richard Gaskin]

kee nethery wrote:

 > I’m confused. Can someone explain why merge function exists when the
 > put function works just as well?
 >
 > merge( [[ 1 + 2 ]] = 3)
 > vs
 > put 1 + 2 && “= 3”
 >
 > What is it that merge can do that a put cannot do? Just asking because
 > I don’t want LiveCode to end up like Perl where there are so many
 > completely different ways to do the exact same thing that one person’s
 > perl code can be unreadable to another equally talented Perl coder.

Not to worry about new things in the language stinking up the place. <g> 
Merge has been in the xTalk family of languages for a long time, and 
serves a distinct purpose.  A little history may be helpful:

Gary Poppitz of the SuperCard team introduced the merge function to the 
xTalk world in the mid-90s, to support a server-side version of 
SuperCard called Flamethrower.

The goal was to provide a convenient way to sprinkle xTalk evaluations 
and statements throughout text that isn't xTalk -- in that use-case, HTML.

In short: templating.

Without a merge function you'd need to write your own parse to walk 
through the text to find whatever delimiters you're using, then run the 
found substring through "do" or "value".  Possible, but tedious and 
error-prone.  Indeed there were some HyperCard stacks back in the day 
with similar functionality done in script (Bob McBurney's Arachnid comes 
to mind), so one could deliver dynamic web pages from a Mac server in 
our favorite language.  But it was no speed demon compared to what LC 
does by handling that robustly in the engine.

Some time around MetaCard v2.0 Scott Raney added it to the engine we now 
call LiveCode, so it's been around for more than 20 years.  Mark 
Waddingham has enhanced it since then, and the core functionality is 
similar in many respects to how LC Server processes .lc files, so it's 
not going away any time soon.

And considering its utility, I'm grateful for it.  While I use it most 
often with HTML templates, I've used it with other formats as well for a 
wide range of tasks.  The ability to quickly and conveniently process 
any number of LC Script placeholders within a body of non-LC text has 
many applications once you get the hang of it.


Bonus:

A sort of logical inverse to using LC expressions in the middle of 
non-LC text is to put non-LC text in the middle of LC Scripts.  In bash 
this is done with heredoc, and some other languages offer such 
functionality as well.  I've proposed it in the LC request queue:

https://quality.livecode.com/show_bug.cgi?id=17471

Comment #5 there from Brian Milby shows existing syntax used in another 
xTalk, SenseTalk, that could conceivably be adopted, perhaps less useful 
for compatibility with that dialect than simply having proven design 
work already done.

Used with the merge function, a heredoc-like implementation would make 
short work of many tasks we currently write 
"complicated"&space&"and"&space&"difficult-to-read"&space&"concatenation" 
for.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com