numberFormat affecting array keys???

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
Hi Lagi,

I can’t agree more.  Never break anyone’s code if at all possible.
Create a new numberformat like NumberFormatXL or something
similar.  Leave the old working stuff alone.

Just my 2 cents for the day!

Rick

> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <[hidden email]> wrote:
>
> Hi
>
> I don't know why you want to adapt/enhance the number format as that could
> break already working code that uses the nuances of numberformat already.
>
> Why not add an instruction NumberFormatXL and create the an Excel version
> like Curry says. You won't have to jump through hoops to make sure it
> doesn't break anything, you can fix what's wrong(?) and you can add stuff
> in there without affecting old code, plus and with Curry's experience with
> spreadlib you probably have a lot of the problems to solve sorted.
>
> Now my usual caveat "Everything is easy for the man who doesn't have to do
> it himself" - but I haven't seen anything that Mark and his team can't do -
> usually the problems stem from trying no to break older stuff.
>
> I think in this case adding a new command would make it easier all round.
> While you're at it why not put a callback/ or in  wordpress parlance an
> "AddAction"  option so you can add to the formatting on the fly?
>
> Regards Lagi
>


_______________________________________________
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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
+1

And if you must introduce a arguably newer/better term, please make its
syntax more English-like and less code-like.  This _is_ LiveCode.  Cryptic
is for those other languages.  /2_cents

~Roger


On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
[hidden email]> wrote:

> Hi Lagi,
>
> I can’t agree more.  Never break anyone’s code if at all possible.
> Create a new numberformat like NumberFormatXL or something
> similar.  Leave the old working stuff alone.
>
> Just my 2 cents for the day!
>
> Rick
>
> > On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
> [hidden email]> wrote:
> >
> > Hi
> >
> > I don't know why you want to adapt/enhance the number format as that
> could
> > break already working code that uses the nuances of numberformat already.
> >
> > Why not add an instruction NumberFormatXL and create the an Excel version
> > like Curry says. You won't have to jump through hoops to make sure it
> > doesn't break anything, you can fix what's wrong(?) and you can add stuff
> > in there without affecting old code, plus and with Curry's experience
> with
> > spreadlib you probably have a lot of the problems to solve sorted.
> >
> > Now my usual caveat "Everything is easy for the man who doesn't have to
> do
> > it himself" - but I haven't seen anything that Mark and his team can't
> do -
> > usually the problems stem from trying no to break older stuff.
> >
> > I think in this case adding a new command would make it easier all round.
> > While you're at it why not put a callback/ or in  wordpress parlance an
> > "AddAction"  option so you can add to the formatting on the fly?
> >
> > Regards Lagi
> >
>
>
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
Folks,
What I see in this discussion is extreme efforts to do something that is straightforward and transparent in other languages (I can see these suggested solutions as creating unnecessary complexity).That is to simply declare some variable types.

E.g.
variable ix=integer double
variable yzz=real

Etc, etc

Variables that are not declared would be handled in the same way they are now, by default.

Just my 2 cents.
Bill P

William Prothero
http://es.earthednet.org

> On Apr 25, 2017, at 7:31 AM, Roger Eller via use-livecode <[hidden email]> wrote:
>
> +1
>
> And if you must introduce a arguably newer/better term, please make its
> syntax more English-like and less code-like.  This _is_ LiveCode.  Cryptic
> is for those other languages.  /2_cents
>
> ~Roger
>
>
> On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
> [hidden email]> wrote:
>
>> Hi Lagi,
>>
>> I can’t agree more.  Never break anyone’s code if at all possible.
>> Create a new numberformat like NumberFormatXL or something
>> similar.  Leave the old working stuff alone.
>>
>> Just my 2 cents for the day!
>>
>> Rick
>>
>>> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
>> [hidden email]> wrote:
>>>
>>> Hi
>>>
>>> I don't know why you want to adapt/enhance the number format as that
>> could
>>> break already working code that uses the nuances of numberformat already.
>>>
>>> Why not add an instruction NumberFormatXL and create the an Excel version
>>> like Curry says. You won't have to jump through hoops to make sure it
>>> doesn't break anything, you can fix what's wrong(?) and you can add stuff
>>> in there without affecting old code, plus and with Curry's experience
>> with
>>> spreadlib you probably have a lot of the problems to solve sorted.
>>>
>>> Now my usual caveat "Everything is easy for the man who doesn't have to
>> do
>>> it himself" - but I haven't seen anything that Mark and his team can't
>> do -
>>> usually the problems stem from trying no to break older stuff.
>>>
>>> I think in this case adding a new command would make it easier all round.
>>> While you're at it why not put a callback/ or in  wordpress parlance an
>>> "AddAction"  option so you can add to the formatting on the fly?
>>>
>>> Regards Lagi
>>>
>>
>>
>> _______________________________________________
>> 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


_______________________________________________
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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
On 04/25/2017 08:33 AM, prothero--- via use-livecode wrote:

> Folks,
> What I see in this discussion is extreme efforts to do something that is straightforward and transparent in other languages (I can see these suggested solutions as creating unnecessary complexity).That is to simply declare some variable types.
>
> E.g.
> variable ix=integer double
> variable yzz=real
>
> Etc, etc
>
> Variables that are not declared would be handled in the same way they are now, by default.
>
> Just my 2 cents.
> Bill P

Heh. Don't hold your breath waiting for this one.
Requested back in 2005 (version 2.5.1).

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

--
  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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
Variable Typing! EEEK!!!

Bob S


> On Apr 25, 2017, at 08:33 , prothero--- via use-livecode <[hidden email]> wrote:
>
> Folks,
> What I see in this discussion is extreme efforts to do something that is straightforward and transparent in other languages (I can see these suggested solutions as creating unnecessary complexity).That is to simply declare some variable types.
>
> E.g.
> variable ix=integer double
> variable yzz=real
>
> Etc, etc
>
> Variables that are not declared would be handled in the same way they are now, by default.
>
> Just my 2 cents.
> Bill P
>
> William Prothero
> http://es.earthednet.org
>
>> On Apr 25, 2017, at 7:31 AM, Roger Eller via use-livecode <[hidden email]> wrote:
>>
>> +1
>>
>> And if you must introduce a arguably newer/better term, please make its
>> syntax more English-like and less code-like.  This _is_ LiveCode.  Cryptic
>> is for those other languages.  /2_cents
>>
>> ~Roger
>>
>>
>> On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
>> [hidden email]> wrote:
>>
>>> Hi Lagi,
>>>
>>> I can’t agree more.  Never break anyone’s code if at all possible.
>>> Create a new numberformat like NumberFormatXL or something
>>> similar.  Leave the old working stuff alone.
>>>
>>> Just my 2 cents for the day!
>>>
>>> Rick
>>>
>>>> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
>>> [hidden email]> wrote:
>>>>
>>>> Hi
>>>>
>>>> I don't know why you want to adapt/enhance the number format as that
>>> could
>>>> break already working code that uses the nuances of numberformat already.
>>>>
>>>> Why not add an instruction NumberFormatXL and create the an Excel version
>>>> like Curry says. You won't have to jump through hoops to make sure it
>>>> doesn't break anything, you can fix what's wrong(?) and you can add stuff
>>>> in there without affecting old code, plus and with Curry's experience
>>> with
>>>> spreadlib you probably have a lot of the problems to solve sorted.
>>>>
>>>> Now my usual caveat "Everything is easy for the man who doesn't have to
>>> do
>>>> it himself" - but I haven't seen anything that Mark and his team can't
>>> do -
>>>> usually the problems stem from trying no to break older stuff.
>>>>
>>>> I think in this case adding a new command would make it easier all round.
>>>> While you're at it why not put a callback/ or in  wordpress parlance an
>>>> "AddAction"  option so you can add to the formatting on the fly?
>>>>
>>>> Regards Lagi
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
On 2017-04-25 12:48, Lagi Pittas via use-livecode wrote:
> Hi
>
> I don't know why you want to adapt/enhance the number format as that
> could
> break already working code that uses the nuances of numberformat
> already.

Although it may have not been 100% clear in my previous post, as
numberFormat
in LiveCode is just string formatting (it doesn't do what it does in
HyperCard
where it also controls numerical precision of each arithmetic operation)
it can be
extended without affecting existing code.

> Why not add an instruction NumberFormatXL and create the an Excel
> version
> like Curry says. You won't have to jump through hoops to make sure it
> doesn't break anything, you can fix what's wrong(?) and you can add
> stuff
> in there without affecting old code, plus and with Curry's experience
> with
> spreadlib you probably have a lot of the problems to solve sorted.

When would numberFormatXL be used instead of numberFormat? I presume if
it has
been explicitly set in local context... In which case...

There's no point in introducing a new property whose only action is to
subsume
the action of the previous one since that is equivalent to just
extending the
original property.

Warmest Regards,

Mark.

P.S. The main suggestion in my previous post wasn't about numberFormat
per-se
more about restricting its domain slightly (to things which are not
integers)
in order to (1) solve a problem with numeric representation (wouldn't it
be nice
to have infinite precision integers?) and (2) make the language more
ergonomic
when dealing with numeric arrays - allowing to use 'numberFormat'
(or whatever) *and* numeric arrays.

--
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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
My point was to set variable types when they need to be set explicitly. Those who don't want to set a type can just use forget about it. Once you get into more scientific, numeric type applications, the precision and type of variables can get crucial. To me, the suggested changes to numberformat, adding numberformatXL, etc, just make the situation more complex rather than applying a simple, direct solution that is common in other programming languages. I see no advantage in going through extreme gymnastics to solve a problem that has been solved clearly in other environments. As far as I'm concerned, the English language-like features are great for the new programmer, but actually doing useful work pretty quickly deviates from English like syntax. I'm thinking of Adobe Director rather than C++ or JavaScript. To me, LC's greatest strength is in its UI support and cross platform capabilities.

Best,
Bill P

William Prothero
http://es.earthednet.org

> On Apr 25, 2017, at 9:27 AM, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Variable Typing! EEEK!!!
>
> Bob S
>
>
>> On Apr 25, 2017, at 08:33 , prothero--- via use-livecode <[hidden email]> wrote:
>>
>> Folks,
>> What I see in this discussion is extreme efforts to do something that is straightforward and transparent in other languages (I can see these suggested solutions as creating unnecessary complexity).That is to simply declare some variable types.
>>
>> E.g.
>> variable ix=integer double
>> variable yzz=real
>>
>> Etc, etc
>>
>> Variables that are not declared would be handled in the same way they are now, by default.
>>
>> Just my 2 cents.
>> Bill P
>>
>> William Prothero
>> http://es.earthednet.org
>>
>>> On Apr 25, 2017, at 7:31 AM, Roger Eller via use-livecode <[hidden email]> wrote:
>>>
>>> +1
>>>
>>> And if you must introduce a arguably newer/better term, please make its
>>> syntax more English-like and less code-like.  This _is_ LiveCode.  Cryptic
>>> is for those other languages.  /2_cents
>>>
>>> ~Roger
>>>
>>>
>>> On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
>>> [hidden email]> wrote:
>>>
>>>> Hi Lagi,
>>>>
>>>> I can’t agree more.  Never break anyone’s code if at all possible.
>>>> Create a new numberformat like NumberFormatXL or something
>>>> similar.  Leave the old working stuff alone.
>>>>
>>>> Just my 2 cents for the day!
>>>>
>>>> Rick
>>>>
>>>>> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
>>>> [hidden email]> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> I don't know why you want to adapt/enhance the number format as that
>>>> could
>>>>> break already working code that uses the nuances of numberformat already.
>>>>>
>>>>> Why not add an instruction NumberFormatXL and create the an Excel version
>>>>> like Curry says. You won't have to jump through hoops to make sure it
>>>>> doesn't break anything, you can fix what's wrong(?) and you can add stuff
>>>>> in there without affecting old code, plus and with Curry's experience
>>>> with
>>>>> spreadlib you probably have a lot of the problems to solve sorted.
>>>>>
>>>>> Now my usual caveat "Everything is easy for the man who doesn't have to
>>>> do
>>>>> it himself" - but I haven't seen anything that Mark and his team can't
>>>> do -
>>>>> usually the problems stem from trying no to break older stuff.
>>>>>
>>>>> I think in this case adding a new command would make it easier all round.
>>>>> While you're at it why not put a callback/ or in  wordpress parlance an
>>>>> "AddAction"  option so you can add to the formatting on the fly?
>>>>>
>>>>> Regards Lagi
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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


_______________________________________________
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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
Way to steal my post and make it eloquent, Bill :-P

On Tue, Apr 25, 2017 at 12:57 PM, prothero--- via use-livecode <
[hidden email]> wrote:

> My point was to set variable types when they need to be set explicitly.
> Those who don't want to set a type can just use forget about it. Once you
> get into more scientific, numeric type applications, the precision and type
> of variables can get crucial. To me, the suggested changes to numberformat,
> adding numberformatXL, etc, just make the situation more complex rather
> than applying a simple, direct solution that is common in other programming
> languages. I see no advantage in going through extreme gymnastics to solve
> a problem that has been solved clearly in other environments. As far as I'm
> concerned, the English language-like features are great for the new
> programmer, but actually doing useful work pretty quickly deviates from
> English like syntax. I'm thinking of Adobe Director rather than C++ or
> JavaScript. To me, LC's greatest strength is in its UI support and cross
> platform capabilities.
>
> Best,
> Bill P
>
> William Prothero
> http://es.earthednet.org
>
> > On Apr 25, 2017, at 9:27 AM, Bob Sneidar via use-livecode <
> [hidden email]> wrote:
> >
> > Variable Typing! EEEK!!!
> >
> > Bob S
> >
> >
> >> On Apr 25, 2017, at 08:33 , prothero--- via use-livecode <
> [hidden email]> wrote:
> >>
> >> Folks,
> >> What I see in this discussion is extreme efforts to do something that
> is straightforward and transparent in other languages (I can see these
> suggested solutions as creating unnecessary complexity).That is to simply
> declare some variable types.
> >>
> >> E.g.
> >> variable ix=integer double
> >> variable yzz=real
> >>
> >> Etc, etc
> >>
> >> Variables that are not declared would be handled in the same way they
> are now, by default.
> >>
> >> Just my 2 cents.
> >> Bill P
> >>
> >> William Prothero
> >> http://es.earthednet.org
> >>
> >>> On Apr 25, 2017, at 7:31 AM, Roger Eller via use-livecode <
> [hidden email]> wrote:
> >>>
> >>> +1
> >>>
> >>> And if you must introduce a arguably newer/better term, please make its
> >>> syntax more English-like and less code-like.  This _is_ LiveCode.
> Cryptic
> >>> is for those other languages.  /2_cents
> >>>
> >>> ~Roger
> >>>
> >>>
> >>> On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
> >>> [hidden email]> wrote:
> >>>
> >>>> Hi Lagi,
> >>>>
> >>>> I can’t agree more.  Never break anyone’s code if at all possible.
> >>>> Create a new numberformat like NumberFormatXL or something
> >>>> similar.  Leave the old working stuff alone.
> >>>>
> >>>> Just my 2 cents for the day!
> >>>>
> >>>> Rick
> >>>>
> >>>>> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode <
> >>>> [hidden email]> wrote:
> >>>>>
> >>>>> Hi
> >>>>>
> >>>>> I don't know why you want to adapt/enhance the number format as that
> >>>> could
> >>>>> break already working code that uses the nuances of numberformat
> already.
> >>>>>
> >>>>> Why not add an instruction NumberFormatXL and create the an Excel
> version
> >>>>> like Curry says. You won't have to jump through hoops to make sure it
> >>>>> doesn't break anything, you can fix what's wrong(?) and you can add
> stuff
> >>>>> in there without affecting old code, plus and with Curry's experience
> >>>> with
> >>>>> spreadlib you probably have a lot of the problems to solve sorted.
> >>>>>
> >>>>> Now my usual caveat "Everything is easy for the man who doesn't have
> to
> >>>> do
> >>>>> it himself" - but I haven't seen anything that Mark and his team
> can't
> >>>> do -
> >>>>> usually the problems stem from trying no to break older stuff.
> >>>>>
> >>>>> I think in this case adding a new command would make it easier all
> round.
> >>>>> While you're at it why not put a callback/ or in  wordpress parlance
> an
> >>>>> "AddAction"  option so you can add to the formatting on the fly?
> >>>>>
> >>>>> Regards Lagi
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >>
> >> _______________________________________________
> >> 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
>
>
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode
I wouldn't even be here if not for my introduction to English-like syntax
via HyperCard 25+ years ago.  My apparently "not very useful work" over the
past 25 years while benefiting from that very same "less complex" syntax
has kept me employed, my family clothed and fed, a roof over our heads, and
all my bills paid.  Not too bad for a less than useful old hack who rarely
has to rely on a cryptic syntax!


On Tue, Apr 25, 2017 at 12:57 PM, prothero--- via use-livecode <
[hidden email]> wrote:

> My point was to set variable types when they need to be set explicitly.
> Those who don't want to set a type can just use forget about it. Once you
> get into more scientific, numeric type applications, the precision and type
> of variables can get crucial. To me, the suggested changes to numberformat,
> adding numberformatXL, etc, just make the situation more complex rather
> than applying a simple, direct solution that is common in other programming
> languages. I see no advantage in going through extreme gymnastics to solve
> a problem that has been solved clearly in other environments. As far as I'm
> concerned, the English language-like features are great for the new
> programmer, but actually doing useful work pretty quickly deviates from
> English like syntax. I'm thinking of Adobe Director rather than C++ or
> JavaScript. To me, LC's greatest strength is in its UI support and cross
> platform capabilities.
>
> Best,
> Bill P
>
> William Prothero
> http://es.earthednet.org
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
Sorry Roger. I didn’t mean to open a debate on whether English-like syntax is good or bad. Just to make a point about doing coding gymnastics to follow a viewpoint, that actually makes things more complex. I think that all of us who start with LiveCode get hooked, then learn more by discussing and reading the docs. For some applications we really need to burrow down to details of the engine that can’t be automatically take care of without understanding them. There is a tendency for those who already have learned something to see it as simple. But I think you need to really watch the newbies and their thought processes to really determine how easy it is to get started in livecode. Richmond is probably the most expert because of his work in teaching young learners.

I don’t see that simply declaring (optionally) that you want a variable to be an integer, a real, or whatever, actually violates the spirit of the language. To me, it seems like some folks are interested in doing numerical computations that exceed the scope of what now exists. For example, the computation of prime numbers. Others focus more on applications that are not heavily numerical and the current situation is fine. Although I personally may prefer other syntaxes, my suggestion was only to look at the trees and let the forest stay the same for livecode. Many of the discussions lately have been pretty esoteric and I could easily see where folks could get confused. Example: “how many items are in “x,x,x,” ?) or Is a number treated as a string or as a number, and when is it invisibly converted by the engine? I just think that the mantra of “English-like” is only partially applicable to livecode. Other languages have “English-like” syntaxes too, although their vocabulary and its application may be quite different. And, what about French speakers, Chinese speakers, etc, etc. I could go on, but …….

Anyway, have a great day (or evening, whatever the case may be).
Best,
Bill P

> On Apr 25, 2017, at 11:16 AM, Roger Eller via use-livecode <[hidden email]> wrote:
>
> I wouldn't even be here if not for my introduction to English-like syntax
> via HyperCard 25+ years ago.  My apparently "not very useful work" over the
> past 25 years while benefiting from that very same "less complex" syntax
> has kept me employed, my family clothed and fed, a roof over our heads, and
> all my bills paid.  Not too bad for a less than useful old hack who rarely
> has to rely on a cryptic syntax!
>
>
> On Tue, Apr 25, 2017 at 12:57 PM, prothero--- via use-livecode <
> [hidden email]> wrote:
>
>> My point was to set variable types when they need to be set explicitly.
>> Those who don't want to set a type can just use forget about it. Once you
>> get into more scientific, numeric type applications, the precision and type
>> of variables can get crucial. To me, the suggested changes to numberformat,
>> adding numberformatXL, etc, just make the situation more complex rather
>> than applying a simple, direct solution that is common in other programming
>> languages. I see no advantage in going through extreme gymnastics to solve
>> a problem that has been solved clearly in other environments. As far as I'm
>> concerned, the English language-like features are great for the new
>> programmer, but actually doing useful work pretty quickly deviates from
>> English like syntax. I'm thinking of Adobe Director rather than C++ or
>> JavaScript. To me, LC's greatest strength is in its UI support and cross
>> platform capabilities.
>>
>> Best,
>> Bill P
>>
>> William Prothero
>> http://es.earthednet.org
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode

Roger:

 > I wouldn't even be here if not for my introduction to
 > English-like syntax via HyperCard 25+ years ago.  My
 > apparently "not very useful work" over the past 25 years
 > ... has kept me employed, my family clothed and fed,
 > a roof over our heads, and all my bills paid.

Well said! I'd go even further. There's no need for xTalk users to be on
the defensive at all. This looks like a false dilemma on two fronts.

Some people are trend-attuned, bandwagonish and when something like
JavaScript becomes extremely popular, they feel the need to compromise
or follow it beyond the extent which is already dictated by technology.
It's possible that nothing will make those people feel comfortable until
LC scripting is essentially JS. And later if another language were to
overtake JS, they'd want to follow that. That's largely subjective, so I
can't really add anything on that side of the equation. Objectively,
good syntax is not a limitation.

The other front, whether/how to improve numberFormat, does have a real
dilemma of limited size, but there's no need for massive changes to the
language. Treating integers and reals differently would introduce a
variety of problems, I think, starting with the fact that I may have
what may look like an integer but I consider a real.

I think that approach would violate KISS, and certainly backward
compatibility. There may still be little quirks to think about, but
there are straightforward ways to make improvements to specific
numberFormat limitations without breaking anything. Failing that, I'm
happy to keep enjoying the limited role that it does well, and rolling
some of my own solutions. :)

Best wishes,

Curry Kenworthy

Custom Software Development
http://curryk.com/consulting/

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
Curry Kenworthy wrote:

 > Some people are trend-attuned, bandwagonish and when something
 > like JavaScript becomes extremely popular, they feel the need
 > to compromise or follow it beyond the extent which is already
 > dictated by technology. It's possible that nothing will make
 > those people feel comfortable until LC scripting is essentially
 > JS. And later if another language were to overtake JS, they'd
 > want to follow that.

Where do you find comments like those?

I've seen a request or two for true OOP in the forums, and a few for dot
notation now and then (FWIW I'm agnostic on the subject), but by and
large most folks I know using xTalks like the flavor of the language family.

No offense to JavaScript; I enjoy it, along with bash and R, and I even
miss some things about Pascal now and then.  But I spend more time in LC
than the others in large part because the language is more fun.  Seems
most polyglots I run into feel the same.

--
  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
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Klaus major-k via use-livecode
In reply to this post by Klaus major-k via use-livecode

Mark:

 > If we made this distinction, then it would be viable to
 > make it so that numberFormat *only* affects reals:

 > put 1 + 0 into tInteger
 > put 1. + 0 into tReal
 > set the numberFormat to "0.00"
 > put tInteger , tReal
 > => "1,1.00"

I would expect big problems doing that generally! But it may hint at
another workable approach.

Doing this for all number to text conversions would be chaotic, because
one man's integer is another man's real, and another person would like
their integers formatted too. I may have "5" and intend that to be $5.00
or 005. I would expect the new problems and code breakage to be much
more extensive than the ones this is intended to solve.

 > Arrays in LiveCode serve two purposes - both lists
 > (if integer keyed, dense, starting from 1) and dictionaries
 > (all other types).

But doing the above ONLY for numbers that are going into array keys
would be less chaotic, more targeted to the problem. It is intuitive to
be able to put a formatted string into an array without worrying about
the key changing on you.

Then is it necessary to differentiate real vs integer, both for the
user's number and the array structure? Or just do it for all array keys?
One guy may have a loop incrementing by .1 and expect it to work,
another guy may have a mix of integer and text keys. They don't qualify
as an LC list array, but considering the formatting a separate issue,
should it just work for them too? To me it seems more intuitive to treat
all those numbers the same for array key formatting (or nonformatting)
purposes. I'm not worrying about how the array keys are stored internally.

Either way could be fine with me if it seems consistent, limited to
array keys, and a persistent way to turn it off which could also be the
backward compatibility solution, default on for new version stacks and
off for old ones?

 > The problem is that I'm not sure it is feasible to extend
 > the allowed size of integers (having them arbitrary precision
 > would be really neat!) whilst preserving this graceful
 > degradation to double (at least not in a performant way).

I would consider that a completely separate issue from the formatting
(and as above, I think it would be chaotic and break a lot of things to
conflate them in general. Plus second-guessing the user's intended type
(or nontype) could be frustrating. I firmly believe non-typed is a plus
for LC.

But as a behind-the-scenes math thing, yes, very useful! Having numbers
shift types automatically to retain best precision, without necessarily
worrying about what type they are, could be amazing. It would probably
still run into problems though, such as two big numbers .1 apart (one an
integer) ending up miles apart. So it's another issue to consider on its
own merits.

Back to formatting, this gives us at least two viable possibilities for
the numberFormat array key issue? Not bad!

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.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
123
Loading...