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.
