The terms "function" and "relation" as used in programming languages have meanings carved out of the pure concepts by the, sometimes, judicious application of Ockham's Chainsaw Massacre in order to "get things done".
I am speaking of the pure concepts. Procedures are sequences of statements. Statements are state transitions. The before state is the input to the statement viewed as a pure function. The after state is the output of the statement viewed as a pure function. On Tue, Aug 20, 2013 at 10:41 AM, yary <not....@gmail.com> wrote: > I'll bite... this concept of "commensurablity" is not one I grasp from > your email. > > "functions are (sugarably) degenerate (many to 1) relations and > procedures are (sugarably) degenerate (state-transition) functions." > Perl & many other languages don't have a strong distinction between > functions & procudures (as I'm sure you know), a "function" is a > subroutine returning a scalar, a "procedure" is a subroutine with no > return value, side-effects only. A subroutine returning many values- a > parcel of containers, perhaps, or an iterator, etc- is a > "many-to-many" relation. I understand "relational algebra" from > decades of SQL work, and have seen ORM's replicate relations in object > systems with some success. What's missing for creating a relational > wonderland in perl6? > > (Also: "a ton of apples should _not_, in general, be added to 3000 kg > of oranges"- unless I operate a refrigerated shipping line, in which > case all I care is that they are subclasses of "perishables"... Adding > an acre of orchard to a season in the sun might be less > "commensurable", though they could both be subclasses of "gifts to a > lucky winner"... hmmm... what was the point again?) >
