Consistency in common operators across various types.
# Wesley Oliver (5 years ago)
I have decided to put to gather a document, logically thinking about a scripting language holistically on how to achieve type free scripting language that is consistent and predictable regardless of the data option which is operating. In other words, a script problem is type invariant and input and outputs will never differ base on any implicit, inferable, or backing types.
Rules and constraint for writing a good scripting language or script for that matter, such that it has consistent predictable and usable behaviour
docs.google.com/document/d/1065G_MqNMFL_fBhSHSfH3ju0FUKC5iRpbj1iVwgAh3o/edit?usp=sharing
Kind ,
Wesley Oliver
Hi, I have decided to put to gather a document, logically thinking about a scripting language holistically on how to achieve type free scripting language that is consistent and predictable regardless of the data option which is operating. In other words, a script problem is type invariant and input and outputs will never differ base on any implicit, inferable, or backing types. *Rules and constraint for writing a good scripting language or script for that matter, such that it has consistent predictable and usable behaviour* https://docs.google.com/document/d/1065G_MqNMFL_fBhSHSfH3ju0FUKC5iRpbj1iVwgAh3o/edit?usp=sharing Kind Regards, Wesley Oliver On Fri, Apr 10, 2020 at 3:33 PM Wesley Oliver <wesley.olis at gmail.com> wrote: > Hi, > > Just like to maybe challenge javascript here or any script language in > that mater. > > The definition of comparing two variables with an operator such as > <.<=,>,>= of the operators above definition changes depending on the left > and right backing types. > > If both are strings then it does string comparison if both numbers then > its numbers. > Seem great but there are small gotchas. > > So if someone writes an algorithm and some gives them some badly formatted > data, where some values are strings and some are numbers or what eva, > because we are operating in type free space. > Then sometimes the correct behaviour will be happening depending on what > the intention is. > string comparison or number comparison. > Some of the loops evaluate the data going to be doing all sort wonderfully > things, flipping between definitions. kinda works for sort single > numerical string sort method but not for logical algorithm comparisons, > because they may and much work from time to time depending on the input > data. > > Reason for a scripting language is be free of types and not care about > different types, that things just work, but clearly there some additional > corner cases, we need to improve on. > > The problem here is that based on the types the operator behaviour is > inconsistent. > To write script programs the behaviour for different operators needs to > remain the same > regardless of types. Else can't have data streams that data types don't > matter and when algorithms basically break, then what was the point of > using a type language. > > So in future for script languages, implement functions if there is > conflict in that operator definition is not consistent across all types. > This would allow use to write algorithms, > were don't care about the types, else must ensure that * 1 before > comparison or that > format all the data on input, which requires projection and doubles memory > usage, which then sucks, incremental versus balk conversion. > > For scripting language, the operator definition should remain the same, > regardless of the left hand or right-hand side types thought out the > language. > > A scripting language should choose base type in which these operators will > be evaluated and everything will be coerced into that base operator type > first. > > You could implement scope blocks, were one could choose operator base type > so simplify code writing and understanding. > > [<,<=,+.,>]:string { > > } > > [comp-ops]:number { > > } > Consistency and behaviour consistent across types is key to scripting > language becoming more powerful. Rather use the function in future if there > is no consistency across backing types for the operator. > > Kind Regards, > > Wesley Oliver > > -- > ---- > GitHub:https://github.com/wesleyolis > LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/ > Blog/Website:https://sites.google.com/site/wiprogamming/Home > Skype: wezley_oliver > MSN messenger: wesley.olis at gmail.com > > > -- > ---- > GitHub:https://github.com/wesleyolis > LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/ > Blog/Website:https://sites.google.com/site/wiprogamming/Home > Skype: wezley_oliver > MSN messenger: wesley.olis at gmail.com > -- ---- GitHub:https://github.com/wesleyolis LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/ Blog/Website:https://sites.google.com/site/wiprogamming/Home Skype: wezley_oliver MSN messenger: wesley.olis at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200410/1d4d8851/attachment.html>
Just like to maybe challenge javascript here or any script language in that mater.
The definition of comparing two variables with an operator such as <.<=,>,>= of the operators above definition changes depending on the left
and right backing types.
If both are strings then it does string comparison if both numbers then its numbers. Seem great but there are small gotchas.
So if someone writes an algorithm and some gives them some badly formatted data, where some values are strings and some are numbers or what eva, because we are operating in type free space. Then sometimes the correct behaviour will be happening depending on what the intention is. string comparison or number comparison. Some of the loops evaluate the data going to be doing all sort wonderfully things, flipping between definitions. kinda works for sort single numerical string sort method but not for logical algorithm comparisons, because they may and much work from time to time depending on the input data.
Reason for a scripting language is be free of types and not care about different types, that things just work, but clearly there some additional corner cases, we need to improve on.
The problem here is that based on the types the operator behaviour is inconsistent. To write script programs the behaviour for different operators needs to remain the same regardless of types. Else can't have data streams that data types don't matter and when algorithms basically break, then what was the point of using a type language.
So in future for script languages, implement functions if there is conflict in that operator definition is not consistent across all types. This would allow use to write algorithms, were don't care about the types, else must ensure that * 1 before comparison or that format all the data on input, which requires projection and doubles memory usage, which then sucks, incremental versus balk conversion.
For scripting language, the operator definition should remain the same, regardless of the left hand or right-hand side types thought out the language.
A scripting language should choose base type in which these operators will be evaluated and everything will be coerced into that base operator type first.
You could implement scope blocks, were one could choose operator base type so simplify code writing and understanding.
[<,<=,+.,>]:string {
}
[comp-ops]:number {
} Consistency and behaviour consistent across types is key to scripting language becoming more powerful. Rather use the function in future if there is no consistency across backing types for the operator.
Kind ,
Wesley Oliver