Re: Naming debate- what's the location for it?

[Steve Pitchford]

Ok. So here is something revolutionary.

Free up "Perl 6" for a future generation of Perl 5 and remove the ceiling
on the perl 5 language. Perl 6 has become more than a major iteration,
hasn't it?

Perl on parrot
Perl on jam
Perl on mono

Lots of space for a five from six once you vacate the lot.

Reposition as not so much a sequel as a spin off, a "b side". Some b-sides
have eclipsed the inspiration. Sometimes letting go is what counts.

Steve

( I continually admire from afar what has been achieved and surfaced in the
voyage of discovery that is YOUR language )


On 9 Feb 2018 10:34 pm, "Darren Duncan"  wrote:

> On 2018-02-09 12:55 PM, Eaglestone, Robert J wrote:
>
>> I think a name change is too radical. /And yet/.
>>
>> I think Steve has a point, though I don’t know what to do about it.  The
>> developers in my little corner of the world may not be up on the
>> new-language-of-the-week, but even they see Perl as a has-been, write-only
>> language, so when their brain matches /perl/i they automatically toss it in
>> the bit bucket.  Some of them are too nice to say it outright.  Some aren’t.
>>
>
> Personally I think having the "6" as part of the name is the worst part of
> the situation.  Its too confusing with a version number.
>
> I think if we want to keep "Perl" in the name we should use "C" as a
> precedent. Other related languages keeping "C" include "Objective C", "C#",
> "C++", and its much more clear those are separate languages, even if
> C-alike.
>
> So one way or another, "6" should be dropped from the name of the language
> formally.  Then we either have "Foo Perl" or "Perl Foo" or "Foo".
>
> After this is done, regular "Perl" can also be free to increment its first
> version number for major releases (albeit skipping 6 to avoid confusion)
> just as Postgres and many other projects do these days, as staying at 5.x
> forever is weird.
>
> -- Darren Duncan
>

Re: Naming debate- what's the location for it?

[Steve Pitchford]

Thought the conversation felt like bikeshedding but... My point still
stands. This is a new language targetted at a post php world. The
significance of a version number will be lost outside the perl echo chamber
and in that context seen as baggage... IMHO... YMMV...

On 9 Feb 2018 6:15 pm, "Lucas Buchala"  wrote:

I doubt the name is "up for discussion" just because there's a blog
post about it. The name ain't changing ever, or at least that's how I
understand things. But, please, feel free to correct me if I'm wrong.

Sure, you can have as many alternative nicknames and aliases as you
want (for marketing purposes?), but the official name won't change.
So, move on, folks.

Re: Naming debate- what's the location for it?

[Steve Pitchford]

Well, for what it's worth, as an outsider - IMHO, leaving "perl" behinds a
good thing. Love it or loath it, we live in a js/python/jvm leaning world.
Perl was great, but it's dated. Why have the baggage? Rakudo is a new
language. Treat it as such - best hope for it. In layman's terms an
informal "Perl V2", ridiculous as that may be to the community.

Steve

On 8 Feb 2018 10:18 pm, "Darren Duncan"  wrote:

My personal favorite resolution is to officially name the language Rakudo,
full stop.

The implementation that was/is using the name would be renamed to something
else so it isn't the same as the language.

Then we say "Rakudo" is a sibling language of "Perl", full stop.

Then "Perl 6" becomes a deprecated alias for Rakudo, used informally rather
than formally from now on, and officially considered a historical footnote
rather than anything still cited in official documentation or marketing.

The unqualified name "Perl" continues to refer to the original lineage
(currently at version 5.x) such as what 99% of the world means when they
refer to it.

Remember, we can still say "Rakudo is a sibling of Perl" for all the
reasons we currently do without actually calling it any kind of "Perl" as
an individual; we don't actually lose the family thing.

For documentation/marketing materials and to help with continuity, we can
typically reference "the Rakudo language, a sibling of Perl", where the
latter part is then more of a description.

This is what I really think should and that I would like to happen.

-- Darren Duncan

On 2018-02-08 12:47 PM, yary wrote:

> ...and "rakudo" even better by that criterion. And then there's how
> "rakudo" is already named in many files, databases, websites, and that's
> enough to make me think it's a "good enough" name. Though I'd like to
> change that implementation's name to something else if we start calling the
> language Rakudo!
>
>
> I quite like having the distinction between the language and its
> implementations. No one confuses C with cc, gcc, pcc, tcc, mvcc, XCode, or
> Borland. Using the name "rakudo" to mean the language makes me feel a
> little bad in that it muddies that distinction further, and gives this
> current implementation a special status. A status which it earned, we're
> not talking about calling the Perl6 language "pugs" or "parrot" or "niecza"
> for a reason. /me shrugs.
>

Re: Commensurability as Key

[Steve Pitchford]

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



On Thu, Aug 22, 2013 at 5:54 AM, Doug McNutt dougl...@macnauchtan.comwrote:

 At 20:27 -0700 8/20/13, Jonathan Lang wrote: Off list accidentally I think.
 Could you try to put commensurability into layman's terms?  Preferably
 with a focus on some of its less obvious advantages.
 
 On Aug 20, 2013, at 8:19 PM, Doug McNutt dougl...@macnauchtan.com
 wrote:
 
  At 11:41 -0400 8/20/13, yary 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  ( see below)
 
  , 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?
 
 
  I confess.  I'm here because I hoped perl 6 would do vector operations
 after reading an early small book.
 
  I would really like to see perl support a function called a cross
 product that would return a vector, the product of amplitudes and the sine
 of the angle between them, as a vector using the   notation.  That's not
 a scalar!  But i surely would be commensurate with the input arguments.
 
  It's still FORTRAN forever for physics, electrical engineering, and
 global warming.

 Commensurable has a meaning in integer arithmetic that pretty much means
 that two integers have a common factor.  If they appear as numerator and
 denominator of a fraction that fraction is reducible by dividing both by
 the factor.

 In the physical sciences commensurable refers to numerical quantities that
 can be legitimately compared as if they were results of an experiment. In
 most cases the numbers have units of measure associated with them.  2.54
 centimeters is rightly compared as equal to 1 inch even though 2.54 is  not
 an integer and it's certainly not equal to 1.00.

 For a 3-D vector to be equal, less, or greater than another 3-D vector
 only if the two vectors refer to the same variable which might be velocity,
 position, or acceleration.  The units  must match if comparison is needed.
 Acceleration might be ft/sec/sec for one vector and meters/sec/sec for
 another and they could be reasonably compared but finding a programming
 language that handles that automatically is a PITA. I sort of remember, on
 this list, some work with allowing numbers to have units. I think it got
 lost.

 O'Reilly Perl6 Essentials (2003) on page 37 introduced vector operators
 in the form + which represents vector addition with an example @sums =
 @first +  @second.  I took that to mean that @first was a three element
 list of the x, y, and z components of a real vector. I assumed (foolishly)
 that meant there would be a X and a . which would return cross and
 dot products. I even thought about the 4-vectors of relativity where the
 fourth component is time multiplied by the velocity of light..

 But it was not to be without getting deeply into the process of compiling.
 My home built subroutines do it in perl 5 and long ago they worked with
 FORTRAN without any numbers after the name.

 The term vector has also found meaning in programming. C calls that a
 pointer and other languages call them references. All point to 

Fwd: Commensurability as Key

[Steve Pitchford]

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

Re: Commensurability as Key

[Steve Pitchford]

I have to admit to currently being of the opinion that Commensurability
appears to be a feature for program code to perform rather than a
programming language to perform, but openly admit to the possibility that I
do not understand the concept fully enough for my opinion to be valid.

Your point is obviously valid, but regrettably I'm not looking to volunteer.


On Fri, Aug 23, 2013 at 12:30 PM, Paweł Murias pawelmur...@gmail.comwrote:

 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

Re: Commensurability as Key

[Steve Pitchford]

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.comwrote:

 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

Re: exponentiation of Duration's

[Steve Pitchford]

On Wed, Nov 17, 2010 at 2:20 PM, Oha o...@oha.it wrote:

 I could be wrong but this reminds me that a Duration could not be only based
 in seconds, but also in other units (which may automagically be converted to
 seconds) and also those seconds may be leap or not.

 Maybe the point is that really the power of a Duration should not be
 performed, unless you coerce the Duration in a specific unit value?


I was thinking about larger scale durations - sometimes seconds are
just an irrelevence

http://dinosaurs.about.com/od/dinosaurbasics/a/dinosaurages.htm

( URL says it all  )

Steve

Re: perl6 compiler

[Steve Pitchford]

Aha - A FAQ - for the answer, read here:

http://use.perl.org/~pmichaud/journal/39411

and here:

http://en.wikipedia.org/wiki/Rakudo_Perl

Cheers,

Steve

On Fri, Mar 19, 2010 at 4:05 AM, Wendell Hatcher 
wendell_hatc...@comcast.net wrote:

 Is there ever going to be a perl6 production version coming out soon?

 Sent from my iPhone
 Wendell Hatcher
 wendell_hatc...@comcast.net
 303-520-7554
 Blogsite: http://thoughtsofaperlprogrammer.vox.com/
 http://thoughtsofaperlprogrammer.vox.com/


 On Mar 17, 2010, at 7:18 AM, Steve Pitchford steve.pitchf...@gmail.com
 wrote:

 Have a read of this:

 http://www.parrot.org/http://www.parrot.org/

 The parrot project is to build a virtual machine for dynamic languages,
 like perl 6.

 On Wed, Mar 17, 2010 at 1:43 AM, Dell  wendell_hatc...@comcast.net
 wendell_hatc...@comcast.net wrote:

 Has anyone thought about designing or is the Rakudo compiler similar to
 the JVM on an enterprise level? What I mean is would I be able to write
 applications that can process huge amounts of data like files,claims or
 account transactions on Rakudo in the future? I think this would be a huge
 push for perl and any dynamic language. :-)



 Matthew Walton wrote:

  Rakudo in its normal operation will compile the program, then run it
 immediately. You can, however, get it to save the compiled code for
 later use i fyou wish.

 On Sun, Mar 14, 2010 at 4:09 PM, dell  wendell_hatc...@comcast.net
 wendell_hatc...@comcast.net wrote:


 Hello,

   I had just began looking at the perl6 raduko compiler and have
 a
 question. Is perl6 actually compiled then ran similar to java or is the
 script ran and then compiled at run time?


 -Wendell

Re: perl6 compiler

[Steve Pitchford]

I think this question was largly addressed in the first link?

On Fri, Mar 19, 2010 at 12:59 PM, Wendell Hatcher 
wendell_hatc...@comcast.net wrote:

 I actsully read the fact sheets in the past and want to confirm that a
 stable production qaulity release of perl6 is coming out this April or at
 the berry least the summer?


 Sent from my iPhone
 Wendell Hatcher
 wendell_hatc...@comcast.net
 303-520-7554
 Blogsite: http://thoughtsofaperlprogrammer.vox.com/
 http://thoughtsofaperlprogrammer.vox.com/


 On Mar 19, 2010, at 3:19 AM, Steve Pitchford steve.pitchf...@gmail.com
 wrote:

 Aha - A FAQ - for the answer, read here:

 http://use.perl.org/%7Epmichaud/journal/39411
 http://use.perl.org/~pmichaud/journal/39411http://use.perl.org/%7Epmichaud/journal/39411

 and here:

 http://en.wikipedia.org/wiki/Rakudo_Perl
 http://en.wikipedia.org/wiki/Rakudo_Perl

 Cheers,

 Steve

 On Fri, Mar 19, 2010 at 4:05 AM, Wendell Hatcher 
 wendell_hatc...@comcast.net
 wendell_hatc...@comcast.net wrote:

 Is there ever going to be a perl6 production version coming out soon?

 Sent from my iPhone
 Wendell Hatcher
 wendell_hatc...@comcast.netwendell_hatc...@comcast.net
 303-520-7554
 Blogsite: 
 http://thoughtsofaperlprogrammer.vox.com/http://thoughtsofaperlprogrammer.vox.com/
 http://thoughtsofaperlprogrammer.vox.com/


 On Mar 17, 2010, at 7:18 AM, Steve Pitchford steve.pitchf...@gmail.com
 steve.pitchf...@gmail.com wrote:

 Have a read of this:

 http://www.parrot.org/ http://www.parrot.org/http://www.parrot.org/

 The parrot project is to build a virtual machine for dynamic languages,
 like perl 6.

 On Wed, Mar 17, 2010 at 1:43 AM, Dell  
 wendell_hatc...@comcast.netwendell_hatc...@comcast.net
 wendell_hatc...@comcast.net wrote:

 Has anyone thought about designing or is the Rakudo compiler similar to
 the JVM on an enterprise level? What I mean is would I be able to write
 applications that can process huge amounts of data like files,claims or
 account transactions on Rakudo in the future? I think this would be a huge
 push for perl and any dynamic language. :-)



 Matthew Walton wrote:

  Rakudo in its normal operation will compile the program, then run it
 immediately. You can, however, get it to save the compiled code for
 later use i fyou wish.

 On Sun, Mar 14, 2010 at 4:09 PM, dell  
 wendell_hatc...@comcast.netwendell_hatc...@comcast.net
 wendell_hatc...@comcast.net wrote:


 Hello,

   I had just began looking at the perl6 raduko compiler and
 have a
 question. Is perl6 actually compiled then ran similar to java or is the
 script ran and then compiled at run time?


 -Wendell

Re: perl6 compiler

[Steve Pitchford]

Have a read of this:

http://www.parrot.org/

The parrot project is to build a virtual machine for dynamic languages, like
perl 6.

On Wed, Mar 17, 2010 at 1:43 AM, Dell wendell_hatc...@comcast.net wrote:

 Has anyone thought about designing or is the Rakudo compiler similar to the
 JVM on an enterprise level? What I mean is would I be able to write
 applications that can process huge amounts of data like files,claims or
 account transactions on Rakudo in the future? I think this would be a huge
 push for perl and any dynamic language. :-)



 Matthew Walton wrote:

  Rakudo in its normal operation will compile the program, then run it
 immediately. You can, however, get it to save the compiled code for
 later use i fyou wish.

 On Sun, Mar 14, 2010 at 4:09 PM, dell wendell_hatc...@comcast.net
 wrote:


 Hello,

   I had just began looking at the perl6 raduko compiler and have
 a
 question. Is perl6 actually compiled then ran similar to java or is the
 script ran and then compiled at run time?


 -Wendell

Re: what should be the default extension?

[Steve Pitchford]

Richard Hainsworth wrote:


May I suggest the following extension to the 'use ' pragma, viz.
use module name written in unicode and case sensitive in filename 
as constrained by local system



Without wanting to sound too stupid - why not delegate the decision to a 
class/resource loader of some manner, specify your resources as '[some 
unique charactor sequence uniquly identifying a module and version such 
as a the string form of a URI - ie not using the URI as a pointer to an 
online resource, just as a unique sequence of charactors]' and leave it 
up to the class/resource loader where it gets it from?


That way for prototyping code you just say use and some wierd derivitave 
of CPAN and a resource loader can automatically go to some library 
resource, find out where it is, and get it for you and cache it. You 
probably wouldn't want this to be default behavour though.


For live code you could use a loader that only uses the local file 
system. For an application you may only want to check inside the 
aggregated package your distribution comes in ( ie a tar.gz or zip file )


And the programmer wouldn't have to give a monkeys about the syntax 
because retreiving the resource would be left to the class/resource loader.


Note - after scanning through the thread some of this seems similar to 
David Greens post about a proper library-manager...


Steve

--
All thoughts are my own and not those of my employer or any other 
association