Re: Numeric literals, take 1
On Thu, Nov 14, 2002 at 07:58:55PM +0100, Angel Faus wrote: > Hi all, Hi Angel, > This is the numeric literals part, reformated to follow Michael's > outline. My contribution is some copyediting and a few suggestions. Take what you think is worthwhile. > - > =section * Numeric Literals > > =section ** Integer and Decimal literals > > There are many ways to specify literal numeric values in > perl, but they default to base 10 for input and output. s/perl/Perl/ (Aren't we still using the capitalization to distinguish between the interpreter and the language?) > Perl allows you to use the standard scientific notation s/the// > It works just like the standard scientific notation: Delete this phrase; you've already said that this IS standard SN. > the left portion of the C is the coefficient, and the s/the/The/ > right is the exponent, so a number of the form C > is actually intepreted as C. I would suggest using XX for the exponent, so as to have less confusion with the 'e'-as-exponent-marker. Also, add a sentence stating that the exponent marker may be in either case. Then you get: "...right is the exponent, so a number of the form C is actually intepreted as C. You may use either upper- or lowercase 'e' as the exponent marker, so, for example, 3.6e3 is the same as 3.6E3." > For example, the literal C<7.828e6> is interpreted as > C<7823000>. 7828000, as was already pointed out > You can use negative numbers in the exponent side, allowing > you to write very small numbers. "You may write very small numbers by using negative exponents." > =section ** Radix Notation > > For integer numbers, you can represent the literal value > in any other base, using the C syntax. s/other// > a need to represent digits that are greater than 9. > > You can do this in two ways: Make the above be one paragraph; you haven't started a new thought yet. > Alphabetic characters: Following the standard convention, > perl will interpret the A letter as the digit 10, the B > letter as digit 11, and so on. s/perl/Perl/ "...will interpret the letter A...the letter B as the digit" ^^^ > Separating by dots: You can also write each digit in its > decimal representation, and separate digits using the C<.> > character. Although "separating by dots" is perfectly correct and fluid, I would suggest using the term "dotted notation," just so people start getting used to it. > my $m = 256:255.255.255.0;# 256-base "# base 256" > For example, the integer 30 can be written in hexadecimal > base in two equivalent ways: Either say: "...in hexadecimal..." or "...in base 16...", but don't mix them. > Also note that a compile-time error will be generated > if you specify a "digit" that is larger than your radix > can support. For instance, > > my $x = 3:23; # error Very small nit: the problem here is the digit 3, but on first glance it looks like you are saying that the digit in question is 23. Extend the comment to explain: "my $x = 3:23; # error; can't use digit '3' in base 3" > Beware that when writing negative integers, the negative > character C<-> should be at the leftest point of the > expression: "When writing negative integers, be aware that the minus sign (C<->) must always be the leftmost character in the literal, which means it will come to the left of the radix when using radix notation." > my $z = -256:234.254; # negative number > my $e = 256:-234.254; # error > > Keep in mind that once the number has been read by perl Perl > it becomes just a magnitude. That is it loses all trace of s/That is it/That is, it/ > the way it was originally represented and is just a number. > Perl will use decimal base when printing all the numbers, no > matter what base did you use to type them. Either say "base 10" or "decimal notation", not "decimal base". I would suggest: "Perl always uses decimal for printing numbers, regardless of what base you used to enter them." > =section ** Underscore character as a seprator > > Perl allows the underscore character, C<_>, to be placed as s/placed/used/ > a separator between the digits of any literal number. You > can use this to break up long numbers into more readable > forms. "...to break up a long number into a more readable form." > There aren't any rules to it; you can use it however > you like: "The only rule is that you may only use underscore between digits, not between any other characters that is allowed to appear in a number." > 123_456_000.000 (floating point) > 2:0110_1000 (binary) > 16:FF_88_EE (hexidecimal) > 1312512.25(decimal number) > 1_312_512.25 (the same) 1_312_512_.25 (error) 1_312_512._25 (error) 1.375_e56 (error) 1.375e_56 (error) > _2_3_45___6 (error) [delete inter
Contributor License forms
Greetings all, Allison has asked me to be the coordinator to make sure that we all send in our Contributor License Forms. You can read all the license details at: http://snipurl.com/bkt Basically, what it comes down to is that we need everyone to sign a document saying that, for all the docs you write, you assign the license to the Perl6 project. This is pretty important, so please try to send them in soon--you can fax them, email them, or snail-mail them. The info is: Download form from:http://snipurl.com/bkt Fax to:1 413 254 0312 (in the US) +44 (0) 870 120 7793 (in the UK) or email scanned copy to: [EMAIL PROTECTED] or snail-mail to: The Perl Documentation Project 5301 N. Kenmore Rd. #2 Chicago, IL 60640, USA All of this is specified in the second paragraph of the Agreement; I'm just reiterating for your convenience. When you've sent it in, please let me know and I'll mark you down. --Dks
RE: Continuations
Damian Conway wrote:
>
> The formulation of coroutines I favour doesn't work like that.
>
> Every time you call a suspended coroutine it resumes from immediately
> after the previous C than suspended it. *And* that C
> returns the new argument list with which it was resumed.
>
> So you can write things like:
>
> sub pick_no_repeats (*@from_list) {
> my $seen;
> while (pop @from_list) {
> next when $seen;
> @from_list := yield $_;
> $seen |= $_;
> }
> }
>
> # and later:
>
> while pick_no_repeats( @values ) {
> push @values, some_calc($_);
> }
>
> Allowing the list of choices to change, but repetitions still to be
avoided.
>
I understand that this formulation is more powefull, but one thing I like
about python's way (where a coroutine is just a funny way to generate lazy
arrays) is that it lets you _use_ coroutines without even knowing what they
are about.
Such as when you say:
for $graph.nodes { ... }
..nodes may be implemented as a coroutine, but you just don't care about it.
Plus any function that previously returned an array can be reimplemented as
coroutine at any time, without having to change the caller side.
In other words, how do you create a lazy array of dynamically generated
values in perl6?
Maybe it could be something like this:
$foo = &bar.instantiate(1, 2, 3);
@array = $foo.as_array;
-angel
Re: Continuations
At 1:29 PM +1100 11/17/02, Damian Conway wrote: The formulation of coroutines I favour doesn't work like that. Every time you call a suspended coroutine it resumes from immediately after the previous C than suspended it. *And* that C returns the new argument list with which it was resumed. Hrm. I can see the power, but there's a fair amount of internal complication there. I'll have to ponder that one a bit to see if there's something I'm missing that makes it easier than I think. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 12:46 PM +1100 11/17/02, Damian Conway wrote: Dan Sugalski pondered: What does: > $foo = any(Bar::new, Baz::new, Xyzzy::new); $foo.run; do? Creates a disjunction of three classnames, then calls the C<.run> method on each, in parallel, and returns a disjunction of the results of the calls (which, in the void context is ignored, or maybe optimized away). I was afraid you'd say that. It does rather complicate things, as the interpreter really isn't set up to be quantum for control flow. Can we at least guarantee undefined order of operations on things? (I can pitch heisenbunnies at people if it'll help) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric Literals (Summary)
Dave Storrs wrote:
[...] Just as an aside, this gives me an idea: would it be
feasible to allow the base to be specified as an expression instead of
a constant? (I'm pretty sure it would be useful.) For example:
4294967296:1.2.3.4 # working with a really big base, hard to grok
2**32:1.2.3.4 # ah, much better
I very much hope that perl will do constant propagation as a
compile-time optimization. So you could just write:
eval( 2**32 _ ":1.2.3.4" ); # or whatever strcat is, this week.
or
literal("$(2**32):1.2.3.4"); # have we decided on the fn name yet?
Dave.
Re: Glossary?
Dave Storrs writes: > > Good point. I volunteered to be keeper of the glossary a while ago, > but I never actively started creating one. That said, let's make this > the first entry. Comments and constructive criticisms welcomed from > all comers. > I tryed to "cut in stone" ( but this is very far from it being so ) the answers to my many annoying questions. This is just summary of the answers to my questions . ( though I myself feel that "fomulated" they became less clear than in the form of questions and answers . ) anyway hope this may be of help . =Refernces I provide the references : Apo3, Exe3, =ref Topic http://www.perl.com/pub/a/2002/10/30/topic.html http://archive.develooper.com/perl6-language%40perl.org/msg12362.html http://archive.develooper.com/perl6-language%40perl.org/msg12412.html http://archive.develooper.com/perl6-language%40perl.org/msg12425.html =ref Variables, assign, bind http://archive.develooper.com/perl6-language%40perl.org/msg12393.html =ref sigil http://archive.develooper.com/perl6-language%40perl.org/msg12480.html =begin Glossary =- =section variables , containers , values =- variable provides a "view" of the value. By itself it is an association between a ( variable ) name and ( variable ) container . * name is entry in one of symbol-tables . it is subject to scope and lifetime restrictions enforced by symbol-table . Its first character may be a *sigil* , in that case it is subject to additional ... magic. * container is a "box" that contain a value (??? it cannot contain nothing -- at worse it contain value undef ???). Container's life-circle , its life or death question is controlled by only one RULE: "Be referred by something" : container is dead as soon as it is not referred by anybody. There are several basic classes of "variable containers" in perl . Scalar Array Pair Hash ???Code??? ???Class??? * value is ... value -- some ( scalar ) number that is of value to you . Similar to containers , value is alife till it is referenced by ( contained in ) at least one container . it is important to note : perl manipulate the values only *through* associated with them containers. ( pictorially -- it can "view" values only through the "spectacles" of the container ). hence if several "variable names" happen to be bound to ( reffering ) *the same* container ( as it may be enforced using := operator , see *aliasing* ) then operations on any of the bound names will affect the value . examples : $a = 5 can be pictorially described as name '$a' | V container (.) | V value (number 5) ??? here have to be a lot more of *good* examples =- =section sigil =- in perl several classes of variables containers have to be associated with (directly bound to ) a varable name that begin with a special character corresponding to a container type . This speial character is called *sigil*. Currently perl have 4 different sigils. Sigil is user extensible in the sence that it is possible to define new user defined fully functional sigil. The "standart sigil characters are '$scalar' - name for all scalar containers '@array' - array containers '%hash' hash containers '&closure' code # but in program & may be omitted from the point of view of functionality the sigil do the following : * every variable declared or first used is marked by perl by additional property "is Scalar" . these two are equivalent my $a ; my $a is Scalar ; so perl *notice* the sigil and add additional property "is Scalar" to the variable container associated with name '$a' , which ( the prperty ) from that on controll all the functionality of *variable container*. * =- =section symbol-tables =- symbol-table is table ( actually implemented as a named hash, see below ) that lists (subset of) known *symbols* also known as variable/subroutine/class/... *names*. everything in the text of a program except *keywords* and *operators* and ( ??? ) are *symbols* in the above sense. perl has several types of symbol tables. Every name in the symbol-table is *bound* to *variable container* ( of the type corresponding to its sigil if there is a sigil ). In particular there are the following classes of symbol-tables: * special global symbol-table named "*" . many built-in functions live there , e.g. *print is fully qualified name of "core" print function ( ???may this is a bad example ) * every lexical scope , including outmost lexical scope - the file scope - have associated with it symbol-table tha
Re: Perl 6 Bugs List
chromatic writes: >I've submitted three bugs for Perl 6 to [EMAIL PROTECTED] They're in >RT, but they haven't been announced on this group. I believe Allison >has asked Ask to look into this. Well, since I'm the RT owner, you and she should have asked me, or even better, the bugs6-admin at perl.org email address. Also, there is no bugs6 at perl.org email address as far as I can tell. >My plan is to funnel all Perl 6 test patches through the normal >process, so they may start showing up on this list. (If people >object, we can find something else.) The perl6 queue is not currently active in RT. Since development is primarilly happening on Parrot, things going into the parrot queue are forwarded to perl6-internals. The perl6 queue is just "there". It seems still to submit things for a project that doesn't have a complete spec yet. >I'd like to get some code review on these patches, but I don't want to hold >things up. If no one comments on them after a couple of days and if they seem >to work, I'll probably just check them in myself. >Everybody happy? I think we need a little bit of off-list discussion between the appropriate project management to come up with a scheme for this that prevents eggregious cross posting between mailing lists and keeps everyone happy and efficient. -R
Re: Glossary? ( Some additions/changes )
=-
=section assignment vs binding
=-
* A = B ;
"assign" means :
evaluate the *value* on the right hand side and
*distribute* it ( value ) among the containers ( which if
needed should be created/changed ) on the left .
* A := B ;
*alias* or *bind* variable containers to names :
take a hold of containers on the right hand side and
*distribute* them (containers ) among ( bind them to )
*names* on the left.
there is a special binding operator ::= that is same as := but force
binding to happen at compile time .
so , again ,
* after the assignment ( variables at ) left and right hand sides
refer to the same values through different ( independent )
containers. ( modulo some Copy on Write magic ) .
$a = $b ;
($a, $b) = ($b, $a);
(@a, @b) = (@b, @a);
@a = ( @b, @c ) ;
&a = sub { ... } ;
* after the binding -- ( names, if there were names ! ) at right hand
side and names ( which surely have to be there ! ) at left hand
sides refer to the same containers.
$a := $b ;
($a, $b) := ($b, $a);
(@a, @b) := (@b, @a);
@a := ( @b, @c ) ;
&a := sub { ... } ; #same as sub a { ... }
#here @a *interface* can change values seen by $x, $y, $z, @c
@a := ( $x , $y, $z , @c) ;
#here first *anonymous container is created holding (1, 2, 3) and then
#this container is bound to name '@a'
@b := ( 1 ,2 ,3 ) ;
as a consequence, run-time properties are "passed" ( from the variable
on the right side to variables on the left ) in both cases , since
they are attached to values . compile-time properties are "passed"
only at binding since they are attached to containers .
Re: Glossary?
here is ( a liitle bit ) poished version of
http://archive.develooper.com/perl6-language%40perl.org/msg12393.html
just if somebody want to use it .
I left some of the comments by Damian Conway because when I tryed to (
thought of ) saying it myself , it lost clarity/brevity/intensity .
But some comments by him I did incorporated in the text.
What I have in mind is to have some (informal & clear & simple & not
too vague & selfcontained ) introduction to the general structure (
which is beautiful ) of the language . I am not sure I fit the role
.. But I would be happy to participate in the effort .
anyway :
=section Variable : Name -> Container -> Value
=head1 short intro to compile/run phase
perl execution of you program may be roughly divided in two phases :
=over
=item *
compile phase . everything happening at that time is said to
happen at compile-time. At this phase perl read the perl source,
parse it, and evntually output Parrot assembly , which is the
"mashine language" of perl.
=item *
run phase. at that stage the programm is actually executed
at run phase parrot code is
executed by parrot virtual mashine ( which "physically" may be
almost everything -- from mailing the bytecode to your friend
to ... just executing it ).
=back
from the point of view of perl programmer all actions are taken by
perl either at comile-time or at run-time . And all entities are
sprung to existence / living / destroyed either at compile time or at
run time ( or both ) .
=head1 what is variable
perl as any other language manipulate data through "variables". since
perl have very rich semantic structure it is best to keep some picture
of its structure.
in perl, "variable" embrace 3 *mostly* independent concepts
=over
=item 1)
variable-name . live "symbol-tables", also known as in
namespaces.
=item 2)
actually "variables" or *containers* . live in perl parser
memory at compile-time-phase. But may persist to run-time.
=item 3)
values . live everywhere .
=back
So , perl Variable can be viewed as the following 3 - level thing
my $a = 5 ;
1) name | '$a'
||
|V
2) container| (.)
||
|V
3) value| some number e.g., 5
=over Variable names
dc> Though, in Perl, those restrictions aren't terribly
dc> restrictive. Here, for example, is a variable whose name is
dc> (phonetically):
dc>
dc> NEWLINE-NEWLINE-ALLO-ALLO-SPACE-the-SPACE-sky-SPACE-is-TAB-falling-BANG-BANG-BANG
dc>
dc> and yet it is perfectly legal in Perl:
dc>
dc> *{'
dc>
dc> «» the sky is falling!!!'} = \[0]->[0];
dc> while (${'
dc>
dc> «» the sky is falling!!!'}<10) {
dc> print ${'
dc>
dc> «» the sky is falling!!!'}, "\n";
dc> ${'
dc>
dc> «» the sky is falling!!!'}++;
dc> }
Variable names
names ( variable-names ) are strings. they may be virtually everything
( see \cite ) although perl may interpret specially
the first character -- the sigil. Names *live* in symbol-tables.
that is, perl keep tables that make a bookkeeping of known symbols
also known as variable-names. each name refer to a container. Perl
have 4 general classes of names differing by the sigil - the first
character. '$thing' , @thing' , '%thing' , &thing' . the type of
symbol-table, (such as: global, package, lexical and so on), defines
the *scope* of variable-name and its life-circle ( but only for
variable-name ). special modifiers "my" or "our" help perl to
understand in which "variable-namespace" you want to place your
variable-name.
=item * Containers
container is mystical ( or may be not so - after reading this )
intermediate between value and variable name.
dc> Mystical? I'd have said that the container is the *least* mystical
dc> part of the symbiosis. It's the only tangible piece of the puzzle.
Its a wheels and sticks inside the clock . we don't see it but it
is necessary to "de-mystify" - how the clock *knows* what time is
it.
Container's life-circle , its life or death question is
controlled by only one RULE: "Be referred by something" : container
is dead as soon as it is not referred by anybody.
In perl variable
may have properties . Actually containers and values have.
=item *Values
value is actual data - the 0's and 1's that actually run here and
there when program runs.
dc> Not quite. The value is the *interpretation* of the 1's and 0's.
dc> For example, the same bitsequence (say 01010101) may be part of
dc> a (very short) string, or an integer, or a floating point number, or a
dc> reference. And no two of those interpretations will necessarily
dc> represent the same "value.
value is always a scalar - some number,
alt
Re: String concatentation operator
Dan Sugalski wrote:
Creates a disjunction of three classnames, then calls the C<.run>
method on each, in parallel, and returns a disjunction of the results
>> of the calls (which, in the void context is ignored, or maybe
>> optimized away).
I was afraid you'd say that.
Then you shouldn't have asked the question. ;-)
It does rather complicate things, as the
interpreter really isn't set up to be quantum for control flow.
QCF is definitely not required because "Junctions Are Not Quantum".
Normal threading is quite enough.
And even that's not *essential*. The Q::S module can do this now:
use Quantum::Superpositions;
my $test = all(\&tall, \&dark, \&handsome);
if ($test->()) { print "I'm in lurv!"}
my $frankie = any(Tall->new(), Dark->new(), Gruesome->new());
$frankie->spark();
$frankie->live();
$frankie->menace();
# etc.
and just evaluates the various calls serially.
It would be *vastly* better thought integrate junctive calls with
the standard threading behaviour.
Can we at least guarantee undefined order of operations on things?
Yes. Please. I would certainly expect that the order of execution
is undefined, since the states of a junction are not themselves ordered.
Damian
Re: Unifying invocant and topic naming syntax
Adam D. Lopresto wrote:
It seems like that would be useful and common enough to write as
sub bar(;$foo is given) {
...
}
Where $foo would then take on the caller's topic unless it was explicitly
passed an argument.
While I can certainly see the utility of that, I believe it is too confusing
to have all three of:
* C on parameters
* C on parameters
* C on subroutines
withthe two Cs meaning quiet different things.
In addition, I think saying C<$param is given> doesn't convey what is actually
happening there (i.e. that $param only *defaults* to the caller's topic).
Finally, I would rather we did not have more than one syntax for specifying
default values for parameters.
I still think my original:
sub bar(; $foo = $topic) is given($topic) {...}
is the appropriate compromise.
Damian
Re: String concatentation operator
> Date: Mon, 18 Nov 2002 07:39:55 +1100 > From: Damian Conway <[EMAIL PROTECTED]> > > It would be *vastly* better thought integrate junctive calls with > the standard threading behaviour. Of course, there will be a pragma or something to instruct it to operate serially, yes? Luke
Re: String concatentation operator
Luke Palmer asked: Of course, there will be a pragma or something to instruct it to operate serially, yes? I doubt it. Unless there's a pragma to instruct threads to operate serially. In any case, I'm not sure what such a pragma would buy you. The ordering of evaluation would still be inherently unordered. BTW, in thinking about it further, I realize that Dan is going to have to tackle this issue anyway. There's fundamentally no difference in the exigencies of: $junction = $x | $y | $z; foo($junction);# Call foo($x), foo($y), and foo($z) # in parallel and collect the results # in a disjunction and $junction = &f | &g | &h; $junction($x); # Call f($x), g($x), and h($x) # in parallel and collect the results # in a disjunction Damian
Re: Continuations
Angel Faus wrote:
I understand that this formulation is more powefull, but one thing I like
about python's way (where a coroutine is just a funny way to generate lazy
arrays) is that it lets you _use_ coroutines without even knowing what they
are about.
Such as when you say:
for $graph.nodes { ... }
.nodes may be implemented as a coroutine, but you just don't care about it.
Plus any function that previously returned an array can be reimplemented as
coroutine at any time, without having to change the caller side.
Yes, it may be that Pythonic -- as opposed to Satherian/CLUic -- iterators are
a better fit for Perl 6. It rather depends on the semantics of Perl 6
iterators, which Larry hasn't promulgated fully yet.
In other words, how do you create a lazy array of dynamically generated
values in perl6?
Maybe it could be something like this:
$foo = &bar.instantiate(1, 2, 3);
@array = $foo.as_array;
Well, I think it has to be much less ugly than that! ;-)
Damian
Re: Continuations
Of course, apart from the "call-with-new-args" behaviour, having
Pythonic coroutines isn't noticably less powerful. Given:
sub fibs ($a = 0 is copy, $b = 1 is copy) {
loop {
yield $b;
($a, $b) = ($b, $a+b);
}
}
we still have implicit iteration:
for fibs() {
print "Now $_ rabbits\n";
}
and explicit iteration:
my $iter = fibs();
while <$iter> {
print "Now $_ rabbits\n";
}
and explicit multiple iteration:
my $rabbits = fibs(3,5);
my $foxes = fibs(0,1);
loop {
my $r = <$rabbits>;
my $f = <$foxes>;
print "Now $r rabbits and $f foxes\n";
}
and even explicitly OO iteration:
my $iter = fibs();
while $iter.next {
print "Now $_ rabbits\n";
}
And there's no reason that a coroutine couldn't produce an iterator object
with *two* (overloaded) C methods, one of which took no arguments
(as in the above examples), and one of which had the same parameter list
as the coroutine, and which rebound the original parameters on the next
iteration.
For example, instead of the semantics I proposed previously:
# Old proposal...
sub pick_no_repeats (*@from_list) {
my $seen;
while (pop @from_list) {
next when $seen;
@from_list := yield $_;
$seen |= $_;
}
}
# and later:
while pick_no_repeats( @values ) {
push @values, some_calc($_);
}
we could just write:
# New proposal
sub pick_no_repeats (*@from_list) {
my $seen;
while (pop @from_list) {
next when $seen;
yield $_;
$seen |= $_;
}
}
# and later:
my $pick = pick_no_repeats( @values );
while $pick.next(@values) {
push @values, some_calc($_);
}
These semantics also rather neatly solve the problem of whether or
not to re-evaluate/re-bind the parameters each time a coroutine
is resumed. The rule becomes simple: if the iterator's C
method is invoked without arguments, use the old parameters;
if it's invoked with arguments, rebind the parameters.
And the use of the <$foo> operator to mean $foo.next cleans up
teh syntax nicely.
I must say I rather like this formulation. :-)
Damian
Re: Continuations
> Date: Mon, 18 Nov 2002 09:28:59 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
I've a couple of questions here:
> we still have implicit iteration:
>
> for fibs() {
> print "Now $_ rabbits\n";
> }
Really? What if fibs() is a coroutine that returns lists (Fibonacci
lists, no less), and you just want to iterate over one of them? The
syntax:
for &fibs {
print "Now $_ rabbits\n";
}
Would make more sense to me for implicit iteration. Perhaps I'm not
looking at it right. How could you get the semantics of iterating
over just one list of the coroutine?
> and explicit iteration:
>
> my $iter = fibs();
> while <$iter> {
> print "Now $_ rabbits\n";
> }
Ahh, so $iter is basically a structure that has a continuation and a
value. When you call the .next method, it calls the continuation, and
delegates to the value otherwise. Slick (Unless the coroutine itself
is returning iterators... then... what?).
class Foo {
method next { print "Gliddy glub gloopy\n" }
}
sub goof () {
loop {
print "Nibby nabby nooby\n";
yield new Foo;
}
}
my $iter = goof;
print $iter.next; # No.. no! Gliddy! Not Nibby!
How does this work, then?
> For example, instead of the semantics I proposed previously:
>
> # Old proposal...
>
> sub pick_no_repeats (*@from_list) {
> my $seen;
> while (pop @from_list) {
> next when $seen;
> @from_list := yield $_;
> $seen |= $_;
> }
> }
Hang on... is C a topicalizer now? Otherwise this code is not
making sense to me.
> These semantics also rather neatly solve the problem of whether or
> not to re-evaluate/re-bind the parameters each time a coroutine
> is resumed. The rule becomes simple: if the iterator's C
> method is invoked without arguments, use the old parameters;
> if it's invoked with arguments, rebind the parameters.
>
> And the use of the <$foo> operator to mean $foo.next cleans up
> teh syntax nicely.
So filehandles are just loops that read lines constantly and yield
them. I'm really starting to like teh concept of tohse co-routines :)
They elegantify stuff.
Luke
Re: Numeric Literals (Summary)
On 15 Nov 2002 at 12:02, Dave Whipp wrote: > A couple more corner cases: > > $a = 1:0; #error? or zero Shouldn't base-1 be: 1:0 == 10:0 1:1 == 10:1 1:11 == 10:2 1:111 == 10:3 1:1010111 == 10:5 etc.. Also 0:0 == 10:0 -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Literals, take 2
On Wed, 2002-11-13 at 14:53, Andrew Wilson wrote: > >> So, can we specify floats in other bases? > > > > Why would you want to? > > Personally I wouldn't. That doesn't mean it's not useful to someone. FWIW, I occasionally work with floating point in base-2 and base-16. Not that that should, by any means, justify core functionality to do so. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Literals, take 2
On Wed, 2002-11-13 at 14:08, Jonathan Scott Duff wrote: > On Wed, Nov 13, 2002 at 07:26:06PM +0100, Angel Faus wrote: > > For example: > > > > my $x = 18; > > my $y = -18; > > my $z = -256:234.254; # negative number > my $e = 256:-234.254; # error Why? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Unifying invocant and topic naming syntax
> > My favorite was from ages ago:
> >
> > sub bar(;$foo //= $_) {...}
>
> I think that today that would be written more like this:
>
> sub bar(;$foo) is given($def_foo) {
> $foo = $def_foo unless exists $foo;
> ...
> }
>
> Though we might get away with:
>
> sub bar(;$foo = $def_foo) is given($def_foo) {
> ...
> }
It seems like that would be useful and common enough to write as
sub bar(;$foo is given) {
...
}
Where $foo would then take on the caller's topic unless it was explicitly
passed an argument.
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Never be afraid to tell the world who you are.
--Anonymous
Re: Continuations
Luke Palmer enquired:
we still have implicit iteration:
for fibs() {
print "Now $_ rabbits\n";
}
Really? What if fibs() is a coroutine that returns lists (Fibonacci
lists, no less), and you just want to iterate over one of them? The
syntax:
for &fibs {
print "Now $_ rabbits\n";
}
Would make more sense to me for implicit iteration. Perhaps I'm not
looking at it right. How could you get the semantics of iterating
over just one list of the coroutine?
The semantics of C would simply be that if it is given an iterator
object (rather than a list or array), then it calls that object's iterator
once per loop.
and explicit iteration:
my $iter = fibs();
while <$iter> {
print "Now $_ rabbits\n";
}
Ahh, so $iter is basically a structure
It's an object.
that has a continuation and a
value. When you call the .next method, it calls the continuation, and
delegates to the value otherwise.
Err. No. Not quite. Though that would be cute too.
(Unless the coroutine itself is returning iterators...
Yep.
The idea is that, when any subroutine (&f) with a C in it is called,
it immediately returns an Iterator object (i.e. without executing its body at
all). That Iterator object has (at least) two C methods:
method next() {...}
method next(...) {...}
where the second C's parameter list is identical to the
parameter list of the original &f.
Code can then call the iterator's C method, either explicitly:
$iter.next(...);
or operationally:
<$iter>
or implicitly (in a C loop):
for $iter {...}
Previously Larry has written that last variant as:
for <$iter> {...}
but I think that's...err...differently right. I think the angled version
should invoke C<$iter.next> once (before the C starts iterating) and
then iterate the result of that. In other words, I think that a C
loop argument should always have one implicit level of iteration.
Otherwise I can't see how one call call an iterator directly in a
for loop:
for {...}
But I could certainly live with it not having that, in which case
the preceding example would have to be:
my $iter = fibs();
for <$iter> {...}
and, if your coroutine itself repeatedly yields a iterator
then you need:
my $iter = fibses();
for < <$iter> > {...}
(Careful with those single angles, Eugene!)
class Foo {
method next { print "Gliddy glub gloopy\n" }
}
sub goof () {
loop {
print "Nibby nabby nooby\n";
yield new Foo;
That would have to be:
yield new Foo:;
or:
yield Foo.new;
}
}
my $iter = goof;
print $iter.next; # No.. no! Gliddy! Not Nibby!
How does this work, then?
Calling C returns an iterator that resumes the body of C
each time the iterator's C method is called.
Teh actual call to C<$iter.next> resumes the body of C, which runs
until the next C, which (in this case) returns an object of class
C. So the line:
print $iter.next;
prints "Nibby nabby nooby\n" then the serialization of the Foo object.
If you wanted to print "Nibby nabby nooby\n" and then "Gliddy glub gloopy\n"
you'd write:
print $iter.next.next;
or:
print <$iter.next>;
or:
print < <$iter> >;
Hang on... is C a topicalizer now?
That's still under consideration. I would like to see the special-case
Perl 5 topicalization of:
while <$iter> {...}
to be preserved in Perl 6. Larry is not so sure. If I can't sway Larry, then
we'd need explicit topicalization there:
while <$iter> -> $_ {...}
which in some ways seems like a backwards step to me.
So filehandles are just loops that read lines constantly and yield
them.
Nearly. Filehandles are just iterator objects, each attached to a
coroutine that reads lines constantly and yields them.
I'm really starting to like the concept of those co-routines :)
Likewise.
They elegantify stuff.
If you're going to talk Merkin, talk it propericiously:
"They elegantificatorize stuff"
;-)
Damian
Re: String concatentation operator
At 7:39 AM +1100 11/18/02, Damian Conway wrote: Dan Sugalski wrote: Creates a disjunction of three classnames, then calls the C<.run> method on each, in parallel, and returns a disjunction of the results of the calls (which, in the void context is ignored, or maybe optimized away). I was afraid you'd say that. Then you shouldn't have asked the question. ;-) Sometimes the answers to the questions I don't ask are scarier than the answers to the ones I do... ;-P It does rather complicate things, as the interpreter really isn't set up to be quantum for control flow. QCF is definitely not required because "Junctions Are Not Quantum". Normal threading is quite enough. [Snip] It would be *vastly* better thought integrate junctive calls with the standard threading behaviour. Perl's standard threading behaviour's going to be rather heavyweight, though. I'm not 100% sure we're going to want to go that route, unless we can sharply restrict what the heisenbunnies can see. (Though the presentation on Erlang at LL2 has got me thinking more about efficient multithreading. I don't think we'll be able to use it for perl, though) Can we at least guarantee undefined order of operations on things? Yes. Please. I would certainly expect that the order of execution is undefined, since the states of a junction are not themselves ordered. Good. We shall have to enforce that, then. Wedge some randomness into the quantum thingies or something. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
* Dan Sugalski ([EMAIL PROTECTED]) [18 Nov 2002 12:56]: [...] > Perl's standard threading behaviour's going to be > rather heavyweight, though. Silly question time: Why is it going to be rather heavyweight? (Not complaining or berating, just wanting information =) ) > (Though the presentation on Erlang at LL2 has got me thinking more > about efficient multithreading. Good! > I don't think we'll be able to use it > for perl, though) Not so good! =) cheers, -- Iain.
Re: Numeric Literals (Summary)
On Sun, Nov 17, 2002 at 03:01:08PM +0200, Markus Laire wrote: > On 15 Nov 2002 at 12:02, Dave Whipp wrote: > > > A couple more corner cases: > > > > $a = 1:0; #error? or zero > > Shouldn't base-1 be: > > 1:0 == 10:0 > 1:1 == 10:1 > 1:11 == 10:2 > 1:111 == 10:3 > 1:1010111 == 10:5 > etc.. Nope. Remember, for any N, base N consists of the digits from 0 up to N-1. So, in base 2 (binary), you may only use the numbers 0 and 1. In base 10 (decimal), you may only use the digits from 0-9. And so on. Therefore, in base 1, you can only use the digit 0. (Actually, I think base 1 is a corner case--you only get one digit, but that digit is 1, so you can represent any number N by making N tally marks.) >Also 0:0 == 10:0 In base 0, you would get no digits at all, so you can't represent anything...which makes sense: after all, how many times must you multiply 0 by itself to represent the decimal number 10? --Dks
Re: Numeric Literals (Summary)
> Date: Sun, 17 Nov 2002 18:51:05 -0800 > From: Dave Storrs <[EMAIL PROTECTED]> > > Therefore, in base 1, you can only use the digit 0. (Actually, I > think base 1 is a corner case--you only get one digit, but that digit > is 1, so you can represent any number N by making N tally marks.) Well, if you want to be ≪useful≫, yes. But to be consistent, take how you compute the magnitude of base n: \i /d n i i Where d_i ∈ [0, n) (or any set of n symbols representing those magnitudes). Thus, our digits in base 1 are d_i ∈ [0, 1), or just 0. So, any number represented in base 1 is 0. OTOH, nothing can be represented in base 0, as there are no valid symbols with which to work. If there were, all numbers would still be 0, because n^i is always zero. But for usefulness sake, you can define 0 and 1 as digits, in which case the number of 1's is the number represented. But that's no fun... As for semantics, base zero is of course an error, and I'd say base one should be as well. Just because I prefer consistency over almost-useless exceptions. Luke
Re: Numeric Literals (Summary)
On Sun, Nov 17, 2002 at 08:13:58PM -0700, Luke Palmer wrote: > > Date: Sun, 17 Nov 2002 18:51:05 -0800 > > From: Dave Storrs <[EMAIL PROTECTED]> > > > > Therefore, in base 1, you can only use the digit 0. (Actually, I > > think base 1 is a corner case--you only get one digit, but that digit > > is 1, so you can represent any number N by making N tally marks.) > [...] > As for semantics, base zero is of course an error, and I'd say base > one should be as well. Just because I prefer consistency over > almost-useless exceptions. Ditto. I was just being pedantic.
Re: String concatentation operator
At 1:00 PM +1100 11/18/02, Iain 'Spoon' Truskett wrote: * Dan Sugalski ([EMAIL PROTECTED]) [18 Nov 2002 12:56]: [...] Perl's standard threading behaviour's going to be rather heavyweight, though. Silly question time: Why is it going to be rather heavyweight? (Not complaining or berating, just wanting information =) ) Well, the problem is shared data. Firing off multiple interpreters isn't that big a deal, though there is some overhead in initializing an interpreter. If we do Clever Things, we can cut down the overhead, but there's still some, so creating a new interpreter will not be dirt cheap. (Which is fine, as it makes the common case faster) The expensive part is the shared data. All the structures in an interpreter are too large to act on atomically without any sort of synchronization, so everything shared between interpreters needs to have a mutex associated with it. Mutex operations are generally cheap, but if you do enough of them they add up. The threading model that perl leans towards is either a share-lots scheme, or a share-nothing-but-copy scheme, both of which are pretty expensive. The copy form, of course, requires copying data, which isn't cheap. The share scheme requires lots of locking, as the core data structures are too big for low-level atomic access. > (Though the presentation on Erlang at LL2 has got me thinking more about efficient multithreading. Good! I don't think we'll be able to use it for perl, though) Not so good! =) Why? It's not perl's problem space. To do efficient large-scale multithreading you need a shared-nothing system with fast message passing and very little information being sent between threads. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 8:22 AM +1100 11/18/02, Damian Conway wrote: Luke Palmer asked: Of course, there will be a pragma or something to instruct it to operate serially, yes? I doubt it. Unless there's a pragma to instruct threads to operate serially. In any case, I'm not sure what such a pragma would buy you. The ordering of evaluation would still be inherently unordered. BTW, in thinking about it further, I realize that Dan is going to have to tackle this issue anyway. There's fundamentally no difference in the exigencies of: I've been noticing things have been getting rather more quantum lately. This may have some... interesting repercussions, as that has some subtle and not so subtle ramifications in how the interpreter needs to behave. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
