Re: Numeric literals, take 1
On Fri, Nov 15, 2002 at 08:17:04PM -0700, Luke Palmer wrote: : Presumably, C is a keyword and it would be an error to say "sub i". Depends on how the complex module decides to implement it. It could make it a keyword, or it could just import a sub of some sort. Whether you have to "use" the complex module explicitly is a different question. I'd say if you use the bareword "i" it's pretty clear what's wanted. Use of "i" as a postfix operator is also pretty indicative... : I don't recall complex numbers ever being considered as a builtin : type; i.e. non-module. Could someone point me to where this was : discussed? This whole issue of what's "builtin" and what isn't is really kinda bogus. A built-in is something that is either pre-imported or auto-imported. That's all. To the first approximation, the only function that *has* to be built-in to Perl is sub (that is, lambda). Almost everything else is negotiable. : (Just, I don't see a general enough usage for them as to make them : builtin...) I don't think Perl 6 documentation should use the word "builtin". At best we can go for a hierarchy of standard levels, where each level assumes the availability of a certain set of function names. But even then, different levels might have the same name an implement them differently. A level 0 Perl might implement basic functionality like C only as a subroutine. Looking at it another way, we can have varying levels of guaranteed functionality from femtoperl picoperl nanoperl microperl milleperl perl kiloperl megaperl gigaperl teraperl petaperl Calling something "builtin" has little meaning unless you answer the question: "Built into what?" Larry
on the current summary
1: string cat is an old and reliable horsehide drum. I've been
doing C programming recently, where you can concat two literal
strings by having no other language tokens between them. Really.
That's the real basis for repeating the suggestion of juxtaposition
as a string joining operator. Syntactic arguments can all be deflated
by retreating what gets recognized as a string juxtaposition to the
point where it is clear that other things are happenind when other
things are meant to happen. Besides, there's always join('',...).
2: deprecating bitwise ops. I've also been working with C++ recently
where the
bitwise ops, particularly shift-left, were completely overrun and are
rarely missed.
Multiple dispatch means the same syntax can mean completely different
things. A
more perlish solution to the situation might be, since bitwise ops are
used rarely, to
explicitly bring them in with a pragma.
{
use bitwiseops;
...
}
3: I propose "means" as a postfix macro indicator. Macros are not
allowed to alter
the blocking structure, theymust be block-sane (like Lisp, unlike C).
Tokens on both sides are the pieces that get replaced. Tokens and other
syntax on the
left that does not appear on the right is the pattern that will get
matched to invoke the
macro. The right hand side guides the rewriting.
No reserved begin and end markers are required because of the blocking
sanity
requirement. For example
for( initialize ; test ; increment ) body
means
{initialize ; while (test) {body ; increment }}
;
thanks
--
David Nicol, independent consultant and contractor 312 587
2868
"For every old blackboard there are now hundreds of new electronic
computers"
Re: Quick note on JIT bits
On 11/16/02 Gopal V wrote: > > the above was a partial cut&paste with s/mono/parrot/ :-) > > But don't act like you invented it Kaffe had one before you thought > about mono JIT ... The idea probably predates kaffe, too. Anyway, I didn't say I had the idea, but the implementation. Quoting what you dropped from my mail, I said we had the complete examples and: > We have also an implementation of the symbol file writer in > mono/jit/debug* that may be helpful to look at. If you think you have novel ideas in the JIT (or in the intepreter) space, you're probably just deluding yourself. > http://www.kaffe.org/doc/kaffe/FAQ.xdebugging > > I just saved some typing by cut-pasting what I had in my box > And don't bother to thank me for introducing the "debug jit" so that you > could show up with "Mono has this and more" banner I pointed at the mono implementation simply because it is more complete and flexible than the kaffe one. kaffe only does the stabs format (and it outputs only the info for the code). Mono has the code that allows you to access locals and arguments in a stack frame and inspect the fields of the runtime-created types. Mono can also output symbol files in both stabs and dwarf format: the dwarf format doesn't have the limitation of stabs regarding line number info, for example, and it makes it possible to output debug info also for optimized code. BTW: the mono implementation is not mine, I just started it and then Martin Baulig filled the holes and implemented the dwarf stuff. If you can find a better implementation than mono's, I'd like to know about it, too:-) Until then, it's just a waste of people's time to provide limited information or to point to a limited implementation of the idea ;-) lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
[CVS ci] JIT restart code - all platforms
I did remove the somewhat hackish jit_restart function and changed Parrot_jit_begin() to emit the jump to the given PC. This implied a change, how the generated jit code gets called, it is now called like: run(interpreter, pc); The code for i386 is done, other platforms have a comment there, waiting for replacement by the real thing. leo
[OT] Re: Quick note on JIT bits
If memory serves me right, Paolo Molaro wrote: > If you think you have novel ideas in the JIT (or in the intepreter) space, > you're probably just deluding yourself. Oh yes I said that "debuggable JIT" is one of my very own personal ingienous ideas . This list for people who are interested in parrot and its VM Which is why I posted that info .. But I cannot see the same motive behind your mail ... > If you can find a better implementation than mono's, I'd like to know > about it, too:-) Guess I'll have to wait until the Parrot guys finish *sigh*, do you Ximian people never quit stalking me ? ... NOREPLY, Gopal -- The difference between insanity and genius is measured by success
[CVS ci] simple JIT debug via gdb
Thanks to the hints of Gopal and Paolo, I added a simple stabs generator for JIT code. As we currently don't have line numbers, the code assumes, there are no comments and no empty lines, just one op per line. Here is a sample debug session (the important thing happens after build_asm where symbols got built): $ gdb parrot GNU gdb 4.18 (gdb) b runops_jit Breakpoint 1 at 0x8049ca7: file interpreter.c, line 227. (gdb) r -j -d mops.pbc Starting program: /home/lt/src/parrot-leo/parrot -j mops.pbc Breakpoint 1, runops_jit (interpreter=0x812eab0, pc=0x81466b0) at interpreter.c:227 227 code_start = interpreter->code->byte_code; (gdb) n 228 code_size = interpreter->code->byte_code_size / sizeof(opcode_t); (gdb) 229 code_end = interpreter->code->byte_code + code_size; (gdb) 231 jit_code = build_asm(interpreter, pc, code_start, code_end); (gdb) 232 (jit_code) (interpreter, pc); (gdb) add-symbol-file mops.o 0 add symbol table from file "mops.o" at text_addr = 0x0? (y or n) y Reading symbols from mops.o...done. (gdb) s jit_func () at mops.pasm:1 1 setI2, 0 (gdb) 2 setI3, 1 (gdb) l 1 setI2, 0 2 setI3, 1 3 setI4, 1 4 print "Iterations:" 5 print I4 6 print "\n" 7 setI1, 2 8 mulI5, I4, I1 9 print "Estimated ops: " 10 print I5 (gdb) l 11 print "\n" 12 time N1 13 REDO: subI4, I4, I3 14 if I4, REDO 15 DONE: time N5 16 subN2, N5, N1 17 print "Elapsed time: " 18 print N2 19 print "\n" 20 if I4, BUG (gdb) b 13 Breakpoint 2 at 0x814ecc6: file mops.pasm, line 13. (gdb) c Continuing. Iterations:1 Estimated ops: 2 Breakpoint 2, jit_func () at mops.pasm:13 13 REDO: subI4, I4, I3 (gdb) n 14 if I4, REDO (gdb) 14 if I4, REDO (gdb) 14 if I4, REDO (gdb) b 15 Breakpoint 3 at 0x814ecdc: file mops.pasm, line 15. (gdb) c Continuing. Breakpoint 3, jit_func () at mops.pasm:15 15 DONE: time N5 (gdb) c Continuing. Elapsed time: 9.725663 M op/s:20.564151 Program exited normally. (gdb) q Have fun, leo
RE: Numeric literals, take 1
> > Why would C be a keyword? Its not in perl5, and I don't > remember any discussion where non-real numbers would > be part of the core language. > My fault. For some strange reason I had a false idea that this had been said somewhere, and didn't check. Shame on me. -angel
Re: on the current summary
> From: david nicol <[EMAIL PROTECTED]>
> Date: 15 Nov 2002 18:56:35 -0600
>
I don't know if you haven't been paying attention, or you're
summarizing what's happened. I'll assume the former. Forgive me if
I've misunderstood you.
>
> 1: string cat is an old and reliable horsehide drum. I've been
> doing C programming recently, where you can concat two literal
> strings by having no other language tokens between them. Really.
> That's the real basis for repeating the suggestion of juxtaposition
> as a string joining operator. Syntactic arguments can all be deflated
> by retreating what gets recognized as a string juxtaposition to the
> point where it is clear that other things are happenind when other
> things are meant to happen. Besides, there's always join('',...).
>
If you're saying that juxtaposition should be string cat, see Larry's
post on the subject. If you're saying that string I
juxtaposition should concatenate, that's more sane, but why if we
already have a cat? If you're saying juxtaposition is bad, good for
you.
>
> 2: deprecating bitwise ops. I've also been working with C++ recently
> where the
> bitwise ops, particularly shift-left, were completely overrun and are
> rarely missed.
> Multiple dispatch means the same syntax can mean completely different
> things. A
> more perlish solution to the situation might be, since bitwise ops are
> used rarely, to
> explicitly bring them in with a pragma.
Bitwise ops in their traditional form are depricated. They're
replaced by I-don't-know-what-godawful-symbol (I think .& and .|, but
I don't remember well). The | and & are junction constructors now
(which I think is fantastic).
> {
> use bitwiseops;
> ...
> }
>
> 3: I propose "means" as a postfix macro indicator. Macros are not
> allowed to alter
> the blocking structure, theymust be block-sane (like Lisp, unlike C).
>
> Tokens on both sides are the pieces that get replaced. Tokens and other
> syntax on the
> left that does not appear on the right is the pattern that will get
> matched to invoke the
> macro. The right hand side guides the rewriting.
> No reserved begin and end markers are required because of the blocking
> sanity
> requirement. For example
>
> for( initialize ; test ; increment ) body
> means
> {initialize ; while (test) {body ; increment }}
> ;
Ummm... why? Why not just grammar-munge or define a sub?
FYI, this macro thing has been discussed before, and failed to reach a
conclusion. People wanted the power of Lisp macros, but found it
would be hard to do because Perl has so much more structural
complexity than Lisp. C-like-macros (as this is) don't give a big
advantage in a spicy language like Perl. That is, unless you can come
up with a good advantage
Luke
Re: Continuations
Peter Haworth asked: So to get the same yield context, each call to the coroutine has to be from the same calling frame. If you want to get several values from the same coroutine, but from different calling contexts, can you avoid the need to wrap it in a closure? I don't think so. Damian
Re: Superpositions and laziness
Piers Cawley wrote: [Speculations elided] Which is somewhat dependent on being able to do C. Which you can't do, since C is compile-time. Damian
Re: Meta-operators
Timothy S. Nelson asked: Question: are there any plans to have user-defined meta-operators in perl6? Explanation: By meta-operators, I mean operators which operate on other operators (much as APL operators do to APL functions). Yes. The vectorizing notation (»OP«) is an example. Larry has also pondered general "adverbs", introduced by a colon, that modify a subroutine, method, or operator call. Damian
Re: Unifying invocant and topic naming syntax
Luke Palmer wrote:
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) {
...
}
Or, if you stick with Perl5 convention, and I imagine this is what
people will expect from the builtins at least:
sub bar($foo; $baz) is given($baz) {...}
I think this should definitely be a compile-time error.
Damian
Re: More junctions
Deborah Ariel Pickett wrote:
Luke wrote:
$foo = 1 | 2 | 4
print $foo;
# Foo is now just one of (1, 2, 4); i.e. not a junction
Just a sanity check, but is this kind of behaviour something we still
want from junctions?
Perhaps the above should just print JUNCTION(0x1234) or something,
like the other built-in types do.
But in Perl 6, they *don't*. The serialize somehow (probably by calling
their C<.serialize> method).
And I suspect that junctiosn serialize as follows:
* Disjunctions (Cs) serialize to their eigenstates.
* Conjunctions (Cs) and abjunctions (Cs)
with exactly one eigenstate serialize to that.
* Every other junction serializes to some representation of
its junctive type and internal states (e.g. "all(1,2)",
"none('Crosby', 'Stills', 'Nash', 'Young')", etc.)
Damian
Thoughts on memory
Hello all, I have been away for a while. I started writing my own version of parrot (or at least chunks of it) so I can get a feel for the current parrot internals. I have learned a lot and now realize why some things were done the way they were. I am on memory management now and my implementation is different from that of parrot. I would just like to outline it so that if there is any interest in the code I can provide it to you. I'm not suggesting that parrot implement this technique, but it may spur the creative thinking in someone with their fingers already in the cookie jar. First of all it looks as though there is no one perfect memory management technique. There are a lot of papers and several different techniques. An individual technique may be close to optimum for a certain type of application, but may be poor in another. Even in the same program some chunks of memory may be highly dynamic, while others are fairly static. So I figure that there is no reason to treat all memory the same, I would like future advances to just plug in, I don't want to force a hard-coded memory management scheme on someone who knows exactly what they want. So my implementation has an "interface" called Memory Manager (written in c). Each instance of a Memory Manager implements certain memory management functions. The remainder of the program addresses each manager in the same way. However, each manager is free to allocate, store, read ,and free memory in its own way. In each program there can be several memory managers created, each using there own management technique. Variables of certain types or meeting certain criteria can be directed to the optimized (or specialized) memory manager for that type. This also opens up the possibility of allocating memory storage space in a file, or on a database, or in another interpreter using something like soap. An implementation of a memory manager could itself be bytecode as long as it implements the managers interface. This would make it a nice platform to experiment with or find the optimum technique for your program before you distribute it. It would allow you to run the same program code, but with different plug in memory managers. Of course those that don't want to deal with it can just ignore it and it will use a default manager. There is some talk about memory manager that learn, or expert systems. When these technologies develop, it would be nice if parrot could just plug in a new AI Memory Manager. Erik
[perl #18445] [PATCH] Fix packfile initialization
# New Ticket Created by Simon Glover # Please include the string: [perl #18445] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18445 > Packfile_new assumes that the memory it gets from mem_sys_allocate is zeroed, which is no longer the case. This causes Bad Things to happen when I run parrot with --gc-debug (and, frankly, I think it's only luck that's stopping Bad Things from happening the rest of the time as well). The patch below fixes the problem by initializing to 0 (or NULL) everything that's currently unitialized; an alternative fix would be to change mem_sys_allocate to mem_sys_allocate_zeroed -- I can send a patch that fixes it that way if people would prefer. Simon --- packfile.c.old Sat Nov 16 16:11:43 2002 +++ packfile.c Sat Nov 16 17:16:33 2002 @@ -86,6 +86,11 @@ PackFile_new(void) /* Other fields empty for now */ pf->byte_code = NULL; pf->byte_code_size = 0; +pf->need_wordsize = 0; +pf->need_endianize = 0; +pf->fetch_op = NULL; +pf->fetch_iv = NULL; +pf->fetch_nv = NULL; return pf; }
Re: Unifying invocant and topic naming syntax
Andrew Wilson wrote:
It's the difference between this:
print;
and this:
print $_;
It is as far as I'm concerned exactly what topic is all about.
Exactly.
It let's you write subroutines that behave like builtins with respect
> to $_. I think it's generally intended to be used like so:
sub my_print is given($default) {
my @args = @_ // $default;
...
}
i.e. only doing stuff with $_ if no explicit parameters are passed.
I would expect that to be by far the most common use of C.
I don't think that'll be a massive problem with this. It's not the same
thing at all because $_ is now lexical it's not passed to stuff you call
unless it specifically asks for it. This will eliminate the trampling
over $_ several levels down. Needlessly messing with caller's $_ will
become like not using strict or warnings. Occasionally useful but
generally frowned on in a "don't do that" kind of way.
My sentiments precisely. Though it may only be frowned upon in a
"don't do that without documenting it" kind of way. ;-)
Damian
Re: Continuations
At 8:31 AM +1100 11/17/02, Damian Conway wrote: Peter Haworth asked: So to get the same yield context, each call to the coroutine has to be from the same calling frame. If you want to get several values from the same coroutine, but from different calling contexts, can you avoid the need to wrap it in a closure? I don't think so. I dunno. One of the things I've seen with coroutines is that as long as you call them with no arguments, you get another iteration of the coroutine--you actually had to call it with new arguments to reset the thing. (Which begs the question of what you do when you have a coroutine that doesn't take any args, but that's a separate issue) OTOH, forcing a closure allows you to have multiple versions of the same coroutine instantiated simultaneously, which strikes me as a terribly useful thing. Perhaps we'd be better with an explicit coroutine instantiation call, like: $foo = &bar.instantiate(1, 2, 3); or something. (Or not, as it is ugly) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More junctions
Luke Palmer wrote:
sub foo($x) {
if ($x != 4) {
print "Not four\n";
}
if ($x == 4) {
print "Four\n";
}
}
sub oof($x) {
if ($x != 4) {
print "Not four\n";
}
else {
print "Four\n";
}
}
If given 3 | 4, foo would print "Not Four\nFour\n", while oof would
print "Not four\n".
Maybe not. We're still pondering the interactions of subroutines and
junctive arguments. There are two possibilities (naturally ;-):
1. Passing a junction as a subroutine argument calls the
subroutine (in parallel, perhaps in separate threads)
with each value of the junction, then juncts the results
(in which case both C and C print both strings).
2. Junctions are just passed in as any other scalar argument.
(in which case what Luke suggested is correct).
The reason that 1) might be a better semantics is that it makes
something like:
sub longest_common_substr($a, $b) {
my $substrs_a = substr $a, any(0,$a.end), any(0,$a.length);
my $substrs_b = substr $a, any(0,$a.end), any(0,$a.length);
my $common = $substrs_a == $substrs_b;
return $common >= any($common.states);
}
work correctly.
That is, we generally want C to produce C.
In those cases where the junction *should* be passed into the subroutine
(primarilyboolean predicates, I suspect), that would have to be marked
explicitly:
sub even ($x is junctive) { # Allow C to work on junctions too
return $x % 2 == 0;
}
Note that C would work for regular scalars too, since they can be
considered a degenerate case of a disjunction (or of a conjunction or
abjunction, for that matter).
I don't know how much this would come up in practice, but I do see it
as an issue. The question is: are junctions more useful if they do
or don't collapse upon examination?
I'm fairly solidly convinced that it's better if they don't.
Damian
Re: More junctions
Brent Dax wrote:
More simply, !($x == 4) is no longer exactly equivalent to ($x != 4).
Correct. Junctive algebra and logic is slightly different. yet another
reason not to allow junctions to seep into subroutines by default.
Actually, this suggests to me a flaw in the != operator, not a flaw in
junctions. We should probably make != exactly equivalent to the
negation of ==; this implies that when != gets a junction the type of
junction is reversed (any becomes all, all becomes any).
I don't think so. I think it's important to preserve the useful
intuitive distinction between:
if $moe|$larry|$curly == $hurt {...} # i.e. any of them hurt
and:
if $moe|$larry|$curly != $hurt {...} # at least one not hurt
and also between:
if $moe&$larry&$curly == $hurt {...} # all hurt
and:
if $moe&$larry&$curly != $hurt {...} # none hurt
Damian
Re: More junctions
On Saturday, November 16, 2002, at 04:52 PM, Damian Conway wrote:
if $moe|$larry|$curly == $hurt {...} # i.e. any of them hurt
and:
if $moe|$larry|$curly != $hurt {...} # at least one not hurt
and also between:
if $moe&$larry&$curly == $hurt {...} # all hurt
and:
if $moe&$larry&$curly != $hurt {...} # none hurt
Although I admit I don't mind the lack of space on either side of the
C<|> operator, it bugs me with the C<&> operator. Couldn't C<&$larry>
in the above snippet dereference a code reference? I really hope that,
stylistically, we'll more often see code like this:
if $damian | $larry | $dan == $hurt {...} # i.e. any of them hurt
if $damian & $larry & $dan == $hurt {...} # all hurt
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Control Structures I: given
Scott Duff essayed:
So, I was all set to show how this could work with junctions, but then
I realized that I don't understand them well enough, so here's what I
came up with:
$j0 = $that_happens | $that_doesnt_happen;
$j1 = !$that_happens | !$that_doesnt_happen;
given ($this) {
when $j0 ~~ $that_happens { ... }
when $j0 ~~ $that_doesnt_happen { ... }
when all($j0) { ... }
when any($j0) { ... }
when any($j1) { ... } # "some" Rare, I expect
when none($j0) { ... }
}
Is that right?
Not quite. The first problem is that if either of the first two C
fire, we immediately break out of the C. There will probably be
a lexical pragma to reverse that default behaviour.
The other problem is that your using junctions of junctions, which have
quite different semantics.
Here's some code that has (what I construe to be) the desired behaviour:
@possible_states = ($that_happens, $that_doesnt_happen);
given ($this) {
use fallthrough;
when $that_happens { "Have a party" }
when $that_doesnt_happen{ "Sing" }
when all(@possible_states) {
# Do something
}
when any(@possible_states) {
# Do something else
}
when $_ !~ all(@possible_states) {
# Do something other
}
when none(@possible_states) {
# Do something however
}
}
> What happens when there's a
junction on either side of a smart match?
That depends (multimorphically) on the types of the junctions.
Here's a handy table:
all(A,B) ~~ all(C,D)--> ( A~~C && A~~D ) && ( B~~C && B~~D )
all(A,B) ~~ any(C,D)--> ( A~~C || A~~D ) && ( B~~C || B~~D )
all(A,B) ~~ one(C,D)--> ( A~~C ^^ A~~D ) && ( B~~C ^^ B~~D )
all(A,B) ~~ none(C,D) --> (!(A~~C) && !(A~~D)) && (!(B~~C) && !(B~~D))
any(A,B) ~~ all(C,D)--> ( A~~C && A~~D ) || ( B~~C && B~~D )
any(A,B) ~~ any(C,D)--> ( A~~C || A~~D ) || ( B~~C || B~~D )
any(A,B) ~~ one(C,D)--> ( A~~C ^^ A~~D ) || ( B~~C ^^ B~~D )
any(A,B) ~~ none(C,D) --> (!(A~~C) && !(A~~D)) || (!(B~~C) && !(B~~D))
one(A,B) ~~ all(C,D)--> ( A~~C && A~~D ) ^^ ( B~~C && B~~D )
one(A,B) ~~ any(C,D)--> ( A~~C || A~~D ) ^^ ( B~~C || B~~D )
one(A,B) ~~ one(C,D)--> ( A~~C ^^ A~~D ) ^^ ( B~~C ^^ B~~D )
one(A,B) ~~ none(C,D) --> (!(A~~C) && !(A~~D)) ^^ (!(B~~C) && !(B~~D))
none(A,B) ~~ all(C,D) --> (!(A~~C && A~~D)) && (!(B~~C && B~~D))
none(A,B) ~~ any(C,D) --> (!(A~~C || A~~D)) && (!(B~~C || B~~D))
none(A,B) ~~ one(C,D) --> (!(A~~C ^^ A~~D)) && (!(B~~C ^^ B~~D))
none(A,B) ~~ none(C,D) --> !(!(A~~C) && !(A~~D)) && !(!(B~~C) && !(B~~D))
The logic is straightforward and the pattern not too hard to see: the type of
the left operand determines the "top level" (i.e. lower precedence)
logical connective whilst the type of the right operand determines the "bottom level"
(higher precedence) logical connectives.
BTW, the same table works for any boolean operation between junctives.
And, of course, it generalizes to any number of states on either side.
Damian
Re: String concatentation operator
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). Damian
Re: Unifying invocant and topic naming syntax
Acadi asked:
> Just ( my ) terminology clean-up : in this example sub{ } is implicit
> topicalizer
No. It isn't a topicalizer at all.
> ( it does not set $_ explicitly )
Or implicitly.
> and you are setting $_ for perl .
Yes.
> that's why you can use "when" .
Yes.
is this valid ?
(morning() is function that analyse stringifyed time )
#!/usr/bin/perl -w
when ~time ~~ &morning { print "good morning" }
Yep. If C is given a boolean, it acts like an C
(except for the automatic C at the end of its block.
and also
#!/usr/bin/perl -w
$_ = ~time
when &morning() { print "good morning" }
Almost. You want:
when &morning { print "good morning" }
(i.e. no explicit call parens)
Damian
Re: Hmm...
Austin Hastings pondered:
my $outfh = all(@input_handles);
while (<$outfh>) print;
No. Apart from the bug (leaving off the braces around the C...spot
the C hacker! ;-), this reads from each of the @input_handles and returns
a conjunction of the values that were read. The print then serializes the
conjunction and prints it. But serialization of a conjunction probably
involves putting an "all(...)" around its states.
You'd get *closer* to the desired behaviour with:
my $outfh = any(@input_handles);
while <$outfh> { print; }
because the serialization of a disjunction is just the list of
states. However, junctions don't guarantee the order of their
states so your interleaving might be messed up. Moreover, they
*do* guarantee uniqueness of their states, so any lines that
happened to be identical in two or more files would appear only
once. :-(
What you want here is probably just:
print zip »readline« @input_handles;
> Do junctions know about the origins of their components?
No.
Is "preserving order" a meaningful concept?
No.
(Especially in light of entanglement, which will require origin
> info if it is to be added as an external module.)
Junctions aren't quantum mechanical, so this doesn't apply.
Damian
Re: is sigil user - extensible ? Was: UTF-8 and Unicode FAQ, demos
Acadi asked: is it possible to extend the perl sigil behaviour . Yes. that is , one day somebody decides it needs ¢ as sigil for certain class of variables . will it be possible to do . ( without rewriting the whole perl ) Yes. Just inherit the standard Perl grammar, extend the C rule and install the derived grammar as the caller's parser. Damian
Perl 6 Bugs List
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. 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.) 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? -- c
Re: Continuations
Dan Sugalski wrote:
I dunno. One of the things I've seen with coroutines is that as long as
you call them with no arguments, you get another iteration of the
coroutine--you actually had to call it with new arguments to reset the
thing.
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.
OTOH, forcing a closure allows you to have multiple versions of the same
coroutine instantiated simultaneously, which strikes me as a terribly
useful thing.
Yep!
Perhaps we'd be better with an explicit coroutine instantiation call, like:
$foo = &bar.instantiate(1, 2, 3);
or something.
Ew!
(Or not, as it is ugly)
That'd be my vote! ;-)
Damian
Re: Roll Call
> "Michael" == Michael Lazzaro <[EMAIL PROTECTED]> writes: Michael> If you wish to take part in the discussions (or even just lurk), Michael> please reply to this message. If you have any particular goals that Michael> you feel this list should be addressing, please let us know. I'm here, swirling in the mist of trying to understand all of the progress, and figuring out how Stonehenge is going to remain the world's leading on-site and open-enrollment Perl training company. :) Not to mention how much Learning Perl and other books will have to change. Anyone have a spare supply of irons? Mine are all in the fires already. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Glossary?
On Thu, Nov 14, 2002 at 02:29:38PM -0600, Garrett Goebel wrote: > It is interesting that no one has yet taken the time to start defining the > terms we're using. 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. Term: literal Definition: A literal is a way of writing a particular fixed value. For example, 65 (decimal), b101 (binary), and 0x41 (hexadecimal) are all literals, are all constants, and are each a different representation of the same fixed value. Sometimes literals come in groups...most commonly in lists or arrays. An example of a list of literals would be: (1, 2, 3). An example of an array of literals would be: ['a', 'b', 'c']. (*) Note that there is a subtle difference between saying an "array of literals" and a "literal array". An array of literals is simply an array that happens to contain nothing but literals. A literal array is a more slippery concept since an array is actually three things strung together: a name, a memoryspace that acts as a container, and a value (see the L entry for more information). Of these, the name is a literal, the container is not a literal, and the values stored in the container may or may not be literals. (In the example given in the L section, the values 7 and 'a' are literals, while $quux is not.) Examples of literals: 7, 3.1415926535897932384, 'Fourscore and seven', 0xDEADBEEF, b10100011, 'z'. Examples of non-literals: $foo, @bar, %baz, jaz() Term: array Definition: An array is a collection of Perl L and/or variables, indexed by number using square brackets, where the first index is 0. Therefore, you would say @myarray[0] to retrieve the first element, @myarray[1] to retrieve the second, and so on. On a deeper level, an array is actually three things at once: it is a name, a container, and a collection of values. For example, an array @a which contained the values 7, 'a', and $quux would look like this: Name: @a | Container: +++ ||| Values:(7) (a)($quux) Here we see that the name of this array is '@a', the name is associated with a container in memory, and that there are currently three values in that container. The first two of these values are L (specifically, the number 7 and the letter 'a'), but the third item is another container: a L variable named $quux. When accessed with an index that is a positive integer N, an array will access the element at the N-1th place (because, remember, indices start with 0). When accessed with an index that is a B integer M, an array will access the element that is at position M+1 from the B of the array. Therefore, @array[-1] returns the last element, @array[-2] returns the second to last element, and so on. Arrays know how to manage their own size; they will grow and shrink as needed when you add or remove elements. You never need to worry about whether an array has enough space to hold the number of elements you are about to insert. (***) Examples of arrays (usage): @foo = (1, 2,3); # create/init an array @foo[2]; # fetch last element @foo[-1]; # fetch last element undef @foo; # destroy array, free associated memory, #and decrement reference count on each #value NOTES: (*) There was a long thread a little while ago on how arrays would be written. I believe the final decision was that [] was the array composer, but I'm not sure. Can someone confirm or deny this for me? (I'll go dig through the archives after I send this, but if someone knows offhand, it would save time.) (**) There needs to be a point here explaining the difference between "list of literals" and "literal list" (and the same for arrays), but I find that I don't understand it well enough myself to explain it. (***) I feel like there should be some discussion here of the fact that an array is "really" a reference, and that when you pass it or assign it, you are really assigning the reference--I'm just not quite sure how to put it. Any suggestions? Also, a couple of questions: First, when I originally started writing these entries, they were substantially shorter. As I look at them now, I wonder if I haven't written something that is too long for a glossary entry, and would better be used for main documentation (or bird cage liner, if you are unkind)--what do you all think? Second, what format should this document be kept in? I know that POD is the standard, but I feel that POD by itself is a poor fit for a glossary, since a glossary needs very little presentation but a lot of structure (for example, you want to group the definition with the term, and you might want t
Re: Literals, take 2
On Fri, Nov 15, 2002 at 12:03:32PM -0800, Larry Wall wrote: > On Thu, Nov 14, 2002 at 12:24:50AM -0800, Dave Storrs wrote: > > : Also, on this subject...what happens if I want to use "letter notation" > : in a base higher than 36? > > What happens then is that people will think you're silly. :-) > > Larry On that point, I wholeheartedly agree. However, SOMEONE will try it. So, the final answer is that, for bases over 36, your only option is to use dotted notation, correct? --Dks
Re: Numeric Literals (Summary)
On Thu, Nov 14, 2002 at 01:33:31PM -0600, Jonathan Scott Duff wrote:
> On Thu, Nov 14, 2002 at 10:28:38AM -0800, Michael Lazzaro wrote:
>
> > 1.23_e_4# ok?
>
> Hrm. This one is annoying, but I think it should be okay.
Are you sure? If so, can you explain why for me, because I don't
think it should. Larry said that _ is only allowed between
digits--and here 'e' is not a digit, it is an exponent marker. It
serves a similar function to the decimal ('.') in 7.3 -- not an actual
component of the number (i.e., a digit), but a structural marker
within the number (saying "this next part is the (decimal|exponent)"
for floats/exponentials, respectively).
> > 20:1.G.K# base 20 (identical?)
> > 20:1_G_K# base 20 (identical?)
> > 20:1.16.19 # base 20 (identical?)
> > 20:1_16_19 # base 20 (identical?)
>
>(I still don't see
> a use for non-decimal floating point representations, but that's
> probably just my lack of imagination).
It's not just you--I don't see it either, fwiw. The only reason I can
come up with--and I am not convinced by it--is that if you are doing a
long series of calculations in one base, you might now want to do the
context switch in your head just because you need to use a float.
--Dks
Re: Numeric Literals (Summary)
On Fri, Nov 15, 2002 at 12:02:02PM -0800, Dave Whipp wrote: > $b = 4294967296:1.2.3.4 # base 2**32 Hmm, interesting. 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 24*60*60:10 # one day in seconds, easy representation Or how about run-time evaluated versions? # Set a timer to run for either a day or an hour, depending $timer = 60*60*($use_days ? 24 : 1):10 Or a REALLY sick one: fetch_base():7.9# great for Obfuscated Perl. also good for # concisely (though not partiuclarly readably) # determining multiple values for the index # into a dispatch table. --Dks
