subject:"Re\: synonyms"


On 2017-08-18 17:18, Bob Sneidar via use-livecode wrote:

That actually is a great explanation which solves a mystery I've often
wondnered about, which is how a handler with a different variable name
can contain the *actual* original variable. I thought the engine
actually created a new variable and copied the incoming value to it,
and then reversed this operation on return. Aliasing makes perfect
sense.


That's what would call 'inout' parameter mode.

For most languages which exist today, the way you can specify to pass 
parameters to functions distills down into 4 types (generally these are 
called parameter 'modes'):


  - by-ref
  - by-value (also called 'in')
  - copy-out (generally called 'out')
  - copy-in-copy-out (generally called 'inout')

Let us imagine we supported all these modes and we had a handler with 
signature:


  command myHandler @yRef, in pIn, out rOut, inout xInOut

Called with

  myHandler tRef, tIn, tOut, tInOut

The 'by-value'/'in' mode is what we are most familiar with. On entry to 
the handler the value in pIn is copied into the receiving variable tIn.


The 'out' mode is similar to what you describe. On entry to the handler 
rOut contains nothing; on exit from the handler, the value in rOut is 
'copied back' into the passed variable tOut.


The 'inout' mode is a mixture of the two: on entry tInOut is copied into 
xInOut, and on exit xInOut is copied back into tInOut.


In the 'by-ref' mode there is no copying at all - mutations to the 
receiving variable yRef are actually mutations to the passed variable 
tRef. i.e. yRef doesn't really exist at all.


The by-ref mode can emulate all of the other modes - you just have to 
code with some rules:


To use a by-ref parameter as 'in' - you must not change the value of the 
parameter in the handler being called.


To use a by-ref parameter as 'out' - you must not read the parameter at 
all and only change the value of the parameter except just before you 
exit/return.


To use a by-ref parameter as 'inout' - you can read the parameter at any 
point, but only change it just before you exit/return.


In most languages, the 'copy-back' part of the 'out' and 'inout' modes 
only generally happen for normal handler exit - they don't happen if you 
throw an exception.


Now, having said all of that - there is actually a fifth parameter mode 
'call-by-name' which at least one language had - ALGOL. Basically this 
meant (IIRC) that you passed in the symbolic expression to the receiver 
so it acted as some kind of macro:


  foo(tArray[I]) - inside foo, any reference to that parameter would 
re-evaluate tArray[I] in the context of the caller.


The reason I mention this is because the way LiveCode does by-ref 
parameters for array elements is *almost* like this - but not quite as 
unwieldy. When you do:


  command myHandler @xVar
put 100 into xVar["baz"]
  end myHandler

  local tArray
  myHandler tArray[tIndex1][tIndex2]

What actually happens is somewhat equivalent to the following:

  local tArrayPath
  put tIndex1 into tArrayPath[1]
  put tIndex2 into tArrayPath[2]
  myHandlerModified tArray, tArrayPath -- a second parameter has been 
added here


With

  command myHandlerModified @xArray, pArrayPath
put 100 into xArray[pArrayPath]["baz"]
  end myHandlerModified

Basically, the 'path' is frozen before the call, but implicitly used 
within the call when mutating the by-ref variable.


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: Using '@' to mark pass-by-reference (was Re: synonyms)

2017-08-18 Thread Bob Sneidar via use-livecode

That actually is a great explanation which solves a mystery I've often 
wondnered about, which is how a handler with a different variable name can 
contain the *actual* original variable. I thought the engine actually created a 
new variable and copied the incoming value to it, and then reversed this 
operation on return. Aliasing makes perfect sense. 

Bob S


> On Aug 18, 2017, at 08:13 , Mark Waddingham via use-livecode 
>  wrote:
> 
> In fact, what is happening is aliasing of variables:
> 
>  myHandler @tFoo -- when tFoo is passed to myHandler, xFoo1 in myHandler is 
> aliased to tFoo
> 
>  command myHandler @xFoo1 -- xFoo1 as a variable does not exist, it is an 
> alias to the calling var
>myOtherHandler @xFoo -- xFoo *is* tFoo, we are passing by-ref again so use 
> @ which 'passes the alias on'
>  end myHandler
> 
>  command myOtherHandler @xFoo2 -- xFoo2 as a variable does not exist, it is 
> an alias to the calling var
>answer xFoo2 -- xFoo2 *is* tFoo
>  end myOtherHandler
> 
> Perhaps I'm not explaining this very well - or there is something I'm 
> missing...
> 
> 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: Using '@' to mark pass-by-reference (was Re: synonyms)


On 2017-08-18 17:14, Bob Sneidar via use-livecode wrote:

Not sure I understand this allegory. Do you mean that there might be
dragons all over the place waiting to eat me? Or do you mean there may
be dragons waiting to eat different bits of me in different places? Or
do you mean they were about to eat the kettle of fish when a much more
appetizing meal walked into the cave i.e. me? And how did a kettle of
fish get into a dragon cave in the first place?


Lol! Any and all of those things I think...

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: Using '@' to mark pass-by-reference (was Re: synonyms)

2017-08-18 Thread Bob Sneidar via use-livecode

I did once. After that it was pretty easy. 

Bob S


> On Aug 18, 2017, at 06:53 , Mike Kerner via use-livecode 
>  wrote:
> 
> I understand the difference.  I'm just trying to help with the mental
> arithmetic.  I, and others, I'm sure, will constantly forget where the "@"
> goes, for instance.


___
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: Using '@' to mark pass-by-reference (was Re: synonyms)

2017-08-18 Thread Bob Sneidar via use-livecode

Not sure I understand this allegory. Do you mean that there might be dragons 
all over the place waiting to eat me? Or do you mean there may be dragons 
waiting to eat different bits of me in different places? Or do you mean they 
were about to eat the kettle of fish when a much more appetizing meal walked 
into the cave i.e. me? And how did a kettle of fish get into a dragon cave in 
the first place? 

Bob S

> On Aug 18, 2017, at 06:48 , Mark Waddingham via use-livecode 
>  wrote:
> 
> General references (I don't think using the term 'pointer' is appropriate) 
> are a whole different kettle of fish which come with dragons waiting to eat 
> you all over the place...

___
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: Using '@' to mark pass-by-reference (was Re: synonyms)


On 2017-08-18 15:53, Mike Kerner via use-livecode wrote:

I understand the difference.  I'm just trying to help with the mental
arithmetic.  I, and others, I'm sure, will constantly forget where the 
"@"

goes, for instance.


Okay so - the question to ask is - what would make you forget where to 
put the "@"?


In this case, if you want a by-ref parameter you have to put '@' before 
it in the signature, the proposal is to allow '@' to also be placed 
before the argument in a handler call for by-ref parameters... So it is 
entirely symmetric:


  command myHandler @xFoo
  end myHandler

  myHandler @tFoo

There is no 'de-referencing' operation as by-ref parameters implicitly 
de-reference on use - indeed, there's no need to have a de-reference 
operation because there is no such thing as a 'reference' which can be 
'put into' a variable (that would be general references - which this 
isn't about).


In fact, what is happening is aliasing of variables:

  myHandler @tFoo -- when tFoo is passed to myHandler, xFoo1 in 
myHandler is aliased to tFoo


  command myHandler @xFoo1 -- xFoo1 as a variable does not exist, it is 
an alias to the calling var
myOtherHandler @xFoo -- xFoo *is* tFoo, we are passing by-ref again 
so use @ which 'passes the alias on'

  end myHandler

  command myOtherHandler @xFoo2 -- xFoo2 as a variable does not exist, 
it is an alias to the calling var

answer xFoo2 -- xFoo2 *is* tFoo
  end myOtherHandler

Perhaps I'm not explaining this very well - or there is something I'm 
missing...


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: Using '@' to mark pass-by-reference (was Re: synonyms)

2017-08-18 Thread Mike Kerner via use-livecode

I understand the difference.  I'm just trying to help with the mental
arithmetic.  I, and others, I'm sure, will constantly forget where the "@"
goes, for instance.

On Fri, Aug 18, 2017 at 9:48 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-18 15:21, Mike Kerner via use-livecode wrote:
>
>> So how about trying to make it a little easier to read, and using "->"
>> instead (a 4D way of identifying pointers)?  The position of the symbol
>> indicates if we have are referencing or dereferencing.  ->a is a reference
>> to a (pointer to a), and a-> is dereferencing a (give me what a is
>> pointing
>> to).
>>
>
> Two reasons not to:
>
>   1) By-Reference parameters are not the same as pointers - in particular,
> dereferencing is implicit, and referencing is only allowed in the context
> of passing the parameter.
>
>   2) We already have a symbol '@' for marking by-ref parameters in handler
> signatures, so surely it makes more sense to use that in its directly
> equivalent position (on sending, as well as receiving).
>
> General references (I don't think using the term 'pointer' is appropriate)
> are a whole different kettle of fish which come with dragons waiting to eat
> you all over the place...
>
>
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Using '@' to mark pass-by-reference (was Re: synonyms)


On 2017-08-18 15:21, Mike Kerner via use-livecode wrote:

So how about trying to make it a little easier to read, and using "->"
instead (a 4D way of identifying pointers)?  The position of the symbol
indicates if we have are referencing or dereferencing.  ->a is a 
reference
to a (pointer to a), and a-> is dereferencing a (give me what a is 
pointing

to).


Two reasons not to:

  1) By-Reference parameters are not the same as pointers - in 
particular, dereferencing is implicit, and referencing is only allowed 
in the context of passing the parameter.


  2) We already have a symbol '@' for marking by-ref parameters in 
handler signatures, so surely it makes more sense to use that in its 
directly equivalent position (on sending, as well as receiving).


General references (I don't think using the term 'pointer' is 
appropriate) are a whole different kettle of fish which come with 
dragons waiting to eat you all over the place...


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: Using '@' to mark pass-by-reference (was Re: synonyms)

2017-08-18 Thread Mike Kerner via use-livecode

So how about trying to make it a little easier to read, and using "->"
instead (a 4D way of identifying pointers)?  The position of the symbol
indicates if we have are referencing or dereferencing.  ->a is a reference
to a (pointer to a), and a-> is dereferencing a (give me what a is pointing
to).

On Fri, Aug 18, 2017 at 9:15 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-07-04 17:39, Ben Rubinstein via use-livecode wrote:
>
>> May I hijack this thread to have another go at promoting my feature
>> request for a bit of syntax sugar around parameters which I _think_
>> would not have a very deep implementation requirement?
>>
>> http://quality.livecode.com/show_bug.cgi?id=8945
>>
>
> It is no longer a hijack - I've changed the name of the thread :)
>
> (Although I have hijacked your original post by rewriting the content
> slightly - I hope you don't mind too much!)
>
> The underlying problem here is that whether or not an argument passed to a
> handler is treated 'by value' or 'by reference' is determined by the
> handler at the point it is invoked - not at the point it is called
> (remember that the message path means that one call can end up invoking
> several handlers as it passes through the message path).
>
> This is the only way it can work at the moment because LiveCode Script
> does not require you to explicitly mark arguments that should be passed by
> reference - without that bit of information, the only thing you have to
> 'trust' is whether '@' is present in the signature of the parameter in the
> handler definition *when that handler is actually executed*.
>
> Ben's suggestion (which I think is a really good one - even though I've
> not commented on it at all up until now - including the original
> enhancement request) is that we use '@' as an explicit marker for whether
> an argument should be passed by reference.
>
> I can think of at least one other language which has a similar thing - C#.
> C# has both by-ref and by-value - and it requires 'ref' to be used on
> arguments to method parameters which are 'by-ref'. It requires this because
> C# allows method overloading - you can have two methods in a class with the
> same name as long as their parameters are different:
>
> class RefOverloadExample
> {
> public void SampleMethod(int i) { }
> public void SampleMethod(ref int i) { }
> }
>
> Because C# requires 'ref' on arguments it can disambiguate the call to
> 'SampleMethod' - SampleMethod(tFoo), SampleMethod(ref tFoo).
>
> [ For more details about this see https://docs.microsoft.com/en-
> us/dotnet/csharp/language-reference/keywords/ref ]
>
> The weak form of the proposal would not require @ before arguments to
> reference parameters, but would require that it is not present before
> arguments to value parameters:
>
>   command myHandler @xRef, pValue
>   end myHandler
>
>   myHandler tRefVar, tValueVar - fine
>   myHandler @tRefVar, tValueVar - fine
>   myHandler [@]tRefVar, @tValueVar - not fine: passing tValueVar by
> reference to by-value parameter
>
> The strong form of the proposal would require @ before arguments to
> reference parameters:
>
>   command myHandler @xRef, pValue
>   end myHandler
>
>   myHandler tRefVar, tValueVar - not fine: passing tRefVar by value to
> by-ref parameter
>   myHandler @tRefVar, tValueVar - fine
>
> The weak form would still allow you to make the 'accidentally passing the
> wrong argument to a reference parameter' coding fault, but at least if you
> used @ consistently then it would catch the 'passing the wrong argument to
> a value parameter' coding fault. The strong form would eliminate
> ref-parameter related coding faults entirely.
>
> Even in its weak form, there are a few other fringe benefits:
>
>   - we could allow @ to mean: I know this is a by-ref parameter,
> but I don't care about what it gets changed to, I just want it to be
>  on input
>   - we could allow 'put x into param(y)' if the y'th argument was marked
> with '@'
>   - if @ is used consistently then it solves the mismatched reference
> parameter markings in the message path problem:
>group: on myHandler @isRef
>card: on myHandler isRef -- oops, I forgot the '@'
>
> There is a very low risk, in my view, of breaking backwards
>>
>
> Ignoring lexical issues (i.e. @ being allowed in an identifier - which is
> only the case because of the way the parameter list of handlers is parsed -
> ick!), then the weak form has no backwards-compatibility issues as far as I
> can see.
>
> In terms of the lexical issue, then the change would mean that '@' would
> become a self-delimiting token - and not be allowed in identifiers.
>
> I can't imagine there is any reasonable code out there which uses '@' in
> identifiers, a bit like "'" is also allowed in identifiers - so changing
> that is probably 'completely' safe. Indeed, we are already considering
> removing various characters from the definition of identifier to allow a
> little more

Using '@' to mark pass-by-reference (was Re: synonyms)


On 2017-07-04 17:39, Ben Rubinstein via use-livecode wrote:

May I hijack this thread to have another go at promoting my feature
request for a bit of syntax sugar around parameters which I _think_
would not have a very deep implementation requirement?

http://quality.livecode.com/show_bug.cgi?id=8945


It is no longer a hijack - I've changed the name of the thread :)

(Although I have hijacked your original post by rewriting the content 
slightly - I hope you don't mind too much!)


The underlying problem here is that whether or not an argument passed to 
a handler is treated 'by value' or 'by reference' is determined by the 
handler at the point it is invoked - not at the point it is called 
(remember that the message path means that one call can end up invoking 
several handlers as it passes through the message path).


This is the only way it can work at the moment because LiveCode Script 
does not require you to explicitly mark arguments that should be passed 
by reference - without that bit of information, the only thing you have 
to 'trust' is whether '@' is present in the signature of the parameter 
in the handler definition *when that handler is actually executed*.


Ben's suggestion (which I think is a really good one - even though I've 
not commented on it at all up until now - including the original 
enhancement request) is that we use '@' as an explicit marker for 
whether an argument should be passed by reference.


I can think of at least one other language which has a similar thing - 
C#. C# has both by-ref and by-value - and it requires 'ref' to be used 
on arguments to method parameters which are 'by-ref'. It requires this 
because C# allows method overloading - you can have two methods in a 
class with the same name as long as their parameters are different:


class RefOverloadExample
{
public void SampleMethod(int i) { }
public void SampleMethod(ref int i) { }
}

Because C# requires 'ref' on arguments it can disambiguate the call to 
'SampleMethod' - SampleMethod(tFoo), SampleMethod(ref tFoo).


[ For more details about this see 
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref 
]


The weak form of the proposal would not require @ before arguments to 
reference parameters, but would require that it is not present before 
arguments to value parameters:


  command myHandler @xRef, pValue
  end myHandler

  myHandler tRefVar, tValueVar - fine
  myHandler @tRefVar, tValueVar - fine
  myHandler [@]tRefVar, @tValueVar - not fine: passing tValueVar by 
reference to by-value parameter


The strong form of the proposal would require @ before arguments to 
reference parameters:


  command myHandler @xRef, pValue
  end myHandler

  myHandler tRefVar, tValueVar - not fine: passing tRefVar by value to 
by-ref parameter

  myHandler @tRefVar, tValueVar - fine

The weak form would still allow you to make the 'accidentally passing 
the wrong argument to a reference parameter' coding fault, but at least 
if you used @ consistently then it would catch the 'passing the wrong 
argument to a value parameter' coding fault. The strong form would 
eliminate ref-parameter related coding faults entirely.


Even in its weak form, there are a few other fringe benefits:

  - we could allow @ to mean: I know this is a by-ref 
parameter, but I don't care about what it gets changed to, I just want 
it to be  on input
  - we could allow 'put x into param(y)' if the y'th argument was marked 
with '@'
  - if @ is used consistently then it solves the mismatched reference 
parameter markings in the message path problem:

   group: on myHandler @isRef
   card: on myHandler isRef -- oops, I forgot the '@'


There is a very low risk, in my view, of breaking backwards


Ignoring lexical issues (i.e. @ being allowed in an identifier - which 
is only the case because of the way the parameter list of handlers is 
parsed - ick!), then the weak form has no backwards-compatibility issues 
as far as I can see.


In terms of the lexical issue, then the change would mean that '@' would 
become a self-delimiting token - and not be allowed in identifiers.


I can't imagine there is any reasonable code out there which uses '@' in 
identifiers, a bit like "'" is also allowed in identifiers - so changing 
that is probably 'completely' safe. Indeed, we are already considering 
removing various characters from the definition of identifier to allow a 
little more flexibility in the symbols we can use (not that I 
particularly want to add that many symbols, however I fear that adding a 
few more is unavoidable if we want to keep the language ergonomic).


My general feeling is that the weak form is much better than we have 
now, but the strong form is actually how things should be. Indeed, as 
'by-ref' is a more complicated concept in many ways than 'by-value' it 
seems fitting that it should be explicitly marked - especially as if we 
were able to move to the strong form, we would eliminate the

Re: synonyms

2017-07-05 Thread Mark Wieder via use-livecode


On 07/05/2017 08:32 AM, Bob Sneidar via use-livecode wrote:

Not too bad. For every 5 psychiatrists there are 10 views on what causes 
bipolar syndrome.


That's obviously a binary 10.

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

2017-07-05 Thread Bob Sneidar via use-livecode

> On Jul 4, 2017, at 10:38 , Mark Wieder via use-livecode 
>  wrote:
> 
> Well, yes and no.

>From a programming with synonyms standpoint, this statement should always 
>return false. Which is a synonym for 0. Which is a synonym for  in an 
>8 bit word. 

Bob S




___
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: synonyms

2017-07-05 Thread Bob Sneidar via use-livecode

Not too bad. For every 5 psychiatrists there are 10 views on what causes 
bipolar syndrome. 

Bob S


> On Jul 4, 2017, at 01:02 , Mark Waddingham via use-livecode 
>  wrote:
> 
 For a problem placed before any three coders, you will find at least four 
 different solutions. 


___
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

OT Re: synonyms

2017-07-05 Thread David V Glasgow via use-livecode

My ancient Quaker father-in-law (now deceased) never gave them up. 

His first utterance to me was “What has thou done with Liss?” - a question I 
was none to keen on answering (‘Liss'= his daughter)

His language took a little getting used to, but after a while I barely noticed, 
except to enjoy it.

Cheers,

David Glasgow

> On 4 Jul 2017, at 8:55 pm, Richmond Mathewson via use-livecode 
>  wrote:
> 
> Thou hast no need at all to be pompous, just a wee bit old-fashioned.
> 
> Thou art more than welcome me to the extremely select club of language 
> nutters (current membership: 1 and a few stray Mennonites)
> who want to bring Thou, thee, they and thine back into mainstream English 
> usages.
> 
> Membership is free, and thou art not required to wear a daft uniform, change 
> thy dietary habits, take any odd vows, or
> reassess thy personal hygiene regime . . .
> 
> However, if thou usest the middle-finger in any way whatsoever thou wilt be 
> expelled forthwith, fifthwith and sixthwith!
> 
> None of our membership have become obsessive enough to remove their 
> middle-finger, Yet!
> 
> Richmond.
> 
> On 7/4/17 10:43 pm, Mark Wieder via use-livecode wrote:
>> On 07/04/2017 11:34 AM, Mark Waddingham via use-livecode wrote:
>>> It was a generic 'you' and not you 'you' :)
>>> 
>>> I think part of my brain decided on 'one' there but my fingers objected 
>>> ('when' should have been 'one').
>>> 
>>> Indeed in this instance 'one' in both places probably would have been 
>>> better, however I always feel like that sounds slightly pompous...
>> 
>> LOL
>> 
>> Yes, "one" would maybe have been more syntactically correct but made you 
>> feel pompous. "You" in both places emphasizes the lexical ambiguity. So even 
>> though the sentence would be diagrammed the same way (the bytecode 
>> implementation would be identical) they feel completely different.
>> 
>> So... aren't you glad we have synonyms? 
>> 
>> And placing the sentence in passive voice would eliminate the above problems 
>> by allowing a different creative process to take place. Thus my argument for 
>> synonyms: not that it makes much (if any) difference at the engine level, 
>> but it allows for some right-brain interaction in what would otherwise be a 
>> completely left-brain activity.
>> 
> 
> ___
> 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: synonyms

2017-07-04 Thread Richmond Mathewson via use-livecode


Thou hast no need at all to be pompous, just a wee bit old-fashioned.

Thou art more than welcome me to the extremely select club of language 
nutters (current membership: 1 and a few stray Mennonites)
who want to bring Thou, thee, they and thine back into mainstream 
English usages.


Membership is free, and thou art not required to wear a daft uniform, 
change thy dietary habits, take any odd vows, or

reassess thy personal hygiene regime . . .

However, if thou usest the middle-finger in any way whatsoever thou wilt 
be expelled forthwith, fifthwith and sixthwith!


None of our membership have become obsessive enough to remove their 
middle-finger, Yet!


Richmond.

On 7/4/17 10:43 pm, Mark Wieder via use-livecode wrote:

On 07/04/2017 11:34 AM, Mark Waddingham via use-livecode wrote:

It was a generic 'you' and not you 'you' :)

I think part of my brain decided on 'one' there but my fingers 
objected ('when' should have been 'one').


Indeed in this instance 'one' in both places probably would have been 
better, however I always feel like that sounds slightly pompous...


LOL

Yes, "one" would maybe have been more syntactically correct but made 
you feel pompous. "You" in both places emphasizes the lexical 
ambiguity. So even though the sentence would be diagrammed the same 
way (the bytecode implementation would be identical) they feel 
completely different.


So... aren't you glad we have synonyms? 

And placing the sentence in passive voice would eliminate the above 
problems by allowing a different creative process to take place. Thus 
my argument for synonyms: not that it makes much (if any) difference 
at the engine level, but it allows for some right-brain interaction in 
what would otherwise be a completely left-brain activity.




___
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: synonyms


On 07/04/2017 11:34 AM, Mark Waddingham via use-livecode wrote:

It was a generic 'you' and not you 'you' :)

I think part of my brain decided on 'one' there but my fingers objected ('when' 
should have been 'one').

Indeed in this instance 'one' in both places probably would have been better, 
however I always feel like that sounds slightly pompous...


LOL

Yes, "one" would maybe have been more syntactically correct but made you 
feel pompous. "You" in both places emphasizes the lexical ambiguity. So 
even though the sentence would be diagrammed the same way (the bytecode 
implementation would be identical) they feel completely different.


So... aren't you glad we have synonyms? 

And placing the sentence in passive voice would eliminate the above 
problems by allowing a different creative process to take place. Thus my 
argument for synonyms: not that it makes much (if any) difference at the 
engine level, but it allows for some right-brain interaction in what 
would otherwise be a completely left-brain activity.


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

2017-07-04 Thread Ben Rubinstein via use-livecode


Anniversary vote! Renew your vows!

On 04/07/2017 18:20, Mark Wieder via use-livecode wrote:

On 07/04/2017 08:39 AM, Ben Rubinstein via use-livecode wrote:


This is also at:
http://quality.livecode.com/show_bug.cgi?id=8945


Heh. I just went to add my vote to this and found that I had already done so 
some seven years ago. 




___
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: synonyms

It was a generic 'you' and not you 'you' :)

I think part of my brain decided on 'one' there but my fingers objected ('when' 
should have been 'one').

Indeed in this instance 'one' in both places probably would have been better, 
however I always feel like that sounds slightly pompous...

Sent from my iPhone

> On 4 Jul 2017, at 18:49, Mark Wieder via use-livecode 
>  wrote:
> 
>> On 07/04/2017 10:37 AM, Mark Waddingham via use-livecode wrote:
>> 
>> Of course, once when has figured out all the potential issues and 
>> complexities which arise from such an addition, you then actually have to 
>> implement it.
> 
> Ooo... I *do* hope that's a generic "you" and not a finger pointed my way...
> 
> -- 
> 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


___
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: synonyms

2017-07-04 Thread Richmond Mathewson via use-livecode

'Twas a pity when most dialects of English gave up the "Thou, thee, thy, 
thine" set of second person pronouns.


wait 1 ticks

Richmond.

On 7/4/17 8:49 pm, Mark Wieder via use-livecode wrote:

On 07/04/2017 10:37 AM, Mark Waddingham via use-livecode wrote:

Of course, once when has figured out all the potential issues and 
complexities which arise from such an addition, you then actually 
have to implement it.


Ooo... I *do* hope that's a generic "you" and not a finger pointed my 
way...




___
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: synonyms


On 07/04/2017 10:37 AM, Mark Waddingham via use-livecode wrote:

Of course, once when has figured out all the potential issues and 
complexities which arise from such an addition, you then actually have 
to implement it.


Ooo... I *do* hope that's a generic "you" and not a finger pointed my way...

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


On 07/04/2017 01:02 AM, Mark Waddingham via use-livecode wrote:

For a problem placed before any three coders, you will find at least 
four different solutions. Limiting the language limits the ways in 
which a problem may be thought of - that's the basis of the 
linguistic relativism, and it applies to programming languages as 
well as to natural languages.


Of course.


Although I think Mark's original statement is conflating two things - 
there is the *abstract* method of solution, and the *concrete* rendering 
of the solution.


Well, yes and no.
I'm arguing for allowing the concrete solution in support of the 
abstract solution (see below).




In most cases you might get 'four different solutions' - however it is 
more than likely that at least half of them will be the same if you 
strip away all the concrete baggage (i.e. syntax, variable names, choice 
of array of string-list etc.). Simply because abstractly there tends to 
be far fewer ways to solve any one given problem (in computing at least) 
than there is concretely, as computers think about things in a specific 
way (which often is nothing like how humans do on an average day-to-day 
basis).


Aside from the folding of several similar solutions into a single one as 
far as the computer goes (and I have no dissension there, nor any real 
need for any synonyms at that much of a context-free level), I think 
that allowing for more synonyms in the language allows at a human level 
(abstracted from the ones and zeros of the computer) for a more creative 
approach to viewing possible solutions to any given problem. So that a 
faster or more elegant or more functional or... solution may arise that 
may not have come about without the natural-language associations of the 
synonym(s). For instance, "is" may evoke associations that "=" does not, 
and vice versa. For me "<>" evokes BASIC and I tend to think more 
linearly, where "is not" has different connotations, as does "!=", even 
if they all condense to the same machine code.


For the same reason, I use "switch" constructs more than nested or 
sequential "if"s when possible, partly because they're easier for me to 
read afterwards and therefore easier to maintain, but also because they 
impact my thought processes differently, even though they become the 
same machine code as far as the silicon is concerned.


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


On 2017-07-04 19:14, Mark Wieder via use-livecode wrote:

On 07/04/2017 01:18 AM, Mark Waddingham via use-livecode wrote:
Quite right. After I posted that bit I realized that after 'fixing'
the parser one would also need to deal with the complexities of
assigning the variables, and the issues arising from allowing 'local'
declarations when local variables may or may not already be assigned,
etc.


Not to mention the actual passing of them around (i.e. the internal 
representation, and not just the syntactic representation); how they 
interact as things pass through the message path; how they might bind 
when called from languages such as JavaScript (from the browser - e.g. 
the recently added ability to the HTML5 engine); or, indeed, from other 
languages as LiveCode evolves to interoperate more heavily; how they 
might be 'compiled' in the future to native code...


The list of considerations for addition of any general language feature 
often ends up being as long as your proverbial arm.


Of course, once when has figured out all the potential issues and 
complexities which arise from such an addition, you then actually have 
to implement it.


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


On 07/04/2017 08:39 AM, Ben Rubinstein via use-livecode wrote:


This is also at:
http://quality.livecode.com/show_bug.cgi?id=8945


Heh. I just went to add my vote to this and found that I had already 
done so some seven years ago. 


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


On 07/04/2017 01:18 AM, Mark Waddingham via use-livecode wrote:

Just to point this out but 'just' changing the script parser does 
absolutely nothing at all beyond meaning that a piece of text of the 
form now accepted by said modified parser does not throw a syntax error. 
Said change would actually *do* absolutely nothing.


Quite right. After I posted that bit I realized that after 'fixing' the 
parser one would also need to deal with the complexities of assigning 
the variables, and the issues arising from allowing 'local' declarations 
when local variables may or may not already be assigned, etc.


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

2017-07-04 Thread Ben Rubinstein via use-livecode


On 04/07/2017 09:18, Mark Waddingham via use-livecode wrote:
Syntax is just sugar - you need to implement the feature at all levels 
underneath for it to work... Like most things (unfortunately), there's usually 
a great deal of depth involved - usually directly proportional to the 
generality of the change... In this case (as it is dealing with parameter 
passing) it is quite general indeed.


May I hijack this thread to have another go at promoting my feature request 
for a bit of syntax sugar around parameters which I _think_ would not have a 
very deep implementation requirement?


My (initial) request is for "@" to be ignored - treated as "/* @ */" - at the 
start of a parameter in a command or function call.


It seems to me a significant risk of error that it's possible to invoke a 
command or function which takes a parameter by reference, without realising 
it. Certainly it's not an aid to readability that, when looking at code that 
makes such a call, there's no clue that this is what is happening.


A change that ensured "@' is effectively ignored immediately before a 
parameter, would at least give the careful coder an elegant and concise way of 
indicating in the code that this parameter is passed by reference. Of course, 
my long term plan is that in five years or so the compiler might (at least in 
explicitVars mode) actually warn you if the @ marking is inconsistent between 
caller and callee.


There is a very low risk, in my view, of breaking backwards compatibility. At 
present, if you have explicitVars set, you cannot use @ in this way - it is an 
error. If you don't have explicitVars set, then with this code

put 23 into x
mycommand @x

mycommand would currently receive "@x" as the parameter, but after my 
suggested change would receive "23". That would be bad. But what kind of 
person would do the above anyway?!?


Arguably it would be possible to process @ in this way only when explicitVars 
was set, in which case there would be no incompatibility issues at all.


This is also at:
http://quality.livecode.com/show_bug.cgi?id=8945

cheers,

Ben

___
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: synonyms


On 2017-06-29 21:13, Mark Wieder via use-livecode wrote:

Don't know about the 'less confusing' part, but otherwise ruby lets
you interleave them: if there's an associated name with a parameter
then that parameter gets assigned to that variable. Otherwise you have
to work with the parameter position, which IMO is less intuitive, more
error-prone, and harder to read and maintain. I wouldn't object to
using python's restriction, but I don't think it's necessary. Given
that parameters are comma-separated, it's a simple change to the
script parser to allow this (not that I expect this will ever happen).


Just to point this out but 'just' changing the script parser does 
absolutely nothing at all beyond meaning that a piece of text of the 
form now accepted by said modified parser does not throw a syntax error. 
Said change would actually *do* absolutely nothing.


Syntax is just sugar - you need to implement the feature at all levels 
underneath for it to work... Like most things (unfortunately), there's 
usually a great deal of depth involved - usually directly proportional 
to the generality of the change... In this case (as it is dealing with 
parameter passing) it is quite general indeed.


In regards to named parameters. Python views functions as (essentially) 
taking two abstract parameters - a sequence (the positional parameters) 
and a dictionary (the named parameters). You can see this directly when 
you look at the 'dynamic' invocation form... Which (I think) is:


  function(*listOfArgs, *dictOfArgs)

Here, this invokes 'function' with the positional args from the list 
'listOfArgs' and the dictionary of args 'dictOfArgs'. i.e. it is 
equivalent to doing:


  function(listOfArgs[1], ..., listofArgs[n], firstKey of dictOfArgs: 
dictOfArgs[firstKey], ...)


Indeed, as has already been noted Python does not allow you to mix the 
two. Although I think you could relax that just by re-ordering all named 
args to the end of the parameter list before invocation e.g.


  function 1, foo: bar, 2

Becomes

  function 1, 2, foo:bar

You might even be able to make it so that named parameters also have a 
position - however I suspect the necessary rules underlying that would 
end up being so obtuse as to make it a somewhat pointless exercise in 
semantic uniformity, and probably not worth the effort.


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


On 2017-06-26 22:29, J. Landman Gay via use-livecode wrote:

On 6/26/17 3:14 PM, Richmond Mathewson via use-livecode wrote:


On 6/26/17 11:07 pm, J. Landman Gay via use-livecode wrote:
Just please don't remove the ones we've got. I haven't typed out 
"background" or "card" in 30 years. My brain would short out.


I wonder if it is about time in this discussion to differentiate 
between *abbreviations* and *synonyms*?


I think from the engine's perspective they're the same.


Yes - which is part of the problem.

They are actually a 'different thing' abstractly. It is just that they 
were implemented using the same mechanism because (at first glance at 
least) that mechanism 'does the same thing' when one does not consider 
what is *actually* going on.


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


On 2017-06-26 21:57, Richmond Mathewson via use-livecode wrote:

Most of us are well aware that LiveCode is NOT Hypercard any more than
I am not a small, furry mouselike mammal that danced around
the toes of dying dinosaurs: LiveCode is descended from HyperCard, and
I may be descended from small, furry mammals.


No it is not HyperCard, but it is (pretty much) a large superset of what 
HyperCard was...


Okay so there are some implementation differences - HyperCard used a 
page-based stack format, LiveCode's is in-memory; HyperCard used decimal 
arithmetic, LiveCode uses double arithmetic, HyperCard's parser was 
completely contextual, LiveCode's is a little bit of a mix (and a fair 
few other things).



"train people implicitly" . . . hard job.


Indeed it isn't easy; and most environments don't really try and do so. 
Even LiveCode at the moment doesn't help that much.


In this case, I think 'implicit' comes from an environment which tells 
you what you are doing wrong, rather than just saying when you've got it 
right. After all, learning from mistakes is a general 'fact of life' - 
however, to learn from mistakes you have to know what they are in the 
first place.



Yes; but that presupposes LiveCode is going to be burdened with the
"it's an xTalk dialect" label forever, and whether "xTalk"
continues to make sense seeing how far the xTalk outgrowths from
HyperCard have diverged.


I don't think the 'its an xTalk dialect' is that much of a burden - at 
least not from a syntax point of view. In many ways the abstractions 
which the syntax exposes are far far more important - and those persist 
regardless of the syntax which is wrapped around them.


For a problem placed before any three coders, you will find at least 
four different solutions. Limiting the language limits the ways in 
which a problem may be thought of - that's the basis of the 
linguistic relativism, and it applies to programming languages as 
well as to natural languages.


Of course.


Although I think Mark's original statement is conflating two things - 
there is the *abstract* method of solution, and the *concrete* rendering 
of the solution.


In most cases you might get 'four different solutions' - however it is 
more than likely that at least half of them will be the same if you 
strip away all the concrete baggage (i.e. syntax, variable names, choice 
of array of string-list etc.). Simply because abstractly there tends to 
be far fewer ways to solve any one given problem (in computing at least) 
than there is concretely, as computers think about things in a specific 
way (which often is nothing like how humans do on an average day-to-day 
basis).


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


On 2017-06-26 21:34, Mark Wieder via use-livecode wrote:

Heh. Autocomplete, I think, works well when you already have an idea
where you're going. I don't think it would help much with a line like

"if x "


If the autocomplete mechanism is good enough then it could it would come 
up with a list like:


  'then'
  'is '
  'contains '
  ...

Of course, there would be a big list in this case (as there are quite a 
few operators); however, other contextual information can be used to 
order it (e.g. how often had you used operators in the current script) 
and implicitly computed type information could help cut down the list to 
the things that would actually work.



My PR for 'hilite' wasn't to 'normalise' the term, but to be
consistent about its use. To this day I can't remember where
'highlight' is acceptable and where 'hilite' is proscribed, my
distaste for 'hilite' as a word notwithstanding.


Indeed - there are 'different cases' of synonyms - this would fall into 
the class of spelling variations. However, the point there was that a 
specific variation had already been chosen - 'hilite' - for better or 
for worse.



Point taken, but do you seriously believe it would be a good idea to
have different meanings for "hilite" and "highlight"? I can't imagine
that repurposing either of these for the same syntax would help in
anyone's comprehension of the language or ease in scripting. Making
the two words synonyms is the only thing that makes sense to me.


No - of course I wouldn't - but then this just goes to show that the 
'synonym' thing is a great deal deeper than it appears at first sight. 
Already in this thread the following three kinds have been noted:


  - abbreviations

  - spelling variations

  - functional synonyms

Of these, only the last can truly be called 'synonyms' - and they are 
more complex than the other two as they *should* be context dependent 
(but cannot be at the moment).


Abbreviations people probably wouldn't notice the lack of direct support 
for in the language if the tooling auto-expanded them.


In terms of spelling variations choosing *one* and sticking to it in any 
particular project is really important otherwise you can create subtle 
bugs which are virtually impossible to spot (e.g. using 'colour' as a 
key in an array in one place, but 'color' in another).


I normalized my spelling to US English when coding quite early on after 
starting at LiveCode - however, you can still see inconsistent vestiges 
lurking around in various places. Color wasn't so bad to move to as I'd 
already had that battle at the age of around 6 when playing with Amiga 
BASIC on my grandfather's computer and not being able to figure out for 
the life of me why I kept getting 'syntax error' in my code... It was 
because I was typing COLOUR and not COLOR. However, 'Behavior' took me a 
fair bit longer!



Having submitted several rejected PRs for synonyms I can vouch for the
fact that they're not that hard to add.


Just because something is 'easy' doesn't mean it is 'right'. (It is easy 
to knock down walls in a house with a big enough hammer - but you might 
not end up with a house afterwards!).


The point here is that the architecture we currently have for synonyms 
is woefully inadequate as it is global - if you apply a synonym to one 
property token then it is that way for all uses of that property, 
regardless of where they are.


For example, for one type of 'thing' the two words 'purge' and 'delete' 
might well mean the same thing... However for another type of 'thing' 
they might not.



That may be the basis of our disagreement then... I'd prefer that
everyone *not* be stamped from the same mold.


It is not about stamping everyone from the same mould - however, for 
people to work together well and efficiently you need consistent 
communication.


In the world of programming, the code is the primary means of 
communication so ensuring that is consistent amongst any one group or 
team produces big benefits.


As I already said I am against synonyms being part of the *core* 
language as they only add friction at level, and do not help (the 'core' 
of anything should be only as large as it needs to be to express 
everything built on top of it). However, I have no issue with them being 
available as tailorings - we just aren't quite at the point where this 
is usefully possible.


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

Wait I think that is what the Tree View (however imperfectly) works. 

Bob S


> On Jun 29, 2017, at 13:44 , Bob Sneidar via use-livecode 
>  wrote:
> 
> I thought it was about making the engine do it. Still, I take your point that 
> many arguments will require a lot more typing. If it's that much of a chore, 
> how about an array building pallet stack, where you type an array name, a 
> series of keyname/value/hit enter sequences and it builds the code for you? 
> Even less typing. 
> 
> Bob S


___
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: synonyms

I thought it was about making the engine do it. Still, I take your point that 
many arguments will require a lot more typing. If it's that much of a chore, 
how about an array building pallet stack, where you type an array name, a 
series of keyname/value/hit enter sequences and it builds the code for you? 
Even less typing. 

Bob S

> On Jun 29, 2017, at 13:00 , Richard Gaskin via use-livecode 
>  wrote:
> 
> > If it's that big a deal someone could write a function that takes
> > doSomething type="chart"  size="100"
> > and converts it
> 
> That's pretty much what this thread is about.

___
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: synonyms

2017-06-29 Thread Richard Gaskin via use-livecode

Bob Sneidar wrote:

> On Jun 29, 2017, at 10:33 , Richard Gaskin wrote:
>>
>> > put "chart" into tType
>> > put "100" into tSize
>> > doSomething tType, tSize
>>
>> That's not a one-liner.  That's three lines.  :)
>>
>> The call itself is indeed only one line, but to prep the args for the
>> call requires as many additional lines as there are args.
...
> put "chart" into tType ; put "100" into tSize ; doSomething tType,
> tSize
>
> That is a one liner too.

Not in this context.  In programming, a "line" is generally understood 
to be referring to a statement.  Whether the statements are separated by 
0x10 or 0x59 is less the point than that a lot more typing is happening.

> So what? Are we averse to carriage returns?

No, just typing in general. :)

The array example about is about 70 keystrokes, while this:

  doSomething type="chart" size="100"

...is about half as many.

With just two args it doesn't matter much.

But once we start looking at the scope of args supported by rich 
functions like R's plot command or Hugh Senior's great ChartMaker the 
additional typing can add up very significantly.

> If it's that big a deal someone could write a function that takes
> doSomething type="chart"  size="100"
> and converts it

That's pretty much what this thread is about.

> to:
> doSomething put "chart" into type ; put "100" into size ; doSomething
> type, size
> and then replaces it in your script editor with a hotkey. I just think
> the whole thing is majoring in the minors.

Preprocessing. I like it. Could be good.  Let's call that Option 5. :)

> I suppose lots of things are possible in other languages. Are we
> trying to be just like all the other languages?

Like I said, I'm not at all married to the idea of having named params 
in LC.  If Mark Waddingham were to show up here and say, "I changed my 
mind, let's do it!" I'd happily use them, but I've gotten along well 
enough without them all these years that their absence isn't stopping me 
from shipping anything.

What I find interesting about this thread is discovering the range of 
use cases others have in mind for named param.  All this time I thought 
I was alone in finding them useful.  Good ideas have shown up here.

Whether named params or something else, personally I'm glad the language 
grows with new features from time to time.

Those of us using xTalks from the beginning remember that we spent about 
half our working lives without arrays, and had to wait nearly half a 
decade for SuperCard to deliver the first xTalk implementation of custom 
properties.

Today, I can't imagine trying to get my work done without either of those.

Sometimes even sprawling discussions like this one give rise to ideas 
that later become valuable features.

Other times they become useful libraries, or additions to Master Library.

And sometimes it's just entertainment.

But there are worse ways to enjoy oneself than to explore new directions 
in scripting language design among friends.

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

2017-06-29 Thread Mark Wieder via use-livecode


On 06/29/2017 09:57 AM, Alex Tweedly via use-livecode wrote:

Mark,

are you trying to allow mixing of positional and named actual parameters ?


Exactly.



In your example, is "This is a chart" the actual parameter for the first 
or second positional parameter ?


Would it not be less confusing to expect (as Python does) that non-named 
parameters must come first in the actual usage, so they can be 
unambiguously allocated to the correct parameter place ?


[  i.e. SyntaxError: non-keyword arg after keyword arg ]


Don't know about the 'less confusing' part, but otherwise ruby lets you 
interleave them: if there's an associated name with a parameter then 
that parameter gets assigned to that variable. Otherwise you have to 
work with the parameter position, which IMO is less intuitive, more 
error-prone, and harder to read and maintain. I wouldn't object to using 
python's restriction, but I don't think it's necessary. Given that 
parameters are comma-separated, it's a simple change to the script 
parser to allow this (not that I expect this will ever happen).


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




On 29/06/2017 19:11, Bob Sneidar via use-livecode wrote:



That's possible in R, Python, CSS, and others, but not natively in LC.

I suppose lots of things are possible in other languages. Are we trying to be 
just like all the other languages?

No. What we should be trying to do is pick out the best, worthwhile 
features of other languages and see if they fit comfortably within LC.


One aspect of that is whether they will be either confusing to, or be 
sadly missed by, many potential LC converts. So the fact that this 
feature (with variations) occurs in so many other, popular languages is 
relevant - it makes it, IMHO, unlikely they will be confusing to very 
many people coming to LC from other (modern) language backgrounds, and 
it also means they will be missed by many.


Even other languages not in the above list (e.g. Perl) which do *not* 
have named parameters (or keyword args, or ...) do have simple, commonly 
used ways round it - Perl passes arguments as a dictionary (i.e. an 
array in LC terms), and has a simple, clean, succinct way to fill it 
that dictionary either in, or immediately prior to, the function call.  
So the benefits of the mechanism are known to even more people who 
already program in a modern language.



-- Alex.


___
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: synonyms

put "chart" into tType ; put "100" into tSize ; doSomething tType, tSize

That is a one liner too. So what? Are we averse to carriage returns? If it's 
that big a deal someone could write a function that takes
> doSomething type="chart"  size="100"
and converts it to:
> doSomething put "chart" into type ; put "100" into size ; doSomething type, 
> size

and then replaces it in your script editor with a hotkey. I just think the 
whole thing is majoring in the minors. 

> That's possible in R, Python, CSS, and others, but not natively in LC.

I suppose lots of things are possible in other languages. Are we trying to be 
just like all the other languages? 

Bob S



> On Jun 29, 2017, at 10:33 , Richard Gaskin via use-livecode 
>  wrote:
> 
> > put "chart" into tType
> > put "100" into tSize
> > doSomething tType, tSize
> 
> That's not a one-liner.  That's three lines.  :)
> 
> The call itself is indeed only one line, but to prep the args for the call 
> requires as many additional lines as there are args.
> 
> This is a one-linter:
> 
>  doSomething type="chart"  size="100"
> 
> That's possible in R, Python, CSS, and others, but not natively in LC.
> 
> -- 
> Richard Gaskin


___
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: synonyms

2017-06-29 Thread Richard Gaskin via use-livecode

Bob Sneidar wrote:

> Sorry, I simply do not see any advantage to this, other than making a
> one liner to pass data to a command or function.
>
> put "chart" into tType
> put "100" into tSize
> doSomething tType, tSize

That's not a one-liner.  That's three lines.  :)

The call itself is indeed only one line, but to prep the args for the 
call requires as many additional lines as there are args.

This is a one-linter:

  doSomething type="chart"  size="100"

That's possible in R, Python, CSS, and others, but not natively in LC.

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

Mark,

are you trying to allow mixing of positional and named actual parameters ?

In your example, is "This is a chart" the actual parameter for the first 
or second positional parameter ?

Would it not be less confusing to expect (as Python does) that non-named 
parameters must come first in the actual usage, so they can be 
unambiguously allocated to the correct parameter place ?

[  i.e. SyntaxError: non-keyword arg after keyword arg ]

-- Alex.

On 29/06/2017 17:19, Mark Wieder via use-livecode wrote:

On 06/28/2017 08:55 AM, Richard Gaskin via use-livecode wrote:

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

I think if the loophole of allowing space-separated parameters were 
fixed then the following syntax might work, thus allowing the engine's 
parser to differentiate between named parameters and otherwise (the 
following would be four parameters, two of them named):

DoSomething name: "my chart", "This is a chart", width: 100, pArray

___
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: synonyms



On 29/06/2017 17:43, Mike Bonner via use-livecode wrote:

yeah, that was kinda my point.  It bipasses the need to jump through all
the hoops of building up the proper string, then having to break it into
parts on the other end.  My earlier example (way over simplified) ended up
using split create an array out of name value pairs.. It just makes more
sense to me, to pass in the array to begin with.

Having said that, building such a string could be simplified using merge..
doSomething 12,4, merge("size=[[tsize]],row=[[gAData]]")

??
[[gAData]] is still not convertable to a string, so I don't see how that 
could work.


But who cares :-) ?

For some cases - basically simpler ones - the string parsing works 
nicely, though it can be a bit untidy when you are passing variables.


For 98% of the others, an array of named/optional parameters works well 
(and you can use tricks/functions to make that less verbose).


doSomething 12, 4, _("size", tSize, row, gAData)
 works well for me, is probably anathema to some (many?) others

and for the last 2% where you want named, optional, pass-by-reference 
parameters - you're out of luck,  maybe LCB will help some day.


-- Alex.


But again, you either do the work first (and build the array to send)  or
you do the work after (and break up the name value pairs after the fact.)
  It just seems simpler to me to use arrays from the start.

On Thu, Jun 29, 2017 at 10:31 AM, Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 29/06/2017 17:17, Mike Bonner via use-livecode wrote:


The thing about passing in as an array is.. its just a different form of
name value pairs, so it sidesteps the whole issue.
alue pairs.


Not quite - there's a crucial difference.

Using an array for name/value pairs, you can pass in an array as an actual
parameter.

You can't do that with strings for the name/value pairs.

put gAData into tA["row"]
put 100 into tA["size"]
DoSomething 12, 4, tA

but you can't do
DoSomething 12, 4, "size=100", "row=" & gAData
because the array gAData can't be automatically converted to/from a string
to pass it.

-- Alex.


___
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: synonyms

2017-06-29 Thread Mike Bonner via use-livecode

yeah, that was kinda my point.  It bipasses the need to jump through all
the hoops of building up the proper string, then having to break it into
parts on the other end.  My earlier example (way over simplified) ended up
using split create an array out of name value pairs.. It just makes more
sense to me, to pass in the array to begin with.

Having said that, building such a string could be simplified using merge..
doSomething 12,4, merge("size=[[tsize]],row=[[gAData]]")

But again, you either do the work first (and build the array to send)  or
you do the work after (and break up the name value pairs after the fact.)
 It just seems simpler to me to use arrays from the start.

On Thu, Jun 29, 2017 at 10:31 AM, Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 29/06/2017 17:17, Mike Bonner via use-livecode wrote:
>
>> The thing about passing in as an array is.. its just a different form of
>> name value pairs, so it sidesteps the whole issue.
>> alue pairs.
>>
>
> Not quite - there's a crucial difference.
>
> Using an array for name/value pairs, you can pass in an array as an actual
> parameter.
>
> You can't do that with strings for the name/value pairs.
>
>put gAData into tA["row"]
>put 100 into tA["size"]
>DoSomething 12, 4, tA
>
> but you can't do
>DoSomething 12, 4, "size=100", "row=" & gAData
> because the array gAData can't be automatically converted to/from a string
> to pass it.
>
> -- Alex.
>
>
> ___
> 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: synonyms


On 29/06/2017 17:17, Mike Bonner via use-livecode wrote:

The thing about passing in as an array is.. its just a different form of
name value pairs, so it sidesteps the whole issue.
alue pairs.


Not quite - there's a crucial difference.

Using an array for name/value pairs, you can pass in an array as an 
actual parameter.


You can't do that with strings for the name/value pairs.

   put gAData into tA["row"]
   put 100 into tA["size"]
   DoSomething 12, 4, tA

but you can't do
   DoSomething 12, 4, "size=100", "row=" & gAData
because the array gAData can't be automatically converted to/from a 
string to pass it.


-- Alex.


___
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: synonyms

2017-06-29 Thread Mark Wieder via use-livecode


On 06/28/2017 08:55 AM, Richard Gaskin via use-livecode wrote:


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


I think if the loophole of allowing space-separated parameters were 
fixed then the following syntax might work, thus allowing the engine's 
parser to differentiate between named parameters and otherwise (the 
following would be four parameters, two of them named):


DoSomething name: "my chart", "This is a chart", width: 100, pArray

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

2017-06-29 Thread Mike Bonner via use-livecode

The thing about passing in as an array is.. its just a different form of
name value pairs, so it sidesteps the whole issue.



On Thu, Jun 29, 2017 at 10:11 AM, Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

> No, what I meant was Richard's fourth method, described in
>
>
>> 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
>>
> As I said in the follow-up email (with changed subject line), I think that
> works perfectly, except it is rather verbose.
>
> -- Alex.
>
>
>
> On 29/06/2017 17:00, Bob Sneidar via use-livecode wrote:
>
>> I'm not sure what you mean by "pass by parameters" but I pass arrays by
>> parameters all the time. If you mean:
>>
>> function getSomeInfo @aMyArray
>> -- do some stuff
>> return true
>> end getSomeInfo
>>
>> That works fine.
>>
>> Bob S
>>
>>
>> On Jun 28, 2017, at 15:14 , Alex Tweedly via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> He also mention a fourth method - using arrays - which he describes as
>>> "more with the grain" which is more appealing, since it solves all the
>>> above problems except the limitation on not using 'pass-by-reference'
>>> parameters. But I'll split that off to a separate response, with a changed
>>> subject/thread header.
>>>
>>> -- Alex.
>>>
>>
>> ___
>> 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: Array assignment / initialization [was Re: synonyms]

2017-06-29 Thread Mark Wieder via use-livecode


On 06/28/2017 03:32 PM, Alex Tweedly via use-livecode wrote:

Yes, it would be nice if we had an easier (terser) way to assign to an 
array. Maybe something like Python / Perl use to assign to a dictionary.


...and ruby. Let's not forget ruby. Ruby allows for

DoSomething name: "my chart", width: 100, label: "This is a chart", 
annaray: sAMine




put { "name": "my chart", "width": 100, "label": "This is a chart", 
"anarray": sAMine } into tA

DoSomething tA


LCB lets you do just that. And I'm promised that *someday* the LCB 
syntax will morph into the fabled Open Language project that's used as 
the excuse not to fix these anomalies.


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


No, what I meant was Richard's fourth method, described in



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
As I said in the follow-up email (with changed subject line), I think 
that works perfectly, except it is rather verbose.


-- Alex.


On 29/06/2017 17:00, Bob Sneidar via use-livecode wrote:

I'm not sure what you mean by "pass by parameters" but I pass arrays by 
parameters all the time. If you mean:

function getSomeInfo @aMyArray
-- do some stuff
return true
end getSomeInfo

That works fine.

Bob S



On Jun 28, 2017, at 15:14 , Alex Tweedly via use-livecode 
 wrote:

He also mention a fourth method - using arrays - which he describes as "more with 
the grain" which is more appealing, since it solves all the above problems except 
the limitation on not using 'pass-by-reference' parameters. But I'll split that off to a 
separate response, with a changed subject/thread header.

-- Alex.


___
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: synonyms

Sorry, I simply do not see any advantage to this, other than making a one liner 
to pass data to a command or function. 

put "chart" into tType
put "100" into tSize
doSomething tType, tSize

What is the big deal? This can become:
put "chart" into tType ; put "100" into tSize ; doSomething tType, tSize

TADAAA! One liner. ;-)

Bob S



> On Jun 29, 2017, at 08:59 , Alex Tweedly via use-livecode 
>  wrote:
> 
> Yeah, so do I - that's why it's important to me :-).
> 
> But you can't do that using the "parameters as strings" techniques described 
> by Mike Bpnner and Paul Dupuis - i.e.
> 
>   DoSomething "type=chart", "size=100"
> 
> or
> 
>  DoSomething "type=chart, size=100"


___
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: synonyms

I'm not sure what you mean by "pass by parameters" but I pass arrays by 
parameters all the time. If you mean:

function getSomeInfo @aMyArray
   -- do some stuff
   return true
end getSomeInfo

That works fine. 

Bob S


> On Jun 28, 2017, at 15:14 , Alex Tweedly via use-livecode 
>  wrote:
> 
> He also mention a fourth method - using arrays - which he describes as "more 
> with the grain" which is more appealing, since it solves all the above 
> problems except the limitation on not using 'pass-by-reference' parameters. 
> But I'll split that off to a separate response, with a changed subject/thread 
> header.
> 
> -- Alex.


___
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: synonyms


Yeah, so do I - that's why it's important to me :-).

But you can't do that using the "parameters as strings" techniques 
described by Mike Bpnner and Paul Dupuis - i.e.


   DoSomething "type=chart", "size=100"

or

  DoSomething "type=chart, size=100"


Also, you can use the technique of using paramcount() and param(i) to 
pass a variable number of parameters - but you can't make those variable 
ones be passed by reference (unless I've missed something).


-- Alex.


On 29/06/2017 16:14, Mike Kerner via use-livecode wrote:

Alex,
I don't understand.  I pass arrays as parameters all the time, and I use
the pass by reference "@", too.
___
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: synonyms

2017-06-29 Thread Mike Kerner via use-livecode

Alex,
I don't understand.  I pass arrays as parameters all the time, and I use
the pass by reference "@", too.
___
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: Array assignment / initialization [was Re: synonyms]


On 28/06/2017 23:32, Alex Tweedly via use-livecode wrote:
Yes, it would be nice if we had an easier (terser) way to assign to an 
array. Maybe something like Python / Perl use to assign to a dictionary.


   put { "name": "my chart", "width": 100, "label": "This is a chart", 
"anarray": sAMine } into tA

   DoSomething tA

OK, here I go answering my own post (again).

function _
  local tA
  repeat with i = 1 to paramcount()
 put param(i+1) into tA[param(i)]
  end repeat
  return tA
end _

and then I can do

put _("name","my chart",   "width",100,   "label","This is a chart",   
"anarray",sAMine) into tA

DoSomething tA

or, indeed, even

DoSomething  _("name","my chart",   "width",100,   "label","This is a 
chart",   "anarray",sAMine)


Still doesn't handle pass-by-reference - but that's a problem even with 
variable numbers of params in LC, so I'll accept it for this case.


-- Alex.

___
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: synonyms

2017-06-29 Thread Mike Kerner via use-livecode

ick.

On Wed, Jun 28, 2017 at 10:14 AM, Mike Bonner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Even easier would be to just pass a single string like so..
>
> myhandler "type=blue,name=fred,something=234"
>
> And use split
>
> split pVar by comma and "="
>
> ending up with an array keyed by name.
>
> On Wed, Jun 28, 2017 at 5:41 AM, Paul Dupuis via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Here is some code to pass params by name - value pairs. It is relatively
> > easy with the paramCount and param functions of livecode.
> >
> > on mouseUp
> >
> >   myHandler "type=blue","name=fred","something=234"
> >
> > end mouseUp
> >
> >
> > on myHandler
> >
> >   repeat with i=1 to the paramCount
> >
> > put param(i) into tArg
> >
> > set itemDel to "="
> >
> > put item 1 of tArg into tName
> >
> > put item 2 of tArg into tValue
> >
> > put "Name:"&&&"= Value:"& after msg
> >
> >   end repeat
> >
> > end myHandler
> >
> >
> >
> >
> > On 6/28/2017 2:42 AM, FlexibleLearning.com via use-livecode wrote:
> > > This is how ChartMaker (www.flexibleLearning.com/chartmaker ) works,
> > with
> > > only the required name-value pairs and in any order. It does make
> > > implementing modifications to chart displays a lot easier for exactly
> the
> > > reasons you give!
> > >
> > > Hugh Senior
> > > FLCo
> > >
> > >> -Original Message-
> > >> I don't know when OL will be available or how it'll work.  I only know
> > >> one thing it won't support, based on an earlier conversation with Mark
> > >> Waddingham:  R-style arguments (similar in many respects to CSS
> values).
> > >>
> > >> In R, things like the plot command have reasonably-useful defaults, so
> > >> that you can just pass in data with nothing else and get a useful
> > result.
> > >>
> > >> But if you want to tailor it you pass arguments in as name-value
> pairs,
> > >> e.g.:
> > >>
> > >>plot(cars, type="o", col="blue", ylim=c(0,12))
> > >>
> > >> What I like about that is I'm free from having to remember parameter
> > >> order, which also means I don't need to add a hundred commas if I want
> > >> to pass in a value for the 101st param.
> > >>
> > >> With name-value pairs I can include only the options I want, and in
> any
> > >> order.
> > >>
> > >> Extra bonus points that the purpose of any argument is made explicit
> by
> > >> including its name.  If I see "o" I don't need to count commas and
> guess
> > >> about what that applies to, I know very clearly looking at the name
> > >> provided with it that it governs the plot type.
> > >
> > >
> > > ___
> > > 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

Array assignment / initialization [was Re: synonyms]

2017-06-28 Thread Alex Tweedly via use-livecode


On 28/06/2017 16:55, Richard Gaskin via use-livecode wrote:



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 don't accept that named parameters are "unusual" nowadays.
They're in Python, Csharp, R and (if my quick Google got it right) Swift 
- so that 's 5 of the top 20 most "popular" languages now, so I would 
expect that a fairly high proportion of potential LC users would be 
familiar with them.


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

Yes, it would be nice if we had an easier (terser) way to assign to an 
array. Maybe something like Python / Perl use to assign to a dictionary.


   put { "name": "my chart", "width": 100, "label": "This is a chart", 
"anarray": sAMine } into tA

   DoSomething tA

-- Alex.
btw - whose bright idea was it to not put a 'sharp' key visible on a 
British Mac keyboard :-) ?


___
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: synonyms

2017-06-28 Thread Alex Tweedly via use-livecode


On 28/06/2017 15:27, Paul Dupuis via use-livecode wrote:


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

I completely disagree; to me, this discussion shows how much LC would 
benefit from named parameters.


Clearly the examples so far look pretty nice -

(a) myHandler "type=blue","name=fred","something=234"
(b) myhandler "type=blue,name=fred,something=234"

but that's largely an illusion due to the fact that these are very 
simple examples, using constant strings as actual parameters. Try to use 
variables instead, and it doesn't look so pretty.


(a) myHandler "type=" & kConstant,"name=" & myName,"something="& the rect of grp 
"abc"
(b) myhandler "type=" & kConstant,"name=" & myName,"something="& the rect of grp 
"abc"

And in fact, that last one reminds us - as soon as you use a variable or 
property, you need to be concerned about the current value in it; it 
night contain the delimiter characters, in this case comma. So the 
'single parameter string' version fails - you actually need to do


(b) myhandler "type=" & urlencode(kConstant),"name=" & urlencode(myName), \
  "something="& urlencode(the rect of grp "abc")

(you can use a simpler encoding than urlencode - but this is built into 
the engine, so it's probably faster).


And even then, you still have problems 
 - you can't pass arrays as parameters (I'm not going down the 
'arrayencode() route :-)

 - you can't have 'pass by reference' parameters

Richard mentioned a third alternative - but it is basically just using 
whitespace instead of comma to delimit individual key/value pairs in a 
single-string parameter, and so retains all the above problems.


He also mention a fourth method - using arrays - which he describes as 
"more with the grain" which is more appealing, since it solves all the 
above problems except the limitation on not using 'pass-by-reference' 
parameters. But I'll split that off to a separate response, with a 
changed subject/thread header.


-- Alex.


___
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: synonyms

2017-06-28 Thread Mark Wieder via use-livecode


On 06/28/2017 08:55 AM, Richard Gaskin via use-livecode wrote:

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


http://quality.livecode.com/show_bug.cgi?id=16941

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

2017-06-28 Thread Richard Gaskin via use-livecode

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

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

2017-06-28 Thread Paul Dupuis via use-livecode

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.


On 6/28/2017 10:14 AM, Mike Bonner via use-livecode wrote:
> Even easier would be to just pass a single string like so..
>
> myhandler "type=blue,name=fred,something=234"
>
> And use split
>
> split pVar by comma and "="
>
> ending up with an array keyed by name.
>
> On Wed, Jun 28, 2017 at 5:41 AM, Paul Dupuis via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Here is some code to pass params by name - value pairs. It is relatively
>> easy with the paramCount and param functions of livecode.
>>
>> on mouseUp
>>
>>   myHandler "type=blue","name=fred","something=234"
>>
>> end mouseUp
>>
>>
>> on myHandler
>>
>>   repeat with i=1 to the paramCount
>>
>> put param(i) into tArg
>>
>> set itemDel to "="
>>
>> put item 1 of tArg into tName
>>
>> put item 2 of tArg into tValue
>>
>> put "Name:"&&&"= Value:"& after msg
>>
>>   end repeat
>>
>> end myHandler
>>
>>
>>
>>
>> On 6/28/2017 2:42 AM, FlexibleLearning.com via use-livecode wrote:
>>> This is how ChartMaker (www.flexibleLearning.com/chartmaker ) works,
>> with
>>> only the required name-value pairs and in any order. It does make
>>> implementing modifications to chart displays a lot easier for exactly the
>>> reasons you give!
>>>
>>> Hugh Senior
>>> FLCo
>>>
 -Original Message-
 I don't know when OL will be available or how it'll work.  I only know
 one thing it won't support, based on an earlier conversation with Mark
 Waddingham:  R-style arguments (similar in many respects to CSS values).

 In R, things like the plot command have reasonably-useful defaults, so
 that you can just pass in data with nothing else and get a useful
>> result.
 But if you want to tailor it you pass arguments in as name-value pairs,
 e.g.:

plot(cars, type="o", col="blue", ylim=c(0,12))

 What I like about that is I'm free from having to remember parameter
 order, which also means I don't need to add a hundred commas if I want
 to pass in a value for the 101st param.

 With name-value pairs I can include only the options I want, and in any
 order.

 Extra bonus points that the purpose of any argument is made explicit by
 including its name.  If I see "o" I don't need to count commas and guess
 about what that applies to, I know very clearly looking at the name
 provided with it that it governs the plot type.
>>>
>>> ___
>>> 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
>


___
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: synonyms

2017-06-28 Thread Mike Bonner via use-livecode

Even easier would be to just pass a single string like so..

myhandler "type=blue,name=fred,something=234"

And use split

split pVar by comma and "="

ending up with an array keyed by name.

On Wed, Jun 28, 2017 at 5:41 AM, Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Here is some code to pass params by name - value pairs. It is relatively
> easy with the paramCount and param functions of livecode.
>
> on mouseUp
>
>   myHandler "type=blue","name=fred","something=234"
>
> end mouseUp
>
>
> on myHandler
>
>   repeat with i=1 to the paramCount
>
> put param(i) into tArg
>
> set itemDel to "="
>
> put item 1 of tArg into tName
>
> put item 2 of tArg into tValue
>
> put "Name:"&&&"= Value:"& after msg
>
>   end repeat
>
> end myHandler
>
>
>
>
> On 6/28/2017 2:42 AM, FlexibleLearning.com via use-livecode wrote:
> > This is how ChartMaker (www.flexibleLearning.com/chartmaker ) works,
> with
> > only the required name-value pairs and in any order. It does make
> > implementing modifications to chart displays a lot easier for exactly the
> > reasons you give!
> >
> > Hugh Senior
> > FLCo
> >
> >> -Original Message-
> >> I don't know when OL will be available or how it'll work.  I only know
> >> one thing it won't support, based on an earlier conversation with Mark
> >> Waddingham:  R-style arguments (similar in many respects to CSS values).
> >>
> >> In R, things like the plot command have reasonably-useful defaults, so
> >> that you can just pass in data with nothing else and get a useful
> result.
> >>
> >> But if you want to tailor it you pass arguments in as name-value pairs,
> >> e.g.:
> >>
> >>plot(cars, type="o", col="blue", ylim=c(0,12))
> >>
> >> What I like about that is I'm free from having to remember parameter
> >> order, which also means I don't need to add a hundred commas if I want
> >> to pass in a value for the 101st param.
> >>
> >> With name-value pairs I can include only the options I want, and in any
> >> order.
> >>
> >> Extra bonus points that the purpose of any argument is made explicit by
> >> including its name.  If I see "o" I don't need to count commas and guess
> >> about what that applies to, I know very clearly looking at the name
> >> provided with it that it governs the plot type.
> >
> >
> > ___
> > 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: synonyms

2017-06-28 Thread Paul Dupuis via use-livecode

Here is some code to pass params by name - value pairs. It is relatively
easy with the paramCount and param functions of livecode.

on mouseUp

  myHandler "type=blue","name=fred","something=234"

end mouseUp


on myHandler

  repeat with i=1 to the paramCount

put param(i) into tArg

set itemDel to "="

put item 1 of tArg into tName

put item 2 of tArg into tValue

put "Name:"&&&"= Value:"& after msg

  end repeat

end myHandler




On 6/28/2017 2:42 AM, FlexibleLearning.com via use-livecode wrote:
> This is how ChartMaker (www.flexibleLearning.com/chartmaker ) works, with
> only the required name-value pairs and in any order. It does make
> implementing modifications to chart displays a lot easier for exactly the
> reasons you give!
>
> Hugh Senior
> FLCo
>
>> -Original Message-
>> I don't know when OL will be available or how it'll work.  I only know
>> one thing it won't support, based on an earlier conversation with Mark
>> Waddingham:  R-style arguments (similar in many respects to CSS values).
>>
>> In R, things like the plot command have reasonably-useful defaults, so
>> that you can just pass in data with nothing else and get a useful result.
>>
>> But if you want to tailor it you pass arguments in as name-value pairs,
>> e.g.:
>>
>>plot(cars, type="o", col="blue", ylim=c(0,12))
>>
>> What I like about that is I'm free from having to remember parameter
>> order, which also means I don't need to add a hundred commas if I want
>> to pass in a value for the 101st param.
>>
>> With name-value pairs I can include only the options I want, and in any
>> order.
>>
>> Extra bonus points that the purpose of any argument is made explicit by
>> including its name.  If I see "o" I don't need to count commas and guess
>> about what that applies to, I know very clearly looking at the name
>> provided with it that it governs the plot type.
>
>
> ___
> 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: synonyms

2017-06-28 Thread FlexibleLearning.com via use-livecode

This is how ChartMaker (www.flexibleLearning.com/chartmaker ) works, with
only the required name-value pairs and in any order. It does make
implementing modifications to chart displays a lot easier for exactly the
reasons you give!

Hugh Senior
FLCo

> -Original Message-
> I don't know when OL will be available or how it'll work.  I only know
> one thing it won't support, based on an earlier conversation with Mark
> Waddingham:  R-style arguments (similar in many respects to CSS values).
> 
> In R, things like the plot command have reasonably-useful defaults, so
> that you can just pass in data with nothing else and get a useful result.
> 
> But if you want to tailor it you pass arguments in as name-value pairs,
> e.g.:
> 
>plot(cars, type="o", col="blue", ylim=c(0,12))
> 
> What I like about that is I'm free from having to remember parameter
> order, which also means I don't need to add a hundred commas if I want
> to pass in a value for the 101st param.
> 
> With name-value pairs I can include only the options I want, and in any
> order.
> 
> Extra bonus points that the purpose of any argument is made explicit by
> including its name.  If I see "o" I don't need to count commas and guess
> about what that applies to, I know very clearly looking at the name
> provided with it that it governs the plot type.



___
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: synonyms

2017-06-27 Thread Alex Tweedly via use-livecode




On 27/06/2017 19:19, Richard Gaskin via use-livecode wrote:


I don't know when OL will be available or how it'll work.  I only know 
one thing it won't support, based on an earlier conversation with Mark 
Waddingham:  R-style arguments (similar in many respects to CSS values).


In R, things like the plot command have reasonably-useful defaults, so 
that you can just pass in data with nothing else and get a useful result.
That's a great shame. Named parameters is one of my favourite features 
in Python too, so I was hoping we'd see it in LC.




Do you think there's any hope that Mark's objection is to the use of the 
'=' sign - as in,


  plot(cars, type="o", col="blue", ylim=c(0,12))

Maybe he'd let us have

  plot (cars, type is "o", col is 'blue', etc.)

:-)

-- Alex.



___
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: synonyms

2017-06-27 Thread Lagi Pittas via use-livecode

Thanks Richard,

Actually I like the idea it's exactly what Bret Victor said was needed in
languages I post this link again nobody commented on it the last time

Are you listening  Mark?

https://www.youtube.com/watch?v=PUv66718DII

Still would like to know if the additional parsers/lexers ideas have any
traction as a crowdfunding to the python/Javascript/Ruby people - they
would probably pay for something that spit out the code they needed to run
a Gui on desktop - NO QT - it's a dog's breakfast of calls, maybe you can
program lots of stuff with it - but I can also build a house out of lolly
sticks and spit.
Regards lagi

On 27 June 2017 at 19:19, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Lagi Pittas wrote:
>
> We are still awaiting the open language that was promised.
>>
>> Now I don't know exactly how that will work in the sense is it going to be
>> all or nothing - a free for all where you can add/change  syntax more like
>> a souped up preprocessor, or allow for change to a different language
>> (python, Ruby, php on a per procedure/function basis or the easier first
>>  step a script only stack in the language of your choice.
>>
>> Everyone can have their cake and eat it.
>>
>
> I don't know when OL will be available or how it'll work.  I only know one
> thing it won't support, based on an earlier conversation with Mark
> Waddingham:  R-style arguments (similar in many respects to CSS values).
>
> In R, things like the plot command have reasonably-useful defaults, so
> that you can just pass in data with nothing else and get a useful result.
>
> But if you want to tailor it you pass arguments in as name-value pairs,
> e.g.:
>
>   plot(cars, type="o", col="blue", ylim=c(0,12))
>
> What I like about that is I'm free from having to remember parameter
> order, which also means I don't need to add a hundred commas if I want to
> pass in a value for the 101st param.
>
> With name-value pairs I can include only the options I want, and in any
> order.
>
> Extra bonus points that the purpose of any argument is made explicit by
> including its name.  If I see "o" I don't need to count commas and guess
> about what that applies to, I know very clearly looking at the name
> provided with it that it governs the plot type.
>
> This may be even more verbose than xTalk for handlers with just one or two
> args.
>
> 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...
>
> --
>  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: synonyms

2017-06-27 Thread Richard Gaskin via use-livecode


Lagi Pittas wrote:


We are still awaiting the open language that was promised.

Now I don't know exactly how that will work in the sense is it going to be
all or nothing - a free for all where you can add/change  syntax more like
a souped up preprocessor, or allow for change to a different language
(python, Ruby, php on a per procedure/function basis or the easier first
 step a script only stack in the language of your choice.

Everyone can have their cake and eat it.


I don't know when OL will be available or how it'll work.  I only know 
one thing it won't support, based on an earlier conversation with Mark 
Waddingham:  R-style arguments (similar in many respects to CSS values).


In R, things like the plot command have reasonably-useful defaults, so 
that you can just pass in data with nothing else and get a useful result.


But if you want to tailor it you pass arguments in as name-value pairs, 
e.g.:


  plot(cars, type="o", col="blue", ylim=c(0,12))

What I like about that is I'm free from having to remember parameter 
order, which also means I don't need to add a hundred commas if I want 
to pass in a value for the 101st param.


With name-value pairs I can include only the options I want, and in any 
order.


Extra bonus points that the purpose of any argument is made explicit by 
including its name.  If I see "o" I don't need to count commas and guess 
about what that applies to, I know very clearly looking at the name 
provided with it that it governs the plot type.


This may be even more verbose than xTalk for handlers with just one or 
two args.


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


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

2017-06-27 Thread Lagi Pittas via use-livecode

I Missed an important bit in my previous post (below)

What I wanted to say after the bit about the Topspeed compilers using the
same backend
is that LiveCode Builder / Stack only scripts could start with a switch
setting at the top saying which language this should compile with or even
which languages.
on a procedural basis within the actual script only stack.

Other thoughts.
You then could have the LCB script calling the FFI or Javascript/Python
libraries within the same stack (or in another library stack) and the
compiler pulls in the specific parser/lexer and intermediate codegenerator
which could output bytecode or native code as needed.

It would then give us the facility to easly (?) write wrappers for all the
useful libraries that are available for all the other languages -
https://www.chilkatsoft.com for example which I have used in My Foxpro
Delphi, VB and C projects for the one single price.

Regards Lagi

-

Previous Post

There is a very simple way of doing this (simple for me - because I don't
have to do it)

We are still awaiting the open language that was promised.

Now I don't know exactly how that will work in the sense is it going to be
all or nothing - a free for all where you can add/change  syntax more like
a souped up preprocessor, or allow for change to a different language
(python, Ruby, php on a per procedure/function basis or the easier first
 step a script only stack in the language of your choice.

Everyone can have their cake and eat it.

This was done by Jensen and partner (Ex Borland->JPI -> Topspeed -Clarion)
with there Modula 2 and C, C++, Pascal  compilers where they shared the
backend of the compiler

With the refactoring I am sure this could be done with LIvecode because
what  the greatest problem with all the other system is they have no GOOD
unified easy to use GUI.

I don't care what anybody says but QT is not cute in any language.

If nothing else I am sure a crowdfund to all the PHP / python people
educators looking for a brilliant Drag and Drop GUI would find an audience
- and we would finally get our Open Language

I hope Mark does a "Mark" now  ;-)

Kindest Regards Lagi

On 27 June 2017 at 02:03, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Synonyms are one of the things that make this language special.  I
> appreciate the fact that my creativity is not interrupted by imposed style
> and syntactic requirements as much as it is with other languages.  I
> appreciate that I don't have to type containers in most cases, and I don't
> have to worry about case sensitivity.  I can go on and on, but Mark, there
> are lots of languages built with the compiler author in mind.  I hope LC
> will remain off that list.
> ___
> 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: synonyms

2017-06-27 Thread Lagi Pittas via use-livecode

There is a very simple way of doing this (simple for me - because I don't
have to do it)

We are still awaiting the open language that was promised.

Now I don't know exactly how that will work in the sense is it going to be
all or nothing - a free for all where you can add/change  syntax more like
a souped up preprocessor, or allow for change to a different language
(python, Ruby, php on a per procedure/function basis or the easier first
 step a script only stack in the language of your choice.

Everyone can have their cake and eat it.

This was done by Jensen and partner (Ex Borland->JPI -> Topspeed -Clarion)
with there Modula 2 and C, C++, Pascal  compilers where they shared the
backend of the compiler

With the refactoring I am sure this could be done with LIvecode because
what  the greatest problem with all the other system is they have no GOOD
unified easy to use GUI.

I don't care what anybody says but QT is not cute in any language.

If nothing else I am sure a crowdfund to all the PHP / python people
educators looking for a brilliant Drag and Drop GUI would find an audience
- and we would finally get our Open Language

I hope Mark does a "Mark" now  ;-)

Kindest Regards Lagi

On 26 June 2017 at 21:59, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Mark Wieder wrote:
>
> > On 06/26/2017 01:29 PM, Richard Gaskin via use-livecode wrote:
> >
> >> Consider Python, the world's fourth-most-popular language, and
> >> perhaps the leading language for introducing newcomers to
> >> programming.
> >>
> >> Among the core principles of Python's language design is:
> >>
> >> "There should be one-- and preferably only one --obvious way to
> >> do it."
> >> - Guido van Rossum
> >>  philosophy.html>
> >>
> >
> > I consider Guido one of the deep thinkers of language design.
> > Nonetheless, python has many pitfalls for developers. There's a
> > wonderful little O'Reilly pamphlet by Mike Pirnat entitled "How to
> > Make Mistakes in Python".
>
> You can't make mistakes in LiveCode? :)
>
> I manage to do it all the time.
>
> At least with Python you need a book to explain how to make mistakes. :)
>
>
> > IMNSHO LiveCode has more to offer newcomers due in
> > no small part to the approachability of the language.
>
> I agree, yet here we are: Python has remained in the top 5 on the TIOBE
> Index as far back as I can recall, and during the time LiveCode has only
> occasionally appeared in the bottom 50 at all.
>
> I was recently turned down on a grant-funded project to make a system for
> teaching programming fundamentals using LiveCode, in favor of a project
> they approved based on Python.
>
> No language is perfect; all have their warts.  And LiveCode is pretty
> great.
>
> But we need to find some way to reach the tipping point of at least bring
> on the TIOBE Index consistently at all.
>
> And I don't think synonyms, or lack thereof, are going to make that
> difference.
>
> --
>  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: synonyms

2017-06-26 Thread Mike Kerner via use-livecode

Synonyms are one of the things that make this language special.  I
appreciate the fact that my creativity is not interrupted by imposed style
and syntactic requirements as much as it is with other languages.  I
appreciate that I don't have to type containers in most cases, and I don't
have to worry about case sensitivity.  I can go on and on, but Mark, there
are lots of languages built with the compiler author in mind.  I hope LC
will remain off that list.
___
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: synonyms

2017-06-26 Thread Jim Lambert via use-livecode

OOOPS! I left out an important word

Then simply set the icon of each to the ID of the appropriate image.

should read

Then simply set the icon of each BUTTON to the ID of the appropriate image.

JimL

___
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: synonyms

2017-06-26 Thread Jim Lambert via use-livecode

> BobS wrote:
> 
> For the record, I have given up on my Object Library. The problem is buttons. 
> Button can have icons. That means that I would need to copy all the linked 
> icons along with the button, then manage the relinking of the copied icons 
> that now have their own ID's, then manage dropping the icons BACK onto 
> another card, but only if another icon of the same name does not exist, blah 
> blah blah. YUK! 
> 
> What is needed is for the engine to allow a BUTTON to dynamically be linked 
> to a grapic ON DISK without having to import a graphic object 

Bob,

I may completely misunderstand the issue.  But can’t you have an unseen card 
with all the icons as image objects referencing image files ON DISK.
Then simply set the icon of each to the ID of the appropriate image.

For example,

create a new image
set its filename to “some>path/hand_icon.jpg”
   set the icon of button “hand” to the ID 1003
where 1003 is the id of the referenced image.

In this way there is no ‘copying’, ‘importing’ or ‘relinking’ needed.

And if you don’t want to deal with remembering IDs just name the new image, say 
“hand_icon’ then

  set the icon of button “hand” to the ID of image “hand_icon” 
(optionally - "of card ‘myIcons’")

Jim Lambert
___
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: synonyms


On 06/26/2017 01:59 PM, Richard Gaskin via use-livecode wrote:


At least with Python you need a book to explain how to make mistakes. :)


LOL

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

2017-06-26 Thread Bob Sneidar via use-livecode

For the record, I have given up on my Object Library. The problem is buttons. 
Button can have icons. That means that I would need to copy all the linked 
icons along with the button, then manage the relinking of the copied icons that 
now have their own ID's, then manage dropping the icons BACK onto another card, 
but only if another icon of the same name does not exist, blah blah blah. YUK! 

What is needed is for the engine to allow a BUTTON to dynamically be linked to 
a grapic ON DISK without having to import a graphic object and link to that 
with all the varied issues people run into. 

Bob S


> On Jun 26, 2017, at 14:18 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Not saying this means anything, but the Macintosh was released at a golden 
> moment in history, where processors had just reached the place where they 
> could support a GUI, a software developer named Microsoft was willing to 
> write programs that made the Mac more than a toy, and a growing industry made 
> such a thing as a Mac potentially profitable. 
> 
> I suspect Python had a golden moment as well. Livecode's golden moment was 
> actually not RunRev's but Apples with Hypercard. Then when there where 
> millions who loved and worked with Hypercard, Apple killed it. True there 
> were other replacements, but a huge number of people threw in the towel then. 
> I was one of them. I tried SuperCard for a while, but early releases were 
> cumbersome and there were no small number of bugs. 
> 
> Now we have Livecode, and since version 2.0 I have been really amazed at how 
> capable it has become. I use an app daily that I wrote for my company, and 
> even my service manager who thinks I just play around with it every day has 
> had to admit that it is really useful. 
> 
> But when is the new golden moment? Software developers abound, and there is 
> no lack of languages scripting or otherwise. It's not like that golden moment 
> with Apple when there was literally NOTHING like Hypercard. What we lack is 
> not features or capabilities. We lack a golden moment where software produced 
> with Livecode fills a need that launches a whole new wave of interest. 
> 
> Or maybe we just need more people to find out about it. 
> 
> Bob S
> 
> 
>> On Jun 26, 2017, at 13:59 , Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> But we need to find some way to reach the tipping point of at least bring on 
>> the TIOBE Index consistently at all.
> 
> 
> ___
> 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: synonyms

2017-06-26 Thread Bob Sneidar via use-livecode

Not saying this means anything, but the Macintosh was released at a golden 
moment in history, where processors had just reached the place where they could 
support a GUI, a software developer named Microsoft was willing to write 
programs that made the Mac more than a toy, and a growing industry made such a 
thing as a Mac potentially profitable. 

I suspect Python had a golden moment as well. Livecode's golden moment was 
actually not RunRev's but Apples with Hypercard. Then when there where millions 
who loved and worked with Hypercard, Apple killed it. True there were other 
replacements, but a huge number of people threw in the towel then. I was one of 
them. I tried SuperCard for a while, but early releases were cumbersome and 
there were no small number of bugs. 

Now we have Livecode, and since version 2.0 I have been really amazed at how 
capable it has become. I use an app daily that I wrote for my company, and even 
my service manager who thinks I just play around with it every day has had to 
admit that it is really useful. 

But when is the new golden moment? Software developers abound, and there is no 
lack of languages scripting or otherwise. It's not like that golden moment with 
Apple when there was literally NOTHING like Hypercard. What we lack is not 
features or capabilities. We lack a golden moment where software produced with 
Livecode fills a need that launches a whole new wave of interest. 

Or maybe we just need more people to find out about it. 

Bob S

> On Jun 26, 2017, at 13:59 , Richard Gaskin via use-livecode 
>  wrote:
> 
> But we need to find some way to reach the tipping point of at least bring on 
> the TIOBE Index consistently at all.

___
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: synonyms

2017-06-26 Thread Richard Gaskin via use-livecode

Mark Wieder wrote:

> On 06/26/2017 01:29 PM, Richard Gaskin via use-livecode wrote:
>
>> Consider Python, the world's fourth-most-popular language, and
>> perhaps the leading language for introducing newcomers to
>> programming.
>>
>> Among the core principles of Python's language design is:
>>
>> "There should be one-- and preferably only one --obvious way to
>> do it."
>> - Guido van Rossum
>> 

>>
>
> I consider Guido one of the deep thinkers of language design.
> Nonetheless, python has many pitfalls for developers. There's a
> wonderful little O'Reilly pamphlet by Mike Pirnat entitled "How to
> Make Mistakes in Python".

You can't make mistakes in LiveCode? :)

I manage to do it all the time.

At least with Python you need a book to explain how to make mistakes. :)

> IMNSHO LiveCode has more to offer newcomers due in
> no small part to the approachability of the language.

I agree, yet here we are: Python has remained in the top 5 on the TIOBE 
Index as far back as I can recall, and during the time LiveCode has only 
occasionally appeared in the bottom 50 at all.

I was recently turned down on a grant-funded project to make a system 
for teaching programming fundamentals using LiveCode, in favor of a 
project they approved based on Python.

No language is perfect; all have their warts.  And LiveCode is pretty great.

But we need to find some way to reach the tipping point of at least 
bring on the TIOBE Index consistently at all.

And I don't think synonyms, or lack thereof, are going to make that 
difference.

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


On 06/26/2017 12:57 PM, Richmond Mathewson via use-livecode wrote:

Well . . . here we are all going to draw ourselves up to do battle . . .


Nope. Not interested. Mr. Waddingham and I have a running argument on 
this topic, and I can't resist the opportunity to get in a few jabs, 
especially when it's handed to me on a plate like that. But as I pointed 
out, I don't expect either of us to change our positions, and if this is 
going to turn out to be a religious war I'm going to dive into my 
atheist foxhole and sit this one out.



I suffer from a horrible tendency to see both sides of an argument.


Don't get me wrong - I do too.
Doesn't stop me from being right, though. 

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


On 06/26/2017 01:29 PM, Richard Gaskin via use-livecode wrote:

Consider Python, the world's fourth-most-popular language, and perhaps 
the leading language for introducing newcomers to programming.


Among the core principles of Python's language design is:

"There should be one-- and preferably only one --obvious way to do it."
- Guido van Rossum




I consider Guido one of the deep thinkers of language design. 
Nonetheless, python has many pitfalls for developers. There's a 
wonderful little O'Reilly pamphlet by Mike Pirnat entitled "How to Make 
Mistakes in Python". IMNSHO LiveCode has more to offer newcomers due in 
no small part to the approachability of the language.


http://www.oreilly.com/programming/free/how-to-make-mistakes-in-python.csp

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

2017-06-26 Thread J. Landman Gay via use-livecode


On 6/26/17 3:14 PM, Richmond Mathewson via use-livecode wrote:


On 6/26/17 11:07 pm, J. Landman Gay via use-livecode wrote:
Just please don't remove the ones we've got. I haven't typed out 
"background" or "card" in 30 years. My brain would short out.


I wonder if it is about time in this discussion to differentiate between 
*abbreviations* and *synonyms*?


I think from the engine's perspective they're the same.

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

2017-06-26 Thread Richard Gaskin via use-livecode

Richmond Mathewson wrote:

> I think that it is probably generally true that the more synonyms
> and ways of saying the same thing a language has, the easier it is
> to learn.
>
> This is also borne out by Linguistic research.

Linguistics for communicating with humans follows different rules than 
the linguistics used for communicating with machines.

Their purpose and scope is vastly different, so it should not be 
surprising that what is "best" for one isn't necessarily "best" in another.

Indeed, most natural languages have no "best"; only artificial languages 
like Esperanto and the older Boontling are "designed" at all.  Natural 
languages are multi-millennial accidents-in-the-making.

In stark contrast. programming languages have a very narrow scope, and 
are not only explicitly designed by necessity, but usually quite 
narrowly, as they attempt to communicate with a machine too stupid to 
count past 1.

Consider Python, the world's fourth-most-popular language, and perhaps 
the leading language for introducing newcomers to programming.

Among the core principles of Python's language design is:

"There should be one-- and preferably only one --obvious way to do it."
- Guido van Rossum

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

2017-06-26 Thread Richmond Mathewson via use-livecode




On 6/26/17 11:07 pm, J. Landman Gay via use-livecode wrote:
Just please don't remove the ones we've got. I haven't typed out 
"background" or "card" in 30 years. My brain would short out.


I wonder if it is about time in this discussion to differentiate between 
*abbreviations* and *synonyms*?


Richmond.



On 6/26/17 1:48 PM, Mark Waddingham via use-livecode wrote:
I'm against synonyms being part of the core language - they have no 
place there as they are 'tailorings'. Indeed a good part of the 
argument for them could be solved by better tooling - e.g. 
autocomplete and suggested tokens if one isn't quite right.


Every single property in the engine could have synonyms and some many 
(see the recent discussion about clipsToRect). An attempt to 
'normalise' hilite and its various compound forms would have resulted 
in 40 (iirc) additions to the token table.


Moreover every single synonym reduces the set of possibilities of 
things we could add in the future and can cause backwards 
compatibility issues in existing scripts (as they become for all 
intents and purposes reserved).


There is no easy way to administer synonym additions centrally and 
each one increases the maintenance burden in the current architecture.


So the only 'synonyms' which it makes sense to adopt right now are 
the ones which help move the current syntax to having a consistent 
and sensible canonical form which is easy to document and explain.


This allows, in the future, for a far more general and decentralised 
way to tailor syntax *in general* whilst ensuring there will always 
be one canonical form to which scripts can be translated to enable 
them to be compiled and (more importantly) be translated to people's 
preferred form.


So, I get the reasoning behind them (although I still think it better 
to train people implicitly to use canonical forms via better tooling, 
as if everyone 'sings' with the same language, uniform understanding 
is increased) so in the future everyone will be able to 'knock 
themselves out'...


However, I'd point out that the primary reason for the architecture 
to allow that is specifying custom syntax, and non-English language 
variants. The fact that the 'synonym problem' would also be 'fixed' 
by it Is but a happy by-product.


Warmest Regards,

Mark.

Sent from my iPhone

On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode 
 wrote:



On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and 
simpler the language is, the easier it is to learn.


...and I would follow that with the (long-running by now) argument 
that synonyms provide for an ease-of-use facility in coding and 
therefore a simpler approach to using the language. For the trivial 
case here, if I can't remember whether the language supports "is" or 
"=" for variable assignments, I can use one or the other without 
having to interrupt my train of thought to look it up in the 
dictionary/guides.


One of LiveCode's strengths is the fact that there are many possible 
solutions to a given problem, and the xtalk language allows much 
flexibility in solving it. For a problem placed before any three 
coders, you will find at least four different solutions. Limiting 
the language limits the ways in which a problem may be thought of - 
that's the basis of the linguistic relativism, and it applies to 
programming languages as well as to natural languages.


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



___
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: synonyms

2017-06-26 Thread J. Landman Gay via use-livecode

Just please don't remove the ones we've got. I haven't typed out
"background" or "card" in 30 years. My brain would short out.

On 6/26/17 1:48 PM, Mark Waddingham via use-livecode wrote:

I'm against synonyms being part of the core language - they have no place there
as they are 'tailorings'. Indeed a good part of the argument for them could be
solved by better tooling - e.g. autocomplete and suggested tokens if one isn't
quite right.

Every single property in the engine could have synonyms and some many (see the
recent discussion about clipsToRect). An attempt to 'normalise' hilite and its
various compound forms would have resulted in 40 (iirc) additions to the token
table.

Moreover every single synonym reduces the set of possibilities of things we
could add in the future and can cause backwards compatibility issues in
existing scripts (as they become for all intents and purposes reserved).

There is no easy way to administer synonym additions centrally and each one
increases the maintenance burden in the current architecture.

So the only 'synonyms' which it makes sense to adopt right now are the ones
which help move the current syntax to having a consistent and sensible
canonical form which is easy to document and explain.

This allows, in the future, for a far more general and decentralised way to
tailor syntax *in general* whilst ensuring there will always be one canonical
form to which scripts can be translated to enable them to be compiled and (more
importantly) be translated to people's preferred form.

So, I get the reasoning behind them (although I still think it better to train
people implicitly to use canonical forms via better tooling, as if everyone
'sings' with the same language, uniform understanding is increased) so in the
future everyone will be able to 'knock themselves out'...

However, I'd point out that the primary reason for the architecture to allow
that is specifying custom syntax, and non-English language variants. The fact
that the 'synonym problem' would also be 'fixed' by it Is but a happy
by-product.

Warmest Regards,

Mark.

Sent from my iPhone

On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode
wrote:

On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and simpler the
language is, the easier it is to learn.

...and I would follow that with the (long-running by now) argument that synonyms provide for an
ease-of-use facility in coding and therefore a simpler approach to using the language. For the
trivial case here, if I can't remember whether the language supports "is" or
"=" for variable assignments, I can use one or the other without having to interrupt my
train of thought to look it up in the dictionary/guides.

One of LiveCode's strengths is the fact that there are many possible solutions
to a given problem, and the xtalk language allows much flexibility in solving
it. For a problem placed before any three coders, you will find at least four
different solutions. Limiting the language limits the ways in which a problem
may be thought of - that's the basis of the linguistic relativism, and it
applies to programming languages as well as to natural languages.

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

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

Re: synonyms

2017-06-26 Thread Richmond Mathewson via use-livecode

Well . . . here we are all going to draw ourselves up to do battle . . .

On 6/26/17 9:48 pm, Mark Waddingham via use-livecode wrote:

I suffer from a horrible tendency to see both sides of an argument.

What you have stated above, Mark, makes 100% perfect sense in terms of a
"tight", efficient programming environment.

It doesn't make sense if one wants to preserve a programming language
which can largely be self-taught rather than didactically

spoon-fed to learners.

That last point was one of the main ideas behind the development of
Hypercard.

Most of us are well aware that LiveCode is NOT Hypercard any more than I
am not a small, furry mouselike mammal that danced around
the toes of dying dinosaurs: LiveCode is descended from HyperCard, and I
may be descended from small, furry mammals.

What LiveCode (the company) have to decide (and it's a tough call) is
how much they want their LiveCode to hold onto the HyperCard
legacy (and probably as a result continue to be regarded by programming
snobs as a kid's toy) and how much they want LiveCode to
"grow up" and try to displace some of the serious market leaders (C++,
C#, VBasic, Python).

My position is well-known, but I am an educator, and an educator who
does not favour didactic teaching.

There is no easy way to administer synonym additions centrally and each one
increases the maintenance burden in the current architecture.

"train people implicitly" . . . hard job.

Warmest Regards,

Mark.

Sent from my iPhone

On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode
wrote:

On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and simpler the
language is, the easier it is to learn.

One of LiveCode's strengths is the fact that there are many possible solutions
to a given problem, and the xtalk language allows much flexibility in solving
it.

Yes; but that presupposes LiveCode is going to be burdened with the
"it's an xTalk dialect" label forever, and whether "xTalk"
continues to make sense seeing how far the xTalk outgrowths from
HyperCard have diverged.

For a problem placed before any three coders, you will find at least four
different solutions. Limiting the language limits the ways in which a problem
may be thought of - that's the basis of the linguistic relativism, and it
applies to programming languages as well as to natural languages.

Of course.

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

Richmond.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:

Re: synonyms

2017-06-26 Thread Richmond Mathewson via use-livecode

I think that it is probably generally true that the more synonyms and 
ways of saying the same thing a language has,

the easier it is to learn.

This is also borne out by Linguistic research.

Today I had 7 children who ALL wrote LiveCode scripts to do a Bubble 
Sort fo 6 fields containing numbers; they

were all different to greater or lesser degress, and they all did the job!

Thankyou HyperCard, MetaCard and LiveCode for making your programming 
"thingy" the way you did!


Richmond.

On 6/26/17 8:59 pm, Mark Wieder via use-livecode wrote:

On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and 
simpler the language is, the easier it is to learn.


...and I would follow that with the (long-running by now) argument 
that synonyms provide for an ease-of-use facility in coding and 
therefore a simpler approach to using the language. For the trivial 
case here, if I can't remember whether the language supports "is" or 
"=" for variable assignments, I can use one or the other without 
having to interrupt my train of thought to look it up in the 
dictionary/guides.


One of LiveCode's strengths is the fact that there are many possible 
solutions to a given problem, and the xtalk language allows much 
flexibility in solving it. For a problem placed before any three 
coders, you will find at least four different solutions. Limiting the 
language limits the ways in which a problem may be thought of - that's 
the basis of the linguistic relativism, and it applies to programming 
languages as well as to natural languages.




___
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: synonyms