Re: How to write this properly in Perl 6?
In data 28 mai 2009 alle ore 00:13:19, Mark J. Reed markjr...@gmail.com
ha scritto:
You can write a sub to return the next step:
sub bondigi { state $n=1; return (Bon Digi Bon Digi, Bon xx $n,
Digi xx $n++); }
Nahh. That's too easy...
It's not fun :-)
but I think an idiomatic Perl 6 solution would have a proper lazy
Iterator.
Yes, that's more interesting.
--
Cosimo
Re: Amazing Perl 6
Hi Damian, This is a really good list. Mind if I copy it / modify it and post it somewhere like my blog? One question: * Compactness of expression + semi-infinite data structures: @fib = 1,1...[+]# The entire Fibonacci sequence Very impressive. That's even shorter than Haskell. What's [+] ? How does this work? In Haskell: fibs = 1 : 1 : zipWith (+) fibs (tail fibs) PS: A really mean, but very effective, way of emphasizing the ease, expressiveness, compactness, and readability of Perl 6 code is to take each of the examples and show the same thing written in Java. ;-) It might be appropriate to compare some examples with Ruby or Python. Daniel.
Re: How to write this properly in Perl 6?
Mark ():
but I think an idiomatic Perl 6 solution would have a proper lazy
Iterator. How do we write one of those?
Like this, I think:
$ perl6 -e '.say for gather { my $n = 1; loop { take bon digi bon
digi; take bon for ^$n; take digi for ^$n; ++$n } }'
That currently parses in Rakudo, but hangs since we don't have Laziness.
// Carl
Re: How to write this properly in Perl 6?
In data 27 mai 2009 alle ore 23:46:40, John M. Dlugosz
2nb81l...@sneakemail.com ha scritto:
Anything in the existing implementation that's hostile to Perl 6? Just
port it over by lightly editing the text or using a p5 module importer.
Yes, right, but that wouldn't use Perl 6 features.
To write from scratch, I suppose it's just a recursive function that
talks and drinks beer.
About the beer drinking, that's one of the main points :)
I think the interesting part is when you want to see it
from the real-world game point of view, so in this case,
writing a function that returns the next correct word.
In the Perl 5 solution, I wrote a function that
allows you to do this:
# Up to any number of repeats
my $iter = bon_digi_sequence(5);
while (my $word = $iter-()) {
print $word, ' ';
}
I'm not saying it's difficult, of course.
To me it's interesting to know from others (because
I don't know) how would you go writing this function
with the weapons Perl 6 gives you.
--
Cosimo
Re: Amazing Perl 6
Daniel Carrera wrote: This is a really good list. Mind if I copy it / modify it and post it somewhere like my blog? That's fine. One question: * Compactness of expression + semi-infinite data structures: �...@fib = 1,1...[+] # The entire Fibonacci sequence Very impressive. That's even shorter than Haskell. What's [+] ? How does this work? The ... operator takes a list on the left and a generator sub (or block) on the right. It creates a lazy list consisting initially of the left operand. When the left operand runs out, the right operand is invoked to generate extra values. The generator grabs as many existing values from the end of the list as it needs arguments, then appends its result to the end of the lazy list. Lather, rinse, repeat, as often as necessary. In the Fibonacci example, the generator sub is [+], which is a shorthand for infix:+. So, after 1,1 the generator grabs the last two values (i.e. 1,1), adds them with infix:+, and puts 2 on the end of the list. Next time a value is needed, infix:+ grabs the final two list elements (now: 1,2), adds them, and appends 3 to the list. Et cetera, et cetera. For the use of ... to generate lists see: infix:..., the series operator under http://perlcabal.org/syn/S03.html#List_infix_precedence. For the [+] syntax, see http://perlcabal.org/syn/S03.html#Nesting_of_metaoperators PS: A really mean, but very effective, way of emphasizing the ease, expressiveness, compactness, and readability of Perl 6 code is to take each of the examples and show the same thing written in Java. ;-) It might be appropriate to compare some examples with Ruby or Python. Only if the comparisons are suitably invidious. ;-) Damian
Re: Amazing Perl 6
On Thu, May 28, 2009 at 1:37 AM, Daniel Carrera daniel.carr...@theingots.org wrote: Hi Damian, This is a really good list. Mind if I copy it / modify it and post it somewhere like my blog? One question: * Compactness of expression + semi-infinite data structures: �...@fib = 1,1...[+] # The entire Fibonacci sequence Very impressive. That's even shorter than Haskell. What's [+] ? How does this work? In Haskell: Start with the addition operator, '1 + 1'. Apply the reducing metaoperator to it so that it works syntactically like a function: '[+] 1, 1'. Instead of calling it, pass a code reference to it: '[+]'. The lazy list then uses that function to extend the list as needed. What I'm wondering is how the list knows to feed two items into '[+]'. While 'infix:+' must accept exactly two arguments, '[+]' can accept an arbitrarily long (or short) list of arguments. -- Jonathan Dataweaver Lang
Re: Amazing Perl 6
Jon Lang suggested: Start with the addition operator, '1 + 1'. Apply the reducing metaoperator to it so that it works syntactically like a function: '[+] 1, 1'. Instead of calling it, pass a code reference to it: '[+]'. No. [+] isn't the Code object for [+]; it's the Code object for infix:+. See http://perlcabal.org/syn/S03.html#Nesting_of_metaoperators What I'm wondering is how the list knows to feed two items into '[+]'. While 'infix:+' must accept exactly two arguments, '[+]' can accept an arbitrarily long (or short) list of arguments. And since [+] is infix:+, that's how it knows. :-) Damian
Re: Amazing Perl 6
So how is this: Any infix operator (except for non-associating operators) can be surrounded by square brackets in term position to create a list operator that reduces using that operation: reconciled with this: Any ordinary infix operator may be enclosed in square brackets with the same meaning ? And if [+] means infix:+, how do I refer to the Code of the list operator [+]?
Re: Amazing Perl 6
Mark J. Reed asked: So how is this: Any infix operator (except for non-associating operators) can be surrounded by square brackets in term position to create a list operator that reduces using that operation: reconciled with this: Any ordinary infix operator may be enclosed in square brackets with the same meaning The first refers to (meta)operators encountered where a term is expected; the second refers to operators encountered where an infix is expected (i.e. after a term). ? And if [+] means infix:+, how do I refer to the Code of the list operator [+]? prefix:[+] Damian
Re: Illustration of stuff we've been discussing
Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; which means that an array is, theoretically, an array of item containers. Consider the following: @a[1] = 0; @a[1] := 1; @a[1] = 2; The first line store 0 in the item container initially created at position 1 of array @a, the second line replaces that container by the value itself, and the third line fails because 1 is a readonly value, not a container, so you can't store into it. Of course this is the theoretical model, and implementations should optimize whenever they can... daniel
Re: Amazing Perl 6
Em Qui, 2009-05-28 às 21:36 +1000, Damian Conway escreveu: Mark J. Reed asked: ? And if [+] means infix:+, how do I refer to the Code of the list operator [+]? prefix:[+] Is that really? I mean... [ ] is a meta-operator, so [+] 1, 1, 2, 3 isn't a prefix, but a [ ] meta with + inside and the list as argument... daniel
Re: Amazing Perl 6
On Thu, May 28, 2009 at 8:43 AM, Daniel Ruoso dan...@ruoso.com wrote: Em Qui, 2009-05-28 às 21:36 +1000, Damian Conway escreveu: prefix:[+] Is that really? I mean... [ ] is a meta-operator, so [+] 1, 1, 2, 3 isn't a prefix, but a [ ] meta with + inside and the list as argument... The operator '[+]', which you get by applying the meta-operator '[...]' to the infix binary operator '+', is a prefix list operator. So that much makes sense. But I still think the two different meanings of square brackets in operators are going to confuse people. -- Mark J. Reed markjr...@gmail.com
New CPAN
Hello all,
There was some talk on IRC about a new version of CPAN to match the new
version of Perl.
Recap: wayland76 wants to integrate CPAN with the local package manager
(RPM, DEB). He proposed using Software::Package for that (which is
incomplete).
Now some ideas of my own:
A) Can we add version, target flags to CPAN metadata? I was thinking
that current modules would all be version=1 and target=perl5.
B) If we can, we can modify the cpan utility to run a different
program depending on the module version:
if (!$version or $version == 1) { system(cpan1 $module); }
else { system(cpan2 $module); }
So initially all modules go to the cpan1 program.
C) With this we are free to make a new CPAN format and a cpan2 install
script. We can upload the new modules to CPAN and the cpan script will
handle them correctly.
In other words: We don't need a new CPAN site. We can have two formats
in the same site. We just need a rule that a module can only depend on
modules with the same format.
Notice that Perl 5 authors can then also start using the new CPAN
format. They'd just set target=perl5.
All in all, I hope this would ease the migration to the new CPAN format.
D) In addition to target=perl5 and target=perl6 we could have target=parrot.
The CPAN user interface would have to be updated to allow two modules
with the same name but different targets.
E) With all this done, we can talk about the new CPAN package format. We
can use the alien utility (written in Perl) to finish the
Software::Package distribution (which currently only supports RPM).
F) In summary, we have a possible course of action:
1. Add version and target metadata to CPAN.
2. Write to the author of alien to see if he'll let us copy his code
under the Perl license.
3. Use alien to finish the Software::Package distribution, adding
support for at least DEB.
4. Use these to make a new CPAN format.
5. We can port Software::Package to Perl 6 and package them as a way to
test the new CPAN format with Perl 6.
...
What do you think?
Daniel.
Re: Illustration of stuff we've been discussing
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; Where in the synopses does it say anything like that is possible? := is applied to a _name_.
Re: Amazing Perl 6
On Wed, May 27, 2009 at 05:42:58PM -0500, John M. Dlugosz wrote: Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote: On Wed, May 27, 2009 at 6:05 PM, John M. Dlugosz 2nb81l...@sneakemail.com wrote: And APL calls it |¨ (two little dots high up) Mr. MacDonald just said upthread that the APL reduce metaoperator was spelled /. As in: +/1 2 3 6 So how does |¨ differ? Sorry, the two dots is APL's equivilent of the hyper operators, not the reduction operators. Easy to get those mixed up! For example, |1 2 3 ⍴¨ 10| would natively be written in Perl 6 as |10 »xx« (1,2,3)|. --John Yes. The full expression in raw APL for n! is: */in (where i is the Greek letter iota - iotan is Perl's 1..$n). Like many things in APL, having a 3-character combination of raw operators to provide a function makes creating a special operator unnecessary. (Although, if I recall correctly, there were also raw operators for combinatorial pick and choose, and factorial(n) is the same as choose(n,n) [or pick(n,n) whichever is the one the considers the order of the returned list to be significant] and factorial was actually returned if there was only one operand provided.)
Re: Amazing Perl 6
DC == Damian Conway dam...@conway.org writes:
DC * Grammars built into the language:
DC grammar Expr::Arithetic {
DC rule Expression { Mult ** $OP= + -}
DC rule Mult { Pow ** $OP= * / % }
DC rule Pow{ Term ** $OP= ^ }
DC token Term {
DC Literal
DC | '(' Expression ')'
DC }
DC token Literal { [+\-]? \d+ [ \. \d+ ]? }
DC }
DC * Grammar inheritance:
DC grammar Expr::Algebraic is Expr::Arithetic {
DC token Literal {
DC alpha+
DC | Expr::Arithetic::Literal
DC }
DC }
when i promote p6, the first and biggest thing i talk about
grammars. many of the other neat things (and damian listed a good bunch)
can be found in other langs or are nice but focused and small. p6
grammars are like nothing out there especially in any mainstream lang
today. and they are BIG in scope of what they can do. also they are very
accessible to newbies as they are based on the familiar regexes we all
use (and in almost all modern langs too). the mapping of grammar rules
to methods/subs and inheritance (which i generally despise but is
totally appropriate in grammars) is also amazing. now you can use
grammar libs and customize them as desired with little effort. before
this if you did have a grammar/parser (in any lang/system) you had to
learn its guts in detail before you dared to touch it. also grammars can
do dynamic things like build up a parsed data tree on the fly. you will
get what you expect (DWIM) with arrays of repeated grabbed sections
(properly nested as it follows your grammar). these are holy grails of
parsing and they come built in with incredible ease of use. note how
every other lang claims a perl5 compatible regex engine (and they lie as
none can do s///e among other things :). now with p6 they will never be
able to copy its grammars as it is a core part of p6 and not some regex
lib.
so you can talk about this amazing feature and be assured that the
audience will be amazed. :)
thanx,
uri
--
Uri Guttman -- u...@stemsystems.com http://www.sysarch.com --
- Perl Code Review , Architecture, Development, Training, Support --
- Free Perl Training --- http://perlhunter.com/college.html -
- Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090528 14:18]: There was some talk on IRC about a new version of CPAN to match the new version of Perl. In March 2006, Sam Vilain and I started to think about a new CPAN what we named CPAN6. There is a lot of information about the project on http://cpan6.org You can see there that a lot of work has been doen. Core Perl people did really discourage me by continuously debating about the name of the project, instead of helping to implement it. But now other people start to wake up, it might get back on track. Recap: wayland76 wants to integrate CPAN with the local package manager (RPM, DEB). He proposed using Software::Package for that (which is incomplete). Be aware that there are confusing entanglements in the current set-up. Firstly, you have the CPAN archive, which uses Pause as entry point and ftp-servers to distribute the accepted distributions. Secondly, you need local configuration tools to get distributions installed on the right spot. That differs per platform. And sometimes people install for instance under usernames, not system-wide. This is the playfield of CPAN.pm and CPANPLUS. For instance compiling XS, discovering libraries, ... Then, you have the administration on what is installed. Basically, that is what RPM/DEB packages think is interesting. CPAN6 is a possible alternative to the first (the CPAN archive), but improving on the second by allowing advanced (server side) searches. Perl's installation tools have a very limited knowledge... much less than search.cpan.org. A) Can we add version, target flags to CPAN metadata? I was thinking that current modules would all be version=1 and target=perl5. CPAN does not have an official concept of version numbers on distributions, but only on the pm files which are inside the distribution. The 02packages list which is used to lookup dependencies converts pm-file $VERSION into distribution names which accidentally contain a number. The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). So the whole concept of installation has to change into something more modern. D) In addition to target=perl5 and target=perl6 we could have target=parrot. IMO, we need many more. What you call target is actually a namespace. The current CPAN archive has only one target. But with Perl6, we have a need for perl6 distributions, but also the pre-compiled versions of these modules, for PIR, pasm, pieton, and whatever languages we will develop based on Parrot. And... maybe deb and rpm archives which (semi-)automatically provide repackaged versions of modules which arrive in the perl6 archive. CPAN6 can do all that in a rather simple way. E) With all this done, we can talk about the new CPAN package format. We can use the alien utility (written in Perl) to finish the Software::Package distribution (which currently only supports RPM). CPAN6's opinion: it distributes releases (Perl5 terminologie: a distribution) which simply is a set of files. During transport, they may get packed together (with f.i. tar) and compressed (with f.i. gzip), but that is unimportant. Whether only a single file is shipped (like a single tar.gz prepared by the author) or many does not matter. So: a minimal installation tool does not need Archive::Tar and a zillion of other core modules in my design. F) In summary, we have a possible course of action: There is a lot more structurally problematic. Please read one of my papers on the cpan6.org website. I am looking forward to meet people who have read my design documents, and understand that there is more to it than let's discuss about the project name. There is at least 40k lines of Perl code already waiting to be used for this task. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
RFC: How does using CPAN with Perl 6 would look like (Was: Re: New CPAN)
Em Qui, 2009-05-28 às 16:18 +0200, Daniel Carrera escreveu: Hello all, There was some talk on IRC about a new version of CPAN to match the new version of Perl. I just wanted to point out some previous conclusion on this issue. What currently we generically name CPAN is actually composed of: 1 - A repository for source archives 2 - A build-system (ExtUtils::MAkeMaker, Module::Build) For Perl 6, there is already some kind of consensus that we need an architecture that goes in the following lines 1 - A repository for source archives (that's markov's CPAN6) 2 - An abstract representation for the source's metadata (describing what the archive has, instead of how to build and install) 3 - A per-implementation per-architecture infra-estructure that knows how to take this abstract metadata and build a installable package (for that implementation and architecture) 4 - A per-implementation per-architecture package manager (in some cases the native package manager can be used) that install and handles dependencies of installable packages. So, a regular scenario would look like: 1 - You search for something, find Some::Module and download Some-Module-0.1.tar.gz it from CPAN6 2 - Some-Module-0.1.tar.gz contains a META.yml like file containing a description of what composes this archive 3 - You run rakudo-build Some-Module-0.1.tar.gz if you're in rakudo or smop-build Some-Module-0.1.tar.gz if you're in smop. If you're in a Debian machine that should build libsome-module-parrot_0.1_i386.deb or libsome-module-smop_0.1_i386.deb. 4 - As in the Debian case, you would use the native package manager, you could simply apt-get install libsome-module-rakudo (considering the above step put the file in a local repo, as apt-build does today). If you're in Win32, a package manager is probably going to written so you can install the 'installable' package in a similar manner. daniel
Re: Illustration of stuff we've been discussing
Em Qui, 2009-05-28 às 09:27 -0500, John M. Dlugosz escreveu: Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; Where in the synopses does it say anything like that is possible? := is applied to a _name_. I don't recall if it is in the synopsis... but it is a general expectation, and, I think, this was discussed in IRC for a long time. But certainly is a good time to either put on the spec or drop the expectation... daniel
Re: New CPAN
Mark Overmeer wrote: In March 2006, Sam Vilain and I started to think about a new CPAN what we named CPAN6. There is a lot of information about the project on http://cpan6.org I know about CPAN6, thanks. It's come up a couple of times on IRC. Perhaps you could hang out on the IRC channel so we don't have different people going off in different directions with CPAN. Core Perl people did really discourage me by continuously debating about the name of the project, instead of helping to implement it. I can see how this could be a point of contention. If I made a website called gimp3.org I'd expect some flack from the Gimp people. A) Can we add version, target flags to CPAN metadata? I was thinking that current modules would all be version=1 and target=perl5. CPAN does not have an official concept of version numbers on distributions, but only on the pm files which are inside the distribution. I know, thanks. I was suggesting a change. The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). Why? D) In addition to target=perl5 and target=perl6 we could have target=parrot. IMO, we need many more. What you call target is actually a namespace. The current CPAN archive has only one target. Target, namespace, same difference. It's an identifier to divide modules into categories. F) In summary, we have a possible course of action: There is a lot more structurally problematic. Please read one of my papers on the cpan6.org website. I have scanned through the first one. It's 30 pages... Daniel.
Re: Amazing Perl 6
On Thu, May 28, 2009 at 10:51:33AM -0400, John Macdonald wrote: : Yes. The full expression in raw APL for n! is: : : */in : : (where i is the Greek letter iota - iotan is Perl's 1..$n). Only if the origin is 1. This breaks under )ORIGIN 0. cough $[ /cough By the way, the assumption here is that everyone can process Unicode, so it's fine to write */⍳n. :) Note that that's the APL iota U+2373, not any of the other 30 or so iotas in Unicode. :/ Well, okay, half of those have precomposed accents, but still... Larry
Re: Amazing Perl 6
On Thu, May 28, 2009 at 09:43:58AM -0400, Mark J. Reed wrote: : So that much makes sense. But I still think the two different : meanings of square brackets in operators are going to confuse people. You're welcome to introduce more bracketing characters into ASCII. :P But seriously, this is one of those tagmemics things, where an A can be *used* as a B without actually being one. (For example, a noun can be used as a verb.) I think of [op] is the unambiguous name of an infix operator (bare op is of course useful when unambiguous), and [op] can be *used* as a prefix operator, or as the short name of the function when prefixed by the noun marker . Note that when you say func() you are, in fact, using the noun func as a verb. Anyway, I suspect people are generally pretty good at differentiating such things from the visual context. Larry
r26953 - docs/Perl6/Spec
Author: lwall
Date: 2009-05-28 18:55:52 +0200 (Thu, 28 May 2009)
New Revision: 26953
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05] document use of #= tags in {*} actions
Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod 2009-05-28 07:40:29 UTC (rev 26952)
+++ docs/Perl6/Spec/S05-regex.pod 2009-05-28 16:55:52 UTC (rev 26953)
@@ -3723,21 +3723,33 @@
Whenever a closure within the grammar returns a CWhatever object, the
grammar engine tries to call a method of the same name as the name of the
-current regex on the action object, passing along the current Match object as
-the first positional argument.
+current regex on the action object, passing along the current CMatch object
as
+the first positional argument, and the tag of the reduction (if any) as the
second
+argument. The tag is supplied via a C#= comment on the same line as the
C{*}.
grammar Integer {
token TOP {
- \d+ {*}
+ | 0b[01]+ {*} #= binary
+ | \d+ {*} #= decimal
}
}
class Twice {
- method TOP($/) {
- make 2 * $/;
+ multi method TOP($match, $tag) {
+ my $text = ~$match;
+ $text = :2($text) if $tag eq 'binary'
+ make $text;
}
+ multi method TOP($match) {
+ make 2 * $match.ast;
+ }
}
Integer.parse('21', :action(Twice.new)).ast # 42
+A C{*} is assumed at the end of every rule, and the method is
+called with no tag argument. Note that the implicit C{*} is
+Ioutside the alternation in the CTOP rule above, despite
+the fact that no explicit square brackets were used.
+
=back
=head1 Syntactic categories
r26954 - docs/Perl6/Spec
Author: lwall
Date: 2009-05-28 19:37:18 +0200 (Thu, 28 May 2009)
New Revision: 26954
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05] clarify #= tags as suggested by [particle]++
Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod 2009-05-28 16:55:52 UTC (rev 26953)
+++ docs/Perl6/Spec/S05-regex.pod 2009-05-28 17:37:18 UTC (rev 26954)
@@ -14,8 +14,8 @@
Maintainer: Patrick Michaud pmich...@pobox.com and
Larry Wall la...@wall.org
Date: 24 Jun 2002
- Last Modified: 8 May 2009
- Version: 97
+ Last Modified: 28 May 2009
+ Version: 98
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them Iregex rather than regular
@@ -3723,9 +3723,11 @@
Whenever a closure within the grammar returns a CWhatever object, the
grammar engine tries to call a method of the same name as the name of the
-current regex on the action object, passing along the current CMatch object
as
-the first positional argument, and the tag of the reduction (if any) as the
second
-argument. The tag is supplied via a C#= comment on the same line as the
C{*}.
+current regex on the action object, passing along the current CMatch
+object as the first positional argument, and the tag of the reduction (if
+any) as the second argument. The tag is supplied via a C#= comment later
+on the same line as the C{*}. there must be whitespace between the C#=
+and the tag, but the tag itself may contain spaces.
grammar Integer {
token TOP {
r26955 - docs/Perl6/Spec
Author: lwall
Date: 2009-05-28 19:54:45 +0200 (Thu, 28 May 2009)
New Revision: 26955
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
typo
Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod 2009-05-28 17:37:18 UTC (rev 26954)
+++ docs/Perl6/Spec/S05-regex.pod 2009-05-28 17:54:45 UTC (rev 26955)
@@ -3726,7 +3726,7 @@
current regex on the action object, passing along the current CMatch
object as the first positional argument, and the tag of the reduction (if
any) as the second argument. The tag is supplied via a C#= comment later
-on the same line as the C{*}. there must be whitespace between the C#=
+on the same line as the C{*}. There must be whitespace between the C#=
and the tag, but the tag itself may contain spaces.
grammar Integer {
Re: Amazing Perl 6
On Thu, May 28, 2009 at 09:30:25AM -0700, Larry Wall wrote: On Thu, May 28, 2009 at 10:51:33AM -0400, John Macdonald wrote: : Yes. The full expression in raw APL for n! is: : : */in : : (where i is the Greek letter iota - iotan is Perl's 1..$n). Only if the origin is 1. This breaks under )ORIGIN 0. cough $[ /cough Yep. That was why I was comfortable playing with $[ when it first came along in early perl (wow, you can set the origin to any value, not just 0 or 1 - now that's progress). By the way, the assumption here is that everyone can process Unicode, so it's fine to write */⍳n. :) That's correct (in my case at least) if process means accept and display properly. However, the assumption fails if process is supposed to mean that everyone is capable of generating Unicode in the messages that they are writing. I don't create non-English text often enough to have it yet be useful to learn how. (I'd just forget faster than I'd use it and have to learn it again each time - but Perl 6 might just be the tipping point to make learning Unicode composition worthwhile.) Note that that's the APL iota U+2373, not any of the other 30 or so iotas in Unicode. :/ Well, okay, half of those have precomposed accents, but still... Larry
Re: Amazing Perl 6
Since when are we limited to ASCII again? :) If this is just a question of prefix vs infix telling you what [+] is shorthand for, OK. But it seems there's still scope for conflict between the two meanings of the square brackets. I mean, prefix ops can be used in reduce, too, right? Tagentially related: why doesn't simple + or + work for what we're currently spelling [+] (and which is more specifically spelled infix:+)? On 5/28/09, Larry Wall la...@wall.org wrote: On Thu, May 28, 2009 at 09:43:58AM -0400, Mark J. Reed wrote: : So that much makes sense. But I still think the two different : meanings of square brackets in operators are going to confuse people. You're welcome to introduce more bracketing characters into ASCII. :P But seriously, this is one of those tagmemics things, where an A can be *used* as a B without actually being one. (For example, a noun can be used as a verb.) I think of [op] is the unambiguous name of an infix operator (bare op is of course useful when unambiguous), and [op] can be *used* as a prefix operator, or as the short name of the function when prefixed by the noun marker . Note that when you say func() you are, in fact, using the noun func as a verb. Anyway, I suspect people are generally pretty good at differentiating such things from the visual context. Larry -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Amazing Perl 6
On Thu, May 28, 2009 at 02:55:10PM -0400, Mark J. Reed wrote: : Since when are we limited to ASCII again? :) Well, we used some of Latin-1's bracket offerings, and people already carp about that. :) : If this is just a question of prefix vs infix telling you what [+] is : shorthand for, OK. But it seems there's still scope for conflict : between the two meanings of the square brackets. I mean, prefix ops : can be used in reduce, too, right? I will let you ponder the meaning of reduce a bit more, and the relationship of that to the respective arity of infixes vs prefixes. We already have hyper prefixes, if that's what you're thinking... : Tagentially related: why doesn't simple + or + work for what we're : currently spelling [+] (and which is more specifically spelled : infix:+)? Because it would conflict with twigils and such, not to mention alphabetic infixes. What would xx mean? Larry
Re: Amazing Perl 6
On Thu, May 28, 2009 at 02:55:10PM -0400, Mark J. Reed wrote: : Tagentially related: why doesn't simple + or + work for what we're : currently spelling [+] (and which is more specifically spelled : infix:+)? Oh, and why not +? Mainly because we have lots of infix operators containing and , but none containing [ and ], so we use [...] to disambiguate infixes already in things like [X]=. So reusing square brackets for [+] and [+] is deemed to be a good thing. But also because foo would mean ($/foo). [op] is a special form, so it can get away with parsing it's innards specially, whereas infix:op is not a special form, insofar as all adverbials are parsed similarly, and infix:['op'] therefore requires quotes, which is going the wrong direction when you're looking for a shortcut. People will get used to seeing [+] and thinking infix, whereas + would always be causing double-takes by its similarity to = and such. Larry
Re: Amazing Perl 6
On Thu, May 28, 2009 at 3:13 PM, Larry Wall la...@wall.org wrote: : I mean, prefix ops can be used in reduce, too, right? I will let you ponder the meaning of reduce a bit more, and the relationship of that to the respective arity of infixes vs prefixes. Well, infixes are necessarily binary, but while prefixes tend to be slurpy, I was thinking one could also declare a prefix op with a finite arity. And does [...] only reduce if what's inside is an operator? How do you do a reduce using a plain old binary subroutine? -- Mark J. Reed markjr...@gmail.com
Re: Amazing Perl 6
On Thu, May 28, 2009 at 03:33:34PM -0400, Mark J. Reed wrote: : On Thu, May 28, 2009 at 3:13 PM, Larry Wall la...@wall.org wrote: : : I mean, prefix ops can be used in reduce, too, right? : : I will let you ponder the meaning of reduce a bit more, and the : relationship of that to the respective arity of infixes vs prefixes. : : Well, infixes are necessarily binary, but while prefixes tend to be : slurpy, I was thinking one could also declare a prefix op with a : finite arity. Well, sure, but we de-emphasize that arity when parsing anyway for consistency. All listop-y operators parse infinite args, even if none of the candidates can handle them. And if the prefix is declared slurpy, you'd just call it directly on the arg list, I'd think, since it already has its own idea of reduction built in. : And does [...] only reduce if what's inside is an : operator? Yes, only operator, but including user-defined operators (unlike APL). : How do you do a reduce using a plain old binary subroutine? For the general form, [+] @x is equivalent to reduce [+], @x (Which is another good reason to keep the [+] form.) Note that the first arg to reduce is simply a noun, so forgetting the as in: reduce foo, @x would be an error. Unless foo returns something Callable, of course. But the user probably meant: reduce foo, @x. So just as turns the foo verb into a noun, it turns the [+] verb into a noun. Larry
Re: New CPAN
Jonathan Scott Duff wrote: See http://perlcabal.org/syn/S11.html#Versioning Yeah, I reached that part earlier today (but after I sent my email). Thanks. Daniel.
Re: Amazing Perl 6
Daniel Ruoso asked: prefix:[+] Is that really? I mean... [ ] is a meta-operator, Sure. But once you []-meta an infix operator, you get a prefix operator. See http://perlcabal.org/syn/S03.html#Reduction_operators, which states: Any infix operator (except for non-associating operators) can be surrounded by square brackets in term position to create a list operator and has an example of actually implementing the prefix:[+] operator. Damian
Re: The game of life
If anyone wants to try tackling this, a longer APL one-liner is referenced on the APL wikipedia page and discussed in length here: http://catpad.net/michael/apl/ As an aside, APL was the first computer language I was exposed to. When I was around 7 years old my aunt (who lived in Boston near MIT, Harvard) had a computer scientist friend who gave her the APL: A Programming Language book, after she bragged to him about a smart nephew who liked typewriters... I liked all the symbols and sort of understood a few bits of it...
Re: The game of life
And a link explaining the shorter one-liner: http://aplwiki.com/GameOfLife
Re: New CPAN
Daniel Carrera wrote: Mark Overmeer wrote: The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). Why? Because we need things to work effectively in the general case where what was originally a single module Foo with one name becomes forked with each creator (authority) going off in their own direction, or alternately the creator makes incompatible changes, and then later someone's project Bar may have a bunch of dependencies A and B where A depends on one version of Foo and B depends on an incompatible version of Foo; then both versions of Foo need to work together. And that's just one reason to have this support. -- Darren Duncan
Re: New CPAN
Darren Duncan wrote: Because we need things to work effectively in the general case where what was originally a single module Foo with one name becomes forked with each creator (authority) going off in their own direction, or alternately the creator makes incompatible changes, and then later someone's project Bar may have a bunch of dependencies A and B where A depends on one version of Foo and B depends on an incompatible version of Foo; then both versions of Foo need to work together. And that's just one reason to have this support. -- Darren Duncan Yeah. At the time I wrote that I hadn't yet read S11. The new CPAN needs to handle all the metadata in S11. use Whiteness:fromperl5 Acme::Bleach 1.12 cpan:DCONWAY; So we have to give some thought to how the modules are going to be stored in the system. Daniel. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: The game of life
y == yary not@gmail.com writes: y If anyone wants to try tackling this, a longer APL one-liner is y referenced on the APL wikipedia page and discussed in length here: y http://catpad.net/michael/apl/ y As an aside, APL was the first computer language I was exposed to. y When I was around 7 years old my aunt (who lived in Boston near MIT, y Harvard) had a computer scientist friend who gave her the APL: A y Programming Language book, after she bragged to him about a smart y nephew who liked typewriters... I liked all the symbols and sort of y understood a few bits of it... you must not realize that we have our own conway (part of the p6 design cabal) in the perl world who has coded up in perl5 something that should not have been released on a unsuspecting world. it is a monster called selfgol and it not only plays life, it does much more. here is a wiki entry about it. read the code at your own peril. if this gets translated to p6 (and probably become much shorter too), i suspect the heavens will fall, the sun will burn out and python will take over the universe! :) http://www.perlfoundation.org/perl5/index.cgi?selfgol from that page: * Its a quine (typo - should be It's - uri) * Turns other programs into quines * Plays Conway's Game of Life * Animates a marquee banner It does so without importing any modules, and without using a single if, unless, while, until, for, foreach, goto, next, last, redo, map, or grep. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
[RFC] CPAN6 requirements analysis
While lurking in IRC, I've seen several discussions of what CPAN 6 should look like. Honestly, wayland76++'s idea for packaging seems the best to me. Most of the suggestions so far, especially those based on alien, apt, yum, or other existing package managers have a few major problems: * Alien only converts between a few package formats * All of these suggestions are _heavily_ biased towards binary distributions * These suggestions make automatic packaging for new distros extremely difficult, because they require major changes to multiple projects For example, let's take Gentoo or Exherbo. Gentoo has two package managers, one which is used by most Gentoo users (Portage) and one which is more featureful and advances faster (for various reasons, including more developers) (Paludis). Portage supports binary packages through .tbz2 files with trailing metadata. Paludis does not support these, as they have been deemed ill-conceived and poorly implemented by the lead developer, and is working on its own binary package system. Exherbo uses Paludis exclusively. Both distros are source-based. Paludis has a tool which can import arbitrary trees to merge into the filesystem, but it's generally preferred that it be used only by users, not system packagers. Portage has no such tool. One existing problem for Gentoo is supporting installation of Perl 5 modules. Because all metadata is spread out (and more importantly, /inside/ the tarballs), it is impossible to, say, add a new kind of repository for Perl modules - you'd have to have the full source for every module on your machine. Similarly, the automatic ebuild creator for P5 modules, g-cpan, is forced to recursively download packages, unpack them, and read their metadata before fetching their dependencies. This poses a significant problem for distros which mandate up-front configuration without an interactivity requirement (i.e., Exherbo and to a lesser degree Gentoo). I think that wayland76++'s idea of having a common metadata system with filters to convert that metadata into a distribution package is the best currently-proposed solution, but I also feel that it needs some additional extension. I personally believe that there are a few requirements for a package format that is sufficient for Perl 6: * It must enable packaging for both binary- and source-based distros * It must enable automatic generation of packages for supported systems (although it may well not be capable of it out of the box) * It must permit (or preferably help with) attempts to support new systems * It must be simple to submit packages in the correct format * It must enable the design and building of an automatic testing system My extensions to wayland76++'s proposal are as follows: * Include in the metadata enough information to: * Build a binary package ( deb, rpm, etc) * Create a source build script ( ebuild, exheres, PKGBUILD, etc) * Fetch the source package * Contact maintainer/author/etc with issues * Query stability information * Prod the testing framework (not the actual tests, though) * Separate the metadata from the package * If the metadata is in the source distribution, have CPAN 6 extract it, and put it in a separate tree of just metadata * This enables simple fetching of the entire /metadata/ tree without the entire /source/ tree * Also opens the door to package managers natively supporting this format (Paludis has done this with CRAN and is working on Ruby Gems support) * Have well-documented example filters, and a skeleton-filter-builder script * Enables packaging developers to rapidly roll out support for new systems * Encourage use of pure-P6 filters, so as to enable cross-distro mantainership * Like building Fedora packages on the developer's Debian workstation * Multiple submission avenues * Simple login-controlled FTP * Web submission * PAUSE-like client * Hosted SCM source w/tagging Comments?
Re: [RFC] CPAN6 requirements analysis
Hi Alex, I hve comments. Alex Elsayed wrote: While lurking in IRC, I've seen several discussions of what CPAN 6 should look like. Honestly, wayland76++'s idea for packaging seems the best to me. Most of the suggestions so far, especially those based on alien, apt, yum, or other existing package managers have a few major problems: * Alien only converts between a few package formats * All of these suggestions are _heavily_ biased towards binary distributions * These suggestions make automatic packaging for new distros extremely difficult, because they require major changes to multiple projects * We were mainly looking at Alien as a source of Perl code we could borrow. * The point of wayland76's proposal was to use the local package manager. Whether the local package manager is geared toward binary distributions is a separate issue. At first I liked wayland76's proposal, but now I have a new concern: Most package managers are not designed to hold multiple versions of the same package. As indicated in S11, it is important that a computer can hold multiple versions of the same package. I fear that using the native package manager will make this difficult. * Separate the metadata from the package * If the metadata is in the source distribution, have CPAN 6 extract it, and put it in a separate tree of just metadata * This enables simple fetching of the entire /metadata/ tree without the entire /source/ tree This is something I agree with. It seems smart to be able to download the metadata before downloading the source tree. This allows dependency resolution, searches, etc. Daniel.
Re: [RFC] CPAN6 requirements analysis
On Fri, May 29, 2009 at 01:04:28AM +0200, Daniel Carrera wrote: Hi Alex, I hve comments. Alex Elsayed wrote: While lurking in IRC, I've seen several discussions of what CPAN 6 should look like. Honestly, wayland76++'s idea for packaging seems the best to me. Most of the suggestions so far, especially those based on alien, apt, yum, or other existing package managers have a few major problems: * Alien only converts between a few package formats * All of these suggestions are _heavily_ biased towards binary distributions * These suggestions make automatic packaging for new distros extremely difficult, because they require major changes to multiple projects * We were mainly looking at Alien as a source of Perl code we could borrow. * The point of wayland76's proposal was to use the local package manager. Whether the local package manager is geared toward binary distributions is a separate issue. I support the notion of distributing binaries because nobody's gonna want to chew up their phone's battery doing unnecessary compiles. The ecology of computing devices is different from ten years ago. At first I liked wayland76's proposal, but now I have a new concern: Most package managers are not designed to hold multiple versions of the same package. As indicated in S11, it is important that a computer can hold multiple versions of the same package. I fear that using the native package manager will make this difficult. Most of these package managers have ways of running an installation script at the end, so we could perhaps think of this as downloading an installer rather than the actual software, and the new version of the installer contains or has access to all the versions it knows should be installed, and interacts with the official Perl library installer to install them. * Separate the metadata from the package * If the metadata is in the source distribution, have CPAN 6 extract it, and put it in a separate tree of just metadata * This enables simple fetching of the entire /metadata/ tree without the entire /source/ tree This is something I agree with. It seems smart to be able to download the metadata before downloading the source tree. This allows dependency resolution, searches, etc. By the same token, it's smart to keep the metadata close to the thing it's describing, so if it's easy to extract up front reliably, that's probably sufficient. Larry
Re: [RFC] CPAN6 requirements analysis
On Thursday 28 May 2009 4:04:28 pm Daniel Carrera wrote: * We were mainly looking at Alien as a source of Perl code we could borrow. Ah, I was lumping it in with the previous proposals to actually use .deb as the official P6 package format. My mistake. * The point of wayland76's proposal was to use the local package manager. Whether the local package manager is geared toward binary distributions is a separate issue. Again, my point on the issue of supporting binary/source distros was that wayland76's proposal /would/ be able to handle it properly; the '.deb as official' method would not. At first I liked wayland76's proposal, but now I have a new concern: Most package managers are not designed to hold multiple versions of the same package. As indicated in S11, it is important that a computer can hold multiple versions of the same package. I fear that using the native package manager will make this difficult. This could probably be resolved, but it would probably require distro-specific code. On Gentoo, the way to do it would be with 'slots', which are specifically designed for that use; on Debian, it would seem that the names would have to be distinguished by an identifier, allowing multiple versions.
Re: Illustration of stuff we've been discussing
On Thu, May 28, 2009 at 01:06:18PM -0300, Daniel Ruoso wrote: : Em Qui, 2009-05-28 às 09:27 -0500, John M. Dlugosz escreveu: : Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: : Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: : Please see http://www.dlugosz.com/Perl6/web/info-model-1.html : and talk to me about it. : The illustratino is cool, but it doesn't take into account the : possibility of: :@a[0] := $x; : Where in the synopses does it say anything like that is possible? := is : applied to a _name_. : : I don't recall if it is in the synopsis... but it is a general : expectation, and, I think, this was discussed in IRC for a long time. : But certainly is a good time to either put on the spec or drop the : expectation... It pretty much has to be that way, if we want to represent lexical pads with built-in data types. Our symbol tables are simply hashes, for instance. (There may be many pads corresponding to a given lexical symbol table, however, since all clones of a closure share a single symbol table but each have their own pad of values.) Basically, (ignoring STD's definition of name) I view @a[0] as a name, in the sense of identifying a unique object. It just happens to contain navigational elements like a URL. Of course, if @a is declared to hold only a compact array of native types, binding a pointer into one of the entries isn't going to fly. But we're defining the differences between the behavior of $a and @a in terms of how it desugars in context, so there's no need for the actual binding to distinguish any extra levels of indirection. All it needs to know is where to poke the pointer to the object. And normally @a contains a list of poke-able pointers, so @a[0] := $x is fair game. Larry
Re: [RFC] CPAN6 requirements analysis
On Thursday 28 May 2009 4:22:00 pm Larry Wall wrote: I support the notion of distributing binaries because nobody's gonna want to chew up their phone's battery doing unnecessary compiles. The ecology of computing devices is different from ten years ago. I agree. My ideal situation would be that CPAN6 offers multiple 'heads' - one might be a raw metadata store; another might be a Debian/Ubuntu style PPA provider, possibly building (.deb|.rpm)s when uploaded, or in a distributed CPANTS-like fashion. Most of these package managers have ways of running an installation script at the end, so we could perhaps think of this as downloading an installer rather than the actual software, and the new version of the installer contains or has access to all the versions it knows should be installed, and interacts with the official Perl library installer to install them. This has the potential for greatly angering users and distro packagers: a major reason people use package managers is that they maintain a database of what files were installed, when, and by what package. If you use post-install hooks, many package managers won't have that information, making uninstallation a nightmare. By the same token, it's smart to keep the metadata close to the thing it's describing, so if it's easy to extract up front reliably, that's probably sufficient. Again, agreed. That would fall under the easy to submit well-formed packages requirement in my mail. In fact, it could even still be a Meta.yml file in the source distribution - it could be up to CPAN6 to extract it for external access when the distribution is uploaded.
Re: [RFC] CPAN6 requirements analysis
Larry Wall wrote: I support the notion of distributing binaries because nobody's gonna want to chew up their phone's battery doing unnecessary compiles. The ecology of computing devices is different from ten years ago. By binaries, I assume you mean native binaries, as opposed to Parrot bytecode. The only problem I see is that it may be impractical to ask CPAN mirrors to hold multiple binaries of each module for every OS and every CPU. On the other hand, distributing Parrot bytecode (or PIR, or PASM) seems fine. But I don't know what to suggest for modules that require a C compiler. Most of these package managers have ways of running an installation script at the end, so we could perhaps think of this as downloading an installer rather than the actual software, and the new version of the installer contains or has access to all the versions it knows should be installed, and interacts with the official Perl library installer to install them. I suggested something similar to wayland76 a couple of days ago, to solve a different problem. If I remember correctly, he was concerned about the local package manager not knowing which files were installed. Perhaps we should revisit this idea. This is what I proposed: We have our own package manager (e.g. /usr/bin/cpan6 ) that takes a .tgz file with an appropriate format: /usr/bin/cpan6 install Foo-Bar.tgz The RPM Foo-Bar.rpm would contain Foo-Bar.tgz and the rpm install script would simply run cpan6 install Foo-Bar.tgz. When the Fedora user uninstall the module, rpm runs a script which just calls cpan6 uninstall Foo::Bar. By the same token, it's smart to keep the metadata close to the thing it's describing, so if it's easy to extract up front reliably, that's probably sufficient. Yes. Daniel.
Re: The game of life
yary not.com-at-gmail.com |Perl 6| wrote: If anyone wants to try tackling this, a longer APL one-liner is referenced on the APL wikipedia page and discussed in length here: http://catpad.net/michael/apl/ As an aside, APL was the first computer language I was exposed to. When I was around 7 years old my aunt (who lived in Boston near MIT, Harvard) had a computer scientist friend who gave her the APL: A Programming Language book, after she bragged to him about a smart nephew who liked typewriters... I liked all the symbols and sort of understood a few bits of it... I came upon a copy of A Programming Language in a similar way. My Dad passed it on from a co-worker. I don't recall how young I was, but it was a very interesting read. Perhaps this attracts youngsters because of the strange letters?
Re: [RFC] CPAN6 requirements analysis
On Thursday 28 May 2009 4:54:50 pm Daniel Carrera wrote: On the other hand, distributing Parrot bytecode (or PIR, or PASM) seems fine. But I don't know what to suggest for modules that require a C compiler. The problem with that is that Rakudo isn't the Official impelentation, and never will be. Distributing modules as Parrot bytecode would lock out other implementations, something that is very strongly discouraged. Also, I think Larry may have meant the compiled form of whatever the P6 equivalent of XS is, since Perl is largely designed as a scripting (or at least scripting-ish) language and therefore might lose more than it gains by precompiling the /Perl/ code rather than just the C/C++/etc. I suggested something similar to wayland76 a couple of days ago, to solve a different problem. If I remember correctly, he was concerned about the local package manager not knowing which files were installed. Perhaps we should revisit this idea. This is what I proposed: We have our own package manager (e.g. /usr/bin/cpan6 ) that takes a .tgz file with an appropriate format: /usr/bin/cpan6 install Foo-Bar.tgz The RPM Foo-Bar.rpm would contain Foo-Bar.tgz and the rpm install script would simply run cpan6 install Foo-Bar.tgz. When the Fedora user uninstall the module, rpm runs a script which just calls cpan6 uninstall Foo::Bar. The issue with that goes somewhat farther than just the package manager doesn't know what's there. Package managers provide several important features that would be rendered near-useless by that model: * Collision detection - It becomes impossible to prevent another package from overwriting a file installed this way * Linkage checking - If a library interface breaks compatibility, then binaries installed this way will not be detected when sweeping installed packages to fix linkage * Programmatic generation of binary packages for hybrid distributions [1] * Recording the attributes (permissions, etc) of installed packages, so they can be fixed if changed inappropriately * Source-based distributions which give the user the option of enabling/disabling tests selectively lose that ability (Gentoo, Exherbo) [1]: This is a footnote because it'll take a paragraph. In Gentoo (and when their binary package format is stabilized, Exherbo) binary packages are generated by invoking the package manager with specific options. With Portage (Gentoo only), the --buildpkg[[only]?] flag determines this, while with Paludis (Gentoo and Exherbo) it is accomplished by 'installing' to a binary repository. The system you describe makes this model impossible.
Re: Illustration of stuff we've been discussing
Larry Wall larry-at-wall.org |Perl 6| wrote: Basically, (ignoring STD's definition of name) I view @a[0] as a name, in the sense of identifying a unique object. It just happens to contain navigational elements like a URL. OK, that that might be what was meant in the synopses when it was penned 9 years ago, before formal terminology was better fixed. Of course, if @a is declared to hold only a compact array of native types, binding a pointer into one of the entries isn't going to fly. One of my thoughts, exactly. But we're defining the differences between the behavior of $a and @a in terms of how it desugars in context, so there's no need for the actual binding to distinguish any extra levels of indirection. All it needs to know is where to poke the pointer to the object. And normally @a contains a list of poke-able pointers, so @a[0] := $x is fair game. And if $x is the wrong type, it errors. So if @a is the wrong type in a larger sense of not being able to support that, it errors. E.g. it is a compact array, or some user-defined collection, or is otherwise read-only. --John
Re: Illustration of stuff we've been discussing
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; which means that an array is, theoretically, an array of item containers. Consider the following: @a[1] = 0; @a[1] := 1; @a[1] = 2; Syntax aside, and what the spec actually says about := aside, I do agree that a container must be able to cough up an lvalue for any of its addressable content individually. That works (in this model) because of how items are intimatly tied with lvalues, and the way parameters are bound and what declaring an lvalue return does (returning is the same as passing, as they are both Captures). Anyway, I'll explain my thoughts on that in detail this weekend. --John
Re: Amazing Perl 6
Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote: So that much makes sense. But I still think the two different meanings of square brackets in operators are going to confuse people. I agree. The previously quoted passages in the synopses are confusing, too, since it doesn't make the context clear. If you find the shorthand too confusing, write it out as infix+ instead. Perl can do solid software engineering as well as one-liners. --John
Re: Amazing Perl 6
John Macdonald john-at-perlwolf.com |Perl 6| wrote: However, the assumption fails if process is supposed to mean that everyone is capable of generating Unicode in the messages that they are writing. I don't create non-English text often enough to have it yet be useful to learn how. (I'd just forget faster than I'd use it and have to learn it again each time - but Perl 6 might just be the tipping point to make learning Unicode composition worthwhile.) Just copy/paste from another message or a web page. Perhaps a web page designed for that purpose...
Re: Illustration of stuff we've been discussing
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 09:27 -0500, John M. Dlugosz escreveu: Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: Please see http://www.dlugosz.com/Perl6/web/info-model-1.html and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; Where in the synopses does it say anything like that is possible? := is applied to a _name_. I don't recall if it is in the synopsis... but it is a general expectation, and, I think, this was discussed in IRC for a long time. But certainly is a good time to either put on the spec or drop the expectation... daniel I agree with you there. This Information Model will handle putting an Item Container into a primitive slot in a collection, and it just works after that. This seems to be a useful way of pinning down the abilities and limitations of iterators and modifying containers while iterating on them, in a way that is implementation-agnostic but well defined. So, there should be an easy way to do that. Extending the meaning of := to work in more general terms, create an lvalue that may be aliased, assigned to, etc. initially holding the RHS as its value might be just what people expect it to do, given the symmetry between symbol tables and other collections. But, if you limit the availability of := to declaration-time only (or pre-declared to accept that, but who needs it?) to allow the compiler to optimize based on *knowing* the container type, then a different syntax might be better, since you can make it work on a symbol table entry (alias something else) without actually binding the symbol. Just thinking out loud. Wait for the picture. --John
Re: [RFC] CPAN6 requirements analysis
On Thu, 28 May 2009, Alex Elsayed wrote: On Thursday 28 May 2009 4:04:28 pm Daniel Carrera wrote: At first I liked wayland76's proposal, but now I have a new concern: Most package managers are not designed to hold multiple versions of the same package. As indicated in S11, it is important that a computer can hold multiple versions of the same package. I fear that using the native package manager will make this difficult. This could probably be resolved, but it would probably require distro-specific code. On Gentoo, the way to do it would be with 'slots', which are specifically designed for that use; on Debian, it would seem that the names would have to be distinguished by an identifier, allowing multiple versions. I can confirm that Redhat supports multiple versions: $ rpm -q kernel kernel-2.6.27.5-117.fc10.i686 kernel-2.6.27.12-170.2.5.fc10.i686 kernel-2.6.27.5-117.local.fc10.i686 ... Whether it supports everything that Perl 6 wants is a different question. The options would be: - Embed more metadata into the version (version can contain arbitrary text) - Tell people that if they want to use multiple versions at the same time, they have to not use RPM for those modules at least. There may be some middle way, where we can keep the extra metadata out of the version unless there are conflicts. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
r26957 - docs/Perl6/Spec
Author: wayland Date: 2009-05-29 04:53:24 +0200 (Fri, 29 May 2009) New Revision: 26957 Modified: docs/Perl6/Spec/S22-package-format.pod Log: Actually named the components Modified: docs/Perl6/Spec/S22-package-format.pod === --- docs/Perl6/Spec/S22-package-format.pod 2009-05-28 23:57:58 UTC (rev 26956) +++ docs/Perl6/Spec/S22-package-format.pod 2009-05-29 02:53:24 UTC (rev 26957) @@ -32,10 +32,10 @@ =item * CPAN6; this is a piece of software for managing an archive network (such as CPAN). This is not specified in this document; see http://cpan6.org/ -=item * ???A; this is an actual network based on the cpan6 software (see above). It also +=item * 6PAN-network; this is an actual network based on the cpan6 software (see above). It also is not documented here. -=item * ???B; this is a piece of software that starts with what it can get on ???A, and +=item * 6PAN-packager; this is a piece of software that starts with what it can get on 6PAN-network, and attempts to give you an installed perl module (this is a replacement for CPANPLUS/cpan2dist)
Re: Amazing Perl 6
On Thu, 28 May 2009, John M. Dlugosz wrote:
John Macdonald john-at-perlwolf.com |Perl 6| wrote:
However, the assumption fails if process is supposed to mean that
everyone is capable of generating Unicode in the messages that they
are writing. I don't create non-English text often enough to have
it yet be useful to learn how. (I'd just forget faster than I'd use
it and have to learn it again each time - but Perl 6 might just be
the tipping point to make learning Unicode composition worthwhile.)
Just copy/paste from another message or a web page. Perhaps a web page
designed for that purpose...
Or:
setxkbmap -device $kbd-{ID} 'us(intl),gr(basic),il(biblical)' \
-option grp:switch,grp:scroll_toggle,grp_led:scroll,lv3:ralt_switch
(Worksforme on Fedora 10)
Where the -device option chooses a keyboard (defaults to the core
keyboard); if you need the number, use xinput list.
That will let you type in English, Greek, and Hebrew, with lots of
funny symbols accessible by pressing the right alt key, and using the scroll
lock key to switch groups.
Oh, actually, I thing the scroll lock stuff only works on my computer.
But I'm sure you get the idea :).
And the APL keyboard layout will appear in xorg soon, as soon as
the xkeybaord-config exotic layouts issue is closed.
HTH,
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: Amazing Perl 6
On Thu, May 28, 2009 at 08:06:14PM -0500, John M. Dlugosz wrote: Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote: So that much makes sense. But I still think the two different meanings of square brackets in operators are going to confuse people. I agree. The previously quoted passages in the synopses are confusing, too, since it doesn't make the context clear. If you find the shorthand too confusing, write it out as infix+ instead. Perl can do solid software engineering as well as one-liners. Which, of course, is not as solid as you think, since you left out the : of the adverbial there... :) So let's not make the mistake of thinking something longer is always less confusing or more official. Larry
