| This is kind of a reply to http://arclanguage.org/item?id=12841, where waterhouse said, I'll add that numbers and atoms are... atomic. Pure and indivisible, the building blocks that you can make everything else in Lisp with. I'm fine with compound data structures being functions, because they can be implemented with functions as featureful as you want, but I think atoms should be simple, basic pieces. IMO, it would be fitting if types that simulated algebraic fields had multiplication be their function call behavior. That way you get things like this: (/ (+ -.b (sqrt:- b.b 4.a.c))
2.a)
Continuing along these lines, matrices could be used directly in places where linear transformation functions are expected. Maybe matrices aren't a strong point of Arc just yet, but we can still prepare for them. :-pAnother 'defcall option I've thought about is the Church numeral interpretation of natural numbers. Namely, we could have 3.f be the same as f:f:f. I think this is a bit more axiomatic and elegant, but it suggests an impractical math API design (inefficient Church arithmetic), and it's not as clearly extensible to negative numbers, rationals, etc. So, suppose we do have function calls perform multiplication over fields. We could still have field-bound numbers do interesting things with values outside their own field. For instance, as long as we consider '+ to be the standard thing to extend when defining monoid operations like concatenation, then if we have (3 '(a b c)) rely on '+, we can end up with the meaningful behavior (a b c a b c a b c). In fact, if we have a type of value that has a unary function meaning but no (other) obvious monoid meaning, we can treat it as a monoid under function composition. If we do, 3.f will actually have its Church numeral interpretation for those values of f. Since Church numerals multiply when they're applied to each other anyway, natural numbers will end up sharing a lot of their behavior with this new function type, so there may be times the numbers can be used in place of the special functions without any explicit case-checking code. Pretty elegant, huh? ^_^ Would multiplication be less useful than raising an error? Are there better ideas this approach misses out on? |