Useless instructions: Difference between revisions
Content added Content deleted
SqrtNegInf (talk | contribs) (Added Perl (abstention)) |
|||
Line 205: | Line 205: | ||
=={{header|Perl}}== |
=={{header|Perl}}== |
||
The mind-set behind the task runs counter to the Perl philosophy of TIMTOWTDI (there's more than one way to do it). Non-orthogonality is considered a feature, not a bug. |
The mind-set behind the task runs counter to the Perl philosophy of TIMTOWTDI (there's more than one way to do it). Non-orthogonality is considered a feature, not a bug. |
||
=={{header|Phix}}== |
|||
The five core builtin types form a natural hierarchy, so you can store an integer in a variable declared as |
|||
an integer or a number (aka atom), the latter in an object, and a string in a string or a sequence, and the |
|||
latter in an object. Storing the contents of an object in (say) an integer may either work just fine, or |
|||
trigger a fatal runtime crash - you can use pretty obvious "if integer(o) then" tests before doing that. |
|||
So, apart from error reporting, you don't actually need any data types other than "object".<br> |
|||
Phix supports at least 45 different ways of expressing the same simple integer value, from binary to base 36, |
|||
and that is before even considering string versions of it. For instance there is no difference whatsoever |
|||
between 'A' and 65, except to deliver implicit intuitive intent to a future reader of the source code.<br> |
|||
There are possibly hundreds of simple aliases such as atom/number, int/integer/bool (whereas boolean differs |
|||
in having stricter validation), true/True/TRUE, get_file_base/filebase, K_ANY/KEY_CB, and so on.<br> |
|||
There are a handful of (imo near-pointless) routines added for compatability with legacy Euphoria code, such |
|||
as `head(s,n)` [===`s[1..n]`], `s = remove(s,i,j)` [===`s[i..j]=""`].<br> |
|||
The inline assembler supports most standard intel instructions, so you have all the usual overlaps such as |
|||
xor reg,reg and mov reg,0.<br> |
|||
Not only is the compiler smart enough to suppress code generation for if false then and the like, it will |
|||
also do the same for (say) if integer(x) then when it can determine that at compile-time via constant/type |
|||
propagation, and issue proper warnings for "if integer(x) then ... elsif integer(x) then" and the like.<br> |
|||
Of course "x = x + 3" and "x += 3" are completely identical.<br> |
|||
More surprisingly perhaps, except when "fallthrough" or "with jump_table" is explicitly used, there is very |
|||
little difference internally between a switch statement and an if construct, though of course the latter can |
|||
express tests on multiple variables, which switch cannot.<br> |
|||
While "s = append(s,x)" and "s &= x" are the same when x is an atom, they're not when x is string/sequence.<br> |
|||
One genuinely redundant feature which has since been redacted was "{a, b, c} @= x", where the "@=" was meant to |
|||
stand for "all become equal to". Technically it just about worked when x was a literal integer, but was badly |
|||
broken in almost every other sense, and from the 0 bug reports clearly had never been used in the real world. |
|||
=={{header|Raku}}== |
=={{header|Raku}}== |
||
Line 242: | Line 269: | ||
say [*] (1,2,3,4,5,6,7); # same operation, sweeter syntax |
say [*] (1,2,3,4,5,6,7); # same operation, sweeter syntax |
||
</lang> |
</lang> |
||
=={{header|Wren}}== |
=={{header|Wren}}== |