Useless instructions: Difference between revisions
→{{header|Phix}}
SqrtNegInf (talk | contribs) (Added Perl (abstention)) |
|||
Line 205:
=={{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.
=={{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}}==
Line 242 ⟶ 269:
say [*] (1,2,3,4,5,6,7); # same operation, sweeter syntax
</lang>
=={{header|Wren}}==
| |||