In this article, i explain how the use of bit masks is a hack in many
imperative languages.
Often, a function will need to take many True/False parameters. For
example, suppose i have a function that can draw a rainbow, and each
color of the rainbow can be turned on or off individually. My function
specification can be of this form: “rainbow(red, orange, yellow,
green, blue, violet, purple)”. Each parameter is a true or false
value. So, to draw a rainbow with only red and yellow stripes on, one
would code, for example “rainbow(t,f,t,f,f,f,f)”, where “t” stands for
true and “f” stands for false. (or, similar values for the true/false
of the language's boolean system)
The problem with this simple approach is that when a function has too
many parameters, “which position means what” becomes difficult to
remember and manage. Alternatively, a high-level language may provide
a system for named parameters. So, for example, the function may be
called like this with 2 arguments “rainbow(red:t, yellow:t)”, meaning,
give the true values to the parameters named “red” and “yellow”.
Parameters not given may automatically assumed to have false values by
default. Similarly, the language can simply have the function call
look like this: “rainbow(red, yellow)”, where omitted parameter names
simply means false.
LSL deals with this issue by using a concept of bit-mask that came
from low-level languages. From the programer's point of view, the way
to call this rainbow function would look like this: “rainbow(red|
yellow)”. On the surface, it seems just a syntax variation. But
actually, the “red” and “yellow” here are global constants of type
integer, defined by the language, and the “|” is actually abit-wise
binary operator. To explain this to a educated person (e.g. a
mathematician) but who are not a professional programer, it gets a bit
complex as one has to drag in binary notation, boolean operation on
binary notation realized as a sequence of slots, and the compiler ease
in processing numbers as binary digits, and the compiler writer and
language designer's laziness in resorting to these instead of a high-
level interface of named parameters.
The hack of using the so-called bit-mask as a interface for functions
that need named parameters, is similar to languages using “1” and “0”
as the true/false symbols in its boolean system, and languages using
the “or” operator “||” as a method of nested “if else” program flow
constructs. The problem with these hacks, is that they jam logically
disparate semantics into the same construct. Their effects is making
the source code more difficult to read, and thus increased programer
error.
----
It may seem like nickpicking to say that it is a hack. However, when
many such seemingly trivially improper designs appear in a language,
adds up to the language's illness, and overall making the language
difficult to learn, difficult to read, difficult to extend, increase
programing errors, and most importantly, reduce a clear understanding
of key concepts.
Unix and C, are the primary perpetrator of this sin. Due to their
“$free$” and “speedy” and “simplistic” nature as cigarettes given to
children, have passed these designs to many imperative languages and
left programers not understanding the basic issues of a function's
parameters and named parameters.
Examples of using bitmask as a hack:
• Many functions in C. (e.g. fcntl)
• Unix's function/“command line tool”'s error values. (as bits)
• Perl's “sysopen”, “select”, and others. (if you know a perl example
that isn't related to unix, pls let me known)
• Second Life's Linden Scripting Language.
(see http://xahlee.org/sl/ls-prob.html )
A example of confusion about function's parameters is exhibited in
unix's bewildering, inconsist syntaxes in its command line tools's
ways of taking arguments. (some parameter influence other parameters.
Argument order sometimes matter, sometimes doesn't, sometimes causing
unintented output and sometimes causing syntax error. Named parameters
sometimes have the names optional(!). Named parameters that are
predicates sometimes act by their presence along, sometimes by their
value, sometimes accept both, sometimes causes syntax error. Some
defaults are supplied to unnamed parameters, and some are to named
parameters. Some parameters has synonyms. ...)
For another example in a more modern language, is Python's
“re.search()” function for text pattern matching. Its optional third
parameter is a bitmask. ( see “Regular Expressions in Python”
http://xahlee.org/perl-python/python...b/node111.html )
As a example of not clearly understanding a function's parameters and
the need and role of named parameters in computing languages, Python's
“sorted” function as well as its “lambda” construct are both victims.
(Further reading:
• “Sorting in Python and Perl”
http://xahlee.org/perl-python/python_doc_sort.html
• “Python Doc Problem Example: sort()”
http://xahlee.org/perl-python/sort_list.html
• “Lambda in Python 3000”
http://xahlee.org//perl-python/python_3000.html
)
Bitmask used as a function's parameter but not considered as a hack,
would be if it actually deals with bits necessarily (e.g. in protocols
that employ bits. (e.g. in networking), byte processing, binary digit
computation, ...)
I would appreciate other examples you know in the above languages, and
or in particular if Java, Lisp, Haskell.
----
This article is a modified excerpt from
“Linden Scripting Language Problems” at
http://xahlee.org/sl/ls-prob.html
Xah
xa*@xahlee.org
∑ http://xahlee.org/
