[perl6/specs] 44511d: [S06] rw parameters can never be optional
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 44511d749bbbae4286dd1675ad6264c72acd2433 https://github.com/perl6/specs/commit/44511d749bbbae4286dd1675ad6264c72acd2433 Author: TimToady Date: 2010-11-16 (Tue, 16 Nov 2010) Changed paths: M S06-routines.pod Log Message: --- [S06] rw parameters can never be optional You can't put a default on a parameter marked "rw".
Re: base-4 literals
Larry (>>), Dan (>):
>> The lack of base 4 numbers in Real Life seems to me to justify the
>> convention. Do you have a use case?
>
> Real Life on Earth is base-4 coded :-p
Heh. :)
> hey, do we have tr/// equivalent already?
In S05? Yes, since the get-go.
In Rakudo? You do know that it's freely available, right? :)
(Sometimes the lack on grounding on this list in actual, working
implementations has me flummoxed.)
$ perl6 -e 'say "GATTACA".trans("TCAG" => "0123")'
3200212
The tr[][] form doesn't work yet, though.
// Carl
Re: base-4 literals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 17 2010, at 05:16 , Larry Wall wrote: > On Tue, Nov 16, 2010 at 12:11:01PM -0800, Darren Duncan wrote: > : Carl Mäsak wrote: > : >Darren (>): > : >>While I haven't seen any prior art on this, I'm thinking that it would be > : >>nice for a sense of completeness or parity to have an 0a syntax specific > to > : >>base-4 that complements the 4 that we have now for bases 2,8,16,10. > : > > : >You're joking, right? > : > : No, its a serious idea, just not so conventional. -- Darren Duncan > > The lack of base 4 numbers in Real Life seems to me to justify the > convention. Do you have a use case? Real Life on Earth is base-4 coded :-p FYI we already have :4<12301230> which is ALREADY supported. If you want to use ACGT instead, just apply grammar or tr... hey, do we have tr/// equivalent already? Dan the Base-4 Coded Creature -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkzi+RoACgkQErJia/WXtBvXUACfeqzcxEpkEL5SrPgcwAwkYK+t LhwAni5fE4lADkIkp/wHgXWZm65FYJco =1QQG -END PGP SIGNATURE-
Re: base-4 literals
Larry Wall wrote:
On Tue, Nov 16, 2010 at 12:11:01PM -0800, Darren Duncan wrote:
: Carl Mäsak wrote:
: >Darren (>):
: >>While I haven't seen any prior art on this, I'm thinking that it would be
: >>nice for a sense of completeness or parity to have an 0a syntax specific to
: >>base-4 that complements the 4 that we have now for bases 2,8,16,10.
: >
: >You're joking, right?
:
: No, its a serious idea, just not so conventional. -- Darren Duncan
The lack of base 4 numbers in Real Life seems to me to justify the
convention. Do you have a use case?
Actually, the primary case I was thinking of was with blobs.
S02 currently says:
* Blob literals look similar to integer literals with radix markers, but use
curlies instead of angles:
:2{0010_1110_1000_10} a blob1, base 2, 1 bit per column
:4{}a blob2, 2 bits per column
:8{5235 0437 6} a blob3, 3 bits per column
:16{A705E} a blob4, 4 bits per column
Whitespace and underscores are allowed but ignored.
Now, granted, all of the above examples use :N format, but if 0a formats
actually are supported for blobs as I would expect given the above description,
like this:
0b{0010_1110_1000_10} a blob1, base 2, 1 bit per column
0o{5235 0437 6} a blob3, 3 bits per column
0x{A705E} a blob4, 4 bits per column
... then for blobs in particular, I had thought it would be appropriate to have
a base-4 version.
But if there is no agreement, then so be it, I will retract my proposal.
-- Darren Duncan
Re: base-4 literals
> : >Darren (>): > : >>While I haven't seen any prior art on this, I'm thinking that it would be > : >>nice for a sense of completeness or parity to have an 0a syntax specific > to > : >>base-4 that complements the 4 that we have now for bases 2,8,16,10. > : > > : >You're joking, right? > : > : No, its a serious idea, just not so conventional. -- Darren Duncan > > The lack of base 4 numbers in Real Life seems to me to justify the > convention. Do you have a use case? My reaction parallels that of Carl and Larry. Isn't the ":4<222>" syntax sufficient? Unless you're manipulating a lot of bitstreams in pairwise increments, I don't see the point. Orthogonality for its own sake is not very Perlish... -- Mark J. Reed
Re: base-4 literals
On 11/16/2010 08:46 PM, Darren Duncan wrote: > So, any thoughts on this? A wonderful application for a module. And don't we already have :4<1230> for base 4 literals? With a simple scheme that can be used up to base 36? Cheers, Moritz How thinks that Perl 6 should really become smaller over time, not larger
Parrot 2.10.0 "Pesquet's" released!
On behalf of the Parrot team, I'm proud to announce Parrot 2.10.0 "Pesquet's". Parrot is a virtual machine aimed at running all dynamic languages. Parrot 2.10.0 is available on Parrot's FTP site (ftp://ftp.parrot.org/pub/parrot/releases/devel/2.10.0/), or follow the download instructions at http://parrot.org/download. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Git on our source code repository to get the latest and best Parrot code. SHA digests for this release are: 159249a3a6025677353c393e4878e800874a466fdc6c049a6e081876137b669a parrot-2.10.0.tar.gz 4fa2b042b14ceefc0ce56295cb8f5b6575308a8fba781668812920dfb7180442 parrot-2.10.0.tar.bz2 Parrot 2.10.0 News: - Core + We are on github now! https://github.com/parrot/parrot + Configure, build and test subsystems were made Git-aware + New parrot_config key 'osvers' which contains Operating System Version information + Updated to the latest nqp-rx + A proper exception is now thrown on IO read errors + Garbage Collector optimizations and memory leak fixes + Deprecated charset ops were removed + Configure system learned to detect IPv6 + The mk_language_shell and create_language scripts have not yet been ported to Git. - Documentation + How To Use Git to work on Parrot https://github.com/parrot/parrot/blob/master/docs/project/git_workflow.pod + Git Terminology https://github.com/parrot/parrot/blob/master/docs/project/git_terminology.pod - Platforms - Testing + Increased coverage on: String, FixedBooleanArray, PMCProxy, LexPad - Community + Macports portfile updated to 2.6.0 + A Fedora package for PL/Parrot ( postgresql-plparrot ) was created This package allows you to write stored procedures for PostgreSQL in PIR or Rakudo Perl 6 http://pl.parrot.org + Parrot Foundation is teaming up with The Perl Foundation and taking part in Google Code-In 2010. Learn about it and how to get involved here: http://trac.parrot.org/parrot/wiki/GoogleCodeIn2010Tasks http://leto.net/perl/2010/11/parrot-foundation-the-perl-foundation-google-code-in.html Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next release is 21 December 2010. Enjoy!
Re: base-4 literals
On Tue, Nov 16, 2010 at 12:11:01PM -0800, Darren Duncan wrote: : Carl Mäsak wrote: : >Darren (>): : >>While I haven't seen any prior art on this, I'm thinking that it would be : >>nice for a sense of completeness or parity to have an 0a syntax specific to : >>base-4 that complements the 4 that we have now for bases 2,8,16,10. : > : >You're joking, right? : : No, its a serious idea, just not so conventional. -- Darren Duncan The lack of base 4 numbers in Real Life seems to me to justify the convention. Do you have a use case? Larry
Re: base-4 literals
Carl Mäsak wrote: Darren (>): While I haven't seen any prior art on this, I'm thinking that it would be nice for a sense of completeness or parity to have an 0a syntax specific to base-4 that complements the 4 that we have now for bases 2,8,16,10. You're joking, right? No, its a serious idea, just not so conventional. -- Darren Duncan
Re: base-4 literals
Darren (>): > While I haven't seen any prior art on this, I'm thinking that it would be > nice for a sense of completeness or parity to have an 0a syntax specific to > base-4 that complements the 4 that we have now for bases 2,8,16,10. You're joking, right? // Carl
base-4 literals
A simple proposal ... While I haven't seen any prior art on this, I'm thinking that it would be nice for a sense of completeness or parity to have an 0a syntax specific to base-4 that complements the 4 that we have now for bases 2,8,16,10. With that addition, the line-up would look like this: 0b - binary (2) 0t - tetra (4) 0o - octal (8) 0d - decimal (10) 0x - hexidecimal (16) Another alterative for 0t is 0q (quad) but I like the look of 0t more because that character's glyph doesn't have a descender like the other 4. With numeric literals, it means we have an 0a form for every power of 2 between 1 and 4, rather than skipping one. Even more important, with blob literals, we have an 0a form for every power likely to be used period, since for all practical purposes they can only take literals in powers of 2 anyway. So, any thoughts on this? -- Darren Duncan
[perl6/specs] 977d92: [S02] clarify * vs *-1 semantics for globbish ops
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 977d920241c26aec8913d5f37c218948b28bbb23 https://github.com/perl6/specs/commit/977d920241c26aec8913d5f37c218948b28bbb23 Author: TimToady Date: 2010-11-16 (Tue, 16 Nov 2010) Changed paths: M S02-bits.pod Log Message: --- [S02] clarify * vs *-1 semantics for globbish ops Globbish ops like .. and xx do not autocurry on Whatever but do autocurry on WhateverCode. Also mention that assignment and smartmatching don't autocurry because they're primitive pseudo-operators.
[perl6/specs] 8b43df: random errant "or"
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 8b43df0b09582837dfb91bf69f3d65ce966cad35 https://github.com/perl6/specs/commit/8b43df0b09582837dfb91bf69f3d65ce966cad35 Author: Jonathan Scott Duff Date: 2010-11-16 (Tue, 16 Nov 2010) Changed paths: M S09-data.pod Log Message: --- random errant "or"
[perl6/specs] c0b084: Spring before Summer usually :)
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: c0b0845586be1d1fe07106cd2bb13acf56f13a20 https://github.com/perl6/specs/commit/c0b0845586be1d1fe07106cd2bb13acf56f13a20 Author: Jonathan Scott Duff Date: 2010-11-16 (Tue, 16 Nov 2010) Changed paths: M S09-data.pod Log Message: --- Spring before Summer usually :)
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
Jon Lang wrote:
Darren Duncan wrote:
This said, I specifically think that a simple pair of curly braces is the
best way to mark a Set.
{1,2,3} # a Set of those 3 elements
... and this is also how it is done in maths I believe (and in Muldis D).
In fact, I strongly support this assuming that all disambiguation eg with
hashes can be specified.
That would be great.
Glad you agree.
Sets built from multi-dimensional arrays migt be a problem:
{1, 2, 3: 4, 5, 6}
Does that even work? I thought the colon, or is it a semicolon, only had that
meaning in a delimited list like () or [].
In any event, I don't believe there is such a thing as a multi-dimensional set
in that way. Unless you have a concept of multi-dimensional Hash keys, and then
there might be an analogy.
As for bags, well I think that is where we could get fancier.
But *no* doubling up, as we don't want to interfere with nesting.
Instead, it is common in maths to associate a "+" with set syntax to refer
to bags instead.
So, does Perl already ascribe a meaning to putting a + with various
bracketing characters, such as this:
+{1,2,2,5} # a Bag of 4 elements with 2 duplicates
+{} # an empty Bag, unless that already means something
So would the above try to cast the collection as a number, or take the count
of its elements, or can we use something like that?
I'd expect +{...} to count the elements.
Something else I just thought of, and my main reason for writing this reply, is
other options.
Firstly, and I don't necessarily like this option, maybe we could use the simple
curly-brace pair to mean something more general that can be treated as either
a Set or a Bag depending on context. At least from my brief look around, it
appears that maths use the same {foo, bar, baz} syntax to denote both sets and
bags. In some ways it would be like how Perl has the generic "(foo, bar, baz)"
syntax, which remembers order but isn't an Array. We certainly can't use the
presence of duplicates in the {...} to pick Set vs Bag because there could
legitimately be duplicates or not duplicates in the literals for both,
especially if any of the list items are variables and we won't know until
runtime whether any duplicate each other or not.
I still think the better option is to have slightly different looking syntax for
the two. I still prefer Set being the plain brace pair and a Bag being that
plus something extra. It seems that a leading + or ~ or ? is out because those
have established meanings as treating what they're next to in num/str/bool
context, so something else. But it really should be a leading symbolic.
The differentiator needs to be be leading, not trailing; end-weight is bad.
I think that having the marker character /inside/ the curly braces actually
gives us more choices and would cut down on syntactic conflicts, because then we
can basically pick anything that isn't a symbolic prefix unary.
Barring a better suggestion, I suggest the greater-than symbol.
So:
{1,2,3,3,4} # 4-element Set
{>1,2,3,3,4} # 5-element Bag
I think that looks different than anything else we have, and the greater-than
could be a mnemonic that there is "more" in here.
Moreover, the different appearance means we could use => to indicate a count of
that element's contribution to its count, "{>1,2,3=>2,4}", without there being a
confusion with a Hash.
That said, I like the "+" most when differentiating a Bag from a Set, but we
have that symbolic unary "+" which could interfere with it.
-- Darren Duncan
