One thing to keep in mind is that while adding such things to the Perl 6 core might not be the highest priority at this point something like that could be implemented as a module (if we have a consistent idea what we want). Currently it's possible to change the language to (a subset of) Perl 5 ( https://github.com/rakudo-p5/v5) so it should be possible to at least prototype the units handling.
2013/8/23 Steve Pitchford <steve.pitchf...@gmail.com> > I'll start with your last point: > > At this point, though, plans to expand on Perl 6's capabilities are taking > a back seat to getting Perl 6's existing capabilities implemented. This > has been true for some time now, in fact — which is all the more reason to > get Perl 6.0 fully implemented as soon as possible. > > I've been lurking here for a while, and have learned a great deal whilst > reading. I've had previous plays with perl 6, would love to again, but find > myself limited by freetime. To those ends, I'm just here to chat about > something that seems interesting - not to try to influence the hard work > being done by all of those pushing the perl6 project forwards. > > I'm a big fan of Eric Evans Domain Driven design - it's a fantastic book. > He pushes the importance of context and relevance with respect to object > orientated programming. > > From that perspective - the answer to the following question is rather > brutal: > > 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? > > 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. > > That's where software engineering comes in. Systems are sharded and > Classes are defined containing aggregations of behaviour. In a grocer, you > may never need to add 1kg of apples - you may sell 1.25kg in a single > transaction, you could sell 6 apples, depending on your pricing structure. > You could even sell 2kg of discounted fruit which includes apples and > oranges close to it's use by date. > > Because you have moved away from primitive arithmetic and into object > behaviour and relationship, the notion of 1kg + 1kg becomes irrelevant. > > Because systems are becoming fragmented, it may make no sense to hook the > checkout up directly to the purchase system. You can happily sell weights > of apples, but have stock control implemented by how many trays of apples > get sent to the shop floor - in this case, you may have an alarm that > indicates another tray is probably needed, but it tackles the inherent > disjoint between purchase and sale quantities without any complex, over > generic modelling of the relationships between trays of apples and weights > or other quantities sold on the shopfloor. > > The fragmentation of the system in this way also allows the canny grocer > to flog bags of mixed fruit without worrying that his software developer > will charge him thousands and delay implementation of what seems the > exploitation of a simple opportunity by a few weeks. > > > ---------- Forwarded message ---------- > From: Jonathan Lang <datawea...@gmail.com> > Date: Fri, Aug 23, 2013 at 9:47 AM > Subject: Re: Commensurability as Key > To: Steve Pitchford <steve.pitchf...@gmail.com> > > > > > > > > On Aug 23, 2013, at 1:17 AM, Steve Pitchford <steve.pitchf...@gmail.com> > wrote: > > > > > I think James Bowery's comments are intended to address a real need for > programming languages to work with units of measurement. It might even > prevent aircraft accidents which have really happened because fuel was > delivered in Canadian gallons, or kilograms, when the pilots request was > for American pounds in his owners manual. Commensurable purchase orders > would be nice. > > > > Putting tools like PHP and VB to one side for a second, > > > > Maybe I'm getting the wrong end of the stick, but this just seems like a > case of what is known in object orientated terms as "Primitive Obsession" - > in this case, the overuse of integer and float arithmetic where objects > make far better use cases. > > > > There does seem to be significant clear water between the use of > procedural/functional languages for Maths and the rising trend of using OO > languages ( though all too often badly ) for implementing industrial > solutions - does this represent a split between computer science and > software engineering? > > > > OO - done right - emphasises relationships and the strengths of type > over traditional, potentially clumsier coding. This is obviously not > without overhead, and does appear to be a paradigm shift too far for many, > but I'm wondering if anyone can explain to me why OO is not the most > appropriate solution to the "Commensurable" problem space in perl 6? > > > > Steve > > I'm not sure if this is an answer; but: > > 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 > > Bear in mind that the above assumes that a common system of measures is in > use; things get messier once you start trying to add miles and kilometers > together, and messier still if you need to differentiate between (tons of) > apples and (tons of) oranges. > > I'm not saying that there isn't an OO-based solution for this; in fact, I > suspect that there probably is. But it's not a trivial one; nor is it > clear that Perl wouldn't benefit from a bit more syntactic sugar here. > Would it be possible, given an "apple" role, to be able to say something > like the following? > > my $x = 1 apple; > $x *= 5; # $x == 5 apples. > $x -= 2; # error: can't subtract a unitless number from 5 apples. > $x += 2 orange; # error: can't mix apples and oranges. > > That is, attach a collection of roles to a numeric value in a manner where > the roles represent some sort of "units" for that value, instead of being > applied directly to the value in question. > > --- > > At this point, though, plans to expand on Perl 6's capabilities are taking > a back seat to getting Perl 6's existing capabilities implemented. This > has been true for some time now, in fact — which is all the more reason to > get Perl 6.0 fully implemented as soon as possible. > >
