Re: Guessing game

[Brian Milby via use-livecode]

cREVGeneral is an example of where recursion would be a problem.  In the
common library there are getProp and setProp handlers that depend on lock
messages.  The handlers intercept the message and in some cases need to
lock messages to get the system property before continuing (so a pass would
not work).

On Thu, Apr 5, 2018 at 5:19 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Yes, for the purposes it was designed for (stopping the triggering of
> system messages) the "lock messages" command is very useful.
>
> The problem with getProp and setProp is that those triggers occur in
> response to *custom* properties, not system properties.
>
> As originally implemented (and as remains since) if you use libraries or
> other components which may lock messages, the effects on getProp and
> setProp can be unknowable in advance, and difficult to pin down when
> issues occur from scripts that depend on those messages but sometimes
> they're not sent.
>
> Mark Waddingham reviewed this a while back and offered the view that
> custom property triggers should follow the convention of custom handlers
> being immune to "lock messages".
>
> But there's apparently a challenge there with avoiding recursion which
> makes it unlikely getProp and setProp will be revised any time soon to
> be immune to lockMessages.
>
> If you work in teams sufficiently disciplined and communicative that any
> use of "lock messages" is well accounted for with regard to property
> triggers, and restrict use of any third-party components to those with
> open code that's been carefully scanned for "lock messages" and
> "lockMessages", I suppose this anomaly isn't much of an issue.
>
> It wasn't for me:  I got bit only once, moved back to getter/setter
> accessors, and moved on; problem solved. :)
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
>
> David Bovill wrote:
> > Yes - thanks for pointing that out. So far I've found the behaviour of
> > lockmessages to be actually useful rather than an issue with
> > getprop/setprop - seems well designed to me.
> >
> > The place where the syntax really shines is with functions calls rather
> > than commands - dispatch is quite natural for that. Say you want the
> model
> > data of a stack "My Project" - the syntax:
> >
> > put the project_Data of stack "My Project" into pData
> >
> >
> > is much more elegant and comprehensible than any way to call a function.
> > this is also nice:
> >
> > put the project_Data ["pretty colour"] of stack "My Project" into
> >> defaultColour
> >
> >
> >
> > On 3 April 2018 at 18:05, Richard Gaskin via use-livecode <
> > use-livecode at lists.runrev.com> wrote:
> >
> >> David Bovill wrote:
> >>
> >> > The use-case I had was to replace send syntax with the more elegant
> >> > set the ... of object to syntax.
> >>
> >> While the getProp and setProp handlers would seem to lend themselves to
> a
> >> lot of useful object binding opportunities, they require caution:
> they're
> >> treated by the engine as system messages, and as such are not immune to
> the
> >> effects of lockMessages the way custom handlers are.
> >>
> >> Systems depending on getProp and setProp will need to monitor
> lockMessages
> >> carefully to insure critical triggers are received as expected.
> >>
> >> Using getter and setter accessor handlers avoids that concern, with a
> >> stylistic difference that isn't much more verbose:
> >>
> >>   set the BeautifulColor of cd 1 to "light-grey"
> >>
> >> -vs-
> >>
> >>   dispatch SetBeautifulColor to cd 1 with "light-grey"
> >>
> >> It doesn't read as nicely, but given that the trade-off can be
> >> unpredictability I'll take what I can get. :)
> >>
> >> And depending on usage context, in many cases the UI event that
> initiates
> >> a calling chain may be on the card in question, not requiring
> >> out-of-message-path dispatching, making the call simpler than a property
> >> setting:
> >>
> >>SetBeautifulColor "light-grey"
> >>
> >> For virtual objects like models, accessors can simplify things by not
> >> requiring that they be bound to a physical object which need not
> otherwise
> >> exist.  The name-value-pair programming we enjoy with custom props
> applies
> >> equally well with any array.  But with arrays we can have deeper levels,
> >> and are more easily savable/transportable than an object bound to a
> stack
> >> file.
> >>
> >> --
> >>  Richard Gaskin
> >>  Fourth World Systems
> >>  Software Design and Development for the Desktop, Mobile, and the Web
> >>  
> >>  Ambassador at FourthWorld.com
> http://www.FourthWorld.com
>
>
> ___
> 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
>
___
use-livecode 

Re: Guessing game

[David Bovill via use-livecode]

I guess I see your perspective. For me it’s totally the right and natural
thing.

It’s automatically reset at the end if the handler. Personally I’d go the
other way and say that if the lock messages were set command calls trapped
by anything above in the hierarchy should also not get executed.

I mean if you lock messages you lock the messages right :)

On Thu, 5 Apr 2018 at 22:19, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Yes, for the purposes it was designed for (stopping the triggering of
> system messages) the "lock messages" command is very useful.
>
> The problem with getProp and setProp is that those triggers occur in
> response to *custom* properties, not system properties.
>
> As originally implemented (and as remains since) if you use libraries or
> other components which may lock messages, the effects on getProp and
> setProp can be unknowable in advance, and difficult to pin down when
> issues occur from scripts that depend on those messages but sometimes
> they're not sent.
>
> Mark Waddingham reviewed this a while back and offered the view that
> custom property triggers should follow the convention of custom handlers
> being immune to "lock messages".
>
> But there's apparently a challenge there with avoiding recursion which
> makes it unlikely getProp and setProp will be revised any time soon to
> be immune to lockMessages.
>
> If you work in teams sufficiently disciplined and communicative that any
> use of "lock messages" is well accounted for with regard to property
> triggers, and restrict use of any third-party components to those with
> open code that's been carefully scanned for "lock messages" and
> "lockMessages", I suppose this anomaly isn't much of an issue.
>
> It wasn't for me:  I got bit only once, moved back to getter/setter
> accessors, and moved on; problem solved. :)
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
>
> David Bovill wrote:
> > Yes - thanks for pointing that out. So far I've found the behaviour of
> > lockmessages to be actually useful rather than an issue with
> > getprop/setprop - seems well designed to me.
> >
> > The place where the syntax really shines is with functions calls rather
> > than commands - dispatch is quite natural for that. Say you want the
> model
> > data of a stack "My Project" - the syntax:
> >
> > put the project_Data of stack "My Project" into pData
> >
> >
> > is much more elegant and comprehensible than any way to call a function.
> > this is also nice:
> >
> > put the project_Data ["pretty colour"] of stack "My Project" into
> >> defaultColour
> >
> >
> >
> > On 3 April 2018 at 18:05, Richard Gaskin via use-livecode <
> > use-livecode at lists.runrev.com> wrote:
> >
> >> David Bovill wrote:
> >>
> >> > The use-case I had was to replace send syntax with the more elegant
> >> > set the ... of object to syntax.
> >>
> >> While the getProp and setProp handlers would seem to lend themselves to
> a
> >> lot of useful object binding opportunities, they require caution:
> they're
> >> treated by the engine as system messages, and as such are not immune to
> the
> >> effects of lockMessages the way custom handlers are.
> >>
> >> Systems depending on getProp and setProp will need to monitor
> lockMessages
> >> carefully to insure critical triggers are received as expected.
> >>
> >> Using getter and setter accessor handlers avoids that concern, with a
> >> stylistic difference that isn't much more verbose:
> >>
> >>   set the BeautifulColor of cd 1 to "light-grey"
> >>
> >> -vs-
> >>
> >>   dispatch SetBeautifulColor to cd 1 with "light-grey"
> >>
> >> It doesn't read as nicely, but given that the trade-off can be
> >> unpredictability I'll take what I can get. :)
> >>
> >> And depending on usage context, in many cases the UI event that
> initiates
> >> a calling chain may be on the card in question, not requiring
> >> out-of-message-path dispatching, making the call simpler than a property
> >> setting:
> >>
> >>SetBeautifulColor "light-grey"
> >>
> >> For virtual objects like models, accessors can simplify things by not
> >> requiring that they be bound to a physical object which need not
> otherwise
> >> exist.  The name-value-pair programming we enjoy with custom props
> applies
> >> equally well with any array.  But with arrays we can have deeper levels,
> >> and are more easily savable/transportable than an object bound to a
> stack
> >> file.
> >>
> >> --
> >>  Richard Gaskin
> >>  Fourth World Systems
> >>  Software Design and Development for the Desktop, Mobile, and the Web
> >>  
> >>  Ambassador at FourthWorld.com
> http://www.FourthWorld.com
>
>
> ___
> 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
>

Re: Guessing game

[Richard Gaskin via use-livecode]

Yes, for the purposes it was designed for (stopping the triggering of 
system messages) the "lock messages" command is very useful.


The problem with getProp and setProp is that those triggers occur in 
response to *custom* properties, not system properties.


As originally implemented (and as remains since) if you use libraries or 
other components which may lock messages, the effects on getProp and 
setProp can be unknowable in advance, and difficult to pin down when 
issues occur from scripts that depend on those messages but sometimes 
they're not sent.


Mark Waddingham reviewed this a while back and offered the view that 
custom property triggers should follow the convention of custom handlers 
being immune to "lock messages".


But there's apparently a challenge there with avoiding recursion which 
makes it unlikely getProp and setProp will be revised any time soon to 
be immune to lockMessages.


If you work in teams sufficiently disciplined and communicative that any 
use of "lock messages" is well accounted for with regard to property 
triggers, and restrict use of any third-party components to those with 
open code that's been carefully scanned for "lock messages" and 
"lockMessages", I suppose this anomaly isn't much of an issue.


It wasn't for me:  I got bit only once, moved back to getter/setter 
accessors, and moved on; problem solved. :)


--
 Richard Gaskin
 Fourth World Systems


David Bovill wrote:

Yes - thanks for pointing that out. So far I've found the behaviour of
lockmessages to be actually useful rather than an issue with
getprop/setprop - seems well designed to me.

The place where the syntax really shines is with functions calls rather
than commands - dispatch is quite natural for that. Say you want the model
data of a stack "My Project" - the syntax:

put the project_Data of stack "My Project" into pData


is much more elegant and comprehensible than any way to call a function.
this is also nice:

put the project_Data ["pretty colour"] of stack "My Project" into

defaultColour




On 3 April 2018 at 18:05, Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:


David Bovill wrote:

> The use-case I had was to replace send syntax with the more elegant
> set the ... of object to syntax.

While the getProp and setProp handlers would seem to lend themselves to a
lot of useful object binding opportunities, they require caution: they're
treated by the engine as system messages, and as such are not immune to the
effects of lockMessages the way custom handlers are.

Systems depending on getProp and setProp will need to monitor lockMessages
carefully to insure critical triggers are received as expected.

Using getter and setter accessor handlers avoids that concern, with a
stylistic difference that isn't much more verbose:

  set the BeautifulColor of cd 1 to "light-grey"

-vs-

  dispatch SetBeautifulColor to cd 1 with "light-grey"

It doesn't read as nicely, but given that the trade-off can be
unpredictability I'll take what I can get. :)

And depending on usage context, in many cases the UI event that initiates
a calling chain may be on the card in question, not requiring
out-of-message-path dispatching, making the call simpler than a property
setting:

   SetBeautifulColor "light-grey"

For virtual objects like models, accessors can simplify things by not
requiring that they be bound to a physical object which need not otherwise
exist.  The name-value-pair programming we enjoy with custom props applies
equally well with any array.  But with arrays we can have deeper levels,
and are more easily savable/transportable than an object bound to a stack
file.

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



___
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

Re: Guessing game

[Mark Wieder via use-livecode]

On 04/03/2018 12:51 AM, Mark Waddingham via use-livecode wrote:


One could imagine a similar thing being added to the arithmetic commands:

   add tLeft to tRight into tResult

Would do nothing different from:

   put tLeft + tRight into tResult

This would just be a different way of expressing the same thing 
syntactically. (Note the 'into' form has not been added to the 
arithmetic commands, and there is no binary intersect/union operator - 
but perhaps both should be considered).


Hmmm... and perhaps not.

I find
put tLeft + tRight into tResult
much more intuitive and readable than
add tLeft to tRight into tResult

In the latter, is tRight modified or not? It's not easy to determine 
that from reading the code, whereas in the first form it seems obvious 
that neither of the lValues are modified.


Also, what if you wanted to add three numbers instead of just two?
add tWhiskey to tTango to tFoxtrot into tTotal

Even if "to" isn't the right preposition here, replacing it with "and" 
or "plus" still gives weird non-natural syntax.


--
 Mark Wieder
 ahsoftw...@gmail.com


___
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

Re: Guessing game

[David Bovill via use-livecode]

Yes - thanks for pointing that out. So far I've found the behaviour of
lockmessages to be actually useful rather than an issue with
getprop/setprop - seems well designed to me.

The place where the syntax really shines is with functions calls rather
than commands - dispatch is quite natural for that. Say you want the model
data of a stack "My Project" - the syntax:

put the project_Data of stack "My Project" into pData


is much more elegant and comprehensible than any way to call a function.
this is also nice:

put the project_Data ["pretty colour"] of stack "My Project" into
> defaultColour




On 3 April 2018 at 18:05, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> David Bovill wrote:
>
> > The use-case I had was to replace send syntax with the more elegant
> > set the ... of object to syntax.
>
> While the getProp and setProp handlers would seem to lend themselves to a
> lot of useful object binding opportunities, they require caution: they're
> treated by the engine as system messages, and as such are not immune to the
> effects of lockMessages the way custom handlers are.
>
> Systems depending on getProp and setProp will need to monitor lockMessages
> carefully to insure critical triggers are received as expected.
>
> Using getter and setter accessor handlers avoids that concern, with a
> stylistic difference that isn't much more verbose:
>
>   set the BeautifulColor of cd 1 to "light-grey"
>
> -vs-
>
>   dispatch SetBeautifulColor to cd 1 with "light-grey"
>
> It doesn't read as nicely, but given that the trade-off can be
> unpredictability I'll take what I can get. :)
>
> And depending on usage context, in many cases the UI event that initiates
> a calling chain may be on the card in question, not requiring
> out-of-message-path dispatching, making the call simpler than a property
> setting:
>
>SetBeautifulColor "light-grey"
>
> For virtual objects like models, accessors can simplify things by not
> requiring that they be bound to a physical object which need not otherwise
> exist.  The name-value-pair programming we enjoy with custom props applies
> equally well with any array.  But with arrays we can have deeper levels,
> and are more easily savable/transportable than an object bound to a stack
> file.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> 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
>
___
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

Re: Guessing game

[Richard Gaskin via use-livecode]

David Bovill wrote:

> The use-case I had was to replace send syntax with the more elegant
> set the ... of object to syntax.

While the getProp and setProp handlers would seem to lend themselves to 
a lot of useful object binding opportunities, they require caution: 
they're treated by the engine as system messages, and as such are not 
immune to the effects of lockMessages the way custom handlers are.


Systems depending on getProp and setProp will need to monitor 
lockMessages carefully to insure critical triggers are received as expected.


Using getter and setter accessor handlers avoids that concern, with a 
stylistic difference that isn't much more verbose:


  set the BeautifulColor of cd 1 to "light-grey"

-vs-

  dispatch SetBeautifulColor to cd 1 with "light-grey"

It doesn't read as nicely, but given that the trade-off can be 
unpredictability I'll take what I can get. :)


And depending on usage context, in many cases the UI event that 
initiates a calling chain may be on the card in question, not requiring 
out-of-message-path dispatching, making the call simpler than a property 
setting:


   SetBeautifulColor "light-grey"

For virtual objects like models, accessors can simplify things by not 
requiring that they be bound to a physical object which need not 
otherwise exist.  The name-value-pair programming we enjoy with custom 
props applies equally well with any array.  But with arrays we can have 
deeper levels, and are more easily savable/transportable than an object 
bound to a stack file.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: Guessing game

[Bob Sneidar via use-livecode]

When I was first exposed to arrays in Foxpro, I saw them as ordered blocks of 
memory which could be addressed using integer values. Back then an array in 
memory resided in a contiguous block of memory for efficiency, and were 2 
dimensional, so a reference to an element was myArray(x,y) (if memory serves 
heh heh). I naturally saw variables as a string reference different kind of 
object in memory. I still do. Livecode therefore supports two types of 
variables in my understanding: String and Array. 

This becomes evident when you try to write either to a file. A string you can. 
An array you have to convert to a string of sorts (arrayEncode) to save it 
anywhere but in LC memory or an LC property. 

Bob S


> On Apr 3, 2018, at 02:24 , Mark Waddingham via use-livecode 
>  wrote:
> 
> P.S. Looking at this another way - I'd perhaps characterize the above as 
> arrays are not 'complete' as values in LiveCode (as in: you can't use arrays 
> in all places where you can use strings, and would still make sense), but I 
> would say they were 'first-class'. I'd suggest 'completeness as values' is a 
> more stringent requirement than 'first-class' - and is more that 'code has 
> not been written to do that' (incomplete), rather than the 'model of the 
> language disallows any notion of it being possible' (not first-class).


___
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

Re: Guessing game

[David Bovill via use-livecode]

Actually the use case was different. More of a generic way with nice syntax
to call remote functions. This is easier now with dispatch but still not
quite as elegant IMO as using virtual properties of models.

Let’s take an example that I currently use. Note that the rational here is
to avoid where possible using libraries with potential name clashes in a
global space, while retaining elegant syntax and a clear mental (visual)
model.

Requirements: to be able to get and set data on an arbitrary number if
project specific user contributed models.

Second requirement:  to also be able to filter and search the data with
minimal syntax.

Solution: rather than calling / evaluating functions in the context of
their particular project which is hard syntax to remember and not easy to
read - define the following:

getprop project_Data
  -- fetch some data drom a suitable data source linked to the current
context
  return projectArray
end getprop

setprop project_Data someArray
  -- fetch some data drom a suitable data source linked to the current
context
  return projectJson
end getprop


That works fine, and you can make it more useable by defining a single
generic library to access stored arrays in a suitably defined place in the
project.

However you want to be able to filter and search the data, returning for
instance only particular fields. Rather than defining lots of separate
handlers it is useful an elegant to extend the virtual properties as
follows:

getprop project_Data [someKey]]
  -- fetch some data drom a suitable data source linked to the current
context
  return projectArray
end getprop


What would be nice is to be able to use the full power of native arrays in
this syntax, as you could then use it to not only return top level keyed
arrays but nested structures and other types of query. For a function you
would just add another parameter for that. you can;t do that with virtual
props - so you need to leverage the power of arrays.

That's one example of why i'd like to enable that functionality - and make
arrays a bit more complete :)


On Tue, 3 Apr 2018 at 11:07, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-04-03 11:35, David Bovill via use-livecode wrote:
> > True - I’d rather be first-class than complete anyway.
>
> To use a more concrete analogy - all British citizens are (since
> suffrage!) 'first-class' in the sense they can vote, but are not
> 'complete' in the sense that there exist things which some citizens are
> allowed to do, which others are not.
>
> > And yes thanks for suggested way around incompleteness. I still
> > suffered
> > culture shock. The use-case I had was to replace send syntax with the
> > more
> > elegant set the ... of object to syntax. I found myself wanting a bit
> > more
> > power ...
>
> That's a slightly different thing - I'd suggest that even your proposed
> 'more elegant' solution is actually probably much less readable than
> using 'send' in the long run as, if I read that line it isn't entirely
> clear what it is intending to do...
>
> So, I'm guessing what you really want to be able to do is:
>
>set the textColor of chunk tChunk of tMyObject to light-grey for each
> tChunk in spellingArray
>
> Or (with slightly less use of non-existant syntax):
>
>set the textColor of each element of spellingArray to light-grey
>
> Where 'spellingArray' is a numeric list of chunk references. Which would
> be the same as:
>
>repeat for each element tMisspeltWordsChunk in spellingArray
>  set the textColor of tMisspeltWordChunk to "light gray"
>end repeat
>
> Which does actually work now - as you can have things like "char 1 to 20
> of field 1" in a variable, which will be parsed at runtime when its the
> target of a set command.
>
> > Power is not always a good thing. I’m glad that the dignity of arrays
> > has
> > been restored.
>
> Power and syntax are intimately related - in the sense that how we
> encode what we want to do as syntax will give us power in some ways,
> whilst removing it in others (the only way for that to not be the case
> is to make the syntax more verbose and more difficult to write - think
> machine code vs. LiveCode Script).
>
> The above is actually a very good example of this as you *can* actually
> use an array as an index outside of setProps, it just means something
> perhaps much more useful...
>
> i.e.
>put "foo" into tPath[1]
>put "bar" into tPath[2]
>put tArray[tPath] into tBarOfFooOfArray
>
> Numerically keyed arrays starting from 1 can be used as an array index,
> in which case they are considered to be a sequence of keys to follow.
> The above is the same as:
>
>put tArray["foo"]["bar"] into tBarOfFooOfArray
>
> To put it another way, as it stands, the use of arrays as indexes in
> arrays has been chosen to mean something which is (to be fair) a *great
> deal* more useful than array-valued keys - as it makes array paths (i.e.
> sequence of keys) first-class in the 

Re: Guessing game

[Mark Waddingham via use-livecode]

On 2018-04-03 11:35, David Bovill via use-livecode wrote:

True - I’d rather be first-class than complete anyway.


To use a more concrete analogy - all British citizens are (since 
suffrage!) 'first-class' in the sense they can vote, but are not 
'complete' in the sense that there exist things which some citizens are 
allowed to do, which others are not.


And yes thanks for suggested way around incompleteness. I still 
suffered
culture shock. The use-case I had was to replace send syntax with the 
more
elegant set the ... of object to syntax. I found myself wanting a bit 
more

power ...


That's a slightly different thing - I'd suggest that even your proposed 
'more elegant' solution is actually probably much less readable than 
using 'send' in the long run as, if I read that line it isn't entirely 
clear what it is intending to do...


So, I'm guessing what you really want to be able to do is:

  set the textColor of chunk tChunk of tMyObject to light-grey for each 
tChunk in spellingArray


Or (with slightly less use of non-existant syntax):

  set the textColor of each element of spellingArray to light-grey

Where 'spellingArray' is a numeric list of chunk references. Which would 
be the same as:


  repeat for each element tMisspeltWordsChunk in spellingArray
set the textColor of tMisspeltWordChunk to "light gray"
  end repeat

Which does actually work now - as you can have things like "char 1 to 20 
of field 1" in a variable, which will be parsed at runtime when its the 
target of a set command.


Power is not always a good thing. I’m glad that the dignity of arrays 
has

been restored.


Power and syntax are intimately related - in the sense that how we 
encode what we want to do as syntax will give us power in some ways, 
whilst removing it in others (the only way for that to not be the case 
is to make the syntax more verbose and more difficult to write - think 
machine code vs. LiveCode Script).


The above is actually a very good example of this as you *can* actually 
use an array as an index outside of setProps, it just means something 
perhaps much more useful...


i.e.
  put "foo" into tPath[1]
  put "bar" into tPath[2]
  put tArray[tPath] into tBarOfFooOfArray

Numerically keyed arrays starting from 1 can be used as an array index, 
in which case they are considered to be a sequence of keys to follow. 
The above is the same as:


  put tArray["foo"]["bar"] into tBarOfFooOfArray

To put it another way, as it stands, the use of arrays as indexes in 
arrays has been chosen to mean something which is (to be fair) a *great 
deal* more useful than array-valued keys - as it makes array paths (i.e. 
sequence of keys) first-class in the language.


(Also, all uses of array-valued keys anywhere can be transformed to code 
which derives a canonical name from an array before being used as a key 
- which is probably something you should be doing anyway directly were 
you to ever think you have a need for such, otherwise it masks what the 
code is *actually* doing, as well as probably causing you horrendous 
performance problems for cases you have not foreseen and will occur!).


Of course, what you wanted (I presume) is a more succinct way to set a 
property of a collection of chunks to a single value - i.e. one which 
takes one line, rather than 3 - which isn't really anything to do with 
array-valued array keys at all - and more syntactic sugar for what other 
languages would call 'list comprehension' I guess.


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

Re: Guessing game

[David Bovill via use-livecode]

True - I’d rather be first-class than complete anyway.

And yes thanks for suggested way around incompleteness. I still suffered
culture shock. The use-case I had was to replace send syntax with the more
elegant set the ... of object to syntax. I found myself wanting a bit more
power ...

Power is not always a good thing. I’m glad that the dignity of arrays has
been restored.

On Tue, 3 Apr 2018 at 10:25, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-04-03 10:28, David Bovill via use-livecode wrote:
> > Arrays as first class citizens? Give them a passport! Arrays have
> > rights
> > too!
> >
> > Need to check if they can be passed as parameters in setprop handlers -
> > as
> > in “set the beautiful_Colour [spellingArray] of my card to light-grey”
>
> Heh - okay let me define what I mean by 'first-class citizen'...
>
> A 'thing' in a programming language is a 'first-class citizen' if it can
> be placed in a variable, and further being then able to use that
> variable to be able to access the functionality of 'thing' instead of
> referencing 'thing' directly. i.e. 'thing' can be indirected.
>
> The above example confuses two things - the idea of being first-class,
> and the ability to use a given type of value in a given context. SetProp
> handlers are defined to take a string argument, as they are backed by a
> LiveCode array (custom property set) if there is no handler to call (or
> if messages are locked). So that's just a case of functionality which
> has not been defined nor implemented.
>
> Perhaps the best example of a language feature which is nearly never
> 'first-class' (as in, I don't believe there are any widely used general
> programming languages which allow it) is types. e.g. You can't do things
> like the following:
>
>put integer between 1 and 3 into tIntBetween1And3Type
>put tMyString as tIntBetween1And3Type into tIntBetween1And3
>
> Certainly you can approximate this in various languages - you *can*
> build concrete instances of abstract base classes (i.e. ones with all
> virtual methods) in C++ at runtime if you don't mind a bit of
> bit-bashing; but you can't build a struct, or class which is used as a
> value (i.e. not passed around as a pointer) which existing compiled code
> can used.
>
> Warmest Regards,
>
> Mark.
>
> P.S. Looking at this another way - I'd perhaps characterize the above as
> arrays are not 'complete' as values in LiveCode (as in: you can't use
> arrays in all places where you can use strings, and would still make
> sense), but I would say they were 'first-class'. I'd suggest
> 'completeness as values' is a more stringent requirement than
> 'first-class' - and is more that 'code has not been written to do that'
> (incomplete), rather than the 'model of the language disallows any
> notion of it being possible' (not first-class).
>
> P.P.S. You could rewrite your example as:
>  set the beautiful_Colour [ the arrayEncode of spellingArray ] of
> this card to "light-grey"
> Which suggests that arrays are actually 'complete' in LiveCode in the
> sense suggested above - it is just you (as the coder) have to work a bit
> harder to use them as such.
>
> --
> 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
___
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

Re: Guessing game

[Mark Waddingham via use-livecode]

On 2018-04-03 10:28, David Bovill via use-livecode wrote:
Arrays as first class citizens? Give them a passport! Arrays have 
rights

too!

Need to check if they can be passed as parameters in setprop handlers - 
as

in “set the beautiful_Colour [spellingArray] of my card to light-grey”


Heh - okay let me define what I mean by 'first-class citizen'...

A 'thing' in a programming language is a 'first-class citizen' if it can 
be placed in a variable, and further being then able to use that 
variable to be able to access the functionality of 'thing' instead of 
referencing 'thing' directly. i.e. 'thing' can be indirected.


The above example confuses two things - the idea of being first-class, 
and the ability to use a given type of value in a given context. SetProp 
handlers are defined to take a string argument, as they are backed by a 
LiveCode array (custom property set) if there is no handler to call (or 
if messages are locked). So that's just a case of functionality which 
has not been defined nor implemented.


Perhaps the best example of a language feature which is nearly never 
'first-class' (as in, I don't believe there are any widely used general 
programming languages which allow it) is types. e.g. You can't do things 
like the following:


  put integer between 1 and 3 into tIntBetween1And3Type
  put tMyString as tIntBetween1And3Type into tIntBetween1And3

Certainly you can approximate this in various languages - you *can* 
build concrete instances of abstract base classes (i.e. ones with all 
virtual methods) in C++ at runtime if you don't mind a bit of 
bit-bashing; but you can't build a struct, or class which is used as a 
value (i.e. not passed around as a pointer) which existing compiled code 
can used.


Warmest Regards,

Mark.

P.S. Looking at this another way - I'd perhaps characterize the above as 
arrays are not 'complete' as values in LiveCode (as in: you can't use 
arrays in all places where you can use strings, and would still make 
sense), but I would say they were 'first-class'. I'd suggest 
'completeness as values' is a more stringent requirement than 
'first-class' - and is more that 'code has not been written to do that' 
(incomplete), rather than the 'model of the language disallows any 
notion of it being possible' (not first-class).


P.P.S. You could rewrite your example as:
set the beautiful_Colour [ the arrayEncode of spellingArray ] of 
this card to "light-grey"
Which suggests that arrays are actually 'complete' in LiveCode in the 
sense suggested above - it is just you (as the coder) have to work a bit 
harder to use them as such.


--
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

Re: Guessing game

[David Bovill via use-livecode]

Arrays as first class citizens? Give them a passport! Arrays have rights
too!

Need to check if they can be passed as parameters in setprop handlers - as
in “set the beautiful_Colour [spellingArray] of my card to light-grey”

Last time I checked not all first class citizens were equal.

On Tue, 3 Apr 2018 at 08:51, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-04-02 21:28, J. Landman Gay via use-livecode wrote:
> > I found this:
> >
> > ***
> > Additionally the into clause has been added to all array set set
> > operations allowing commands such as:
> >
> >   intersect tLeft with tRight into tResult
> >
> > The operation of the commands is the same as the non-into form except
> > that tLeft does not have to be a variable, and the result of the
> > operation is placed into tResult rather than mutating tLeft.
> > ***
> >
> > So when is an array not a variable?
>
> I must confess I found this quite an interesting question - as it speaks
> to the history of arrays in LiveCode.
>
> Originally there were no arrays 'just' variables - a variable could hold
> a string, nothing else.
>
> Then arrays were added, but they were not 'first class citizens' - so a
> perfectly reasonable mental model was that variables had been augmented
> so that they could be collections of named variables - each holding a
> string. (e.g. tFoo["a"], tFoo["b"] were both distinct variables, just
> with a convenient/indexable way of referencing them, and passing them
> around as a collection).
>
> However, this changed when we added hierarchical arrays - i.e. being
> able to set an array as the value of an array key. The variable centric
> model then doesn't work so well - it is perhaps 'better' to think of
> arrays as values like strings. i.e. Arrays ceased to be tied to the
> notion of variable at all, and just became a 'value' which can be put
> into a variable.
>
> Personally I think I always thought of arrays in LiveCode as values, but
> ones which had only been 'partially implemented' - there were lots of
> places prior to adding hierarchical arrays which wouldn't work with the
> existing notion of array, but had to be made to for hierarchical arrays
> to be in any way useful.
>
> Another way to think about 'into' being added to intersect/union is that
> we've essentially added binary operators for array union and intersect:
>
>intersect tLeft with tRight into tResult
>
> Does the same thing as a hypothetical 'intersect' binary operator:
>
>put tLeft intersect tRight into tResult
>
> One could imagine a similar thing being added to the arithmetic
> commands:
>
>add tLeft to tRight into tResult
>
> Would do nothing different from:
>
>put tLeft + tRight into tResult
>
> This would just be a different way of expressing the same thing
> syntactically. (Note the 'into' form has not been added to the
> arithmetic commands, and there is no binary intersect/union operator -
> but perhaps both should be considered).
>
> 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
>
___
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

Re: Guessing game

[Mark Waddingham via use-livecode]

On 2018-04-02 21:28, J. Landman Gay via use-livecode wrote:

I found this:

***
Additionally the into clause has been added to all array set set
operations allowing commands such as:

  intersect tLeft with tRight into tResult

The operation of the commands is the same as the non-into form except
that tLeft does not have to be a variable, and the result of the
operation is placed into tResult rather than mutating tLeft.
***

So when is an array not a variable?


I must confess I found this quite an interesting question - as it speaks 
to the history of arrays in LiveCode.


Originally there were no arrays 'just' variables - a variable could hold 
a string, nothing else.


Then arrays were added, but they were not 'first class citizens' - so a 
perfectly reasonable mental model was that variables had been augmented 
so that they could be collections of named variables - each holding a 
string. (e.g. tFoo["a"], tFoo["b"] were both distinct variables, just 
with a convenient/indexable way of referencing them, and passing them 
around as a collection).


However, this changed when we added hierarchical arrays - i.e. being 
able to set an array as the value of an array key. The variable centric 
model then doesn't work so well - it is perhaps 'better' to think of 
arrays as values like strings. i.e. Arrays ceased to be tied to the 
notion of variable at all, and just became a 'value' which can be put 
into a variable.


Personally I think I always thought of arrays in LiveCode as values, but 
ones which had only been 'partially implemented' - there were lots of 
places prior to adding hierarchical arrays which wouldn't work with the 
existing notion of array, but had to be made to for hierarchical arrays 
to be in any way useful.


Another way to think about 'into' being added to intersect/union is that 
we've essentially added binary operators for array union and intersect:


  intersect tLeft with tRight into tResult

Does the same thing as a hypothetical 'intersect' binary operator:

  put tLeft intersect tRight into tResult

One could imagine a similar thing being added to the arithmetic 
commands:


  add tLeft to tRight into tResult

Would do nothing different from:

  put tLeft + tRight into tResult

This would just be a different way of expressing the same thing 
syntactically. (Note the 'into' form has not been added to the 
arithmetic commands, and there is no binary intersect/union operator - 
but perhaps both should be considered).


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

Re: Guessing game

[J. Landman Gay via use-livecode]

For what it's worth, I don't have a gazebo in my back yard either. I 
suppose that means I'm either a raven or a writing desk.


I believe there's actually an answer to that riddle but I can't remember 
what it is. I think I saw it in the Annotated Alice. Back when we walked 
to school uphill both ways, I read Alice in Wonderland/Through the 
Looking Glass more than 20 times and I still have a custom drawing of 
the White Knight someone did for me.


It was years before I knew what treacle was.

On 4/2/18 3:30 PM, Bob Sneidar via use-livecode wrote:

First of all, neither has a Gazebo in the back yard...

Bob S



On Apr 2, 2018, at 13:20 , Mark Wieder via use-livecode 
 wrote:


So when is an array not a variable?


Why is a raven like a writing-desk?

--
Mark Wieder
ahsoftw...@gmail.com



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Guessing game

[J. Landman Gay via use-livecode]

Aha. Clarity. I'd wondered if properties might be involved but hadn't 
considered functions. Examples in the dictionary would be great.


On 4/2/18 4:03 PM, Ali Lloyd via use-livecode wrote:

Probably there should be an example that illustrates the use of the into
clause in that way!

On Mon, Apr 2, 2018 at 10:00 PM Ali Lloyd  wrote:


Yes, or the return value of a function

On Mon, Apr 2, 2018 at 9:39 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:


Would that be for properties?  Save the step of putting it into a variable
first?

On Mon, Apr 2, 2018 at 2:29 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:



I found this:

***
Additionally the into clause has been added to all array set set
operations allowing commands such as:

intersect tLeft with tRight into tResult

The operation of the commands is the same as the non-into form except
that tLeft does not have to be a variable, and the result of the
operation is placed into tResult rather than mutating tLeft.
***

So when is an array not a variable?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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


___
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




___
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




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Guessing game

[Jerry Jensen via use-livecode]

> 2/2018 12:59 PM, Jerry Jensen via use-livecode wrote:
>> ...variables being promoted to arrays and multidimensional dictionaries...

> Ooo... multidimensional dictionaries are *so* Douglas Adams...
> Mark Wieder


.Jerry



___
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

Re: Guessing game

[Ali Lloyd via use-livecode]

Probably there should be an example that illustrates the use of the into
clause in that way!

On Mon, Apr 2, 2018 at 10:00 PM Ali Lloyd  wrote:

> Yes, or the return value of a function
>
> On Mon, Apr 2, 2018 at 9:39 PM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Would that be for properties?  Save the step of putting it into a variable
>> first?
>>
>> On Mon, Apr 2, 2018 at 2:29 PM J. Landman Gay via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>> >
>> > I found this:
>> >
>> > ***
>> > Additionally the into clause has been added to all array set set
>> > operations allowing commands such as:
>> >
>> >intersect tLeft with tRight into tResult
>> >
>> > The operation of the commands is the same as the non-into form except
>> > that tLeft does not have to be a variable, and the result of the
>> > operation is placed into tResult rather than mutating tLeft.
>> > ***
>> >
>> > So when is an array not a variable?
>> >
>> > --
>> > Jacqueline Landman Gay | jac...@hyperactivesw.com
>> > HyperActive Software   | http://www.hyperactivesw.com
>> >
>> > ___
>> > 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
>> >
>> ___
>> 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
>>
>
___
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

Re: Guessing game

[Ali Lloyd via use-livecode]

Yes, or the return value of a function

On Mon, Apr 2, 2018 at 9:39 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Would that be for properties?  Save the step of putting it into a variable
> first?
>
> On Mon, Apr 2, 2018 at 2:29 PM J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> >
> > I found this:
> >
> > ***
> > Additionally the into clause has been added to all array set set
> > operations allowing commands such as:
> >
> >intersect tLeft with tRight into tResult
> >
> > The operation of the commands is the same as the non-into form except
> > that tLeft does not have to be a variable, and the result of the
> > operation is placed into tResult rather than mutating tLeft.
> > ***
> >
> > So when is an array not a variable?
> >
> > --
> > Jacqueline Landman Gay | jac...@hyperactivesw.com
> > HyperActive Software   | http://www.hyperactivesw.com
> >
> > ___
> > 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
> >
> ___
> 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
>
___
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

Re: Guessing game

[Brian Milby via use-livecode]

Would that be for properties?  Save the step of putting it into a variable
first?

On Mon, Apr 2, 2018 at 2:29 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> I found this:
>
> ***
> Additionally the into clause has been added to all array set set
> operations allowing commands such as:
>
>intersect tLeft with tRight into tResult
>
> The operation of the commands is the same as the non-into form except
> that tLeft does not have to be a variable, and the result of the
> operation is placed into tResult rather than mutating tLeft.
> ***
>
> So when is an array not a variable?
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> 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
>
___
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

Re: Guessing game

[Bob Sneidar via use-livecode]

First of all, neither has a Gazebo in the back yard...

Bob S


> On Apr 2, 2018, at 13:20 , Mark Wieder via use-livecode 
>  wrote:
> 
>> So when is an array not a variable?
> 
> Why is a raven like a writing-desk?
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com


___
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

Re: Guessing game

[Mark Wieder via use-livecode]

On 04/02/2018 12:59 PM, Jerry Jensen via use-livecode wrote:


I recently was attempting to explain, to a savvy younger programmer new to LC, 
the concepts of variables being promoted to arrays and multidimensional 
dictionaries. She gave me the “crazy old man” look.
.Jerry


Ooo... multidimensional dictionaries are *so* Douglas Adams...

--
 Mark Wieder
 ahsoftw...@gmail.com

___
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

Re: Guessing game

[Mark Wieder via use-livecode]

On 04/02/2018 12:28 PM, J. Landman Gay via use-livecode wrote:


So when is an array not a variable?



Why is a raven like a writing-desk?

--
 Mark Wieder
 ahsoftw...@gmail.com


___
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

Re: Guessing game

[Jerry Jensen via use-livecode]

On Apr 2, 2018, at 12:28 PM, J. Landman Gay via use-livecode 
 wrote:
> 
> So when is an array not a variable?

I recently was attempting to explain, to a savvy younger programmer new to LC, 
the concepts of variables being promoted to arrays and multidimensional 
dictionaries. She gave me the “crazy old man” look.
.Jerry


___
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

Re: Guessing game

[J. Landman Gay via use-livecode]

In addition to this:



I was just reading the release notes for 9.0rc1 and came across this entry:

Additional forms of create command
Create in now works correctly
You can now create in as well as in

Any guesses?


I found this:

***
Additionally the into clause has been added to all array set set 
operations allowing commands such as:


  intersect tLeft with tRight into tResult

The operation of the commands is the same as the non-into form except 
that tLeft does not have to be a variable, and the result of the 
operation is placed into tResult rather than mutating tLeft.

***

So when is an array not a variable?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Guessing game

[J. Landman Gay via use-livecode]

Enlightenment! But not as create-ive. I was thinking more along the 
lines of:


You can now create  in  as well as in 

I don't really need documentation to do that though.


On 3/17/18 3:47 PM, Ali Lloyd via use-livecode wrote:

Oops, looks like we need to escape < and > in release notes!
https://raw.githubusercontent.com/livecode/livecode/develop/docs/notes/feature-create-in.md

On Sat, Mar 17, 2018 at 8:30 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:


I was just reading the release notes for 9.0rc1 and came across this entry:

Additional forms of create command
Create in now works correctly
You can now create in as well as in

Any guesses?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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


___
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




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Guessing game

[Ali Lloyd via use-livecode]

Oops, looks like we need to escape < and > in release notes!
https://raw.githubusercontent.com/livecode/livecode/develop/docs/notes/feature-create-in.md

On Sat, Mar 17, 2018 at 8:30 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I was just reading the release notes for 9.0rc1 and came across this entry:
>
> Additional forms of create command
>Create in now works correctly
>You can now create in as well as in
>
> Any guesses?
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> 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
>
___
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