variable xref

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

variable xref

dunbarx via use-livecode
Has anyone written a script to go through a stack and xref the variables?

--
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
On 03/27/2018 06:56 AM, Mike Kerner via use-livecode wrote:
> Has anyone written a script to go through a stack and xref the variables?
>

Yeah, but I didn't find it of much use. Unless you're using a lot of
global variables or constants, why would this be useful?

..and notice that this task becomes a *lot* easier if you declare variables.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
Heck no.  I spend way too much time in environments that were written to
make the complier-writer's job easier and have 50-100 lines of headers.
It's annoying to the extreme.

Nothing makes code less readable than re-using i, j, k, l, and m because
you don't feel like using a readable loop counter because you'll have to
fix the declaration.

I want the best of both worlds, and mostly I want the machine to do the
work, not me.  I'm busy.

On Tue, Mar 27, 2018 at 1:23 PM, Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 03/27/2018 06:56 AM, Mike Kerner via use-livecode wrote:
>
>> Has anyone written a script to go through a stack and xref the variables?
>>
>>
> Yeah, but I didn't find it of much use. Unless you're using a lot of
> global variables or constants, why would this be useful?
>
> ..and notice that this task becomes a *lot* easier if you declare
> variables.
>
> --
>  Mark Wieder
>  [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
On 28/03/2018 14:45, Mike Kerner via use-livecode wrote:
> Heck no.  I spend way too much time in environments that were written to
> make the complier-writer's job easier and have 50-100 lines of headers.
> It's annoying to the extreme.
Yeah - why are those variables declared all together, way up at the top,
when it would generally be better to declare and describe them down
where they are just about to be used :-)
>
> Nothing makes code less readable than re-using i, j, k, l, and m because
> you don't feel like using a readable loop counter because you'll have to
> fix the declaration.
Of course, even with explicitVariable true, loop variables are
auto-declared for you ....
> I want the best of both worlds, and mostly I want the machine to do the
> work, not me.  I'm busy.
And one piece of work it can do much better than me is check for typos
in my code :-)

-- Alex.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
The C key will copy what you have selected, if you hold down the ctrl or cmd key when you type it. Similarly, the V key will put what you copied where the cursor is, and will even replace whatever you have selected! ;-)

Bob S


> On Mar 28, 2018, at 06:52 , Alex Tweedly via use-livecode <[hidden email]> wrote:
>
> And one piece of work it can do much better than me is check for typos in my code :-)
>
> -- Alex.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
Right.  It's the beauty of LC.  You choose to declare, I choose to not
declare.  Can you imagine how annoying it would be whenever you send a text
that included jargon and your phone autocorrected it for you because it
didn't know what you meant?  Or when your voice assistant didn't understand
you and substituted "vasectomy" when you said "vacillate"?  I don't think
I'd be able to take it.  Thank goodness grammar checkers and spellcheckers
just hilite and underline the words and phrases they aren't sure about
instead of making you add them to the dictionary for every single document.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
On 2018-03-28 15:45, Mike Kerner via use-livecode wrote:
> Heck no.  I spend way too much time in environments that were written
> to
> make the complier-writer's job easier and have 50-100 lines of headers.
> It's annoying to the extreme.

Heh - I'm not sure that the necessity to predeclare things in many
languages can just be put down to 'making the compiler writer's job
easier' - even if you go back 'just' 15 years, computers were nowhere
near as powerful as they are today and most of the languages which exist
today have a history which goes back waaaay further.

If things are not pre-declared then you need at *least* two passes to
compile a program. Each pass requires a linear traversal of the input to
the pass. If you require the programmer to pre-declare then you can
compile in a single pass in many cases (a technique called
syntax-directed translation). If you don't pre-declare then the first
phase has to parse all the syntax into structures without knowing how
they fit together, and then you have to iterate over those structures
defining the 'names' in appropriate scopes and *then* you have to
iterate over those structures again to link up the uses of the names to
the definitions.

(You can merge the declaration and parsing phases - but not the
declaration, parsing and definition phases - hence why you have a
minimum of two passes in a language which does not require
pre-declaration).

Of course, in a dynamic environment like LiveCode where code is split up
and insulated into multiple distinct much smaller texts, and you can
defer action until use, pre-declaration is not really required (and
indeed it is not) - you can amortize the cost of the notional passes
over the time the program is running rather than having to do it all
ahead of time.

> Nothing makes code less readable than re-using i, j, k, l, and m
> because
> you don't feel like using a readable loop counter because you'll have
> to
> fix the declaration.

I must confess I still use i, j, k etc. type variable naming - but only
when I want the index and element in numeric arrays or if I'm writing
code which is doing maths where the equations use such index notation:

   repeat with i = 1 to the number of elements in tVar
     -- now I can mutate the elements of tVar as it loops
   end repeat

I'm not sure why I've got into that habit though - its not really a good
one! Although I don't think it does much harm if the loops are only two
or three lines long.

Of course, if you happen to have an non-optimizing lower-level compiler,
then re-using variables can make a huge difference to code performance
as you can be more sure a register will be used (assuming the data type
is appropriate) - that being said 32-bit intel architectures have never
really had that issue as they have virtually no registers anyway!
(Fortunately something which the 64-bit variant has fixed!).

> I want the best of both worlds, and mostly I want the machine to do the
> work, not me.  I'm busy.

Indeed, the work has to be done at some point, by somebody/thing - the
balance is whether you want to pay the cost:
   1) waiting for things to compile (a full recompile of the engine on
Mac OS X used to take 15-20mins when I first got it; although the record
was apparantly 8 hrs on the AIX box MetaCard used to have - and C/C++
*requires* predeclaration for most things).
   2) over the lifetime of the execution of the program (or at the start
if you use a lot of code at startup)
   3) by the programmer whilst writing the code

That all being said, variable analysis could be done better in all
languages I think - although it isn't the easiest of problems or things
to get right. Python I think might be *slightly* better than LiveCode's
(its somewhere between explicitVars = true and explicitVars = false -
and doesn't require declaration). On the other hand, Python doesn't have
a mode where you can have bare literals (which require significant
context analysis to work out whether they are variables are not unless
you do all the work whilst executing the code - which is essentially
what LiveCode does when explicitVars are false - so you pay for that
with a performance cost and not knowing whether you've made an error
before you run).

I think it would be generally true to say that most programming
languages are designed to keep any context-sensitive information
required compile/execute them to the bare minimum - and any which is
required can be collected in very fast and efficient ways. For humans
this is very unintuitive though - if nothing else, humans are generally
quite good at very quickly guessing at the correct context of things
when there is a paucity of information - computers may have caught up a
bit speed wise to allow greater contextual awareness (just because they
are faster with more storage/memory) but programming languages perhaps
have not...

My general feeling that there is a better balance lurking - somewhere
between Python and LiveCode's non-explicit-variables mode:

   1) Python does not require pre-declaration of variables, and is pretty
good at determining when you mis-spelt a variable - however all literals
must be quoted.

   2) LiveCode does not require pre-declaration (in expliciVars = false
mode), and allows you to unquote literals as long as they are not also
variables in the same context - but it cannot tell you if you've
mis-spelt a variable.

The problem here is finding that balance.

Warmest Regards,

Mark.

P.S. We are also, of course, blessed with the fact these days that you
can have readable variable names at all - I think the VMS C compiler
still had an 8 char limit on identifiers until some hideously recent
time.

P.P.S. Even with the machines we do have today, I'm not sure what not
having to predeclare things in C would do the speed of compilation of C
- so in some cases we just have to live with the slight inconvenience :)

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
I don't want to pretend to be an expert on the topic of writing compilers,
since I only ever wrote two, both under the watchful obsession of a
professor, and my lex and parse code were not optimal in either case.  In
general, they were some of the easiest pieces of large code I ever wrote
because the grammars were so rigid and rule-based.  Building forgiveness
into them would have made the poor developer's life easier, even thought
that meant adding a third pass to try to ascertain context instead of
blindly aborting when something didn't exactly fit the formula.

I agree that unquoted literals are not ideal.  I think they should be
deprecated, and I think they should have been removed in 1986, so add that
to the LC10 list.  They have always made reading scripts more difficult.
Readability and approachability are two things that have set xtalk apart.
Unquoted literals detract from that.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
On Mar 29, 2018, at 10:34 PM, Mike Kerner via use-livecode <[hidden email]> wrote:

>
> I don't want to pretend to be an expert on the topic of writing compilers,
> since I only ever wrote two, both under the watchful obsession of a
> professor, and my lex and parse code were not optimal in either case.  In
> general, they were some of the easiest pieces of large code I ever wrote
> because the grammars were so rigid and rule-based.  Building forgiveness
> into them would have made the poor developer's life easier, even thought
> that meant adding a third pass to try to ascertain context instead of
> blindly aborting when something didn't exactly fit the formula.
>
> I agree that unquoted literals are not ideal.  I think they should be
> deprecated, and I think they should have been removed in 1986, so add that
> to the LC10 list.  They have always made reading scripts more difficult.
> Readability and approachability are two things that have set xtalk apart.
> Unquoted literals detract from that.

+1

Devin Asay
Director
Office of Digital Humanities
Brigham Young University


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
I agree. The goal was to make computing as english like as possible, but the take away to that great experiment is that one can only go so far. People interpret what a person may mean. Computers do not have that luxury. Still xTalk is a magnificient accomplishment.

Bob S


> On Mar 29, 2018, at 21:34 , Mike Kerner via use-livecode <[hidden email]> wrote:
>
> I agree that unquoted literals are not ideal.  I think they should be
> deprecated, and I think they should have been removed in 1986, so add that
> to the LC10 list.  They have always made reading scripts more difficult.
> Readability and approachability are two things that have set xtalk apart.
> Unquoted literals detract from that.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
An important question to ask here is 'what do we mean by English-like'?

I'd suggest that the language doesn't matter - so 'natural language like' would perhaps be a better term but even then is that really what we mean?

There's no inherent difference (formally at least) between a programming language and a natural language - at least from the way they are written (letters, punctuation, grammar, vocabulary) and perhaps not even in terms of interpretation (what a phrase in a language means - they are either declarations/definition of things, providing context or instructing actions).

The difference comes at the point we consider the 'machine' which the language is instructing - human or computer.

From this (very narrow) point of view, human machines (the brain) are perhaps just a great deal better 'engineered' to process language quickly and have a much greater capacity for storing, recalling and processing contextual information which means ambiguities can be resolved with a much greater degree of precision and fault tolerance.

So we are perhaps talking about constructing language(s) which allows a computer to be instructed more like we would a human - i.e. not having to define every single thing in mind numbing detail, knowing that the receiver has enough competence and knowledge to infer and fill in the gaps correctly and then carrying out those actions with a high degree of accuracy (although computers are probably already better for accuracy in many domains - they just need their hand held throughout!) or at least have the ability to shout when things really don't 'compute'. In this vein I'm not sure syntax is so important.

I don't think the experiment as you put it has yet ended - computers and their software development have just not caught up yet which is, in part, probably at least related to performance of computer machines for these kinds of tasks.

Warmest Regards,

Mark.



Sent from my iPhone

> On 30 Mar 2018, at 15:35, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> I agree. The goal was to make computing as english like as possible, but the take away to that great experiment is that one can only go so far. People interpret what a person may mean. Computers do not have that luxury. Still xTalk is a magnificient accomplishment.
>
> Bob S
>
>
>> On Mar 29, 2018, at 21:34 , Mike Kerner via use-livecode <[hidden email]> wrote:
>>
>> I agree that unquoted literals are not ideal.  I think they should be
>> deprecated, and I think they should have been removed in 1986, so add that
>> to the LC10 list.  They have always made reading scripts more difficult.
>> Readability and approachability are two things that have set xtalk apart.
>> Unquoted literals detract from that.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
On 03/30/2018 08:56 AM, Mark Waddingham via use-livecode wrote:

> I'd suggest that the language doesn't matter - so 'natural language like' would perhaps be a better term but even then is that really what we mean?

A good question to ask here might be "what are the pain points of the
language as it now exists?"

Since I always use strict variable checking I don't have to worry about
unquoted literals because the compiler will always give me an error. For
me the pain of having to put quotes around literals is muchly offset by
the security of having the compiler keep me out of trouble. Mostly. YMMV.

On the other hand, there are certain keywords that I think really should
be constants and not unquoted literals. I find it a pain to have to put
quotes around color names. If I want to set a text color to black, I
find it awkward to have to set it to "black".

> So we are perhaps talking about constructing language(s) which allows a computer to be instructed more like we would a human - i.e. not having to define every single thing in mind numbing detail, knowing that the receiver has enough competence and knowledge to infer and fill in the gaps correctly and then carrying out those actions with a high degree of accuracy (although computers are probably already better for accuracy in many domains - they just need their hand held throughout!) or at least have the ability to shout when things really don't 'compute'. In this vein I'm not sure syntax is so important.

I'm still not ready to have computers drive cars.
--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
I think we are not seeing the elephant in the room here. Programming languages work because a great deal of effort has been exherted defining what we MEAN when we SAY something to the computer. In fact the whole process of writing software is precicely that of removing all ambiguity. It's true that on the surface it appears that we can tell the computer what we want and it can interpret what we mean, but only because under the hood someone wrote code that says in effect, given all these inputs, produce this output. That process is after all at it's heart a binary one.

The fact that we are not constantly aware of this is why some men are able to believe that "artificial" intelligence means "actual" intelligence. The only intelligence a computer can posess is that of the developer and the end user. Anything else is an illusion. A grand one I grant, but still it's only the old smoke and mirrors of the ancient sorcerers. The "magic" is making sure no one sees what the sorcerer is actually doing while his subjects are distracted by something else.

Let the flaming begin! ;-)

Bob S


> On Mar 30, 2018, at 08:56 , Mark Waddingham via use-livecode <[hidden email]> wrote:
>
> An important question to ask here is 'what do we mean by English-like'?
>
> I'd suggest that the language doesn't matter - so 'natural language like' would perhaps be a better term but even then is that really what we mean?
>
> There's no inherent difference (formally at least) between a programming language and a natural language - at least from the way they are written (letters, punctuation, grammar, vocabulary) and perhaps not even in terms of interpretation (what a phrase in a language means - they are either declarations/definition of things, providing context or instructing actions).
>
> The difference comes at the point we consider the 'machine' which the language is instructing - human or computer.
>
> From this (very narrow) point of view, human machines (the brain) are perhaps just a great deal better 'engineered' to process language quickly and have a much greater capacity for storing, recalling and processing contextual information which means ambiguities can be resolved with a much greater degree of precision and fault tolerance.
>
> So we are perhaps talking about constructing language(s) which allows a computer to be instructed more like we would a human - i.e. not having to define every single thing in mind numbing detail, knowing that the receiver has enough competence and knowledge to infer and fill in the gaps correctly and then carrying out those actions with a high degree of accuracy (although computers are probably already better for accuracy in many domains - they just need their hand held throughout!) or at least have the ability to shout when things really don't 'compute'. In this vein I'm not sure syntax is so important.
>
> I don't think the experiment as you put it has yet ended - computers and their software development have just not caught up yet which is, in part, probably at least related to performance of computer machines for these kinds of tasks.
>
> Warmest Regards,
>
> Mark.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
That's pretty much my point of view - the compiler should keep you out of trouble but not get in the way.

Colours are the same case as left in the context of textAlign. If we reserved all lowercase alphabetic identifiers, so your vars had to contain an uppercase letter or non letter character then that would 'solve' that problem at the expense of freedom of the coder. (But only for natural languages which have casing!).

So really what we want is 'reserved in context' - the problem there though is the context - in many cases that can only be known at runtime.

In terms of computers driving cars then we let computers monitor and interpret sensors for humans in nuclear power stations. We let them 'drive' very large aircraft and provide simulated feedback and sensor interpretation there to pilots. Same for trains, trams, vehicles in factories and warehouses... So why not cars? ;)

Although that being said - I do have a slight issue with computers driving cars at this point in time - but only because they have to deal with humans driving cars and those pesky pedestrians with free will...

Warmest Regards,

Mark.

Sent from my iPhone

> On 30 Mar 2018, at 17:27, Mark Wieder via use-livecode <[hidden email]> wrote:
>
>> On 03/30/2018 08:56 AM, Mark Waddingham via use-livecode wrote:
>>
>> I'd suggest that the language doesn't matter - so 'natural language like' would perhaps be a better term but even then is that really what we mean?
>
> A good question to ask here might be "what are the pain points of the language as it now exists?"
>
> Since I always use strict variable checking I don't have to worry about unquoted literals because the compiler will always give me an error. For me the pain of having to put quotes around literals is muchly offset by the security of having the compiler keep me out of trouble. Mostly. YMMV.
>
> On the other hand, there are certain keywords that I think really should be constants and not unquoted literals. I find it a pain to have to put quotes around color names. If I want to set a text color to black, I find it awkward to have to set it to "black".
>
>> So we are perhaps talking about constructing language(s) which allows a computer to be instructed more like we would a human - i.e. not having to define every single thing in mind numbing detail, knowing that the receiver has enough competence and knowledge to infer and fill in the gaps correctly and then carrying out those actions with a high degree of accuracy (although computers are probably already better for accuracy in many domains - they just need their hand held throughout!) or at least have the ability to shout when things really don't 'compute'. In this vein I'm not sure syntax is so important.
>
> I'm still not ready to have computers drive cars.
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
We have computers automate these processes, but always with a human ready to intervene. The computer will act based upon the inputs it receives. If the inputs go wrong, you may have an exceptional diagnostic routine running to detect it and act accordingly, but only a human can make a judgement at "runtime" if you will.

The value to using computers in these instances is that computers can react much more quickly, and given all the corrects inputs, and assuming it is functioning correctly, will always make the right "decision" based upon a predetermined set of parameters. A human can be slow. A human can make mistakes. A human can become malicious. A computer cannot. A computer can however, lack all the inputs to make what we would call a right decision.

Take the classic arguement of a person walking a dog. The dog breaks away right in front of an oncoming car with no time to stop. Does the car swerve to avoid the living mammal right in front of it and hit the dog owner instead? How could you program a computer to make that distinction?

If computers are going to drive cars, then it needs to be done all at once. A switch gets thrown and now no one's car will work unless the computer is driving it. Also, I think it would be better if auto driving cars were restricted to places without crossing traffic, like highways/freeways. A car leaving a freeway would have to come to a stop and the driver should have to take control to proceed on streets.

Ideally self driving cars should never be based entirely upon optics. For this sort of thing to be really as safe as can be managed, every car would need to have beacons at the corners and maybe along the sides, and the cars would need to be in communication with all the other cars within a certain distance of it. People however would not accept this because there would be the potential to track people without them knowing it's being done. (Of course that is likely happening now but that's another discussion).

Bob S


> On Mar 30, 2018, at 09:51 , Mark Waddingham via use-livecode <[hidden email]> wrote:
>
> In terms of computers driving cars then we let computers monitor and interpret sensors for humans in nuclear power stations. We let them 'drive' very large aircraft and provide simulated feedback and sensor interpretation there to pilots. Same for trains, trams, vehicles in factories and warehouses... So why not cars? ;)


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
When I was thinking about unquoted literals I was thinking about string literals, something like
put one into counter
Or
put one into two

Numeric literals don’t offend the senses:
put 1 into counter

In the case of property assignments I could be persuaded either way:  that there is a global constant left that means “left” (making it a reserved word), that in the context of certain properties, certain string values are constants and not containers (not as ideal since there is then also going to have to be a warning to the user that their container called “left” is not going to work in the context of the property), that we’re going to have to quote “left” (also not ideal), or that we’re going to allow unquoted string literals in property assignments (but then we are back to the parser/lexer really should error check  assignments for some properties so someone doesn’t set the align to tpo unless tpo had previously been used and/or assigned a value, and therefore appears in the symbol table).  The last one gets us back to having the parser/lex doing some spellchecking or symbol lookup.

Deprecating “features” is often the right thing to do because it cleans up kluges that are no long necessary, and clarity and simplicity and order are restored.  Yes, that means that some code will be affected and have to be reworked.  It’s either that or n00bs need a separate note in the dictionary for every kluge, the same way that non-native English speakers get to fight through every exception in spelling and punctuation.  I sometimes mention the running joke in 4D, “The Tao”, a collection of all the things that are counterintuitive that you have to work around.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
Hence my original statement about the xTalk language trying to be English like. (Back then I don't think Hypercard was multi-language).

Bob S


> On Mar 30, 2018, at 10:53 , Mikey via use-livecode <[hidden email]> wrote:
>
> When I was thinking about unquoted literals I was thinking about string literals, something like
> put one into counter
> Or
> put one into two
>
> Numeric literals don’t offend the senses:
> put 1 into counter

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
Mark Wieder wrote:

 > A good question to ask here might be "what are the pain points of the
 > language as it now exists?"

For me performance is a pain point.  If I can demonstrate LC is at least
on par with other scripting languages I get a foot in the door. But in
server work performance counts a lot.

So the question I've been wondering is:  what exactly did the PHP team
do in their v7 to boost its speed so far beyond v5, blowing pretty much
every other scripting language out of the water, and is there anything
among those optimizations that can be applied to LC?

If LC were even close to being as fast as PHP7, it would so destroy
Rails it would open many doors....

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Browser Widget Document Download

dunbarx via use-livecode
I have a url(that does not directly reference a file) that on iOS displays a
PDF in the iOS native PDF viewer and on Android Downloads the PDF as Android
has no native PDF viewer. I would like to download the PDF at all times.
Testing in the IDE... When I set the widget to the url the PDF displays.
When I put the url into a var  "put url (tURL) into MyVar" I see some
html/javascript in MyVar but no PDF. What I would like to do is download the
PDF on both mobile platforms. Is this even possible with LC?

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: variable xref

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
Whenever you deprecate code you may be destroying
someone’s life’s coding work.  There should always be
at least a rock solid migration utility offered that will
make any such deprecations completely smooth,
and painless for anyone who has to make the changes.

Just my 2 cents for the day. ;-)

Rick

> On Mar 30, 2018, at 1:53 PM, Mikey via use-livecode <[hidden email]> wrote:
>
> Deprecating “features” is often the right thing to do because it cleans up kluges that are no long necessary, and clarity and simplicity and order are restored.  Yes, that means that some code will be affected and have to be reworked.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12