On Saturday 20 March 2010 at 12:23, Richard Hainsworth wrote:
> In other words, I am suggesting a sort of mapping of the syntax of perl6
> so that stable areas can us be used, perhaps avoiding instruments that
> are not yet explicitly stable.
That assumes it's possible to know with sufficient c
x27;t too far off, but it does lack some important
features.
For the curious, the Modern Perl Github repository has a book in progress; see
the tools/ directory for some hint of the necessary scaffolding:
http://github.com/chromatic/modern_perl_book/
(Writing a book isn't too
The Beyond and below are like a deep of ocean, and we the creatures
that swim in the abyss. We're so far down that the beings on the
surface -- superior though they are -- can't effectively reach us.
Oh, they fish, and they sometimes blight the upper levels with
points we don't
On behalf of the Rakudo development team, I'm pleased to announce the
December 2009 development release of Rakudo Perl #24 "Seoul".
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org). The tarball for the December 2009 release
is available from http://gi
On Saturday 24 January 2009 05:56:03 Nicholas Clark wrote:
> And if left alone I can ramble that much, is anyone surprised
> that chromatic can't manage to minute several people discussing it?
Amusingly, you were the one who didn't minute it; I wasn't on the call that
week.
-- c
On behalf of the Parrot team, I'm proud to announce Parrot 0.8.1 "Tio
Richie." [1] Parrot is a virtual machine aimed at running all dynamic
languages.
Rat Creature #1: Comrade! We are about to feast! Quick, get your fat
carcass behind this bush and get ready!
Rat Creature
On Wednesday 20 August 2008 15:16:12 Aristotle Pagaltzis wrote:
> It therefore seems necessary to me to specify dispatch such that
> method calls in the Dog role invoke the original Dog role methods
> where such methods exist. There also needs to be a way for a
> class that assumes a role to expli
On Tuesday 05 August 2008 15:25:47 Bob Rogers wrote:
>On Tuesday 05 August 2008 12:01:29 Larry Wall wrote:
>> I believe "veto" is giving the wrong idea here as something that
>> happens after the fact. What's the term for only allowing
>> "acceptable" candidates to put their names
On Tuesday 05 August 2008 12:01:29 Larry Wall wrote:
> I believe "veto" is giving the wrong idea here as something that
> happens after the fact. What's the term for only allowing "acceptable"
> candidates to put their names on the ballot?
"disenfranchise"
-- c
On Sunday 01 June 2008 19:31:34 Paul Fenwick wrote:
> Questions I'm seeking answers to are:
>
> * Is there a document that describes the current p6l exception hierarchy?
> My searching skills seem to be impaired today.
>
> * Does anyone have any input they'd like to make before I start fleshing
>
They were walking to the Hemlock, the Rooster and the Mice, and the
Mice kept looking at one another, questioning.
"We don't know what the future holds, do we?" said Chauntecleer. The
Mice all shook their heads. They knew very little of anything. "If,"
said Chauntecleer, "
On Tuesday 06 May 2008 10:38:38 John M. Dlugosz wrote:
> I have problems with a simple sum. The "distance" is artificially
> inflated if you make lots of small derivation steps vs one large
> change. The concept of derivation steps is ill-defined for
> parameterized types and types that change v
On Friday 02 May 2008 16:07:56 John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> Why is there any difference in declaring classes and roles if a class
> can be used as the target of either 'is' or 'does'?
You can't instantiate a role.
On Friday 02 May 2008 13:11:55 Larry Wall wrote:
> On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote:
> : I could edit it into a Synopsis if you really want.
> Tweet! Foul on #17. Two shots!
What's the point of omnipotence if you can't swoop down from the rafters o
On Friday 02 May 2008 12:48:43 Larry Wall wrote:
> On Fri, May 02, 2008 at 12:21:27PM -0700, chromatic wrote:
> : I'm not sure which is best. Snapshotting at the time of first
> : composition (or the first time someone says "Hey, I provide that other
> : class's
On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> > All classes imply the existence of a role of the same name.
> Please justify that.
http://www.perlfoundation.org/perl6/index.cgi?perl_6_people
I could edit it into a Syn
On Friday 02 May 2008 11:55:54 Larry Wall wrote:
> On Fri, May 02, 2008 at 11:15:34AM -0700, chromatic wrote:
> : All classes imply the existence of a role of the same name.
> If a role is derived from a class, it must of necessity be a snapshot
> of the class, because roles a
On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote:
> TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
> > Then, since classes are open, the programmer can easily say
> >
> > CGI does CGI::Simple;
>
> That would be
>
> class CGI is also { does CGI::Simple }
>
> and means that CGI::Simple is
On Thursday 01 May 2008 06:35:12 John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> > This is why roles-as-types is so important: type inferencers can't infer
> > allomorphism because allomorphism relies on explicitly-marked semantic
> >
On Wednesday 30 April 2008 21:58:50 Brandon S. Allbery KF8NH wrote:
> On May 1, 2008, at 0:53 , chromatic wrote:
> > correctness sense. Sadly, both trees and dogs bark.)
> Hm, no. One's a noun, the other's a verb. Given the linguistic
> orientation of [Perl 6], it see
On Wednesday 30 April 2008 08:56:24 Ovid wrote:
> > That was always my goal for roles in the first place. I'll be a
> > little sad if Perl 6 requires an explicit notation to behave correctly
> > here -- that is, if the default check is for subtyping, not polymorphic
> > equivalence.
> I had in
On Monday 28 April 2008 10:15:25 Jon Lang wrote:
> Ah; that clears things up considerably. If I understand you
> correctly, John is using '£' to mean "use Duck Typing here". _That_,
> I can definitely see uses for. As well, spelling it as 'like' instead
> of '£' is _much_ more readable. With t
On Saturday 05 April 2008 17:10:57 Larry Wall wrote:
> On Fri, Apr 04, 2008 at 09:41:26PM -0500, John M. Dlugosz wrote:
> > I suppose any object would do, it doesn't have to be "but undefined", or
> > created using that Class{hash} syntax?
>
> Possibly. Haven't really thought through the ramific
On Friday 04 April 2008 16:56:44 Audrey Tang wrote:
> In other words, there needs to be no real hard attribute "bar", no
> matter if you call the "bar" method as self.bar(), $.bar(), or simply
> $.bar.
That's what I was trying to say with "uniform access principle", except that
Audrey's version
On Friday 04 April 2008 16:31:56 John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> > It shouldn't be.
> So you are saying that...
I was talking about syntax.
> In that case, why allow the variable-name form at all?
Because they're variables
On Friday 04 April 2008 13:47:40 John M. Dlugosz wrote:
> But, it is also stated that in derived and trusted classes, and even in
> the class itself, $.a is an accessor call? As opposed to $!a which is
> the direct access to the attribute. Is this accessor different from the
> function form used
On Wednesday 26 March 2008 12:26:35 James Fuller wrote:
> I do not think that its right to release
> perl6 for the language, but it might be 'right' to do for language
> adoption no doubt cathedral / bazaar forces are in effect.
I don't follow this; can you elaborate?
-- c
On Wednesday 26 March 2008 11:08:15 James Fuller wrote:
> can I add a few unsolicited ruminations from a lurker;
>
>* just release perl 6 now and move on
To what extent?
Larry "just released" Perl 5 some 13 and a half years ago, and there've been a
few patches applied to it in the past 24 h
On Tuesday 25 March 2008 10:50:15 Richard Hainsworth wrote:
> What the perl6 language needs now is a systematic development plan, with
> broad aims and clear goals that will lead to good quality software and
> to the tools to enable ordinary programmers to use perl6 for a variety
> of tasks.
Rich
On Tuesday 25 March 2008 10:50:15 Richard Hainsworth wrote:
> What the perl6 language needs now is a systematic development plan, with
> broad aims and clear goals that will lead to good quality software and
> to the tools to enable ordinary programmers to use perl6 for a variety
> of tasks.
Perl
On Thursday 13 March 2008 15:27:18 herbert breunung wrote:
> currently just used for compile time constants like $?LINE allright so
> far so good.
> but why not use that for all constants like
>
> my $?constant = 5;
>
> so it's compiletime (even late compiletime like in eval blocks) fix
> binding
On Thursday 21 February 2008 06:25:42 Joshua Gatcomb wrote:
> Here is something to consider. Unless we can afford to fund an individual
> full time with enough money for them to pay for their own health coverage
> and other benefits, the amount of time they are volunteering is already as
> much a
On Tuesday 05 February 2008 20:02:53 Mark J. Reed wrote:
> Ah, macros, is there no problem you can't solve? :)
If my experience with the Perl 5 core is any guide, the problem of too many
macros.
-- c
On Saturday 26 January 2008 08:58:43 Larry Wall wrote:
> That would cover most of the cases for English speakers using regular
> nouns, but I wonder whether there's some kind of generalization that
> would help for cases like:
>
> say "There was/were $o ox/oxen"
That makes me wish for a subju
On Monday 07 January 2008 08:42:06 Trey Harris wrote:
> Then we can have roles that describe cross-cutting behavior of various
> OS's (like POSIX):
>
> my &trytolink;
> give $?OS {
> when OS::HasSymlinks { &trytolink := &*symlink; }
> when OS::HasLinks { &trytolink := &*link;
On Saturday 29 December 2007 13:35:00 Mark J. Reed wrote:
> Ok, consider me duly chastised. Sorry for the sidetracking.
It's not a *bad* idea, but it's less important in my mind than getting useful
information on the wiki. Anyone who wants to pursue it can do so, but I'd
like to forestall a l
On Saturday 29 December 2007 06:56:45 Mark J. Reed wrote:
> Maybe it's just me, but it
> seems like it will just feed the all-too-common perception that Perl
> is for CGI scripts, and "real" web apps need to be written in
> something else (be it Java, PHP, Ruby/Rails, whatever).
Proposed new rule
On Friday 28 December 2007 17:04:40 herbert breunung wrote:
> I have also plans to add my perl article (once they transelated) for $foo
> perl magazine and maybe some perl.com articles, if chomatic allowes.
It's fine with O'Reilly, as long as the authors of the articles agree (they
hold the copy
On Thursday 13 December 2007 13:37:19 ispyhumanfly wrote:
> Any questions? :)
Is it possible to see a list of tasks without the barrier of creating an
account, requesting an invite, or logging in? I understand that a little bit
of administrative overhead is useful, but I'd also like to see as
On Tuesday 11 December 2007 09:20:22 Paul Hodges wrote:
> But on this general note, is there any current organization or location
> where small problems are being parcelled out? I'd love to help, but my
> time is as limited as everyone's If I could get small bites of work
> to do, maybe I coul
On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote:
> I download pugs and parrot from
> SVN repositories, written tests - one of which still hangs the
> compilation of pugs. Indeed the test I wrote for pugs concerned the
> ability of pugs to use existing CPAN modules. I have tried parro
On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote:
> Surely, some concentrated thought by the inventive and resouceful minds of
> who lead this project should go into language utilisation and
> popularisation.
My goodness, @Larry's pretty darn busy trying to build the core kernel of
On Thursday 29 November 2007 07:07:18 James Fuller wrote:
> I have been arguing that having some simple functionality, provided by
> the core, would potentially harmonize usage across modules and promote
> better understanding of code, in general, through consistent usage.
That didn't work for Fi
On Thursday 29 November 2007 03:21:18 cdumont wrote:
> By listening to you all, we shouldn't even think to implement file
> access...
Please drop the sarcasm.
> A programming language is made by humans and subject to the same evolutions
> and bugs and in the end is alive and will die.
> A progra
On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
> I do not nec. agree with 'a particular grammer is not' part of the
> core ... if that grammar is so common to every problem (like regex is)
> then why not include it?
Because it's not necessary for getting and installing other extension
Jack had avoided looking into his sons' faces during this Oration, because he
reckoned they'd not wish to be seen with tears streaming down their faces.
But looking up at Jimmy now he saw dry eyes and a quizzical if impatient
phizz. Turning the other way, he saw Danny gazing distractedly at the
On Monday 25 June 2007 00:57:18 Hakim Cassimally wrote:
> Releasing a language without a useful, easily installable library bundle
> could quite reasonably be construed as a stupid business practice.
Of course. Yet some dozen years later, the argument for keeping interfaces
such as File::Find (
On Friday 22 June 2007 11:07:35 Chas Owens wrote:
> Please, god, no. Or at least make two distributions: Bare Perl 6 and
> Perl 6. Many companies have a "Only Core Perl" policy. They refuse
> to install CPAN modules because "We don't trust them".
I think of this the same way I think of "Do not
On Thursday 21 June 2007 15:23:38 Smylers wrote:
> Has Larry yet decreed whether Web will be bundled with Perl 6?
I also like to proceed from the assumption that the only core modules should
be those required to install other modules.
-- c
On Thursday 31 May 2007 17:36:40 Chas Owens wrote:
> Except of course those poor schmucks who foolishly wrote code like
>
> if (ref $arg eq 'HASH') { ... }
I know you're teasing, but it *would* be nice to see that sort of code just
magically go away.
-- c
As I sailed into Shadow, a white bird of my desire came and sat upon my
right shoulder, and I wrote a note and tied it to its leg and sent it on
its way. The note said, "I am coming," and it was signed by me.
...
The sun hung low on my left and the winds bellied the sails and
On Monday 14 May 2007 15:48:24 Thomas Wittek wrote:
> But it should be no problem to put out a warning/error at runtime (or
> maybe even at compile time) when a variable name clashes with a method
> name.
Do you always know all of the method names in your entire memory space at
compile time?
--
On Monday 14 May 2007 04:35:19 Thomas Wittek wrote:
> BTW: Why do so much people say "go away if you don't like it" instead of
> being open for ideas and discussing them from a neutral point of view?
Perhaps you're not a native English speaker, but running into the room and
saying "Perl 6 doesn'
On Monday 14 May 2007 04:28:15 Thomas Wittek wrote:
> > I'm not a friend of potential conflicts between built-in operators and my
> > identifier names (and especially the conflicts between scalar, aggregate,
> > type, and function names).
> As I partially wrote Moritz, I
> a) don't think that it'
On Sunday 13 May 2007 15:42:30 Thomas Wittek wrote:
> What makes Perl hard to read is the excessive use of special characters
> (/\W/).
It also makes Mandarin and other ideographic languages impossible to read. As
evidence I admit that, though I am very smart, *I* can't read them.
(Try to ignor
On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote:
> What is nedded is a very simple step:
Contributors.
-- c
On Tuesday 10 April 2007 18:51, Shlomi Fish wrote:
> > (Although it seems the most interesting promises made by parrot - fast
> > typeless code for example - are not going to be delivered, too).
> Hmmm I haven't been closely following Parrot.
Despite this mention, this thread is off-topic fo
On Monday 26 February 2007 11:29, Geoffrey Broadwell wrote:
> Does Perl 6 on Parrot have Perl 5 connectivity?
Not until Perl 6 can use PIR code. After that, it depends on what you want to
do with the two.
If you can get Parrot::Embed compiled and running on your machine, Perl 5 can
have Parro
On Sunday 25 February 2007 12:40, Geoffrey Broadwell wrote:
> What backends support packed native arrays at this point? And what's
> the performance like?
Parrot does have ManagedStruct and UnManagedStruct PMCs for mapping complex C
structures. The syntax to define them is a little grotty, but
On Sunday 25 February 2007 13:57, Geoffrey Broadwell wrote:
> I'm not trying to say that the implementors should rush either, nor am I
> complaining about current status; I grok the dynamics of volunteer code.
> I merely disagree with the "spec is all-important" crowd. I personally
> have a prefe
On Sunday 25 February 2007 12:56, Geoffrey Broadwell wrote:
> As I mentioned in another thread, but didn't make clear in that email: I
> don't need a "finished" spec. I need the *current* version of spec to
> actually be mostly implemented.
The implementors want the same thing.
> And if it's no
On Saturday 24 February 2007 22:42, Richard Hainsworth wrote:
> But while perl6 continues
> its evolution, without a tangible end, few are going to dedicate time
> and effort to write documentation for such as me. (eg. How out of date
> are the Exegesis files?)
You could make a very similar argum
On Tuesday 20 February 2007 12:42, Larry Wall wrote:
> 'Course, if someone goes ahead and adds the Y combinator, one must
> naturally begin to wonder what the YY combinator would be... :-)
Obviously it generates a function so anonymous that it can't even refer to
itself. I call it the depresse
On Saturday 28 October 2006 09:15, Larry Wall wrote:
> My initial inclination is to say that "where" clauses in a signature
> are only there for pattern matching, and do not modify the official
> type of the parameter within the function body. However, on a "subset"
> the "where" clause is there
On Wednesday 25 October 2006 03:04, Trey Harris wrote:
> I'll let @Larry speak for @Larry, but at one point I was told that when
> C or C appear in signatures, those are roles, not classes; if
> you examined a particular Array or Hash, the class would be some
> implementation of the Array or Hash
can do
> that, you *must* always be able to turn the strictures back off."
> chromatic, is that a fair paraphrase?
Yes.
> I don't have any problem with that sentiment--if I were you and needed to
> enforce some style on other programmers who work with me, I'd just tell
On Wednesday 04 October 2006 12:48, jesse wrote:
> Ok. So, I think what you're saying is that it's not a matter of "don't let
> people write libraries that add strictures to code that uses those modules"
> but a matter of "perl should always give you enough rope to turn off any
> stricture imposed
On Wednesday 04 October 2006 12:09, jesse wrote:
> Perhaps I'm misunderstanding what you mean by "person writing the
> program" and "person writing the libraries." In fact, I've _gotta_
> be. I'd like to be able to put my strictures in a library rather than
> forcing them into the main body of a
On Wednesday 04 October 2006 01:05, jesse wrote:
> One of the things that many shops have defected from Perl to Java for
> is the additional handcuffs that Java provides for less-than-experienced
> developers. Giving me the power to control what my team, or folks using
> my language variant, do c
On Tuesday 03 October 2006 10:06, Aaron Sherman wrote:
> Would there be such tools used in the core libraries? Maybe, maybe not,
> we could discuss that. If they were implemented in the core libraries
> would there be a universal "no bondage" flag that shut them off?
> Probably, since that's somet
On Monday 02 October 2006 12:32, Jonathan Lang wrote:
> Before we start talking about how such a thing might be implemented,
> I'd like to see a solid argument in favor of implementing it at all.
> What benefit can be derived by letting a module specify additional
> strictures for its users? Ditt
On Monday 02 October 2006 08:58, Jonathan Lang wrote:
> I wonder if it would be worthwhile to extend the syntax of roles so
> that you could prepend a "no" on any declarative line, resulting in a
> compilation error any time something composing that role attempts to
> include the feature in questi
On Tuesday 29 August 2006 13:26, Jonathan Lang wrote:
> Perl6 handles both object-orientation (through inheritance) and
> role-playing (through composition).
What exactly does inheritance have to do with object orientation, except that
some OO systems support inheritance? Plenty of OO systems g
On Friday 14 July 2006 00:30, Darren Duncan wrote:
> This may go without saying, but ...
>
> If $a === $b means what I think it does, then I believe that a
> not-premature implementation optimization of === would be that it
> always $a := $b if it was returning true, so that any future === of
> $a
Author: chromatic
Date: Sun May 21 14:11:09 2006
New Revision: 9305
Modified:
doc/trunk/design/syn/S06.pod
Log:
Minor typo fix.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod
On Thursday 11 May 2006 14:54, Smylers wrote:
> What about :gappy, to indicate that there have to be gaps in the source
> text at the points where there are gaps in the pattern?
I like this better. Forming a new compound word and then abbreviating it
seems confusing -- and I'm a native English
On Saturday 29 April 2006 21:50, Damian Conway wrote:
> Is:
>
> > $antler. .bar;
> > $xyzzy. .bar;
> > $blah. .bar;
> > $foo. .bar;
>
> really so intolerable, for those who are gung-ho to line up the method
> names?
I'm still wondering what's awful about:
$antler.bar;
$xyzzy.bar;
On Saturday 29 April 2006 18:29, Yuval Kogman wrote:
> If dots looked like this:
>
>
>
> then they would be invisible.
Use a laptop with a speck of dust in the wrong place in slightly wrong
lighting and the wrong four pixels might as well be invisible.
Precious few of @Larry deserve the nicknam
On Saturday 29 April 2006 16:58, Yuval Kogman wrote:
> On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote:
> > This would make the enormous semantic difference between:
> >
> >foo. :bar()
> >
> > and:
> >
> >foo :bar()
> >
> > depend on a visual difference of about four
On Wednesday 12 April 2006 00:06, TSa wrote:
> Doesn't that discontinuity devalue the long dot? Its purpose is
> alignment in the first palce. For a one char diff in length one
> now needs
>
> foo. .bar;
> self. .bar;
>
> instead of
>
> foo .bar;
> self.bar;
Or even:
fo
On Sunday 12 February 2006 17:11, Yiyi Hu wrote:
> For perl 6,
> Array and Scalar are in different namespace.
> So,
> class A { has $.a; has @.a };
>
> what will A.new.a return by default?
>
> An Error? or Scalar has a higher priority?
Seems like a compile-time warning (at least) to me.
-- c
On Tuesday 07 February 2006 23:55, Yuval Kogman wrote:
> Does this imply that we should think up this process?
Go ahead.
> If I propose a concrete plan for the implementation of Perl 6 in a
> layered fashion it will probably be even more overlooked.
>
> I have no authority, and this is not somet
On Tuesday 07 February 2006 15:56, Stevan Little wrote:
> The Pugs project and the Parrot project have had very different goals
> actually (at least Pugs did from the early days). Pugs aimed to be
> able to evaluate Perl 6 code, as a way of testing the language
> features and design. It did not re
On Tuesday 07 February 2006 14:17, Yuval Kogman wrote:
> If we have more steps and clearer milestones for whatever is between
> parrot and the syntax/feature level design implementation will be
> easier.
Parrot has had such milestones for well over a year.
> De-facto we have people running PIL o
On Tuesday 07 February 2006 13:28, Yuval Kogman wrote:
> Right now the biggest problem in Perl 6 land is project management.
I disagree, but even if it were true, I don't think the solution is to add
more project management and design to partition the process into even more
subprojects of nebul
On Thursday 19 January 2006 21:53, Stevan Little wrote:
> Okay, so when you say alternate storage then you mean that a class
> like this:
>
> class Foo {
> has $.bar;
> method new ($class, %params) {
> $class.bless('p5Hash', %params);
> }
> method baz {
> $.bar +
On Friday 20 January 2006 07:14, Rob Kinyon wrote:
> I think this entire issue is rising out of the fact that very very few
> people in this discussion are familiar with the design of the MOP.
> Stevan and a few others are the primary movers and I'm lucky enough to
> have been Stevan's sounding bo
On Thursday 19 January 2006 19:50, Rob Kinyon wrote:
> Nothing. Just like it's not a problem if Perl6 uses one of the
> Ruby-specific PMCs for storage. In fact, the alternate $repr idea is
> specifically to allow for the use of foreign datatypes as storage.
> Luke's excellent example is to use a C
On Wednesday 18 January 2006 20:02, Rob Kinyon wrote:
> On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote:
> > Answer me this then -- under your scheme, can I subclass a Perl 5 class
> > with Perl 6 code, instantiate the subclass, and use that object in Perl 5
> > code a
On Thursday 19 January 2006 13:10, Rob Kinyon wrote:
> &bless was a brilliant idea for Perl5. It's wrong for Perl6.
Perhaps you meant to write "Tagging a reference with a package name worked for
Perl 5. It's wrong for Perl 6."
Certainly I can agree with that.
Yet this whole discussion feels l
On Thursday 19 January 2006 06:48, Rob Kinyon wrote:
> "Any practical programming language with structural subtyping will
> probably let you create and use aliases for type names (so you don't
> have to write the full form everywhere). However, the underlying type
> system will only consider the s
On Wednesday 18 January 2006 19:39, Rob Kinyon wrote:
> No, you want to specify the $repr in CREATE(). But, p6hash will still
> not be the same as a ref to an HV. Frankly, I think you're better off
> letting Parrot mediate things the same way it would mediate Ruby and
> Perl6 or Perl5 and Python.
On Wednesday 18 January 2006 19:11, Rob Kinyon wrote:
> As for how that will be handled, I would think that it would be as follows:
> - in Perl6, objects created in another language will be treated as
> p6opaque (unless some other unbox is a more suitable $repr).
... and I specify this exactl
On Wednesday 18 January 2006 18:54, Stevan Little wrote:
> Are you thinking that one would be able to bless a Perl 5 reference
> into a Perl 6 package?
Not really, but depending on the what Perl 6 bless() does it might work.
> I would argue then that we really don't need Perl 6 &bless for this,
On Wednesday 18 January 2006 17:57, Rob Kinyon wrote:
> Well, for one thing, you can't write OO code in P5.
I'll play your semantic game if you play my what-if game.
I have a fair bit of Perl 5 code. Ponie works. I want to migrate my Perl 5
code to Perl 6 slowly. Everything new is Perl 6 cod
On Wednesday 18 January 2006 14:13, Stevan Little wrote:
> Do we really still need to retain the old Perl 5 version of &bless?
> What purpose does it serve that p6opaque does not do in a better/
> faster/cleaner way?
Interoperability with Perl 5 code.
Now if you want to write a p6opaque <-> Perl
On Monday 19 December 2005 05:06, Michele Dondi wrote:
> Speaking of which:
> | The connection between the language in which we think/program and the
> | problems and solutions we can imagine is very close. For this reason
> | restricting language features with the intent of eliminating programme
On Friday 16 December 2005 22:25, Darren Duncan wrote:
> At 10:07 PM -0800 12/16/05, chromatic wrote:
> >This is fairly well at odds with the principle that users shouldn't have
> > to bear the burden of static typing if they don't want it.
> This matter is unre
On Friday 16 December 2005 18:15, Darren Duncan wrote:
> Therefore, I propose that the default behaviour of Perl 6 be changed
> or maintained such that:
>
> 0. An undefined value should never magically change into a defined
> value, at least by default.
This is fairly well at odds with the princi
On Mon, 2005-12-05 at 07:54 +, Luke Palmer wrote:
> I wonder if there is a macroey thing that we can do here. That is,
> could we make:
>
> ok(1);
> is(1, 1);
> like("foo", /foo/);
>
> Into:
>
> ok(1);
> ok(1 == 1);
> ok("foo" ~~ /foo/);
Can you do it without givin
1 - 100 of 209 matches
Mail list logo
