Re: Inconsistent comma requirements
On 2017-06-26 12:41, hh via use-livecode wrote: No reason to get angry. This thread started from an excellent LC Lesson in the forum ( http://forums.livecode.com/viewtopic.php?f=7=29403 ) There is only one line to know: function logarithmicSearch @pArray pItem pLeft pRight Presumably a lot of people uses scripts from these lessons (that are pretty good, recommended for beginners). So "forget pretty quickly" seemed not appropriate to me. And a candidate for your "certain percentage" is each and every beginner. I wasn't getting angry - hence the 'wink' at the end... It was just merely a reminder that none of us are 'omnipotent' - its always useful to reference discussions if they are mixed from different places (there's a lot of posts everywhere, and many times we can only survey the headlines). But please don't judge this as 'bug'. It is a wonderful feature! Beginners can learn from it. Would be better to explain the advantages and disadvantages for using spaces instead of commas (one could use parts of this thread). In general I'd perhaps say that we should normalize the lessons to use code forms which are considered best practice - so I would consider lessons which use spaces and not commas as a bug for this reason. I'm not sure I can see that using spaces between arguments *is* in any way best-practice as it hides a required notion when you actually have to call the command (and can hide subtle typing errors as Paul pointed out) - the synergy between parameter declarations and parameter use is probably an important concept thus should be reinforced at every opportunity. Something Richard mentioned about '=' being used in constant and var init also sticks in my mind as slightly jarring - it is perhaps something we should tweak to allow 'is' and '=' (yes, *technically* a synonym, but we can make the 'is' form strictly preferred as a slightly better way of expressing what you mean): constant kFoo is 100 local tVar is 200 In LCB, we chose 'is' rather than '=' for very much this reason. I think it is probably generally true that the more consistent and simpler the language is, the easier it is to learn. 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: Inconsistent comma requirements
> Mark wrote: > >> Monte wrote: > >> I have seen it before in user scripts but never used it myself. > >> It’s one of those things you discover (like when {} could be used > >> interchangeably with []) that you quickly realise you should never > >> rely on so you forget pretty quickly ;-) > > hh wrote: > > You are member of the LC-team and you know that several 'official' > > LC lessons use this "parameter-feature". > > Because obviously everybody on the LC team knows every single word of > script which has ever been written by anyone ;) > > > So, what should we conclude from such a writing? > > That if something is allowed then, on average, a certain percentage of > people will use it - for better or for worse. No reason to get angry. This thread started from an excellent LC Lesson in the forum ( http://forums.livecode.com/viewtopic.php?f=7=29403 ) There is only one line to know: function logarithmicSearch @pArray pItem pLeft pRight Presumably a lot of people uses scripts from these lessons (that are pretty good, recommended for beginners). So "forget pretty quickly" seemed not appropriate to me. And a candidate for your "certain percentage" is each and every beginner. > Monte wrote: > You could reasonably conclude that I haven’t read every bit of content > published by the company. Of course, I still conclude that. And you really shouldn't read all that. I erroneously assumed you read a bit (sic!) more of the thread. Sorry for this wrong assumption. > One of the things I did in the first few months of my employment was write > some tests which ensured that our examples in the docs actually compiled. > You might be surprised to learn that many didn’t. No, not at all surprised. I read the docs, started in 2013 with that, so may be I read and tested some of the versions you meanwhile corrected. This pushed up my learning curve: You could think about putting in some 'typos' again. ;-) > Which lessons are you referring to though? I’ll bug report them ... Searching an array. See the forum link above. But please don't judge this as 'bug'. It is a wonderful feature! Beginners can learn from it. Would be better to explain the advantages and disadvantages for using spaces instead of commas (one could use parts of this thread). ___ 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: Inconsistent comma requirements
> On 26 Jun 2017, at 4:05 pm, hh via use-livecode >wrote: > >> I have seen it before in user scripts but never used it myself. >> It’s one of those things you discover (like when {} could be used >> interchangeably with []) that you quickly realise you should never >> rely on so you forget pretty quickly ;-) > > You are member of the LC-team and you know that several 'official' > LC lessons use this "parameter-feature". > > So, what should we conclude from such a writing? You could reasonably conclude that I haven’t read every bit of content published by the company (the vast majority of which was produced prior to my employment) and that I might not know that some examples of handler definitions without comma delimited parameters. One of the things I did in the first few months of my employment was write some tests which ensured that our examples in the docs actually compiled. You might be surprised to learn that many didn’t. Mostly minor copy paste errors but one relevant example had handler definitions with the parameters declared within parentheses. That’s just the kind of thing that happens when the author spends most of their day implementing and maintaining a language written in a different language. I for one often forget that `break` can’t be used within repeat loops these days but I never forgot that when I was spending almost all day in LiveCode ;-) Which lessons are you referring to though? I’ll bug report them as we should be being consistent whether this parser anomaly is ever removed or not. Cheers Monte ___ 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: Inconsistent comma requirements
On 2017-06-26 08:05, hh via use-livecode wrote: Monte wrote: I have seen it before in user scripts but never used it myself. It’s one of those things you discover (like when {} could be used interchangeably with []) that you quickly realise you should never rely on so you forget pretty quickly ;-) You are member of the LC-team and you know that several 'official' LC lessons use this "parameter-feature". Because obviously everybody on the LC team knows every single word of script which has ever been written by anyone ;) So, what should we conclude from such a writing? That if something is allowed then, on average, a certain percentage of people will use it - for better or for worse. 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: Inconsistent comma requirements
On 2017-06-26 01:42, Monte Goulding via use-livecode wrote: On 25 Jun 2017, at 1:37 am, Richard Gaskin via use-livecodewrote: How many of you have never before known that commas are optional between definition arguments? I have seen it before in user scripts but never used it myself. It’s one of those things you discover (like when {} could be used interchangeably with []) that you quickly realise you should never rely on so you forget pretty quickly ;-) It is a HyperCard or SuperCard script compatibility thing I believe... The ability to not have commas in the parameter declaration list does no real harm, although as a couple of people have pointed out means error detection in that specific case is less 'strong' so is probably best avoided for that reason, if no other. FWIW it actually wouldn’t be _that_ hard to add the ability to specify some syntactic sugar to your handlers and have the parser ignore said sugar: e.g: command Foo “with” pBar end Foo Foo with pBar However this is somewhat less than and conflicts with the open language concept so it’s probably best not to consider it too seriously. That suggestion is essentially the same as Richard's - whilst it is certainly an idea it means that errors in syntax can't be detected except at runtime (as you can have multiple handlers processed in the message path, and they can change dynamically). Also, in the case of just passing through 'keywords' as string literals you are moving parsing into the command handler - which means that parsing is then on the onus of the script writer, which means just making more work for scripts for what is probably of little benefit. There's also an issue in that you can't really use any connecting words which are used to form expressions: doSomething dA and dB and dC There's no way to know (with the 'ignore connectives' idea) how to process this - dA and dB (and all combinations) is a valid boolean expression. So in this case I might mean a command taking two parameters (ignoring 'and' in the first or second case), or one taking one parameter (dA and dB and dC). 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: Inconsistent comma requirements
> Monte wrote: > I have seen it before in user scripts but never used it myself. > It’s one of those things you discover (like when {} could be used > interchangeably with []) that you quickly realise you should never > rely on so you forget pretty quickly ;-) You are member of the LC-team and you know that several 'official' LC lessons use this "parameter-feature". So, what should we conclude from such a writing? ___ 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: Inconsistent comma requirements
> On 25 Jun 2017, at 1:37 am, Richard Gaskin via use-livecode >wrote: > > How many of you have never before known that commas are optional between > definition arguments? I have seen it before in user scripts but never used it myself. It’s one of those things you discover (like when {} could be used interchangeably with []) that you quickly realise you should never rely on so you forget pretty quickly ;-) FWIW it actually wouldn’t be _that_ hard to add the ability to specify some syntactic sugar to your handlers and have the parser ignore said sugar: e.g: command Foo “with” pBar end Foo Foo with pBar However this is somewhat less than and conflicts with the open language concept so it’s probably best not to consider it too seriously. Cheers Monte ___ 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: Inconsistent comma requirements
On 24 June 2017 at 16:37, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Two questions: > > How many of you have never before known that commas are optional between > definition arguments? > > For those who've known about this, were you confused to discover that this > only works for definitions but not calls? > I was never confused. I chose to always use commas so there would never be any added confusion. Although I have occasionally slipped up and not bothered using the comma but then replace them when I review the code. It was usually 'functions' where this happened, not so much with commands. Sean Cole ___ 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: Inconsistent comma requirements
On 24 June 2017 at 20:59, hh via use-livecodewrote: > Here's to all who didn't ignore the wonderful LC lessons for years! > > on mouseUp > I > end mouseUp > > on I don't care >answer I'm ("fan of it.") > end I > > function I'm fan >return "Beautiful LiveCode! I'm " & fan > end I'm > Beautiful indeed Sean Cole ___ 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: Inconsistent comma requirements
Livecode claims that it's programming langauge is English-like (i.e. like a human language); well it just got more like that: human languages are incredibly inconsistent. Richmond. On 6/24/17 10:59 pm, hh via use-livecode wrote: Here's to all who didn't ignore the wonderful LC lessons for years! on mouseUp I end mouseUp on I don't care answer I'm ("fan of it.") end I function I'm fan return "Beautiful LiveCode! I'm " & fan end I'm ___ 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: Inconsistent comma requirements
Here's to all who didn't ignore the wonderful LC lessons for years! on mouseUp I end mouseUp on I don't care answer I'm ("fan of it.") end I function I'm fan return "Beautiful LiveCode! I'm " & fan end I'm ___ 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: Inconsistent comma requirements
Alex Tweedly wrote: > On 24/06/2017 16:37, Richard Gaskin via use-livecode wrote: >> On the other hand, perhaps a rule could be introduced that any >> keywords used in arg strings with no commas when calling a custom >> handler are treated as literal text. > NO, please not. > > Just think of the consequences ... >DoSomething tA and tB > is different from >put tA and tB into temp >DoSomething temp > and indeed from >DoSomething (tA and tB) Different, yet unambiguous, arguably more so than using "=" for comparison in most contexts but for assignment in variable declaration. DoSomething tA and tB -- "and" treated as a string, since it follows a custom command name put tA and tB into temp -- "put" is a built-in command, so "and" is a logical operator (and isn't "temp" a keyword?) DoSomething (tA and tB) -- Parens bypass any attempt to be English-like, forcing evaluation. -- 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: Inconsistent comma requirements
On 24/06/2017 16:37, Richard Gaskin via use-livecode wrote: Two questions: How many of you have never before known that commas are optional between definition arguments? For those who've known about this, were you confused to discover that this only works for definitions but not calls? I did, and no didn't find it confusing. I discovered it maybe a year or two ago, when some code I downloaded used it. I blinked a few times in surprise, shuddered - and knew that it was just a (mis)feature that I will never, ever use :-) On the other hand, perhaps a rule could be introduced that any keywords used in arg strings with no commas when calling a custom handler are treated as literal text. NO, please not. Just think of the consequences ... DoSomething tA and tB is different from put tA and tB into temp DoSomething temp and indeed from DoSomething (tA and tB) -- 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: Inconsistent comma requirements
I have had several of these typos in the past and they never caused problems. In the example below pParam is argument 1. The comma is ignored. command test, pParam answer pParam end test The parser is much better in v8 but could still be tightened up a bit. An example is extraneous closing parens in "if" or "repeat" expression constructs are no longer ignored. They didn't cause parsing errors prior to v8. My comma in the above example is minor compared to the other LC goals at hand for the team. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Saturday, June 24, 2017 11:38 AM To: How to use LiveCode Cc: Richard Gaskin Subject: Inconsistent comma requirements Apparently commas are optional in a handler definition, e.g.: on DoSomething a b But they are not optional when passing arguments to a definition, e.g.: Doomething a b ...throws a compilation error, but this: DoSomething a,b ...works. Because most languages require commas separating arguments, and because calling a handler explicitly requires them, it never occurred to me that the definition would allow them to be optional. Ideally the same rules would apply on both sides. I can kinda understand why they don't here, but if we had comma-free arguments we could add syntactic sugar to make things more English-like, e.g.: DoSomething with a and b Two questions: How many of you have never before known that commas are optional between definition arguments? For those who've known about this, were you confused to discover that this only works for definitions but not calls? -- 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: Inconsistent comma requirements
On 6/24/2017 11:37 AM, Richard Gaskin via use-livecode wrote: > Two questions: > > How many of you have never before known that commas are optional > between definition arguments? I discovered this in LC6.7.11 only about 2 months ago and was very surprised. I had expected that separating arguments by commas would be a requirement > > For those who've known about this, were you confused to discover that > this only works for definitions but not calls? I see the absence of required comma in handler definitions almost as a "bug" in that is increases the risk of making an error. If I have composite variable names, like 'thisParam' and I accidentally type it a 'this Param' I now have 2 parameters for my handler where I had intended only 1. Unrelated aside: My biggest wish for an IDE script editor improvement would be for a popup list of previously used variables - even if it only listed variables you explicitly declared via a Global or Local statement. There are so many time I am write some code and I cant remember what I called something 100 lines previously and have to scroll up and find it and scroll back to where I am editing. ___ 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: Inconsistent comma requirements
On June 24, 2017 11:36:32 AM Richard Gaskin via use-livecodewrote: It was just odd to find something so fundamental to the language that I'd never seen before in all my years with LC. And apparently there are at least two of us. Three. -- 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: Inconsistent comma requirements
Mark Wieder wrote: > On 06/24/2017 08:37 AM, Richard Gaskin via use-livecode wrote: > >>DoSomething with a and b >> >> Two questions: >> >> How many of you have never before known that commas are optional >> between definition arguments? > > > > However, I don't think that particular syntactic sugar, at least, > would work. The "and" operator is already in use as a logical anding > of two parameters, so there's no way for the parser to differentiate > between that and a list of two separate parameters. Yeah, just a pipe dream, but a pleasant one. On the other hand, perhaps a rule could be introduced that any keywords used in arg strings with no commas when calling a custom handler are treated as literal text. We do generally tread lightly with keywords, and often for good reason. But at the same time the language is chock full o' "sometimes" rules, so apparently the engine is already smart enough now and then to use a token different ways depending on context. For example, like other xTalks LC uses "=" as a comparison operator, but not for assignments as is commonly done in other languages. But only sometimes. When used to define a script-local var or constant, the engine is smart enough to notice the context and allow the readable, compact form that uses "=" for assignment, e.g.: constant kWindowMin = 500 local sMaxConnections = 1 I'm not advocating that the engine team take time away from more critical tasks (like restoring video playback on Linux soon? ) to monkey with trivialities like comma-free handler params. It was just odd to find something so fundamental to the language that I'd never seen before in all my years with LC. And apparently there are at least two of us. PS: I tried using the Dictionary to find "and" in order to review any nuances about its use, but alas was merely reminded why the new Dict isn't as useful as the old one (beyond the painfully generous white space): When I run that search I get a great many results, unsorted and apparently unranked, most not relevant to my search, and with the exact match hidden somewhere in the bottom third of the results list, which mystifyingly includes "exit", "export with palette", and "MCISendString", among others. Since the old Dictionary was written entirely in LiveCode and the new one wraps JavaScript inside the browser widget, in a way the funky results make a very strong statement about the power of LiveCode, however subtly presented: On the TIOBE index JavaScript is listed as the world's seventh most popular language. We're told that one of the reasons languages that reach the tipping point of the TIOBE Top 50 stay there is because they have vast ecosystems of good libraries available for common tasks, like search. Yet what we see in practice here is that it's easier to write a custom indexing and search subsystem from scratch in LC than it is to merely find one of equivalent quality in the JavaScript world. :) Vive le LiveCode! -- 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: Inconsistent comma requirements
On 06/24/2017 08:37 AM, Richard Gaskin via use-livecode wrote: DoSomething with a and b Two questions: How many of you have never before known that commas are optional between definition arguments? However, I don't think that particular syntactic sugar, at least, would work. The "and" operator is already in use as a logical anding of two parameters, so there's no way for the parser to differentiate between that and a list of two separate parameters. -- 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