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 a bit-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_re-write/lib/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 [EMAIL PROTECTED] ∑ http://xahlee.org/ -- http://mail.python.org/mailman/listinfo/python-list
