Re: renaming or adding some operators
Buddha Buck wrote: Secondly, regarding the Bool type, I think it would be useful for Perl 6 to define the full complement of dyadic logical operators, of which I count a few that you don't appear to already have. Probably the best place is in Synopsis 32. There are 16 dyadic logical operators, not all of which make sense to have.You name 10. I think you answered your own criticism right there. The ones I didn't mention are ones that don't make sense to have. 2 of the 16 dyadic operators always result in false or true respectively, regardless of the arguments, same as 2 of the 4 monadic operators, and same as the only 2 niladic operators, contradiction/⊥ and tautology/⊤; only the last make sense to have. Another 2 of the 16 always result in a certain one or other of the arguments, respectively, regardless of the value of the second argument; they are like 1 of the 4 monadic operators that always results in its argument, and so isn't useful. Another 2 of the 16 always result in the opposite of the previous 2 I mentioned, and these are like the only 1 useful monadic operator, not/¬, that returns the opposite of its argument. This then leaves 10 dyadic operators that are actually useful, of which Perl (and most languages) clearly includes 3 as standard infix operators: and, or, xor/!===, === (xnor), which leaves 6 others of which AFAIK implies/→ is the most commonly used of those. Now, clearly ←,↚ are redundant with →,↛ if you just switch the operands around, but then by the same token ,≤/= are also redundant with ,≥/= if you just switch the operands, but it is useful to have both versions regardless. I'm certain I know the semantics of these (and chooses the minimum of the two, or the maximum, xor checks for difference, xnor checks for sameness), but I'm uncertain of some of the rest... But here are a few more dyadic: * nand aka ⊼ aka ↑ true unless both operands are true * nor aka ⊽ aka ↓ true if both operands are false * implies aka imp aka → true unless left operand true and right operand false. * nimp aka ↛ true if left operand true and right operand false? * if aka ← true unless left operand false and right operand true * nif aka ↚ true if left operand false and right operand true? See these urls which were 2 of my primary references when building my lists: http://en.wikipedia.org/wiki/Logical_connective http://www.rbjones.com/rbjpub/logic/log048.htm They should give you all the details. The other six, which don't depend on the value of both operands, would (if they existed) have the names false, left, right, nright, nleft, and true. I believe traditionally they are called: contradition, p, q, ¬q, ¬p, tautology (where p and q are the names of the arguments). Thirdly, there are I'm sure a number of other aliases that could be added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of the inequality operators, although that last one would probably make more sense if = was the equality test operator, so maybe best to avoid ≠ then. Perhaps ≡ and ≢ as aliases? Well that's a thought, since those actually talk about 'identical' rather than 'equal', though I believe for purposes of logic (ignoring geometry say) they mean exactly the same thing, and I prefer the = and ≠ symbols. For all of that matter, I think that Perl 6 would look a lot prettier if it used = as the generic equality test op (what === is used for now) and used the likes of := for assignment/binding/etc. I don't know if using = for assignment is actually liked by people because they think it looks better or just because it has momentum say from Perl 5 and C et al. Probably the single main advantage I can see for needing a single character there is it combines easily with infix ops to make =foo ops, not that this still can't be done another way. Larry, did you choose = for assignment and == etc for comparison because you thought that looked prettier, or because that was the C/etc convention that you decided to copy? -- Darren Duncan
Re: renaming or adding some operators
Darren (): Firstly, regarding the string replication ops as documented in Synopsis 3, 'x' and 'xx', I'm wondering whether it might be better to have something that incorporates a '~', since that operation is about catenation. Would perhaps '~*' work better than 'x' to signify better what the operation is doing; the '~' in this case means catenation and the '*' is meant to invoke 'multiply', not 'whatever'. So '~*' means catenate a multiple of times. This would then free up 'x' to be used for something else, if anything. As for a substitution for 'xx', I'm less sure about that. Thoughts? I like 'x' for string replication and 'xx' for list replication. To me, they share a sort of symmetry with '*' and '**' that at least help as a mnemonic to their use. There's a bit of symbolism in using 'x' for strings repetition too. You may want an asterisk in your version of the operator because the asterisk symbolizes multiplication/repetition to you, but the 'x' looks like a cross operator, and indicates to me that some kind of multiplication is going on here, but not the regular one. I can read '$text x 5' as 'dollar text times five' in a way that feels very natural. // Carl
Re: renaming or adding some operators
Thoughts:
Your nomenclature makes me think you are coming from an APL background.
!=== is already generated from ===, and compares the identity of any two
objects. It works on binary values since they are value types, but
that's not the proper usage, and Perl separates out the concerns.
Some of the things you mention do indeed make sense as a principle form
for an operator, with the current way a digraph. For example, =. It's
been a digraph approximation for so many decades that we have
forgotten. My editor shows the ≤ when it formats =.
exists has already been changed to an adverb on the lvalue, but I
suppose a macro could still be made to work.
Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote:
I had some thoughts lately about the Perl 6 operators, and wanted to
bounce some ideas.
Firstly, regarding the string replication ops as documented in
Synopsis 3, 'x' and 'xx', I'm wondering whether it might be better to
have something that incorporates a '~', since that operation is about
catenation.
Would perhaps '~*' work better than 'x' to signify better what the
operation is doing; the '~' in this case means catenation and the '*'
is meant to invoke 'multiply', not 'whatever'. So '~*' means
catenate a multiple of times.
This would then free up 'x' to be used for something else, if anything.
As for a substitution for 'xx', I'm less sure about that.
Thoughts?
Was that operator called 'x' because it was the best or because that
was how Perl 5 did it, and Perl 6 wanted to not change things if it
didn't need to?
Secondly, regarding the Bool type, I think it would be useful for Perl
6 to define the full complement of dyadic logical operators, of which
I count a few that you don't appear to already have. Probably the
best place is in Synopsis 32.
Note that all the dyadic ops I am discussing are meant to be read as
infix ops only.
These are the boolean/logical ops you already have:
Niladic ops aka value literals / constants:
* Bool::False
* Bool::True
Monadic:
* not aka !, but ¬ alias could be added
Dyadic:
* and aka , but ∧ alias could be added
* or aka ||, but ∨ alias could be added
* xor aka ^^ aka !===, but ⊻, ↮ aliases could be added
* ===, but xnor, ↔ aliases could be added
Now I'm not sure whether or not [also, andthen, orelse] have the
desired semantics of any others or not, or whether [if, unless] could
be used as a value-resulting infix operator or not.
But here are a few more dyadic:
* nand aka ⊼ aka ↑
* nor aka ⊽ aka ↓
* implies aka imp aka →
* nimp aka ↛
* if aka ←
* nif aka ↚
For that matter, as you know, every single boolean/logical operator
could also have a bitwise analogue, if people were so inclined.
Thirdly, there are I'm sure a number of other aliases that could be
added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of
the inequality operators, although that last one would probably make
more sense if = was the equality test operator, so maybe best to avoid
≠ then.
Lots of the other ones I can think of apply to sets, and the
ext/Set.pm bundled with Pugs already documents them quite well.
However, I think some set ops could also be used with hashes. For
example, an alternate way of spelling exists %foo{$bar} is $bar ∈
%foo or %foo ∋ $bar.
So, any thoughts?
-- Darren Duncan
Re: renaming or adding some operators
John M. Dlugosz wrote: Your nomenclature makes me think you are coming from an APL background. Actually, I've never used APL. The main influences for the terminology I use, besides Perl which is my favorite general purpose language, is the field of relational databases, both the SQL language and other database languages, which are heavily tied to the domains of logic and math etc, so I use math/logic-based terminology a lot. I've also studied a wide variety of languages and appreciate functional ones, though I haven't really used them at all. I also appreciate OO languages. !=== is already generated from ===, and compares the identity of any two objects. It works on binary values since they are value types, but that's not the proper usage, and Perl separates out the concerns. I prefer to conceptualize all values as immutable, and if you have something that is mutable, it isn't a value but a container; the identity of every value is itself, and all values are distinct by definition. I appreciate Perl 6's design, with the distinct ===, eqv, =:=, ==, eq operators. I know what === is for. I also know that given its current design, === and !=== just happen to have the same semantics as logical xnor and xor when given 2 Bool inputs, and so they serve the purpose. Having distinct xnor and xor operators is useful from partly a documentation perspective and from error-checking; a strict compiler or runtime should complain if non-Bool inputs are given to them. Some of the things you mention do indeed make sense as a principle form for an operator, with the current way a digraph. For example, =. It's been a digraph approximation for so many decades that we have forgotten. My editor shows the ≤ when it formats =. I thought so, and that's why its good to take advantage of the real thing when we are able to, and take the approximated spellings for what they are, approximations. exists has already been changed to an adverb on the lvalue, but I suppose a macro could still be made to work. Sure. -- Darren Duncan
Re: renaming or adding some operators
On Fri, May 29, 2009 at 11:06:46PM -0700, Darren Duncan wrote: Larry, did you choose = for assignment and == etc for comparison because you thought that looked prettier, or because that was the C/etc convention that you decided to copy? Neither beauty nor convention, really. I chose it for the same reason that C chose it: Assignment is much more common than testing equality, so this is pure Huffman. This was specifically mentioned in the original rationale for the design of C, because by percentage there were more mathematicians in programming then than there are today. So there was certainly some pressure to use = for equality back in the day, and I give KR credit for helping establish the Huffman principle. Certainly the Huffman principle was largely ignored by the designers of COBOL. The first time I saw that you call a subroutine with perform, I said to myself, Something's desperately wrong here. Why didn't they just use 'do'? Which you'll notice is how Perl 1 called subs. Of course, eventually I figured out that two characters is still too long for that, so I changed it to 1 character, , a little slow to realize that the correct answer was 0 characters... :) These days I try to be stupid about other things instead. Larry
Re: renaming or adding some operators
On Fri, May 29, 2009 at 08:45:06PM -0700, Darren Duncan wrote: So does anyone else have thoughts on that? Actually, I think ~x is kinda ugly. And I like the mnemonic value of x returning one thing and xx returning multiple things. And in the bitwise ops ~ doesn't indicate postprocessing. And given that we've only used a ~ modifier in bitops, people would look at ~x and try to figure out what kind of bitop it was meant to indicate. And in any case, it would be silly to actually implement string replication in terms of list replication. So by all means feel free to speculate on what a mathematical syntax module might tweak, but there are lots of obvious and not-so-obvious reasons to keep the standard operators pretty much the way they already are. Most of the current-day tweaks are driven by semantic simplifications, not the desire to refactor S03 yet again in pursuit of some kind of completist agenda, which you know can never entirely satisfy the mathematicians. :) Larry
Re: Commentary on S22 (CPAN [DRAFT])
On Fri, May 29, 2009 at 11:04:38PM +0200, Daniel Carrera wrote: Hello, I finished reading S22 (CPAN [DRAFT]). This synopsis is about the package format, not about the network. I have some comments: 1) Instead of calling the format JIB, how about PAR? It can stand for Perl ARchive or the recursive PAR ARchive. This is more memorable. It might make sense to adopt the same naming as .jar and .epub, two very different zipfile-as-container formats. Both use a top-level directory called META-INF. There's no particular technical reason to pick a given name, so going for something that looks familiar to people may be a win. -jesse
Re: Amazing Perl 6
The same tradition has variations in Windows. I recall the leading zero means ANSI code page. I thought I recall a way to give more digits and specify Unicode, but I can't find it on Google. --John Timothy S. Nelson wayland-at-wayland.id.au |Perl 6| wrote: On Fri, 29 May 2009, John M. Dlugosz wrote: Ah yes, on the PC historically you hold down the ALT key and type the code with the numpad keys. At least when I used it, this was a decimal, rather than hex number, and had to be preceded by a 0 (zero). So if anyone is still on eg. Windows 98, this may be the way to go :). - | 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: New CPAN
On Fri, 29 May 2009, Daniel Carrera wrote: Mark Overmeer wrote: And the next consideration: when we have a piece of software which administers Perl5 or Perl6 or Nokia.bin or Elf. Why stop there? What is the overlap? It is basically all just some blob of data with some associated meta-data to search and retreive the blobs. It is only the client side install tool which looks into the content of the package. Why not allow pure pod releases? A small step to documents in any other format. Why not share holiday pictures? Also just a blob of data with some meta-data. Your idea of using CPAN to share holiday pictures is one of the things that really turned me off from your CPAN6 proposal. I do want this to be about Perl, you don't, and that's a point where we differ. In my examples, Nokia.bin is so that mobile users don't have to compile software on their tiny CPUs. I can see merit in adding Ruby modules because in a new Parrot world, there is real opportunity for Perl and Ruby to share libraries with each other (e.g. Perl on Rails). But when you start talking about sharing holiday pictures, you have completely left the Perl realm and I am completely turned off. Allow me to point something out. He wants to write a freely available software package that can share data, and is useful for the Perl6 environment. He's not suggesting that we have holiday photos on CPAN-the-network, simply that the software not care whether the data inside it is a package or not, just whether it has metadata. If you don't like the holiday photos examples, just skim over them :). It's only 5 or so words to skip :). - | 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: Commentary on S22 (CPAN [DRAFT])
jesse wrote: 1) Instead of calling the format JIB, how about PAR? It can stand for Perl ARchive or the recursive PAR ARchive. This is more memorable. It might make sense to adopt the same naming as .jar and .epub, two very different zipfile-as-container formats. Both use a top-level directory called META-INF. There's no particular technical reason to pick a given name, so going for something that looks familiar to people may be a win. Sounds reasonable. Like you said, there is no strong reason to pick one name or another, so why not pick the name everyone else already uses? Daniel.
Re: [RFC] CPAN6 requirements analysis
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. And, in fact, binary distribution is something that's been done on CPAN for quite a while. A quick poke at the backpan finds things like http://backpan.perl.org/authors/id/G/GS/GSAR/DB_File-1.54-bin-x86-mswin32-bc.zip dating from over a decade a year ago. The motivations for binary distribution have changed, but the need has been there all along. The only thing I'd worry about here is making one of the big mistakes that the Java community made -- Making binary-only distribution an acceptable alternative to source distribution. Nothing should end up on the CPAN unless it's there in source form. Making binary distribution easy is a laudable goal, but it's something the existing infrastructure already supports. I'd love to see CPAN autobuilders which build perl modules for a givven platform and architecture and make them generally available. That'd be a lot cleaner than the current ad-hoc system which requires authors to jump through hoops. But really, that's just another CPAN-related service that could easily layer on the existing infrastructure. Best, Jesse pgpwO3tBWEibH.pgp Description: PGP signature
Re: [RFC] CPAN6 requirements analysis
* Timothy S. Nelson (wayl...@wayland.id.au) [090530 02:15]: * PAUSE6; this is an actual network based on the CPAN6 software (see above). It also is not documented here. Pause6 is one implementation of archive maintenance software. In the first version written in Perl5, it implements things like I'm still not sure we're on the same page. Let me give an example: - Perl6 is a specification - Rakudo is an implementation of that specification - www.example.com runs a copy of Rakudo (to serve their site) So we have: - Specification - Implementation - Installation Which of those is CPAN6? Which is Pause6? Your use of the word implementation is confusing me; I'm saying Pause6 is the installation (accessible to the world). Is that what you're saying? CPAN6 is like IP: routing and exchanging packages. Quite small and stupid. Pause6 is like TCP: knows how to get the right packages. Install tools are like HTTP: understand the content of packages. You should avoid ever changing the IP level. But next to TCP, you have UDP and so on, for different package handling needs. (On that level, I define connections to external archive-like applications, like OpenID) So: CPAN6 has a spec and an implementation Pause6 has a spec and an implementation Install tools may get a spec and implementation (part of this discussion thread, but not of my project) CPAN6 will run on all servers with this group-sharing concept. It enables playing with large number of archives and mirrors: required to move from the solo namespace of current CPAN into multiple namespaces. Pause6 may be replaced eventually, gradulary, with other implementations. One CPAN6 server can run different implementations and configurations in parallel. Install tools for Perl will be installed where people run Perl and use an archive which contains Perl. Of course, other kinds of applications can use the archive data. -- MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
* Andrew Whitworth (wknight8...@gmail.com) [090530 00:24]: I agree. Doing one thing well is so much better for everybody then doing a million things poorly. An assorted blob of data repository is far less valuable to the Perl5, Perl6, and Parrot communities then a dedicated library repository is. Why? Ever heart of extensible meta-data. Can be done in two ways. The idea is tha, on the three levels of implementation (see recent email in other thread), you have some meta-data. 1 On the CPAN6 level (transport layer) you have uniqueness information: give the release a name: . source archive URI or target name . product or package name . version and some standard data, like size and data of upload. 2 On the Pause6 level, you have adminstrative facts: . validation . access . searching, etc 3 On the application level (install tools etc) You may also need some facts. So: the core of the CPAN6 design is meta-data which accompany blocks. But I do not say that the Pause6 administration only accepts meta-data for level 1 and 2. It also transports meta-data on level 3. It does not UNDERSTAND that meta-data, but it does provide that meta-data. Ignoring information does not make the archives implementation harder. The ONLY difference between a specialized implementation of an archive and a flexible one like I propose, is that in the latter you are forced to clearly assign meta-data facts to one of these three levels. But there is no limitiation in the amount and content of the meta-data you can collect. Well, so your worries are unjustified. And the two simple solutions as I promissed in the first line of my comment: 1 Add three seperate meta-data fragments to one blob 2 Create one meta-data file which contains all three components. As simple as that. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: [RFC] CPAN6 requirements analysis
* Timothy S. Nelson (wayl...@wayland.id.au) [090530 03:11]: On Fri, 29 May 2009, Alex Elsayed wrote: Instead, it would go to the distributions, who are already well-prepared to handle packaging. We'd just be providing the tools and material they need to do so. Let me reiterate that, while I'd love to have the complete CPAN available pre-packaged for my distro, it doesn't seem like that's necessarily going to happen. Certainly not if you need recent releases of modules, because someone fixed a bug for you. It can easily take a year before a distribution picks that up. Thus, what I want is a tool that will allow me to download the source, turn it into a package for my distro, and install it. This is why I want the Software::Packager solution. Empower the user :). But that module does not contain anything which is required to produce packages for Linux distributions. Well, ok, I should say: it does not handle any of the complex things. Yesterday, I drew a picture of how I see services to happen. Having an automated service which is specialized in building debs and such. Now, such tools do exist, but are usually not published by the distribution makers. Maybe, you can collect those (and unify them) Could be far more complex than you wish for. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Amazing Perl 6
Assuming you have the right key set in the Registry, you can enter hex Unicode in Windows. Hold down alt, press the + key on the numpad and then type the hex code (using the main keyboard and/or the numpad), then release alt. On Sat, May 30, 2009 at 2:11 AM, John M. Dlugosz j...@dlugosz.com wrote: The same tradition has variations in Windows. I recall the leading zero means ANSI code page. I thought I recall a way to give more digits and specify Unicode, but I can't find it on Google. --John Timothy S. Nelson wayland-at-wayland.id.au |Perl 6| wrote: On Fri, 29 May 2009, John M. Dlugosz wrote: Ah yes, on the PC historically you hold down the ALT key and type the code with the numpad keys. At least when I used it, this was a decimal, rather than hex number, and had to be preceded by a 0 (zero). So if anyone is still on eg. Windows 98, this may be the way to go :). - | 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- -- Mark J. Reed markjr...@gmail.com -- Mark J. Reed markjr...@gmail.com
Re: [RFC] CPAN6 requirements analysis
On Sat, 30 May 2009, Mark Overmeer wrote: * Timothy S. Nelson (wayl...@wayland.id.au) [090530 03:11]: On Fri, 29 May 2009, Alex Elsayed wrote: Instead, it would go to the distributions, who are already well-prepared to handle packaging. We'd just be providing the tools and material they need to do so. Let me reiterate that, while I'd love to have the complete CPAN available pre-packaged for my distro, it doesn't seem like that's necessarily going to happen. Certainly not if you need recent releases of modules, because someone fixed a bug for you. It can easily take a year before a distribution picks that up. ...or if I need a rare package that I need but isn't commonly requested. Thus, what I want is a tool that will allow me to download the source, turn it into a package for my distro, and install it. This is why I want the Software::Packager solution. Empower the user :). But that module does not contain anything which is required to produce packages for Linux distributions. Well, ok, I should say: it does not handle any of the complex things. Well, it should have the metadata; are you saying it won't have the build-install scripts? What decides how it gets built and installed then? Yesterday, I drew a picture of how I see services to happen. Having an automated service which is specialized in building debs and such. Now, such tools do exist, but are usually not published by the distribution makers. Maybe, you can collect those (and unify them) Could be far more complex than you wish for. Well, presumably, completely new ones will need to be developed to use this new framework[*] we're talking about. If we provide an interface that does some of the work for them, they might make adaptor modules for that interface instead of completely rolling their own. That's what I'm hoping for. [*] I'm using the word framework in the vaguest general sense here, that covers everything we've been discussing. 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: New CPAN
On Sat, May 30, 2009 at 7:56 AM, Mark Overmeer m...@overmeer.net wrote: * Andrew Whitworth (wknight8...@gmail.com) [090530 00:24]: I agree. Doing one thing well is so much better for everybody then doing a million things poorly. An assorted blob of data repository is far less valuable to the Perl5, Perl6, and Parrot communities then a dedicated library repository is. Why? Ever heart of extensible meta-data. Can be done in two ways. The idea is tha, on the three levels of implementation (see recent email in other thread), you have some meta-data. I'm not saying we *can't* create a general repository for all sorts of nonsense, I'm saying that we *shouldn't*. It doesn't matter what kind of meta data you use, or how you structure your URI, or whatever: It's a bad idea. In this case, we should follow the maxim that less is more, and realize that a tighter focus will create better value. People are going to form a one-to-one association with your project and what they expect to find there. When I think email, I immediately associate that in my mind with gmail. When I think encyclopedia, I make an immediate association to wikipedia, and vice versa. What do we want people to think about when they think about CPAN, dynamic software packages or all sorts of assorted garbage with extensible metadata. The ONLY difference between a specialized implementation of an archive and a flexible one like I propose, is that in the latter you are forced to clearly assign meta-data facts to one of these three levels. But there is no limitiation in the amount and content of the meta-data you can collect. If you want to create an infrastructure that is vastly extensible and too clever by half, that's you're prerogative. I don't care what software infrastructure we use for a new CPAN, nor what methodology is used to design it. What I do care about is that the final CPAN website that we end up with only contains packages related to Perl5, Perl6, and Parrot. Create a server that can theoretically handle images and other garbage if you want to, but we should make sure the site administrators disable that feature immediately. Well, so your worries are unjustified. And the two simple solutions as I promissed in the first line of my comment: 1 Add three seperate meta-data fragments to one blob 2 Create one meta-data file which contains all three components. As simple as that. Again, we are capable of doing this from a technical standpoint. It's still a bad idea. --Andrew Whitworth
Is the Perl community just about Code? (Was: Re: New CPAN)
Em Sex, 2009-05-29 às 23:37 +0200, Daniel Carrera escreveu: Your idea of using CPAN to share holiday pictures is one of the things that really turned me off from your CPAN6 proposal. If you replace holiday pictures by 'YAPC pictures', 'Talk slides', 'Code Snippets', 'Perl related scientific articles' it does look much more closer to a very good use of CPAN. A few days ago I posted[1] on Perlmonks about how we could extend the tools our community uses to get it even closer, and maybe this is one interesting answer to that. daniel [1] http://www.perlmonks.org/?node_id=765024
Re: renaming or adding some operators
John M. Dlugosz said [off-list]: Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote: I also know that given its current design, === and !=== just happen to have the same semantics as logical xnor and xor when given 2 Bool inputs, and so they serve the purpose. Having distinct xnor and xor operators is useful from partly a documentation perspective and from error-checking; a strict compiler or runtime should complain if non-Bool inputs are given to them. With the heritage as a free-typed language, the use of different operators rather than overloading an operator based on type was a core feature of Perl. You might not have two typed Bool arguments. You have two arguments which might be considered boolean, or numeric, or string, depending on what I want of it at the moment. So !=== between two arrays still does the Bool meaning, and asks if one is empty and the other not. More serious with strings, which can be strings or the serialized form of something else. === with strings will be False if one contains 0 and the other contains false, when both are the same as XML attribute values of type XSD:boolean. Actually, I'll correct myself. In Perl, I would expect the boolean-specific operators like and/or/xor/etc to accept any values at all as arguments, and evaluate them in a boolean context, using each object's notion of truthness. But my point is that, though the behaviour of xor and !=== is very different in the general case, when given two actual Bool arguments, their semantics would be the same, and so someone working in a pure Bool context would get the desired behaviour from !=== and === treated as xor and xnor. -- Darren Duncan
Re: New CPAN
On 2009-May-30, at 6:56 am, Andrew Whitworth wrote: I'm not saying we *can't* create a general repository for all sorts of nonsense, I'm saying that we *shouldn't*. Holiday photos is just a whimsical example. The problem is that it's hard enough keeping up with what Perl6 is today, let alone what it will be tomorrow. Or what Perl 7 will be, or what some other programming language/system will be that isn't even invented yet. Mark's point is that any arbitrary restrictions put in place now will seem short-sighted in 10 years' time, so we need something flexible. And it's all just 1s and 0s to the computer, so you *could* use it for photographs; that shouldn't matter to the software. If you want to create an infrastructure that is vastly extensible and too clever by half, that's you're prerogative. Sure, it's always possible to go too far. But on the other hand, isn't Perl 6 all about being too clever by half? It's certainly about being vastly extensible, anyway. -David
Re: New CPAN
On 2009-May-30, at 12:06 pm, David Green wrote: ...what Perl6 is today, let alone what it will be tomorrow. Actually, we do kind of know what Perl will look like a decade from now, because P6 is deliberately extensible enough that we may never need a Perl 7. But that simply means that holiday photos are already a possibility: perl -MSteganography::Images pics/2009/ceylon.jpg In fact, you could do that in Perl 5 On 2009-May-30, at 9:32 am, Daniel Ruoso wrote: If you replace holiday pictures by 'YAPC pictures', 'Talk slides', 'Code Snippets', 'Perl related scientific articles' it does look much more closer to a very good use of CPAN. Hm, all we need is the right grammar, and your slides can be their own code! -David
r26972 - docs/Perl6/Spec
Author: masak
Date: 2009-05-30 20:56:14 +0200 (Sat, 30 May 2009)
New Revision: 26972
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05-regex.pod] moved ending paren for clarity
Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod 2009-05-30 05:41:06 UTC (rev 26971)
+++ docs/Perl6/Spec/S05-regex.pod 2009-05-30 18:56:14 UTC (rev 26972)
@@ -14,8 +14,8 @@
Maintainer: Patrick Michaud pmich...@pobox.com and
Larry Wall la...@wall.org
Date: 24 Jun 2002
- Last Modified: 28 May 2009
- Version: 98
+ Last Modified: 30 May 2009
+ Version: 99
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them Iregex rather than regular
@@ -1744,7 +1744,7 @@
The Perl 6 equivalents are:
regex { pattern }# always takes {...} as delimiters
- rx/ pattern /# can take (almost any) chars as delimiters
+ rx/ pattern /# can take (almost) any chars as delimiters
You may not use whitespace or alphanumerics for delimiters. Space is
optional unless needed to distinguish from modifier arguments or
r26973 - in docs/Perl6/Spec: . S32-setting-library
Author: lwall Date: 2009-05-30 21:00:14 +0200 (Sat, 30 May 2009) New Revision: 26973 Modified: docs/Perl6/Spec/S12-objects.pod docs/Perl6/Spec/S31-pragmatic-modules.pod docs/Perl6/Spec/S32-setting-library/Containers.pod Log: s/MONKEY_PATCHING/MONKEY_TYPING/ because it's funnier, and goes with duck typing Modified: docs/Perl6/Spec/S12-objects.pod === --- docs/Perl6/Spec/S12-objects.pod 2009-05-30 18:56:14 UTC (rev 26972) +++ docs/Perl6/Spec/S12-objects.pod 2009-05-30 19:00:14 UTC (rev 26973) @@ -1676,7 +1676,7 @@ In order to discourage casual misuse of these declarators, they are not allowed on global classes unless you put a special declaration at the top: -use MONKEY_PATCHING; +use MONKEY_TYPING; For optimization purposes, Perl 6 gives the top-level application the right to close and finalize classes by the use of Coo, a pragma for Modified: docs/Perl6/Spec/S31-pragmatic-modules.pod === --- docs/Perl6/Spec/S31-pragmatic-modules.pod 2009-05-30 18:56:14 UTC (rev 26972) +++ docs/Perl6/Spec/S31-pragmatic-modules.pod 2009-05-30 19:00:14 UTC (rev 26973) @@ -49,7 +49,7 @@ =item use m :foo -- see S05-regex.pod -=item use MONKEY_PATCHING -- see S12-objects.pod +=item use MONKEY_TYPING -- see S12-objects.pod =item use PDL -- see S09-data.pod Modified: docs/Perl6/Spec/S32-setting-library/Containers.pod === --- docs/Perl6/Spec/S32-setting-library/Containers.pod 2009-05-30 18:56:14 UTC (rev 26972) +++ docs/Perl6/Spec/S32-setting-library/Containers.pod 2009-05-30 19:00:14 UTC (rev 26973) @@ -800,7 +800,7 @@ Note this is a private method; you must arrange for yourself to be trusted by the junctions class in order to call it, which probably involves evil -MONKEY_PATCHING. +MONKEY_TYPING. Alternately, the values may be explicitly converted to a set value using C.Set or CSet(). Note, however, that the set of eigenstates
Re: renaming or adding some operators
On 2009-May-29, at 7:53 pm, Darren Duncan wrote:
Thirdly, there are I'm sure a number of other aliases that could be
added to other ops, such as ≤ and ≥ for = and =, and ≠ for
one of the inequality operators, although that last one would
probably make more sense if = was the equality test operator, so
maybe best to avoid ≠ then.
Probably. I would really like to see the obvious symbols defined,
though, for two reasons:
1) Being able to use real symbols (e.g. ≤ instead of crude ASCII
approximations) will make Perl code look ever so pretty and make all
the other kids envious. (Envy is, of course, one the great
programmers' virtues, the one that makes us steal all the best bits
from other languages!)
2) It will discourage people from abusing operators that already have
well-defined standard meanings. For example, if there is no ∑,
somebody might be tempted to use it for multiplication; or to use √
for checking something; or + for concatenating strings, etc.
However, I think some set ops could also be used with hashes. For
example, an alternate way of spelling exists %foo{$bar} is $bar
∈ %foo or %foo ∋ $bar.
I think that one's ambiguous as to whether $bar exists as a key or a
value.
$bar ∈ @foo; $bar ∈ %foo.keys; $bar ∈ %foo.values; ∃ %foo{bar}
-David
r26974 - docs/Perl6/Spec
Author: masak Date: 2009-05-30 21:52:04 +0200 (Sat, 30 May 2009) New Revision: 26974 Modified: docs/Perl6/Spec/S29-functions.pod Log: [S29-functions] chasing spec changes to Cbless Modified: docs/Perl6/Spec/S29-functions.pod === --- docs/Perl6/Spec/S29-functions.pod 2009-05-30 19:00:14 UTC (rev 26973) +++ docs/Perl6/Spec/S29-functions.pod 2009-05-30 19:52:04 UTC (rev 26974) @@ -15,8 +15,8 @@ Moritz Lenz mor...@faui2k3.org Tim Nelson wayl...@wayland.id.au Date: 12 Mar 2005 - Last Modified: 24 Feb 2009 - Version: 42 + Last Modified: 30 May 2009 + Version: 43 The document is a draft. @@ -262,19 +262,18 @@ =item bless - our Object multi method bless( Object::RepCandidate $candidate ) - our Object multi method bless( *%args ) + our Object method bless(Object::RepCandidate $candidate, *...@protos, *%init_args) -Cbless is only available as a method which can be called on a prototype -object like so: +Calling Cbless on any invocant (but typically a type object) to create a new +object with the same class as the invocant. - $object = $proto.bless(k1 = $v1, k2 = $v2, ...); +C$candidate is used to provide the underlying representation of the object. +The default is CP6opaque, but various other representations might be +desired, especially when interoperating with other languages. C@protos and +C%init_args both provide ways for values to be provided to the new +object, just like in the default Cnew method. -A newly created object, based on either the C$candidate representation -or a newly created representation (initialized with the C%args that -are passed in) when the second form is used. - -It automatically calls all appropriate CBUILD routines by calling the +Cbless automatically calls all appropriate CBUILD routines by calling the CBUILDALL routine for the current class, which initializes the object in least-derived to most-derived order. See LS12/Objects for more detailed information on object creation.
Re: renaming or adding some operators
It occurs to me that, while I don't want to pull in all the possible Unicode operators by default, we should make it easy to do so. Perhaps something like use *; should pull in all the Unicode operators. Which if course means that any golfing would start with *; to pull in all the possible operators in non-strict mode, and turn on the mode where methods can be specified by the first few unique characters, and maybe turn off mandatory whitespace in a few spots. :) Larry
Re: renaming or adding some operators
On Sat, May 30, 2009 at 01:09:01PM -0600, David Green wrote:
I think that one's ambiguous as to whether $bar exists as a key or a
value.
$bar ∈ @foo; $bar ∈ %foo.keys; $bar ∈ %foo.values; ∃ %foo{bar}
Generally when hashes have been used as sets we've taken the keys
to be the set, not the values, since the keys guarantee uniqueness.
However, even defining it that way, a hash should really be considered
a set *container* rather than a set, since sets are immutable, and
hashes aren't. This is why we distinguish the Set type from the
KeySet type.
But tagmemically speaking, it's perfectly fine to *use* a hash
as if it were a set.
Larry
CPAN -- moving forward
Hello, In the hopes of helping the CPAN discussion move forward, in the direction of tangible work, I have made a wiki page with a proposal: http://wiki.github.com/perl6/misc/cpan-and-package-format Please read the Basics section, which is quite short. The main point of this section is to divide the issue into three parts: 1) A package format. 2) A low-level install tool, analogous to rpm or dpkg, that converts the package (2) into a local package format (rpm, deb, ebuild). 3) A high-level install tool, analogous to yum or apt, that uses the CPAN network and resolves dependencies. I have used the same numeric labels on the wiki. Tim N. is most interested in (2) and Mark O. is most interested in (3). I propose that we work on (1) and (2) first and do (3) later. (3) is quite independent of (1) and (2). Mark might want to check that the package format includes enough meta-data to not conflict with is ideas. If we can mostly agree on the package (1), we can move to (2). I think we can make quick progress with (2): 2.1 Start with a easyugly script using the alien and zip commands. Get the basic functionality down. 2.2 Gradually port Perl 5 modules (e.g. Software::Packager) and rewrite the script to remove dependency on shell commands. Think of it as a boot-strapping method. What do you think? Daniel.
Re: CPAN -- moving forward
* Daniel Carrera (daniel.carr...@theingots.org) [090530 20:54]: 3) A high-level install tool, analogous to yum or apt, that uses the CPAN network and resolves dependencies. Mark O. is most interested in (3). These are all things which I do *not* play in the layers I want to build. Although I do have an opinion on these subjects (if you know me: I have opinions on everything) but they are all not included in my design. Wrong abstraction layer. A pity you didn't want to read the paper. My Archiver implementation defines ways how to specify the meta-data for dependencies, because that is a common need, but does not resolve dependencies. It provide sufficient means of search so you can investigate the dependency details before you start downloading releases, but in general, there are nasty application dependent interpretations in these details. Interpreting dependency information sometimes requires human intervension. For instance: do you want to upgrade to a higher version which breaks api (and triggers the upgrade of a dozen other modules on your system) or stay in the maintenance track of the older api. (example is Mail:: SpamAssassin 2 vs 3) These problems cannot be resolved server-side. Apt or yum are just like CPAN install tools. Nothing more. So outside my personal scope. (But important to Perl6) Please clarify in your spec what you mean with package in a dependency. Is it about a single distributed version (what I call a release into the archive), or a release with a certain product name, or with a certain tag. Or any of those: how would you specify that? And how would you denote ranges of conflicting packages? Well, maybe start with putting that in your wishlist. And conflicting/dependencies in licenses? How would you resolve dependency conflicts? Design human intervention in this process of dependency processing. How do you handle external dependencies to Linux distribution components like database software, which change name with each new release of each linux distribution? Will we lockin Perl to a few well known distributions, or do week keep our trandition open mind. So: please pick from http://lwn.net/Distributions/ (currently 548 distros listed) which you want to support... and wait for other people to add more. Perl is one of the last pure English open source projects. When you install a localized KDE or Gnome *everything* (95%) gets translated. But not Perl! You must include description and keywords in various languages. Can other people contribute translations? How will they add those to CPAN? The Meta.YML specs are already further than what you propose. Go to a Perl QA Hackathon and see how hard people work to get Meta.YML extended! (last year Oslo, last March in Birmingham) Reuse that. I propose that we work on (1) and (2) first and do (3) later. (3) is quite independent of (1) and (2). Mark might want to check that the package format includes enough meta-data to not conflict with is ideas. There is no way that it can conflict, as long as it is well defined. Have a look at the Kwalify module, or use the horribly (but more widely known) XML Schema's to make it well-defined. My very extended meta-data design probably gives you enough to shop for your wishlist. But I may lack a few things and can add those easily on this stage of the project. Or you can put those in the application specific meta-data block which Pause6/CPAN6 supports. (Which is a pity: unification of meta- data has many advantanges) As examples of how you could adapt your design to my plans: . you do not need to organize file signatures, because those are (far more flexible) already provided on the transport layer of CPAN6. (where it fits logically) . you do not need any packing or unpacking of trees, because that is also part of my transport layer: sender and receiver decide whether they pack temporarily or not. . I offer nice standard solutions for identity management (authors) and licenses. But these are probably automatically translatable. I will keep an eye on your growing list of meta-data needs, and see whether there appear things which are not covered in my specs yet. We need more and better meta-data, not a reinvented wheel. -- MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: renaming or adding some operators
David Green david.green-at-telus.net |Perl 6| wrote: On 2009-May-29, at 7:53 pm, Darren Duncan wrote: Thirdly, there are I'm sure a number of other aliases that could be added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of the inequality operators, although that last one would probably make more sense if = was the equality test operator, so maybe best to avoid ≠ then. Probably. I would really like to see the obvious symbols defined, though, for two reasons: 1) Being able to use real symbols (e.g. ≤ instead of crude ASCII approximations) will make Perl code look ever so pretty and make all the other kids envious. (Envy is, of course, one the great programmers' virtues, the one that makes us steal all the best bits from other languages!) 2) It will discourage people from abusing operators that already have well-defined standard meanings. For example, if there is no ∑, somebody might be tempted to use it for multiplication; or to use √ for checking something; or + for concatenating strings, etc. I agree. The original non-ASCII characters, introduced 9 years ago, are at least Latin-1. But in for a penny, in for a £, eh? The symbols ≤, ≥, and ≠ are u+2264, u+2265, and U+2260 respectively. That's pretty far afield from Latin-1 or any national code page character sets. They are part of the Mathematical Operators block at U+22xx. Checking the fonts installed with Windows, coverage of that block is very sparse. But, those three in particular, and a hand full of others, are present in most fonts, including plain (not the Unicode) Arial, Courier New, and Lucida Console. Even most of the ornamental fonts have those three. One reason might be because ≥ and ≤ are in the DOS OEM code page from ancient BIOS history. Now the existing « » synonym of is a digraph which I believe is mapped at the parser level. Is that because the quoting needs to be understood at a deeper level than just defining operators? I'm wondering if there is any benefit or necessity of making = and = digraphs for the single-char form, as opposed to just making the operators synonyms. I guess the latter means that any overloading would have to cover both explicitly to avoid confusing people. Note that ≥ and ≤ are bidi mirroring characters in the Unicode Properties. So if someone were crazy enough to use them as brackets, then the digraph equivalent should work as well, right? Anyway, I support the idea of making ≤, ≥, and ≠ the principle operators and having =, =, and != as synonyms for them. But, the synonyming would need to be automatic and complete, so that someone can overload infix:≤, for example, and someone else using that module can write = and no worries. Although personally I think someone defining a new class would just give it the Ordered role and supply the minimum two methods for that, and then all the relational operators would just work. I'd also like to point out that there are other variations, such as ≦ and ≶ so it is easy to get carried away. These others don't have the widespread font support that the proposed 3 enjoy. We should leave all the others for the math guys to use in specialized modules, and not be in the core language. I would also endorse using Π or π as synonyms for Pi or pi (or is it PI?). The Latin-1 fractions ¼, ½, ¾ could be Rat constants, since I can't imagine them being used for anything else. There is a full set of them in the Number Forms block. But, those are not Letters. They have a Unicode class of Number, other. I'm more interested in making sure that someone _can_ easily define ℝ as a type name than in providing that by default.
Re: CPAN -- moving forward
Mark Overmeer wrote: A pity you didn't want to read the paper. I have better things to do with my life than read your 30-page paper. I'd rather participate in a consensus process where I feel I can make a difference. Please clarify ... how would you specify that? And how would you denote ranges of conflicting packages? Well, maybe start with putting that in your wishlist. And conflicting/dependencies in licenses? How would you resolve dependency conflicts? Design human intervention in this process of dependency processing. [big snip] My wiki page was purposely only an initial step. I don't believe in working in isolation for days or weeks and then handing down a massive ready-made solution to the masses. I offer a small, incremental step on top of Synopsis 22 and hope that it is useful. Daniel.
Re: CPAN -- moving forward
Em Sáb, 2009-05-30 às 22:54 +0200, Daniel Carrera escreveu: In the hopes of helping the CPAN discussion move forward, in the direction of tangible work, I have made a wiki page with a proposal: Please read the Basics section, which is quite short. The main point of this section is to divide the issue into three parts: Daniel, The leap you make from the source package to the different binary formats is overlooking a lot of details. It would be interesting if you could take a look in the previous discussions on the matter. 1) A package format. This is supposed to be a source format, but different from current model used in CPAN, it's pretty clear already that it can't include a build system, like ExtUtils::MakeMaker or Module::Install. There's already some consensus that this source package format should describe what it contains, not how it should be built or installed. For instance, it should only say something like in the lib directory there's a set of STD Perl 6 modules that don't require any low-level integration. 2) A low-level install tool, analogous to rpm or dpkg, that converts the package (2) into a local package format (rpm, deb, ebuild). 2.0) Build tool Before installing it, you need to create a installable package, or binary package (that's what CPAN plus does today). The thing here is that the process of transforming the source package into an installable package will be specific to the Perl implementation, to the Operating System and to the vendor of the Operating system. That basically means it's implementation specific, and each implementation should do its best to provide that support. For instance, rakudo might want to compile the modules to Parrot Bytecode, while mildew might want to compile down some things to C. If you're in an OS that provides a rich package management system, it means you can generate native packages, otherwise you need to implement the next step as well, which is: 2.5) Install tool In systems where we don't generate native packages, we need a package manager on our own. It should be capable of taking any installable package and making it available in the system, checking all dependencies and other requirements.. 3) A high-level install tool, analogous to yum or apt, that uses the CPAN network and resolves dependencies. I do think this is very much implementation-specific, for instance, in Debian, with little work you could simply use apt-build to get your packages built and available for installation with apt-get. In summary, The part 1 is really the critical issue, 2.0, 2.5 and 3 are mostly implementation specific and are considerably easier to adapt than the things in the part 1. We do need to find a very solid way of describing what the package contains in order that implementation-specific build tools can make them work. daniel
Re: CPAN -- moving forward
Daniel Ruoso wrote: The leap you make from the source package to the different binary formats is overlooking a lot of details. It would be interesting if you could take a look in the previous discussions on the matter. I'll be happy to. I was just trying to make a small iterative step on Synopsis 22. I know that there is a wide gap between that and binary formats. But I wouldn't do anyone any favours if I spend a lot of time on my own trying to make a complete solution. At least now you can point me to the relevant discussion and I'll be happy to read it. I just need a URL link. 1) A package format. This is supposed to be a source format, but different from current model used in CPAN, it's pretty clear already that it can't include a build system, like ExtUtils::MakeMaker or Module::Install. There's already some consensus that this source package format should describe what it contains, not how it should be built or installed. For instance, it should only say something like in the lib directory there's a set of STD Perl 6 modules that don't require any low-level integration. Ok. Thanks for the info. Notice that I didn't assume anything one way or the other on the page I wrote. Just some additions to S22 (mainly the manifest file). I tried not to make many assumptions precisely because I don't know the previous discussion. 2.0) Build tool Before installing it, you need to create a installable package, or binary package (that's what CPAN plus does today). The thing here is that the process of transforming the source package into an installable package will be specific to the Perl implementation, to the Operating System and to the vendor of the Operating system. That basically means it's implementation specific, and each implementation should do its best to provide that support. For instance, rakudo might want to compile the modules to Parrot Bytecode, while mildew might want to compile down some things to C. Seems logical. If you're in an OS that provides a rich package management system, it means you can generate native packages, otherwise you need to implement the next step as well, which is: 2.5) Install tool In systems where we don't generate native packages, we need a package manager on our own. It should be capable of taking any installable package and making it available in the system, checking all dependencies and other requirements.. Yes, certainly. 3) A high-level install tool, analogous to yum or apt, that uses the CPAN network and resolves dependencies. I do think this is very much implementation-specific, for instance, in Debian, with little work you could simply use apt-build to get your packages built and available for installation with apt-get. In Debian there is both apt-get and aptitude. Two different implementations of a high-level package manager wrapped around dpkg. In the RPM world there is yum and urpmi as well. In summary, The part 1 is really the critical issue, 2.0, 2.5 and 3 are mostly implementation specific and are considerably easier to adapt than the things in the part 1. We do need to find a very solid way of describing what the package contains in order that implementation-specific build tools can make them work. Yes, indeed. Most of what I put in the wiki page is an iterative step on the package format described in Synopsis 22. Should we start talking about the package format then? Daniel.
Re: CPAN -- moving forward
On Sun, May 31, 2009 at 12:22:31AM +0200, Daniel Carrera wrote: Mark Overmeer wrote: A pity you didn't want to read the paper. I have better things to do with my life than read your 30-page paper. I'd rather participate in a consensus process where I feel I can make a difference. What is this, a contest to see who can be snippier? Please clarify ... how would you specify that? And how would you denote ranges of conflicting packages? Well, maybe start with putting that in your wishlist. And conflicting/dependencies in licenses? How would you resolve dependency conflicts? Design human intervention in this process of dependency processing. [big snip] My wiki page was purposely only an initial step. I don't believe in working in isolation for days or weeks and then handing down a massive ready-made solution to the masses. I offer a small, incremental step on top of Synopsis 22 and hope that it is useful. People have different work styles. Part of consensus building is not expecting everyone to think the same way you do. We try to put both the tortoises and hares to work here, but each has to work at their own pace, and some temporal displacement necessarily results. A healthy community can put up with a certain amount of tension and compression. It's called tensegrity when it helps hold us all together. It's probably called something else when it drives us apart. Please aim for the tensegrity, because I don't want to figure out what to call the other. Larry
Re: renaming or adding some operators
On Sat, May 30, 2009 at 04:50:02PM -0500, John M. Dlugosz wrote: Note that ≥ and ≤ are bidi mirroring characters in the Unicode Properties. So if someone were crazy enough to use them as brackets, then the digraph equivalent should work as well, right? No, they'd only function as digraphs in the infix syntactic category. Bracketing chars are outside of any such category. Perl 6 is very careful to recognize macro-like things only where they would make sense for their particular category. That's part of the magic of STD, that it generates different lexers at each choice point in the grammar, and does so just-in-time, based on the current language definition. Now, within a particular syntactic category you can have conflicts, and with other categories that are ORed in to it; for example, prefixes share LTM space with terms and circumfixes, for instance. So we do have to be a little careful about defining other termish things that start '' though, since '«'can introduce a term. That's one of the reasons heredocs don't use that notation any more. But that only interferes with spots where a term is expected. There is a corresponding conflict at postfix position, but the two are causally unrelated. I hesitate to call them digraphs even, since to me that kinda implies they're translated without regard to context, as by a preprocessor, and they're not. I'm more interested in making sure that someone _can_ easily define ℝ as a type name than in providing that by default. Indeed, getting close enough is one of the underlying design themes of Perl 6. As to whether we're close to do the operator aliasing in a mostly digraphic fashion, I'm not sure. Currently a macro for an infix would be given the AST of the left argument to play with, and the opportunity to influence the parse of its right argument. This is overkill for a mere alias. We may need to distingish single-token substitution macros from macros that govern the ASTs around them in order to make such operator canonicalization painless, I think. Larry
Re: renaming or adding some operators
Larry Wall larry-at-wall.org |Perl 6| wrote: Indeed, getting close enough is one of the underlying design themes of Perl 6. As to whether we're close to do the operator aliasing in a mostly digraphic fashion, I'm not sure. Currently a macro for an infix would be given the AST of the left argument to play with, and the opportunity to influence the parse of its right argument. This is overkill for a mere alias. We may need to distingish single-token substitution macros from macros that govern the ASTs around them in order to make such operator canonicalization painless, I think. Yes. A context-sensitive (e.g. infix) token-for-token exchange that is easily defined as such without letting the user get into too much trouble. If the operator names can read this table too, then it won't matter which is the real one. Someone can declare an overloaded operator with either name, as well as call it with either name.
Re: The game of life
On Thu, May 28, 2009 at 5:58 PM, John M. Dlugosz
2nb81l...@sneakemail.com wrote:
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?
That was a big part of it... I'm glad Mark posted the APL snippet
because it got me to finally read up on the language that's been at
the back of my mind. Plus it's useful for p6 language discussion. APL
(and a successor, J) may still have a few tricks to lend.
One APL feature already supported in p6 is the ability to use
operations on vectors of any dimension, even mixing dimensions.
Hyperoperators let us add two arrays easily, or multiply every element
in one array by a scalar, etc. (I haven't yet figured out
multi-dimensional arrays in Rakudo, are they implemented?)
Though I'm not quite sure that S03 covers some of the different-dimension cases.
my @table=
(1,2,3;
4,5,6); # is this the syntax to create 2d array?
my @row=4,0,1;
my @column=
(2;
-1);
my @added_to_each_row = @row + @table; # is that (4,3,4 ; 8,5,7) ?
my @col_products = @column * @table; # is that (2,4,6 ; -4,-5,-6) ?
Which also brings up a small point in S09, is it OK to declare an
array with 0 elements in some directions, eg
my @month_calendar[7;5]; # seven days across, five weeks down
my @week[7;0];# one line across in the calendar. Same as @week[7]
my @Sundays[0;5]; # one line down. Different from @Sundays[5]
Another concept mentioned in the APL wiki page are reduction operators
that reduce the dimensionality of an array by one. For a
one-dimensional array, APLs and Perl6's reductions are the same- [+]
1,2,3 = 6 - run the op through all values, return a single value.
But in APL, you can reduce the addition operator on a 2-dimensional
array either by columns or by rows and get a 1-dimensional column or
row of sums. Or take a 3D array and get a rectangle of sums.
Presumably APL also lets you reduce a multi-dimensional vector down to
a grand total as well. I'm not very far in the p6 synopsis so I don't
know if that's a built-in possibility, but I didn't see it mentioned
in S03.
Less general is an APL operator (actually different ops for different
directions, IMO should be a single operator) that rotates vectors, eg
rotate left 2 transforms 1,2,3,4,5 = 3,4,5,1,2- and it also works
for arrays of any dimension. For some reason APL has 2 (or more?)
operators for rotating vectors, depending on which direction, eg
left-right vs up-down. I'd expect that a rotate operator would take a
vector saying the direction magnitude of the rotation. Maybe APL
does do that, maybe perl6 does too, I'm not very far in the synopses.
It's been fun reading... if you are curious start with the APL
wikipedia page http://en.wikipedia.org/wiki/APL_(programming_language)
- install fonts as needed, they're also referenced from there. Then
move on to the links posted earlier about the game of life, they do a
great job of explaining the one-liners.
http://aplwiki.com/GameOfLife - short version, one generation, more
descriptive variable names
http://catpad.net/michael/apl/ - longer version, which, instead of
using a loop, makes a string copy of the short version N times and
'eval's that.
The wiki page for J, Iverson's APL successor
(http://en.wikipedia.org/wiki/J_programming_language ) has an
educational quicksort 1-liner:
quicksort=: (($:@(#[) , (=#[) , $:@(#[)) ({~ ?...@#)) ^: (1#)
which I think can be transformed into a more readable perl6 one-liner.
May try it out sometime...
J's wiki has a page of examples that makes me think, if I want to get
started in that language, there's a ton of good examples:
http://www.jsoftware.com/jwiki/Essays - enviable! One of the
programmer virtues... I'd like to see the better perl6 code collected
in a wiki too.
