synonyms

[Richard Gaskin]

Paul Dupuis wrote:

 > Mike,
 >
 > Even better.
 >
 > You solution illustrate more so than mine how easy it is to make
 > handler and functions that use name/value pairs if someone prefers
 > that model. The xtalk language really doesn't need any extensions
 > or enhancements to enable this.

Fully agreed, as I wrote in my post introducing this arg format to the 
discussion a couple days ago:

     And as much as I like it in R, I'm not sure I would advocate it
     in an xTalk as any sort of necessity.  It might be ideal for
     certain types of commands (oh how I'd love it with "export"),
     but is so unusual compared to most other languages that it may
     just increase the learning curve for most folks.

     I bring it up here not as a recommendation, but just as a sort
     of "think REALLY different" exercise as we consider alternative
     syntax possibilities...


A third option is one I wrote back when I was experimenting with this, 
getting just a bit closer to how those args are handled in R by using a 
single string that doesn't require commas between name-value pairs:

    DoSomething  "name='my chart' width=100 label='This is a chart'"

Still imperfect, a bit cumbersome to have to be mindful of how strings 
are handled with the single-quotes inside and double-quotes outside (see 
below).  But like anything else, you write it once, unit test it, and 
you never have to think about it again.

Though it doesn't kill us to write parsers for things like that, it's 
definitely not for newcomers.  And while the engine is pretty efficient, 
the additional overhead of parsing named args in script makes them 
impractical for commonly-called routines where performance is critical.

More with-the-grain would be this fourth option, passing in an array as 
we see with some existing LC commands and functions, but that requires a 
LOT more typing:

   put "my chart" into tA["name"]
   put 100 into tA["width"]
   put "This is a chart" into tA["label"]
   DoSomething tA

I haven't spent much more time on named args because once I started down 
the road of replicating R functionality in LC (seemed useful at the time 
for some analytics tasks) I found there are a great many conveniences in 
R that would need to be written from scratch to deliver a workflow as 
productive.  Ultimately I decided that rather than try to build R in LC 
it was probably more productive to just learn R. :)  Fun exercise, 
though.  While I rarely end up using such replication experiments in 
production, I don't mind doing them as they help me learn the thing I'm 
translating.  I learned a lot about CSS writing a layout translator, the 
only one likely to find its way into production.  And while I could find 
no practical use-case for a library that rapidly creates objects from 
sparse readable strings I did learn a lot about REBOL Layout playing 
around with the idea back in the day.

All this reminds me of something that actually might be worth 
considering, a real sanity- and time-saver in JavaScript and other 
languages:

The ability to use single-quotes and double-quotes interchangeably so 
they can be nested.

E.g. to get this:

   "Hello", he said. "How are you?"

...we could write:

   put '"Hello", he said, "How are you?"'

...vs today's:

   put quote& "Hello" & quote &", he said. " & quote \
      & "How are you?" & quote

I find having only the "quote" constant with no means of nesting with 
single-quotes often makes concatenated expressions much longer and more 
complicated to type *and read* than their equivalents in JavaScript.

I imagine there are good reasons we don't have this, but I can dream....

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