>
>[Update: Would now need to be <+ - [A..Za..z]> to avoid ambiguity
>with "Texas quotes", and because we want to reserve whitespace as the
> first
>character inside the angles for other uses.]
>
>
Why isn't that:
/<+ alpha - [A-Za-z]>
usands. The ability of Erlang (and go
an IO and many others) to spawn 100,000 threads makes an impressive
demo for the uninitiated, but finding practical uses of such abilities
is very hard.
It may be true that there are only a small number of basic algorithms
that benefit from m
Tom Christiansen wrote:
> Exegesis 5 @ http://dev.perl.org/perl6/doc/design/exe/E05.html reads:
The Exegesis are historical documents, and should be treated as such.
(If any volunteer is around, submitting a patch that puts "HISTORICAL
DOCUMENT ONLY" in big red letter on these p
with "Texas quotes", and because we want to reserve whitespace as the first
character inside the angles for other uses.]
Explicit character classes were deliberately made a little less convenient
in Perl 6, because they're generally a bad idea in a Unicode world. F
nigelsande...@btconnect.com wrote:
There are very few algorithms that actually benefit from using even low
hundreds of threads, let alone thousands. The ability of Erlang (and go
an IO and many others) to spawn 100,000 threads makes an impressive demo
for the uninitiated, but finding
Author: lwall
Date: 2010-05-17 18:08:01 +0200 (Mon, 17 May 2010)
New Revision: 30667
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05] Disrequire retroactive semantics on :ii and :aa
Modified: docs/Perl6/Spec/S05-regex.pod
Author: lwall
Date: 2010-05-17 03:18:51 +0200 (Mon, 17 May 2010)
New Revision: 30665
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] make more explicit that doctrine that ~~ topicalizes, and
remove smartmatch table fossils that automatically fall out from it
Modified: docs/Perl6/Spec
e node, we'll be looking at the ability to invoke hundreds
(or thousands) of threads on a single SMP machine.
There are very few algorithms that actually benefit from using even low
hundreds of threads, let alone thousands. The ability of Erlang (and go an
IO and many others) to spawn 100,
a reentrant
interpreter, and the ability to spawn one in an OS thread,
all the other bits can be built on top. But unless you have that
ability,
whilst the others can be constructed, the cannot make
use of SMP. Eg. They cannot scale.
Okay, this is an important point... Having a reentrant interpreter
best as we can, and hope we can make some of the hard decisions
> right enough to allow future evolution.
>
> I am very glad to see several passionate but mostly-rational
> people thrashing this out here; the future is many-core, and none
> of us understand the implications of that
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
> After reading this thread and S17, I have lots of questions and some
> remarks.
>
> Parallelism and Concurrency could be considered to be two different things.
>
> The hyperoperators and junctions imply,
Em Sex, 2010-05-14 às 18:13 +0100, nigelsande...@btconnect.com escreveu:
> The point I(we)'ve been trying to make is that once you have a reentrant
> interpreter, and the ability to spawn one in an OS thread,
> all the other bits can be built on top. But unless you have that abili
* specific threading model designed to
support all the Perl 6 features in a scalable way.
The point I(we)'ve been trying to make is that once you have a reentrant
interpreter, and the ability to spawn one in an OS thread,
all the other bits can be built on top. But unless you have that abil
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
: After reading this thread and S17, I have lots of questions and some
: remarks.
:
: Parallelism and Concurrency could be considered to be two different things.
:
: The hyperoperators and junctions imply, but do not require
Em Sex, 2010-05-14 às 15:48 +0400, Richard Hainsworth escreveu:
> The less, or rather the more abstract, the specification in perl6, the
> less likely perl6 will 'age'.
I think the important thing to realize here is that the Perl 6 language
keeps its definitions mostly abstract. Junctions, Hyper O
After reading this thread and S17, I have lots of questions and some
remarks.
Parallelism and Concurrency could be considered to be two different things.
The hyperoperators and junctions imply, but do not require, parallelism.
It is left for the implementors to resolve whether a single or
... so here goes the
new version.
0 - No memory is shared between threads, so no locking is necessary.
1 - A value and a coroutine always belong to a thread, thus naturally
implementing synchronized access to data.
2 - Coroutines are, conceptually, the equivalent to green threads,
runnin
One more idea: could you implement the sort of thing being asked for
by means of a buffer? That is, what's the difference between the
bitset being asked for and a Buf[boolean]? And could those
differences be addressed by composing a Buf[boolean] into a more
appropriate role?
Note also that
On Wed, 7 Apr 2010, yary wrote:
> 2010/4/6 Larry Wall :
> > Set(Read | Write) # bogus, R|W is really 3 sets, R, W, and RW!
> > Set(Read & Write) # okay, can only represent RW
>
> Set(A | B) doesn't seem so bogus to me, if what you want is the power
> set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 7, 2010, at 00:52 , Larry Wall wrote:
more syntactic and/or semantic sugar. It's just a bit awkward, after
you say:
enum Permissions ;
subset Perms of Set of Permissions;
that the name of the single-member sets are
Perms
2010/4/6 Larry Wall :
> Set(Read | Write) # bogus, R|W is really 3 sets, R, W, and RW!
> Set(Read & Write) # okay, can only represent RW
Set(A | B) doesn't seem so bogus to me, if what you want is the power
set- not the original posters intent, but reasonable in other
c
> We could make enum declarators even more like constant declarators
> by using a pseudo assignment. Then we could use = instead of parens:
>
> enum Perms = Z=> 1,2,4...*;
Hmm. That doesn't seem very like constant declarators. In a
constant declarator,
the constant ap
# Error
I'm now strongly convinced that a module is the right answer here. We
have the need for a datatype that is essential is a couple of domains,
but much better handled via Sets in most other contexts. So it's
inherently a special-purpose datatype, and hence not appropriate i
: already possible with the language spec as written.
You're right, though you're reaching for the wrong meta-operator, since
hypers have parallel and run-to-completion semantics, and therefore
don't like infinite lists. Instead, you want a nice, ordered, lazy,
"zipwith". In
Damian Conway wrote:
> I do like the idea of being able to specify the sequence of values of an
> enumeration by using a series of some kind.
>
> And I must say the one that feels most natural is the one that plays on
> the equivalence of underlying equivalence of enums and co
PERM_NAMES = { PERM_WRITE => 'Write',
>PERM_READ => 'Read',
>PERM_EXEC => 'Exec' };
> subset Perm of Int where * < 8;
Sure. This certainly works, but the technique requires the developer to
hard-code each
e idea is that an enum of something like PowersOf2 would
> be smart enough not to use values that aren't in the 'of' type.
I do like the idea of being able to specify the sequence of values of an
enumeration by using a series of some kind.
And I must say the one that feels
age the use of proper set
> abstractions for this purpose, so long as the long-suffering hardware
> engineers can still easily convert the final set to an appropriate
> bit-pattern when it's time to pump the results out to the hardware.
The thing that bugs me is that sets have w
On Tue, Apr 06, 2010 at 10:19:15PM -0700, Damian Conway wrote:
: Larry concluded:
:
: > I do freely admit that most Perlfolk are not used to thinking of
: > permissions in terms of set theory. But as I said, we're looking at
: > kind of a strange use case here, and perhaps not
Larry concluded:
> I do freely admit that most Perlfolk are not used to thinking of
> permissions in terms of set theory. But as I said, we're looking at
> kind of a strange use case here, and perhaps not typical of the kinds
> of sets of small numbers that people will be us
On Tue, Apr 06, 2010 at 08:47:11PM -0700, Geoffrey Broadwell wrote:
: First: what Damian said.
:
: Second: Whatever syntax people come up with has to make it easy and
: type-safe to name particular combinations of those bits.
:
: In other words, you should be able to make a bitset with Unix
On Tue, Apr 06, 2010 at 08:31:24PM -0700, Damian Conway wrote:
: An issue came up in a class I was teaching today...
:
: There doesn't seem to be an easy way to create a type that allows a set
: of enumerated bit-flags *and* all the combinations of those flags...and
: nothing else.
:
First: what Damian said.
Second: Whatever syntax people come up with has to make it easy and
type-safe to name particular combinations of those bits.
In other words, you should be able to make a bitset with Unix-style
permissions:
OTHER_EXECUTE
OTHER_WRITE
OTHER_READ
An issue came up in a class I was teaching today...
There doesn't seem to be an easy way to create a type that allows a set
of enumerated bit-flags *and* all the combinations of those flags...and
nothing else.
For example:
enum Permissions ( Read => 0b0001, Write => 0b0010, Exe
l
concept, is a pale shadow of where Boolean Algebra has developed since. In
particular there are things call power sets, and a field using set
intersection and union over those has the same algebraic properties as the
original "algebra of logic", but not with just two "true"
that naturally forms a
>> list, maybe.
>
>A discrete non-finite set is isomorphic to the set of integers.
>
>This implies that you can pick an ordering, although perhaps not one that is
>computational useful. E.g. rational numbers can be mapped onto integers by
>laying them out
isomorphic to the set of integers.
This implies that you can pick an ordering, although perhaps not one that is
computational useful. E.g. rational numbers can be mapped onto integers by
laying them out in a 2D array, much like Gauß's complex integers, and then
walking diagonally in one qua
On Sun, 14 Mar 2010, Jon Lang wrote:
> Ruud H.G. van Tol wrote:
> > Did you consider "discrete"?
>
> I think that "Discrete" could work quite well as the role that
> encapsulates the ways in which Integer and Gauss are alike. It may
> even be genralizable
in the sense of the calculus that truly has an
> infinite number of values.
The set of integers is both discrete and infinite. Likewise rationals
and all the other "countable" sets.
The main thing that discrete sets have that continuous sets don't is
the ability to map them exactly
At 18:14 -0800 3/14/10, Jon Lang wrote:
>There are discrete things that are not ordered (such as gaussian
>integers), and there are ordered things that are not discrete (such as
>real numbers or strings).
The word discrete as in "atoms are the discrete view of matter"
expect that a third-party module should be able to effectively define a
role that would conceptually cover both a core type as well as types of their
own, which they can then use, even though the definition of the core type
doesn't compose that role itself.
So then they get the same functionali
.
There are discrete things that are not ordered (such as gaussian
integers), and there are ordered things that are not discrete (such as
real numbers or strings). As well, I was using the term "Discrete" as
shorthand for "DiscreteNumber", just as "Real" can be thoug
Jon Lang wrote:
Ruud H.G. van Tol wrote:
Did you consider "discrete"?
I think that "Discrete" could work quite well as the role that
encapsulates the ways in which Integer and Gauss are alike. It may
even be genralizable beyond that, although there might be some discor
Ruud H.G. van Tol wrote:
> Did you consider "discrete"?
I think that "Discrete" could work quite well as the role that
encapsulates the ways in which Integer and Gauss are alike. It may
even be genralizable beyond that, although there might be some discord
between th
Darren Duncan wrote:
For the integer version, my understanding is that number theory already
provides a suitable term, "Gaussian integer", which is a complex number
whose real and imaginary parts are both integers.
So I suggest using "Gaussian" as the name option for
;complex".
Is Numeric intended to have a guarantee of commutability? Ie, is it a ring?
Or, put another way, would a Quaternion be a Numeric?
DD> Or maybe better yet for completion sake, make "Gaussian" a role and
DD> something like "Gaus" the type or something.
Wasn’t
Jon, thanks for your feedback; it was both informative and supportive.
Jon Lang wrote:
Darren Duncan wrote:
2. There doesn't seem to be a role for "complex" as there is for "integer"
or "rational" or "real" or "numeric". So, if th
Darren Duncan wrote:
> 2. There doesn't seem to be a role for "complex" as there is for "integer"
> or "rational" or "real" or "numeric". So, if the boxed Perl complex number
> is called "Complex" and the machine native
Follow-up, ...
4. If "Integral" is better called "Integer", or regardless ...
Would "Numeric" be better called "Number"? Would there by any objection to
renaming it such? What are advantages of the former over the latter?
Basically, same idea, if we're going more for nouns or adjectives ro
So, I've been looking more closely at Perl's native value types and associated
roles, and there are a few matters of their naming or availability that I have
questions or suggestions on.
1. As a general observation, I note that it is a common pattern for basic Perl
6 value types t
On Mon, Feb 01, 2010 at 06:12:16PM -0800, Jon Lang wrote:
: Larry Wall wrote:
: > But also note that there are several other ways to predeclare
: > types implicitly. The 'use', 'require', and 'need' declarations
: > all introduce a module name that is
Please find:
http://lith-ology.blogspot.com/2010/02/seven-days-between-parrot-and-camel.html
Lithos
Larry Wall wrote:
> But also note that there are several other ways to predeclare
> types implicitly. The 'use', 'require', and 'need' declarations
> all introduce a module name that is assumed to be a type name.
Just to clarify: it's possible to def
On Tue, Feb 02, 2010 at 12:23:50AM +0100, Carl Mäsak wrote:
: Another thing I started thinking about: if Perl 6 professes to be able
: to put on the hat -- syntactically and semantically -- of most any
: other programming language out there, through the use of a simple 'use
: Language::Jav
design error. I'd be happy to chat with anyone who
has an idea about how they could be simplified away and replaced by
something non-ugly.
Another thing I started thinking about: if Perl 6 professes to be able
to put on the hat -- syntactically and semantically -- of most any
other program
ore finally declaring the real B? If so, then I'd consider it
: >> equivalent to my proposed keyword, and thus there'd be no need for the
: >> latter.
: >
: > Yes. And "declaring the real B" doesn't have to be "final", nor
: > does it have t
er's
> code, but it seems inelegant.
I see it as not being much different that what already happens now
in most languages I deal with.
Assume the above lines of code are in different files -- one for A
and one for B. Presumably A has a reason for saying "class B { ... }"
instead o
t
>> equivalent to my proposed keyword, and thus there'd be no need for the
>> latter.
>
> Yes. And "declaring the real B" doesn't have to be "final", nor
> does it have to occur at all (as long as none of the features needed
> from B are ever neede
On Mon, Feb 01, 2010 at 05:55:47PM +0100, Carl Mäsak wrote:
> Is it allowed to do 'class B { ... }' several times in different files
> before finally declaring the real B? If so, then I'd consider it
> equivalent to my proposed keyword, and thus there'd be no need
names.
:
: It's common for people to read a passage twice when encountering
: something unfamiliar. That's on the large level. And even on the small
: level of reading for the first time, people don't read completely
: linearly, "skilled readers make regressions back to material alrea
ncountering
something unfamiliar. That's on the large level. And even on the small
level of reading for the first time, people don't read completely
linearly, "skilled readers make regressions back to material already
read about 15 percent of the time." -
http://en.wikipedia.org/wiki/E
ay "I use self-referential and cyclical type definitions in
Sprixel's (stage0) C# source..." (because I did at one point), but then I
realized I stopped doing that; it worked, but it was a tad too tricksy to
maintain.
So, point taken.
Please don't assume that rakudo's idiosyncracies and design fossils
are canonical. STD does better namespace management in some respects,
particularly in accepting the approved predeclaration form:
class Foo {...}
(and rakudo might now accept this too).
You don't want to
quot;..." in the body of the class -- it
> indicates that we're only declaring the name as being a type,
> and that something else will fill in the details later.
>
It seems to me that this doesn't really solve the problems that will occur
when people start making packages
{ sub foo { B::bar } }
>
> class B { sub bar { A::foo } }
>
> The first line is a literal "..." in the body of the class -- it
> indicates that we're only declaring the name as being a type,
> and that something else will fill in the details later.
That'
B { sub bar { A::foo } }
The first line is a literal "..." in the body of the class -- it
indicates that we're only declaring the name as being a type,
and that something else will fill in the details later.
Pm
Moritz (>), Carl (>>):
>> But on another level, the level of types, Perl 6 makes it fairly
>> *un*natural that the type C refers to the type C, which in
>> turn refers to the type C.
>
> True, and that has also been bothering me quite a bit.
>
> The "sol
Carl Mäsak wrote:
> But on another level, the level of types, Perl 6 makes it fairly
> *un*natural that the type C refers to the type C, which in
> turn refers to the type C.
True, and that has also been bothering me quite a bit.
The "solution" is to always write ::Typename
There's one thing that bugs me ever so slightly. I'll just air it and
happily accept whatever feedback it produces.
This email is somewhat of a third-strike thing: looking back, I've
been muttering over this itch both on IRC and on Twitter during the
past year.
sometimes one-pass
Please find:
http://lith-ology.blogspot.com/2010/01/seven-days-between-parrot-and-camel_26.html
Lithos
Jan 21, 2010 4:04 PM, "Darren Duncan" wrote:
David Brunton wrote:
> I notice that C returns False and deletes the key for a key
> whose value goes to zero or less than zero, issuing a warning in the
> latter case. Is it the case that C always evaluates to False
> in Boolean con
David Brunton wrote:
I notice that C returns False and deletes the key for a key
whose value goes to zero or less than zero, issuing a warning in the
latter case. Is it the case that C always evaluates to False
in Boolean context when negative?
Please restate your question. I don't thi
I notice that C returns False and deletes the key for a key
whose value goes to zero or less than zero, issuing a warning in the
latter case. Is it the case that C always evaluates to False
in Boolean context when negative?
Please find:
http://lith-ology.blogspot.com/2010/01/seven-days-between-parrot-and-camel_15.html
Lithos
Please find:
http://lith-ology.blogspot.com/2010/01/seven-days-between-parrot-and-camel.html
Lithos
Please find:
http://lith-ology.blogspot.com/2009/12/seven-days-between-parrot-and-camel_28.html
Lithos
Please find:
http://lith-ology.blogspot.com/2009/12/seven-days-between-parrot-and-camel_22.html
Lithos
Please find:
http://lith-ology.blogspot.com/2009/12/seven-days-between-parrot-and-camel_13.html
Lithos
Please find:
http://lith-ology.blogspot.com/2009/12/seven-days-between-parrot-and-camel.html
Lithos
[now CC-ing the list, d'oh!]
On Mon, Nov 23, 2009 at 4:33 PM, Geoffrey Broadwell wrote:
> On Mon, 2009-11-23 at 01:15 +0100, Lithos wrote:
>> Today I posted my first attempt at summarizing Perl 6 and Parrot things at
>>
>> http://lith-ology.blogspot.com/
>>
On Mon, 2009-11-23 at 01:15 +0100, Lithos wrote:
> Today I posted my first attempt at summarizing Perl 6 and Parrot things at
>
>http://lith-ology.blogspot.com/
>
> Any comments and corrections welcome!
This is *very* valuable to us. Please keep it up!
-'f
Hello!
Today I posted my first attempt at summarizing Perl 6 and Parrot things at
http://lith-ology.blogspot.com/
Any comments and corrections welcome!
Lithos
Lithos wrote:
I posted my first attempt at summarizing Perl 6 and Parrot things at
http://lith-ology.blogspot.com/
Any comments and corrections welcome!
Looks good so far.
If you intend to do that weekly, it should be a valuable service, like the
summaries done years ago.
I also
Hello!
I posted my first attempt at summarizing Perl 6 and Parrot things at
http://lith-ology.blogspot.com/
Any comments and corrections welcome!
Lithos
he theme will be most welcome.
>>
>> Moritz++ and I were talking about making a graph showing the increase
>> of Perl 6 projects lately. Proto's project.list contains all the
>> pertinent history, so half an hour with git-log and SVG::Plot ought to
>> be able to pro
I gave the talk at OSSBarcamp in Dublin last weekend and it went well.
My sincere thanks to everyone who contributed.
The slides are available at:
http://www.slideshare.net/Tim.Bunce/perl-myths-200909
The graphs and stats charting the continuing growth of perl and the perl
community were
stead of
a SeriesIterator or any other plain Iterator. Is there some reason to
make :by work on Ranges that way instead of being, say, an adverb on
"..."? I can see that it's obvious and useful to get a list by
filling in the values between two endpoints, but that also appli
1.5 { when 1..2 { say 'between one and two' }; say
: >> 'not'; };
: >>rakudo: given 1.5 { when Range.new(from => 1, to => 2, by => 1/3) {
: >> makes me very leery. I know :by isn't actually implemented yet, but what
: >> should it d
On Sat, Sep 19, 2009 at 9:45 PM, David Green wrote:
> On 2009-Sep-19, at 5:53 am, Solomon Foster wrote:
>
> The one thing that worries me about this is how :by fits into it all.
>>rakudo: given 1.5 { when 1..2 { say 'between one and two' }; say
>> '
On 2009-Sep-19, at 5:53 am, Solomon Foster wrote:
On Sat, Sep 19, 2009 at 6:48 AM, Carl Mäsak wrote:
David (>>>),
It sounds like the split personality of Ranges strikes again. I
still think
it makes more sense to have one Series-only type and one Range-
only type,
rather than o
>> No. 2..3 is always a range. It's just list context that turns it into a
>>> list.
>>>
>>>> That seems confusing.
>>
>> It sounds like the split personality of Ranges strikes again. I still think
>> it makes more sense to have one Serie
s it into a
>> list.
>>
>>> That seems confusing.
>
> It sounds like the split personality of Ranges strikes again. I still think
> it makes more sense to have one Series-only type and one Range-only type,
> rather than one Series type and one Range-plus-Series
seems confusing.
It sounds like the split personality of Ranges strikes again. I still
think it makes more sense to have one Series-only type and one Range-
only type, rather than one Series type and one Range-plus-Series type.
-David
> expected, matching 2 or 3, in only one out of the three cases.
>
>
>
>> The case 2..3 (Range) is pretty clear. S03/Smart Matching/ says about
>> Arrays:
>>
>> Any Array lists are comparable@$_ «===» X
>>
>> so it tries to i
(Range) is pretty clear. S03/Smart Matching/ says about
> Arrays:
>
> Any Array lists are comparable@$_ «===» X
>
> so it tries to interpret the LHS as a List and checks for element-wise
> identity => False
>
I think I see where you're going, here: that ra
to the W3C Spec.
Raphael.
>
> François Perrad
>
> >>>
> >>> Tree manipulation:
> >>> http://github.com/wayland/Tree/tree/master
> >>
> >> Thanks. Any reason they're not known to proto?
> >
> > The latter I wasn't r
ation:
>>>> http://github.com/wayland/Tree/tree/master
>>>
>>> Thanks. Any reason they're not known to proto?
>>
>> The latter I wasn't really aware of. It's now added to the list, and
>> wayland has been given a proto commit bit.
>
aware of. It's now added to the list, and
wayland has been given a proto commit bit.
It doesn't work, though. That's probably one reason it wasn't in
proto :). Until either we get role stubs (role foo {...}) or I figure a way
to work around that, it will continue not to work.
thub.com/wayland/Tree/tree/master
>>
>> Thanks. Any reason they're not known to proto?
>
> The latter I wasn't really aware of. It's now added to the list, and
> wayland has been given a proto commit bit.
>
> The former, while apparently a nice effort, doesn't contain any Perl 6
> code as far as I can see.
>
> // Carl
>
>
On Mon, Sep 14, 2009 at 12:15:05PM +0100, Tim Bunce wrote:
> You can find my current draft at http://files.me.com/tim.bunce/65oikg (2.3MB
> PDF)
page 73 - Haskell should be spelled with two Ls
-kolibrie
401 - 500 of 5022 matches
Mail list logo
