I was going to reply to something, but part way through the last message,
my brain melted and I stated thinking in 8088 assembler. I HATE WHEN THAT
HAPPENS!
The reason for forgetting is because it is not something that I, at least,
will be tempted to use very often, on the order of "this me"
So if
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 a
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 th
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 t
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.
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 mea
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
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, Mik
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),
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 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=8
Brian and Bernd, thank you for this!! I use it all the time now and I love it.
Cheers,
Roger
> On Jul 18, 2017, at 3:59 PM, BNig via use-livecode
> wrote:
>
> Brian Milby contributed to tinyDictinary the extraction of synonyms. He also
> submitted a pull request to add synony
Brian Milby contributed to tinyDictinary the extraction of synonyms. He also
submitted a pull request to add synonyms to the built-in dictionary
https://github.com/livecode/livecode/pull/5669
Synonyms now are part of the built-in dictionary as of LC9 DP8.
TinyDictionary displays synomyms in LC
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
> 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
&g
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.
;
>> 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
e 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
ough 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
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 do
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 fro
'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 al
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..
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
(abs
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 aris
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
__
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 actu
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
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 positi
ot;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 'diffe
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,
t' 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 al
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
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
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
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
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 th
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
A marginal note connected to some nice ideas of this thread:
In LC Builder
handler xx (param1, param2) requires to call xx always with two args.
So, to use one single parameter that is a list or an array is
currently the _only_ way to have optional parameters (which are then
elements of that sing
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 o
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 th
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
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
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 arr
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 e
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
>
>
>>
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:
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 "Thi
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, t
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:
>
> H
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 p
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
prefer
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 } i
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
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 fo
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 compl
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
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
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-liv
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:
> He
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)&cr into tArg
se
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
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 li
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 ha
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 langua
ind 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 s
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 ap
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'
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.run
> 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
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 vis
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 on
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 m
o 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,
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 whe
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
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
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
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 bet
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
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'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 fo
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
On 06/26/2017 11:48 AM, 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 sugg
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
> 26. jun. 2017 kl. 19:59 skrev Mark Wieder via use-livecode
> :
>
> 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.
And it also applies t
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
Pete-
Friday, June 14, 2013, 9:33:20 PM, you wrote:
> I'm sorry...
I'm back in town now. Wow - somebody got up on the wrong side of the
bed...
Pete- I set up a topic on the web forum to discuss the propertynames,
and there's a rather interesting discussion going on there.
--
-Mark Wieder
mw
Pete-
Friday, June 14, 2013, 9:33:20 PM, you wrote:
> I'm sorry...
I'm back in town now. Wow - somebody got up on the wrong side of the
bed...
Pete- I set up a topic on the web forum to discuss the propertynames,
and there's a rather interesting discussion going on there. You can
join in if yo
engine contributors forum regarding whether it's necessary to return
> synonyms from the proposed changes to the propertynames function. SInce
> not everyone reads that forum, I'm posting it here. You can read the prior
> posts on the forum.
> ==
On 15/06/2013, at 2:33 PM, Peter Haworth wrote:
> I'm sorry to have to post this somewhat angry post.
SNIP rest of rant
FWIW I decided I no longer had time to think about propertyNames when you
persisted in posting here after being told where to post and then said you
didn't have time to p
I'm sorry to have to post this somewhat angry post. There's a thread on
the engine contributors forum regarding whether it's necessary to return
synonyms from the proposed changes to the propertynames function. SInce
not everyone reads that forum, I'm posting it here. Yo
91 matches
Mail list logo
