It's often convenient to imagine a process as a tree-shaped (or graph-shaped) assembly line. Inputs flow in through the leaves and are transformed, filtered or reduced where branches join. This well represents lazy-functional programming. Say one wants the words from a line-delimited file, excluding acronyms, then converted to lower case and stored in a set for quick lookup. Compare syntaxes...
words = set()
for line in file('words'):
line = line.strip()
if line and not line.isupper():
words.add(line.lower())
Variables describe edges in a graph, connecting parts of code, but without being obvious to the eye. Names are boring to create and are often misspelled.
set(imap(str.lower, ifilterfalse(lambda w: w.isupper(), ifilter(None, imap(str.strip, file('words'))))))
set(line.strip().lower() for line in file('words') if line.strip() and not line.isupper())
This wastes time on a second strip() call.
set(line.lower() for line in ifilter(None, imap(str.strip, file('words'))) if not line.isupper())
This eliminates the second strip() call but has a confusing mix of syntaxes. The data flow repeatedly changes direction.
Prefix syntax - that of Lisp, Python, C, etc. - is backwards: the functions called later must precede those called earlier. One has to say what comes last first, like saying: "Eat a sandwich; make a sandwich; buy groceries." The words are spelled left to right but the sentence is right to left.
Consider this Python syntax hack to write lazy-functional code like an assembly line.
file('words') | pmethod('strip') | pfilter | pnfilter(methodcaller('isupper')) | pmethod('lower') | pset
This isn't shorter, but allows sequences of operations to be written naturally from left to right, without nested and distant parenthesis.
pmethod() eases mapping using a method of the objects to be mapped, making this version more general because it works if the strings are a mix of str and unicode instances. methodcaller() similarly eases filtering.
Presumably, this would be better in Lisp, using its read macros, but this abuse of __ror__ hasn't caused problems yet.
Related: ASPN Cookbook Python recipe, Dataflow programming.
Does anyone know of a practical language that takes this idea seriously?
There is a common dichotomy between objects and types.
Object: Unique, objective, existing thing.
Examples: Socrates, the Sun, one's self.
Type: A bundle of attributes that may match zero or more objects.
Examples: man, star, yellow.
Similar distinctions appear in the assumptions of major systems of philosophy, logic, and computer programming.
An object is only a type that one expects to have no more than one match at once. That is why minds believe objects exist. For example, if one believes in the Sun, and he believes the Sun is in the eastern sky, then he assumes the Sun is not in the western sky. That seems trivial only because this type of inference is constantly relied on.
Objects are unprovable. There could be a duplicate of any object. One would believe there is only one thing in the Universe with all those attributes, but his mistaken idea of an object is really a type. One can be certain that a type is a type but not that an object is an object. Beliefs in objects are routinely wrong and must be revised; beliefs in types are useless at worst.
Axioms are to formal systems as rules are to a game. It seems unwise to afford an axiom to the idea of objects when the Universe may contain none or when beliefs in them may be useless.
Natural languages, containing nouns and definite articles, encourage the useful presumption of objects.
It is immensely beneficial to minimize axioms. Those remaining represent deeper patterns, giving greater leverage. For example, in a computer program, reducing axioms eases increasing reliability and speed. Also, fewer axioms with the same power are likely to be more expressive: simpler parts can form more combinations.
In first-order logic, the similar distinction between things and predicates limits expressiveness. In it, statements about predicates, such as, "yellow is a color", cannot be made without resorting to a trick like reification. When objects are eliminated, saying "yellow is a color" is no different than saying "the Sun is yellow".
Objects should not be axiomatic. They should be the fluctuating implications of a web of learned types and inferences. The goal is an algorithm for the creation and destruction of object beliefs. Presumably, a system to represent all the knowledge of a general intelligence must contain beliefs and beliefs about associations between beliefs. It's likely that the function of objects can be expressed in terms of negative associations between types.
Thoughts?
©2004-2008 Patrick Roberts | Burlington, Ontario, Canada