herbert breunung wrote:
Mark J. Reed wrote:
I do think It Would Be Nice If there were a native Perl6
DRY/MVC/OMG/WTF/BBQ webapp dev framework ready to go (go where? into a
webapp-oriented P6 distro, natch) around the same time that the lang
itself is done.
I imagine a port of Catalyst would
snip
I don't know why, this given... when sounds so 'English' without
really being that
English.
The construct given ... when sounds better in English than switch ...
case ... because:
a) Switch is more commonly used in English as a noun, eg., Use the
switch to turn on the light. But because
On Dec 8, 2007, at 9:06 , Richard Hainsworth wrote:
or not quite right. And there is absolutely no linguistic link
between 'switch' and 'case'. If I am uncomfortable with 'switch',
'case' really sucks. In fact, whenever I work in language other
than perl, and 'switch' is the preferred
On Fri, Dec 07, 2007 at 02:47:05AM +0100, Juerd Waalboer wrote:
: Jonathan Lang skribis 2007-12-06 16:36 (-0800):
: I know it used to be that way back near the Dawn of Time, but methods
: don't automatically topicalize anymore unless you explicitly name
: one of the parameters '$_':
: Huh.
On Sun, Dec 02, 2007 at 07:43:25PM -0800, Peter Scott wrote:
: I do feel strongly that we need some sort of solution to this so that Perl
: 6 is not merely an outstanding framework that leaves all domain-specific
: extensions to the end user.
Perl 6 as a language doesn't address this (except
On Tue, Dec 04, 2007 at 08:40:10AM -0800, Jonathan Lang wrote:
: or (I think):
:
: method test ($value) {
: setup();
: when $value { doit() } #[smart-match the calling object $_ against
$value.]
: }
I know it used to be that way back near the Dawn of Time, but methods
don't
Larry Wall wrote:
Now, it might well be that a Perl standards body could specify a
mininum suggested set of modules for any distribution to enhance
interoperability, but we haven't got to that point yet, I don't think.
This would be great though!!
Even if it is afterward, it is still a lot
Jonathan Lang wrote:
Another thing to note about given ... when: you don't have to use them
together. All that given does is to set $_ to the variable
provided; this can be used in a manner similar to with statements in
other languages. And when doesn't have to be inside a given
block,
cdumont wrote:
In japanese it could even be :
wa {
'' no baai ni { ... }
}
Getting rid off the thema or I guess here taking $_ as the default.
is this possible :
given $operator {
'' {}
'' {}
}
?
If Larry doesn't mind me elbowing into the conversation...
[[ This message was both posted and mailed: see
the To, Cc, and Newsgroups headers for details. ]]
In article [EMAIL PROTECTED], cdumont
[EMAIL PROTECTED] wrote:
oh, it might not be relevant in many ways but :
http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/
Another thing to note about given ... when: you don't have to use them
together. All that given does is to set $_ to the variable
provided; this can be used in a manner similar to with statements in
other languages. And when doesn't have to be inside a given
block, either: it can be used in any
I found some of the perl 6 new features really neat:
- creating your own type
- type casting
- junctions
- multidispatch
- :r:w:a shortcuts
- hyper operators
- some kind of oop keywords
But there are some changes in the grammar which
benefits aren't that obvious :
1- $str1 ~ $str2
2- $life
?)
There is a :key(value) pair notation already.
And I know this may not sound that much but it could be sent to
javascript or actionscript or any ecmascript based languages.
I don't think it's a good idea to write files that can be interpreted
either as Perl 6 or as javascript
the new concatenation style when most of
the time it's '+' or '.'
It isn't great, but I'm sure we can live with it. It frees up dot for
other things. Anyway, because of interpolation Perl doesn't use
concatenation as much as many other langauges (and even less so in Perl
6 with method calls being
it is that would
need organising)
I do feel strongly that we need some sort of solution to this so that Perl
6 is not merely an outstanding framework that leaves all domain-specific
extensions to the end user.
Please note that I am not arguing for inclusion in the core; presumably
I *am* arguing
in Perl
6 with method calls being interpolatable and braces for conveniently
interpolating any code at all).
It also has the advantage that tilde is consistently used in several
places in Perl 6 to indicate strings.
2- $life = (!$monster) ?? 'safe' !! 'dead';
I don't see how putting 2 questions
that we want Perl 6 to be able to complain about syntax
errors -- that is, we want that when somebody makes a typo, there's a
good chance of perl complaining about the source being invalid, rather
than it being valid Perl 6 (but which silently does something else).
As for the functions, i didn't
Peter Scott writes:
I do feel strongly that we need some sort of solution to this so that
Perl 6 is not merely an outstanding framework that leaves all
domain-specific extensions to the end user.
OK.
Can we find a way to make and maintain some recommendations in a way
that people can find
of the ? ... : operator.
...and it's not just the colon, but the ? also has the potential to be
confusing here, because there's a prefix:? operator that is used to
coerce into boolean context.
Which indirectly gets around to an even stronger reason for using
C?? !! over C? : -- Perl 6 aims for a consistency in the
use
has to be an indirect method call, not a concatenation.
In general, one of the design principles of Perl 6 is that we never
overload operators to do very different things, because even if we can
think of a way to finesse it right now, it has a negative impact on
both extensibility and readability
? : -- Perl 6 aims for a consistency in the
use of the ? and ! characters to mean boolean true and boolean
not true. This is true not only for the operators, but also in
regular expressions and other places. So, having something like
$foo = $cond ?? ...if_true... !! ...if_not_true... ;
achieves
the colon being confused for the : which marks the end
of this part of the ? ... : operator.
Also remember that we want Perl 6 to be able to complain about syntax
errors -- that is, we want that when somebody makes a typo, there's a
good chance of perl complaining about the source being invalid
methods and use . for method calls,
$a.$b has to be an indirect method call, not a concatenation.
Oh! True!
But ~...
it's not has easy to type as '.' and not really visually nice (even if
outstanding)
In general, one of the design principles of Perl 6 is that we never
overload operators to do very
reason for using
C?? !! over C? : -- Perl 6 aims for a consistency in the
use of the ? and ! characters to mean boolean true and boolean
not true. This is true not only for the operators, but also in
regular expressions and other places. So, having something like
$foo = $cond ?? ...if_true
is to discuss the Perl 6 core language.
The very notions of enterprise use and open source use and web use
are so amorphous that it is hard to imagine core language features that
would foster or discourage them. A language is an ecosystem, and it's
hard to argue that Perl has done poorly in any
@ list?
This list is to discuss the Perl 6 core language.
The very notions of enterprise use and open source use and web
use are so amorphous that it is hard to imagine core language features
that would foster or discourage them. A language is an ecosystem, and
it's hard to argue that Perl has
At 2:51 PM +0900 12/4/07, cdumont wrote:
Sorry.
Where can I find a mailing list that is about Perl 6 in general then?
Thank you.
I would recommend that [EMAIL PROTECTED] is the best place to talk
about these things, out of the official Perl 6 lists that I know of.
-- Darren Duncan
Darren Duncan wrote:
At 2:51 PM +0900 12/4/07, cdumont wrote:
Sorry.
Where can I find a mailing list that is about Perl 6 in general then?
Thank you.
I would recommend that [EMAIL PROTECTED] is the best place to talk
about these things, out of the official Perl 6 lists that I know
that is supposed to have reached saturation years ago,
it means that it wasn't the optimum or even closed to be it.
While perl6 is being implemented it is perhaps a good idea to evoluate
perl 6
in regards to perl 5 at the language level but also cultural and
environment level.
I wanted to point out
On Nov 30, 2007 10:57 AM, David Green [EMAIL PROTECTED] wrote:
Maybe some kind of Advisory Board would help, where people (who
might be experts in various ways) can offer informed recommendations
on what modules make a good fit for what circumstances. Ultimately,
if this is something we want,
On 11/29/07, James Fuller wrote:
but by making some fundamental xml processing available by the core
(like file access, regex, and a host of other fundamental bits n
bobs), u do promote a common and systematic approach to working with
XML in all perl modules.
As everyone else and his dog has
. (Or indeed, any other
module, as far as its linguistic aspects go.) The first thing that
caught my eye about James's examples was the way he plunked XML (that
looked like XML) in the middle of Perl (that looked like Perl).
my $sales = sales vendor=John
item type=peas price=4 quantity=6
);
-
declaring some xml in one's perl program;
-
my $sales = sales vendor=John
item type=peas price=4 quantity=6/
item type=carrot price=3 quantity=10/
item type=chips price=5 quantity=3/
/sales;
d) My problem with this snippit is that there is no context
On 11/29/07, James Fuller [EMAIL PROTECTED] wrote:
I understand that there can be different distros customized to certain
problem domains, but as explained I see XML as common to all those
problem domains.
I have a fulltime Perl programming job. I also spend a lot of my free
time with Perl.
types. With Perl 6, they're even
easier to work with, so there are your types and they should be pretty
darned good. Other than the fact that you're forced to pick something
which really suits your needs, why would you want to force *me* to have
stuff which doesn't suit my needs? If you'll pardon
On Nov 29, 2007 6:40 AM, James Fuller [EMAIL PROTECTED] wrote:
I would argue that XML is slightly evolved 'text' and I would like to
see my fav programming language treat it as a first class citizen
internally.
I think you are falling into a classic builtin trap. The idea is that when
you
I guess what should be in the core or not is not something
that should not be debated here.
In fact, perl 6 is supposed to be the *community language*
so instead of saying 'I' use this one but don't use this one,
so I don't see why it should be implemented into perl,
the *community* should decide
On Nov 29, 2007 12:01 PM, Smylers [EMAIL PROTECTED] wrote:
So, to make a claim for any 'domain-specific' functionality to be added
there are plenty of core perl functions that you or I will use rarely
(both in perl 5 and perl 6).
my claim is that XML is significantly common place, that any new
James Fuller writes:
my claim is that XML is significantly common place,
Yes, but the question isn't whether it's common place _now_ -- but
whether it still will be in a couple of decades time.
We know from experience that adding some modules to Perl 5 a decade ago
is now a maintenance burden,
to be added
there are plenty of core perl functions that you or I will use rarely
(both in perl 5 and perl 6).
my claim is that XML is significantly common place, that any new
language that descends from the gods, could have some basic XML
processing support in place.
It's an opportunity
On Nov 29, 2007 1:15 PM, Luke Palmer [EMAIL PROTECTED] wrote:
This has become quite the flame war. There seem to be two sides of
the argument, you arguing one, everybody else arguing the other.
good to see there is passion underlying perl 6 development ;)
So to bring some perspective back
On Nov 29, 2007 1:15 PM, Luke Palmer [EMAIL PROTECTED] wrote:
language? What would you be able to do with it that you couldn't do
if it were a module
(arguments such as use it without putting 'use XML::Foo' at the top
considered valid)?
and to answer specifically the question;
'What would
James Fuller writes:
by making some fundamental xml processing available by the core, u do
promote a common and systematic approach to working with XML in all
perl modules.
Why is that a good thing?
What makes you so sure that nobody will come up with a better way of
working with XML
In
On Nov 29, 2007 3:44 PM, Smylers [EMAIL PROTECTED] wrote:
What makes you so sure that nobody will come up with a better way of
working with XML
there is power in everyone doing the same thing ... this is a
variation of lingua franca design pattern.
For example, would we say that the reason why
? I think you're misunderstanding the
whole core argument. Assume that you install Perl 6, and it comes
with everything you need to do XML processing. You have to add a
'use' statement at the top, but the module so used is preinstalled.
Having used it, operators work on XML objects: you can add
On Thu, Nov 29, 2007 at 10:20:00AM -0500, Mark J. Reed wrote:
The module could even, I suppose, insert a filter into the compiler so
that your proposed literal syntax would work, but I don't really see
the advantage of that over this:
my $doc = Document.new(END);
in that set.
Since one key aspect of Perl 6 is parsing it should be a strict superset
of XML! XML is all about machine friendly parsing---beat me if that is
over simplified but I'm looking at it from a very abstract point of
view. Perl 6 addresses a much harder task: human friendly parsing ;)
(arguments
what I would call build artifacts
of a language e.g. a distro of Perl 6 should be easy to adopt
and easy to use immediately . I would like to see some basic
level of XML support in this distro.
I understand that there can be different distros customized to
certain problem
they're
pedigree, and whose rules are in operation where? How can you even
consistently tell by inspection of the text which language is
intended at the top?
These are questions Perl 6 is addressing. It will be *trivial* to
add syntax such as the above to Perl 6. But unlike the initiatives
above
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
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
a reason that
entire grammars like XPath and XQuery exist to do one thing and one
thing alone. Let these languages do what they do well, and let Perl
use them via modules (I'm working on an XQilla module now). A native
XML type would only serve to antiquate Perl 6 long before it's time
idea. Something
representing an XML element with its children is incredibly useful when
standardised. And if it doesn't do what you want, just add a role that
makes it do that.
A native XML type would only serve to antiquate Perl 6 long before
it's time (!), and is therefore a ... nonstarter
Thanks to all for taking the time to respond at a minimum the
discussion has taught me where perl 6 is headed and where the major
architectural brake points currently are.
gl, Jim Fuller
cdumont wrote:
By listening to you all, we shouldn't even think to implement file access...
I think I'd argue that most file-access features should indeed be
considered non-core. This doesn't mean that we shouldn't think to
implement them -- or that they wouldn't be part of almost every Perl-6
cdumont wrote:
By listening to you all, we shouldn't even think to implement file access...
I think I'd argue that most file-access features should indeed be
considered non-core. This doesn't mean that we shouldn't think to
implement them -- or that they wouldn't be part of almost every Perl-6
be that a problem), making it fast, available, coherent with
perl itself, perl documentation
will save many troubles.
Perl 6 could do without implementing the XML at a core level.
But why not create an interface, directions but not implementation.
Unfortunately, I deal with xml too (very helas
On 11/29/07, Luke Palmer wrote:
I think you are falling into a classic builtin trap. [...]
Please, you, everyone, forget about the word core. It is an
implementation detail.
Yes! Though it's a natural mistake because people assume that The
CORE(TM) in Perl6 means something similar to the
there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps
before Perl 6 is fully baked its time to review what could live in the
core versus an external module.
thoughts?
cheers, Jim Fuller
On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote:
there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps
before Perl 6 is fully baked its time to review what could live in the
core versus an external module.
thoughts?
If I remember the plan correctly, it's roughly
profile capability was the result.
With Ant's latest incarnation, they finally have a good model for
extensibility and have been successful at segregating axiomatic
functionality to the core and relegating extensions to external
libraries.
I completely agree that this is also good approach for Perl 6
On Nov 28, 2007 7:31 PM, C.J. Adams-Collier [EMAIL PROTECTED] wrote:
On Wed, 2007-11-28 at 18:12 +, Nicholas Clark wrote:
On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote:
there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps
before Perl 6 is fully baked
On Wed, Nov 28, 2007 at 07:42:29PM +0100, James Fuller wrote:
in the meantime, I have yet to get latest trunk perl6 running
properly, on parrot, or freebsd then I will start thinking of such a
task (everything compiles fine). as an aside I am getting an;
load_bytecode couldn't find file
On Nov 28, 2007 7:39 PM, Andy Armstrong [EMAIL PROTECTED] wrote:
On 28 Nov 2007, at 18:28, James Fuller wrote:
A few things I could imagine; native XML data type (and whatever that
means at this late stage)
What might that mean at any stage?
from a syntactic point of view, here are
Not too put too strong a bias on it, but:
XML processors are a dime a dozen. There is no way for us to know *now*
what the best XML processor(s) will be a decade from now, and Perl 6
is intended to be a very long term language. And frankly there are
enough different use cases to ensure
On Nov 28, 2007 7:50 PM, Geoffrey Broadwell [EMAIL PROTECTED] wrote:
Not too put too strong a bias on it, but:
XML processors are a dime a dozen. There is no way for us to know *now*
what the best XML processor(s) will be a decade from now, and Perl 6
is intended to be a very long term
On 28 Nov 2007, at 18:28, James Fuller wrote:
A few things I could imagine; native XML data type (and whatever that
means at this late stage)
What might that mean at any stage?
--
Andy Armstrong, Hexten
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
vitally important, completely basic, and utterly
standard (XML is for youngin's, dagnabbit) to me.
The Python folks want to ship batteries included. I want Perl 6 to
ship a Mr. Fusion Home Energy Reactor and an easy way to download power
adapters.
I have a lot of XML in front of me in all projects
On Wed, 2007-11-28 at 11:46 -0800, chromatic wrote:
The criterion for including a module in the core is Is this necessary to get
and install other modules? not Why not include this module?
WELL SAID.
-'f
On Wed, 2007-11-28 at 18:12 +, Nicholas Clark wrote:
On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote:
there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps
before Perl 6 is fully baked its time to review what could live in the
core versus an external module
On 9/18/07, Paul Hodges [EMAIL PROTECTED] wrote:
hypothetical
For the Gearheads
We won't bore you with excess details,
but for more info... c.f. ...
/hypothetical
on 9/19/2007 10:19 AM Adriano Ferreira said the following:
I am thinking about such hooks and good ways to do that.
On 9/19/07, Moritz Lenz [EMAIL PROTECTED] wrote:
Adriano Ferreira wrote:
http://ferreira.nfshost.com/perl6/stitching6.html
A grammatical nit: The infix operator '~' keeps the same precedence of
'+' in Perl 6.
I think that should be the same precedence _as_ (but I'm not a native
speaker, so
On 9/18/07, Joe Gottman [EMAIL PROTECTED] wrote:
Adriano Ferreira wrote:
I salute every bit of help. I am trying to organize the production and
will hopefully provide more details soon. By now, I think that I can
handle suggestions and corrections to the articles. The next one is
here:
information.
We could write a treatise on Perl 6 operators (and that will be long
and fascinating for some), but that's not the goal right now.
For the non-Perl audience, I think it might be worth mentioning the
(to us) obvious automatic context manipulations. e.g.,
~ is stitching strings
...
To learn how to use @@() for multidimensional context, see...
/example
Sounds like a good idea.
Stumbling blocks:
* (@x, *) does not work in current implementations
* it's a very good idea that I learn more Perl 6
* Gotta get those operators articles out
By the way, the article on ~ was published
--- Larry Wall [EMAIL PROTECTED] wrote:
On Tue, Sep 18, 2007 at 07:41:54PM -0700, Paul Hodges wrote:
: while length($ruler) $len; # till there's enough
There is no length function anymore.
duh. I knew that. Still thinking in v5.
Thanks, Larry.
On 9/18/07, Adriano Ferreira [EMAIL PROTECTED] wrote:
Join me. The drafts of the introduction and the first article are here:
http://ferreira.nfshost.com/perl6/intro.html
http://ferreira.nfshost.com/perl6/zip.html
I see the following snippet in zip.html:
# import num2en from Perl 6
snippet in zip.html:
# import num2en from Perl 6 Lingua::EN::Numbers module
use :from perl5 Lingua::EN::Numbers num2en ;
Maybe you meant Perl 5 in that comment? It looks inconsistent to me ;)
Yes. That's what I meant. Fixed by now. Thanks.
Nice article, BTW :)
Thanks,
agentz
In article [EMAIL PROTECTED], Alberto Simões
[EMAIL PROTECTED] wrote:
Adriano Ferreira wrote:
The plan is to write a series of blog entries discussing a Perl 6
operator at a time or a small group of closely related ones.
I think the idea is cool. Also, I do not know how periodically
On 9/18/07, brian d foy [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED], Alberto Simões
[EMAIL PROTECTED] wrote:
Adriano Ferreira wrote:
The plan is to write a series of blog entries discussing a Perl 6
operator at a time or a small group of closely related ones.
I think
--- Adriano Ferreira [EMAIL PROTECTED] wrote:
[[snips here and at end]]
. . . I have one suggestion: you might want to mention
the roundrobin function in the article on the zip function since
the two are very closely related.
Thanks, Joe and Alberto.
Even though the roundrobin is very
On 9/18/07, Paul Hodges [EMAIL PROTECTED] wrote:
--- Adriano Ferreira [EMAIL PROTECTED] wrote:
[[snips here and at end]]
. . . I have one suggestion: you might want to mention
the roundrobin function in the article on the zip function since
the two are very closely related.
Thanks,
Adriano Ferreira wrote:
I salute every bit of help. I am trying to organize the production and
will hopefully provide more details soon. By now, I think that I can
handle suggestions and corrections to the articles. The next one is
here:
http://ferreira.nfshost.com/perl6/stitching6.html
Looks good . . . but how short do we want them?
For the non-Perl audience, I think it might be worth mentioning the
(to us) obvious automatic context manipulations. e.g.,
~ is stitching strings, and will make strings out of its arguments
if it can -- it's not adding, but has the same
On Tue, Sep 18, 2007 at 09:46:14PM -0400, Joe Gottman wrote:
: Adriano Ferreira wrote:
: I salute every bit of help. I am trying to organize the production and
: will hopefully provide more details soon. By now, I think that I can
: handle suggestions and corrections to the articles. The next one
On Tue, Sep 18, 2007 at 07:41:54PM -0700, Paul Hodges wrote:
: while length($ruler) $len; # till there's enough
There is no length function anymore.
Larry
Jesse Vincent has announced the acceptance of my microgrant proposal
(http://use.perl.org/~jesse/journal/34451). It is a plain simple
idea, whose effects are yet to be seen. Comments and feedback most
welcome.
The plan is to write a series of blog entries discussing a Perl 6
operator at a time
Hi
Adriano Ferreira wrote:
The plan is to write a series of blog entries discussing a Perl 6
operator at a time or a small group of closely related ones.
I think the idea is cool. Also, I do not know how periodically that
would be, but it might be a good idea to join some of them in turns
On 9/17/07, Joe Gottman [EMAIL PROTECTED] wrote:
Adriano Ferreira wrote:
Jesse Vincent has announced the acceptance of my microgrant proposal
(http://use.perl.org/~jesse/journal/34451). It is a plain simple
idea, whose effects are yet to be seen. Comments and feedback most
welcome.
Adriano Ferreira wrote:
Jesse Vincent has announced the acceptance of my microgrant proposal
(http://use.perl.org/~jesse/journal/34451). It is a plain simple
idea, whose effects are yet to be seen. Comments and feedback most
welcome.
snip
Join me. The drafts of the introduction and the
Allison Randal wrote:
I just signed an agreement with O'Reilly that assigns the full copyright
in the book Perl 6 and Parrot Essentials to The Perl Foundation. The
text is out-of-date, but can be updated much more rapidly than it can be
rewritten from scratch.
Sounds great. Does TPF
Allison Randal wrote:
I just signed an agreement with O'Reilly that assigns the full copyright
in the book Perl 6 and Parrot Essentials to The Perl Foundation. The
text is out-of-date, but can be updated much more rapidly than it can be
rewritten from scratch.
Sounds great. Does TPF have
On Jun 18, 2007, at 8:13 PM, Moritz Lenz wrote:
Allison Randal wrote:
I just signed an agreement with O'Reilly that assigns the full
copyright
in the book Perl 6 and Parrot Essentials to The Perl Foundation.
The
text is out-of-date, but can be updated much more rapidly than it
can
I'm pleased to announce that the Perl 6 parts of /Perl 6 and Parrot
Essentials/
are now available at http://svn.pugscode.org/pugs/docs/tutorial/ [1]
for your hacking
pleasure.
Thanks to Allison for navigating the sometimes murky waters of
copyright assignment
and licensing to get
I just signed an agreement with O'Reilly that assigns the full copyright
in the book Perl 6 and Parrot Essentials to The Perl Foundation. The
text is out-of-date, but can be updated much more rapidly than it can be
rewritten from scratch.
I'll check the Parrot parts into:
http://svn.perl.org
Allison Randal wrote:
I just signed an agreement with O'Reilly that assigns the full copyright
in the book Perl 6 and Parrot Essentials to The Perl Foundation. The
text is out-of-date, but can be updated much more rapidly than it can be
rewritten from scratch.
Sounds great. Does TPF have
* Damian Conway ([EMAIL PROTECTED]) [070616 23:21]:
I will, however, take a moment to answer the accusation that I appear to
have redesigned Pod the way I did in order to make implementation
easier...
The opposit: your work is known to seek the corners of the language
which hurt most. So
I'm not going to argue about the design of Pod 6 any more. As both Mark
and brian have pointed out, this really comes down to philosophical
differences that no amount of discussion is going to resolve. In any
case, I'm sure that Larry now has plenty of grist from which to mill a
final
:
: In Perl 6, the sigil is used to distinguish between
:
: foo bar
:
: which calls bar and passes the return value to foo, and
:
: foo bar
:
: which passes bar as a Code object to foo.
In other words, the sigil is consistently a noun marker in Perl 6,
even when a sigil is used
501 - 600 of 1442 matches
Mail list logo
