If I understand you correctly, what you are suggesting is the syntactic sugar similar to perl 5's overload, but with Object/Class support, support for autoboxing and a way, either by convention or configuration of facilitating type conversion and degradation?

So one could write something like: if ( $commuterTrain =~ $bob ) { print "bob caught the train"; } instead of if ( $commuterTrain.hasPassenger( $bob ) ) { print "bob caught the train"; } Might make for a richer method call syntax than ".method(...)" or "-> method()", and produce a cultural convention for method names. It would also maintain perls reputation for generous use of squiggles. On Fri, Aug 23, 2013 at 12:53 PM, Jonathan Lang <datawea...@gmail.com>wrote: > On Aug 23, 2013, at 2:41 AM, Steve Pitchford <steve.pitchf...@gmail.com> > wrote: > > > How would you implement, in a robust way, the following things: > > > > 1 kg + 1 kg = 2 kg > > 2 m * 3 m = 6 m^2 > > 5 kg * (3 m/s)^2 = 45 J > > > > The answer is that you wouldn't - the problem domain is so vague as to > be meaningless. 1kg or 1m of what? > > Understood; but it misses the point I was trying to make. Bringing a > measuring system into play needs to be more robust than merely addition and > subtraction of common units; it also needs to be able to transform those > units into related ones. Let's do a little rocket science: > > DeltaV = Ve * ln ( m0 / m1 ) > > Where DeltaV is the total amount your velocity can change, Ve is the > velocity of your rocket propellant, m0 is your initial mass, and m1 is your > final mass. Simple enough: as long as m0 and m1 are both measured using > the same units, they cancel out with each other, letting us take the > natural log of a unitless number — which is fortunate, because I don't have > a clue how you'd take the logarithm of a number that has units of measure. > You then multiply that unitless number by a velocity (measured in units of > distance over units of time) to get another velocity (measured in the same > units). > > In this problem, the question "of what?" is largely irrelevant; the rocket > formula will work equally well whether you're shooting a jet of hydrogen > out the back of your spacecraft or if you're throwing rocks. Likewise, the > number of things that you use as propellant is largely irrelevant. It > doesn't hurt to keep track of that information, as long as doing so doesn't > interfere with your calculations; but you don't really need it. > > A related formula is the thrust formula: > > F = Isp * m' * g0 > > Where F is the thrust generated, Isp, is the specific impulse of the fuel > (a measure of how "efficient" the fuel is), m' is the mass flow: the rate > (measured in mass per unit of time) that the fuel is being expelled, and g0 > is the gravitational acceleration at Earth's surface. The reason why g0 is > in there is because of a conflation between two very different kinds of > units in the early days of rocket science, before metric became the > standard in rocketry; namely, pounds (of force) and pounds (of mass). > > Originally, the formula was simply C< F = Isp * m' >, with F measured in > pounds and m' measured in pounds per second; as such, Isp was assigned > units of "seconds" to make these measurements balance out. When the > formula was converted over to metric, it became blatantly obvious that > things had been improperly conflated, since force is measured in Newtons > and mass flow is measured in kilograms per second. When that's done, it > becomes obvious that the Specific Impulse ought to be measured in units of > speed (meters per second, in this case) rather than in units of time. But > by then, the convention of measuring Specific Impulse in "seconds" was > firmly rooted in the rocket engineering community; so the surface gravity > of Earth was brought in as a fudge factor, since that is the ratio of one > pound of force to one pound of mass. > > > Going back to apples - The value of 1kg of apples in terms of > representation depends on context. > > > > For example, it would be a chore to try to arrange a group of apples to > make an exact kilogram. On an individual basis you may have 6 apples. In > some cases you may represent that as 6 instances. In another context, you > may represent a collection of apples in their tray form - which may have a > notional weight with a tolerance. Now, if one were writing a checkout > system, it may be sufficient for one to have a "fruit" class, of which > "apples" and "oranges" are instances, and both are charged in weight - and > their may be additional algorithms to predict stocking levels and > re-ordering thresholds, but from personal experience, these algorithms > often require the backup of business process such as stock takes to ensure > that waste, theft, and approximation errors are taken for granted, and we > don't end up with a backlog of rotten apples or empty shelves. > > Some relevant tools: > > There's a "repetition operator" infix:<xx> that's currently set up to take > a string and construct a longer one made up of multiple consecutive copies > of the original string. e.g., C< 5 xx "ab" eq "ababababab" >. That might > be leveraged into a general-purpose "assign a count to an object" operator: > e.g., C< 5 xx apple > means that you have five apples; C< 5 xx kg of apple > > (would that parse correctly? I'm not sure off the top of my head; but I > hope so) means that you have 5 kilograms of apples; and so on. > > Turning that around, the infix:<xx> operator could be used to assign a > "measure" (defined by whatever is on the right-hand side) to an > otherwise-unitless "value" (defined by whatever numeric value is on the > left-hand side) to get a "quantity". You could then do things like > multiplying a quantity measured in "kg of apple" by a quantity measured in > "dollars / kg of apple" to get a quantity measured in "dollars". > > If you mix things up and try to sell some oranges using the price for > apples, you'll get an easily-tested-for discrepancy in the resulting > quantity's measure: instead of getting the dollars that you'd expect, you'd > get "dollars * kg of orange / kg of apple". Likewise, adding 5 xx apple to > 5 xx orange might give you 10 xx fruit, since "fruit" is the > nearest-common-ancestor to "apple" and "orange"; but if you're looking for > apples, that generalization of the unit will be a tip-off that something > undesirable has happened. > > As I understand it, this would be commensurability: a means of testing > whether the units you end up with after a calculation are the units that > you wanted. > > Remember: solutions in Perl should aim to make common tasks easy and > difficult tasks possible. Something like the above could make the > programmer's job easy (or at least easier) for common tasks, and would > allow him to produce more legible code. It wouldn't necessarily make > difficult tasks possible; but it might lay the groundwork for doing so, and > more importantly it probably wouldn't interfere with other solutions for > the difficult tasks. > > Trying to make the programmer always think in a strictly OO-based approach > also runs counter to Perl's multi-paradigm model; the above is an attempt > to present a more natural measuring system, one that reflects the way real > people think instead of trying to cram everything into the confines of the > OO paradigm. At the same time, I'm trying to incorporate the power of > objects into it: you can use classes and roles as elements of a quantity's > measure. > > And ideally, it could work like a regular OO solution "under the hood", > keeping it compatible with other solutions: what is a "quantity", anyway? > It might be a "quantity" class or role, or it might be a countable > container of objects, or it might be something else entirely; I haven't > gotten into the implementation details of it. I'd be inclined to say that > it's a role that's composed into a purpose-specific class (for cases where > there's no individuation, just "how much is there?" and "what is it?"), but > also into the standard container types: you should be able to query a list, > hash, or set for "how many objects do you contain?" and "what kind of > objects do you contain?" > > There also might be some subtler issues such as whether you're doing > discrete calculations (you can have 2 or 3 kids, but you won't ever have > 2.3 kids) or continuous ones (there's no reason _not_ to have 2.3 gallons > of gasoline). But the above should be enough to get things started, I > hope.