Re: Initial notes

[Piers Cawley]

"Markus Laire" <[EMAIL PROTECTED]> writes:

> On 9 Nov 2002 at 18:56, Andrew Wilson wrote:
>
>> Starting small sounds like a good idea.  I'm not so sure about trying to
>> "lock things down" before moving on.  I don't think that will be
>> possible in any meaningful way.  The problem with trying to lock things
>> down is that the design team are refining the design as they go.  If
>> something isn't working they change it.
>> 
>> I will be happy to be proved wrong about this but I have a feeling that
>> too much attention to detail will get us bogged down.
>
> I also think that we shouldn't try to provide too exact and final 
> documentation at once. Just define each area "with enough detail" 
> (whatever that means) and then move on. Until whole language-design 
> is somewhat complete, there will be things which requires earlier 
> decisions to be changed.

I'm definitely for this as much as possible. In _A Pattern Language_,
Christopher Alexander has pattern 'Gradual Stiffening', which talks of
the desirability of deciding things as late as possible. Admittedly,
this is a good deal more important in an architectural context, where
decisions really do get Set In Stone; documentation is just words
after all. What's *really* important is that we shouldn't ever allow
the existence of documentation describing one way of doing things to
stop us (Larry) changing our minds. 

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)

[Nicholas Clark]

On Tue, Nov 12, 2002 at 07:15:23PM -0700, Sean M. Burke wrote:
> wrote on Mon, 11 Nov 2002 15:50:34 -0800:

> >and the ability to turn syntax inferencing on a per-document basis.
> 
> On the Pod-people list, we have mostly decided that those inference rules 
> are more trouble than they are worth, precisely because they are 
> unpredictable, and typically there's no way to disable them.  I am entirely 
> happy with a future for Pod where no formatter (or, god help us, a parser) 
> thinks it its duty to turn "an O(N) solution" into "an C solution".

No. no. no. That should be "an L solution" because it's clearly a
man page reference. (Single character in brackets following a word)

(in other words I agree with Sean)

Nicholas Clark

Re: faq

[Markus Laire]

On 12 Nov 2002 at 16:40, Marius Nita wrote:

> Hello,
> 
> I have a question about the Parrot FAQ. I hope it's not too
> off-topic for this list. The FAQ mentions that "it would be nice to
> write the Perl to Bytecode compiler in Perl" and that there is no
> bootstrap problem. 
> 
> Does this mean that the perl6 compiler is written in perl5 and it
> will be rewritten in perl6 when a large enough subset of perl6 is
> implemented? I figure Perl5 will be obsolete at some point in the
> future... 

perl6, or parrot, or something else which runs on parrot.
With parrot you have a lot of possibilities on which languages to use 
(once it's complete).

> I noticed that the current incomplete perl6 implementation is written
> in perl5 using Parse::RecDescent, but I figured it's just a test
> implementation until the "real" compiler is written in C... 

perl5 won't be used anywhere when all is ready.

There will be small 'miniparrot' (currently in development), which 
can be build with just C compiler [was anything else required?].

Miniparrot can then be used to build everything else, including full 
parrot, perl6, other parrot-supported languaged, etc..

This 2nd step might be e.g. Bytecode-compiled perl6-program which is 
simple enough to work with miniparrot.

(Here might be some mistakes, but this is as I understand this, based 
on active lurking here)
-- 
Markus Laire 'malaire' <[EMAIL PROTECTED]>

This week's Perl 6 Summary

[Piers Cawley]

The Perl 6 Summary for the week ending 20021110
Far off in distant Newark a figure, muttering something about `Leon
Brocard', shambles across a railway bridge and makes its way into a
waiting room. Time passes. After a while, a train arrives and the figure
shambles on board, takes its seat, pulls a laptop from its bag and
starts to type. This is what it types: `=head1 The Perl 6 Summary for
the week ending 20021110'.

Yes, it's time for another update on the japes and tomfoolery from the
world of Perl 6. We start, as usual, with perl6-internals.

  The Myth of Fingerprints
At the end of the previous week, Gregor posted an outline of his
proposal for fixing the fingerprinting issue with dynamic loading. (The
fingerprinting issue is that 'old' .pbc files may break big time when
run on newer Parrots. Ideally we'd like Parrot to refuse to run such
files *before* bad things happen. It's proposed that this be done by
adding `fingerprints' to .pbc to allow for identification by Parrot.)
Leopold Tötsch wasn't at all sure about Gregor's approach, pointing out
that it would have massive speed implications, and lo, the thread got
dragged off in the direction of a discussion of optimizing Parrot for
speed. How did that happen then?

http://makeashorterlink.com/?T12252F62

  "on_exit" not portable
Andy Dougherty pointed out that Solaris doesn't have "on_exit", which is
used by Parrot to clean up after itself, and suggested that
interpreter.c be reworked to use "atexit". However, SunOS has on_exit
but doesn't have atexit. It's a quandary. Josh Wilmes suggested
implementing "Parrot_on_exit()" and "Parrot_exit()" in platform.c and
half promised a patch (unless somebody beat him to it.) Leo Tötsch and
Nicholas Clark both said, essentially "Nice idea, go do it."

Dan chimed in, pointing out that the current "on_exit" behaviour seemed
to be there as a workaround for bugs in exceptions, and that fixing
those was probably the better idea. Leo turned off the 'on_exit' stuff,
just as Josh was sending a patch implementing the Parrot_* functions. I
think that, as we now stand, we're back to doing exit cleanup, but using
the portable Parrot_* functions.

http://makeashorterlink.com/?F53246F62

http://makeashorterlink.com/?G14231F62

  Should memory be washed?
Peter Gibbs was unsure of the guarantees given by "Parrot_allocate" and
friends regarding the contents of the memory supplied. Apparently, some
code appears to assume that it will get pre-washed memory, while other
code does its own cleaning. Which is right? Leo Tötsch reckons that the
current behaviour (memory is zeroed at allocation time) should be
guaranteed. Dan wasn't so sure that this was a good idea if we go for a
`malloc like' scheme and thought that it could be argued that it was a
bug for any code to assume that the memory it got was zeroed.

Eventual consensus was that the basic allocator should not guarantee
zeroed memory, but that there should be a set of allocator functions
that *do* return zeroed memory. Leo checked in a patch to that effect.

Then they started talking about performance.

http://makeashorterlink.com/?X15224F62

  "string_set" is back
Leopold Tötsch has added a 'string_set' function which allows strings to
be recycled instead of having to create new strings every time. This can
lead to substantial speed gains when used appropriately. This led to a
discussion on when it was appropriate to use non destructive assignment
and when to use a destructive set. Somewhat to my surprise, nobody has
yet suggested the lispish "set" is non destructive, "set!" is
destructive split, allowing the Parrot coder to choose. Looks like I
just suggested it here.

http://makeashorterlink.com/?M26225F62

Meanwhile, over in perl6-language
Amazingly, the main topic of conversation this week wasn't the dreaded
operator thread...

  Unifying invocant and topic naming syntax
Allison Randal has written an article about Perl 6 topics for perl.com.
`Ralph' read this and didn't appear to like it very much, particularly
the "sub foo ($bar) is given($baz) { ... }" syntax which sets $baz to
the value of the caller's topic. (If you're not sure what I'm talking
about, now would be a good time to read Allison's article. Topics are
great, you'll like them.) Ralph wanted to do "sub foo ($baz : $bar is
topic) { ... }", and supplied several further, terser and terser
declaration forms, "method f ($self : $c : $a*, $b) {...}" anyone?

Allison thought Ralph was barking up the wrong tree, and explained the
thinking behind the topic related syntax and pointed out that Ralph
appeared to be conflating two `independent but interacting features'
with his proposal, but Ralph didn't give up that easily. Eventually,
after

Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)

[Tim Bunce]

On Tue, Nov 12, 2002 at 07:15:23PM -0700, Sean M. Burke wrote:
> 
> That's vaguely like the verbatim-formatted stuff that I've been 
> experimenting with lately, where the second line here:
> flock COUNTER, LOCK_EX;
> #: ^^^
> bolds the characters above the "^".

I'd like to see an easy way to declare that a verbatim block
(or all following verbatim blocks till told otherwise?) should
be parsed for formatting code like B, I, E, X, and L. The loss of
vertical alignment in the pod source would rarely be a concern.

Tim.

[CVS ci] JIT bug fix

[Leopold Toetsch]

I could localize a long outstanding bug in JIT causing 4 perl6 tests to 
fail.
When an opcode was a branch target as well as a branch source, the 
branch target got lost, causing wrong basic blocks, implying missing 
register loads ...

All perl6 tests are now ok on JIT too.

leo

Selfbootstrapping compilers (Was: faq)

[Gopal V]

If memory serves me right, Markus Laire wrote:
> Miniparrot can then be used to build everything else, including full 
> parrot, perl6, other parrot-supported languaged, etc..
> 
> This 2nd step might be e.g. Bytecode-compiled perl6-program which is 
> simple enough to work with miniparrot.

Please for heaven's sake don't write a perl6 compiler in perl6 ... It's
*very* frustrating if I have to download version 1 to compile 1.1 and
so on... (imagine compiling CVS head with a chain of older stuff) ...
And even that is suspect when the fingerprinting and other stuff changes
the binary packfile format ... (stuff like additional blobs or blocs have
been discussed lately) I have seen instances where a fix to support
feature "x" will need feature "x" to compile  Dependency hellhole..
This is especially true as parrot doesn't have a fully functional reference 
implementation (like gcc using cc) to start a bootstrap .

But yeah, I don't have any solutions either ... 

Gopal
-- 
The difference between insanity and genius is measured by success

Re: on Topic

[fearcadi]

Me writes:
 > Sorta. To quote an excellent summary:
 > 
 > "Topic is $_". 
 > 
 > 
 > 
 > > is $_ always lexical variable.
 > 
 > Yes.
 > 
 > 
 > > Or I can have $MyPackage::_ ?
 > 
 > You can copy or alias any value.
 > 

so if I understand correctly , 

Every topicalizer defines a topicalizer scope in which there is
implicit declaration 

my $_ ; 

and then lexical $_ ( implicitely ) is bound to ( or assigned to )
whatever it should in this particular topicalizer. And from that on $_
is just another lexical variable .

Question(s) : 

with no "use strict vars" any "just another variable" is taken by perl as
being global -- it is implicitly "our $just_another_var;" (???) 
about any lexical veriable ( just_another_variable ) Perl have to be
explicitly informed as being such . is $_ just_another_variable in
that respect too ??? 

in other words , what happens if I just use $_ ( that is , without
previous declaration ) *outside any topicalizer* ?

* will it be implicitly "our $_" ( probably not , because it is
  always lexical )
or  * will it be implicitely "my $_" -- class/package lexical 
or  * will it be error to just use it without declaration  
   * with "use strict vars" 
   * with "no strict vars " 

will  it be an error to declare it as "our $_" ; 

and to repeat the question from previous post , 
what will perl do when it see 

$My_Package::_ = 1 ; 


???




thanks , arcadi . 

Re: [CVS ci] JIT bug fix

[Daniel Grunblatt]

On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote:
> I could localize a long outstanding bug in JIT causing 4 perl6 tests to
> fail.
> When an opcode was a branch target as well as a branch source, the
> branch target got lost, causing wrong basic blocks, implying missing
> register loads ...

I wonder who was the #%$# that introduced that bug . D'OH! :)

> All perl6 tests are now ok on JIT too.

YAY! Thanks.

> leo

Re: [CVS ci] JIT bug fix

[Leopold Toetsch]

Daniel Grunblatt wrote:

> On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote:
>
>>I could localize a long outstanding bug in JIT causing 4 perl6 tests to
>>fail.

> I wonder who was the #%$# that introduced that bug . D'OH! :)

Wow, Daniel, the lost son himself ;-)

So I immediately have a question (or some):

I'm currently studying jit.c and I'm wondering, it it wouldn't be better 
to allocate registers for a whole basic block, and only store/load the 
used registers for non JITed sections when necessary. These normally 
don't have a lot of IRegs, so we could save a bunch of store/load's.

And 2), when doing this, I would change

char intval_map[INT_REGISTERS_TO_MAP] =
{ emit_EDI, emit_EBX, emit_EDX, emit_ECX };

to use callee saved regs first (ebx, edi, esi), and then (edx, ecx), 
which would mean, that the first 3 registers wouldn't be globbered by 
external functions. The current usage of esi could be done by ebp, I 
think. This would need some defines, how many/which registers are callee 
saved (like CALL_USED_REGISTERS in gcc/config/*).

What do you think of this?
leo

Re: Superpositions and laziness

[Peter Haworth]

On Tue, 12 Nov 2002 21:11:36 +, Piers Cawley wrote:
> Michael Lazzaro <[EMAIL PROTECTED]> writes:
> > On Friday, November 8, 2002, at 07:03 AM, Adam D. Lopresto wrote:
> >> I still prefer "cached", which sounds less lingo-ish than "memoized"
> >> but reads better than "same" ("Same as what?").
> >
> > Insert obligatory reference to Eiffel here, which IIR uses the word
> > "once":

But that means "once per system", not "once per unique argument list".

-- 
Peter Haworth   [EMAIL PROTECTED]
Interesting trivia: If you took all the sand in North Africa and spread
it out... it would cover the Sahara desert.

Re: Continuations

[Peter Haworth]

On Tue, 12 Nov 2002 14:30:24 +, Peter Haworth wrote:
> 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'm an idiot. Why not make the closure a coroutine itself?

  sub consume(@bar){
my $next=sub{ yielf $_ for @bar; return; };
while my $val = $next() {
  do_stuff($val,$next);
}
  }

>   sub do_stuff($val,$next){
> ...
> if $val ~~ something_or_other() {
>   my $quux = $next();
>   ...
> }
>   }
> 

-- 
Peter Haworth   [EMAIL PROTECTED]
"The term `Internet' has the meaning given that term in
 section 230(f)(1) of the Communications Act of 1934."
-- H.R. 3028, Trademark Cyberpiracy Prevention Act

Re: Meta-operators

[fearcadi]

Timothy S. Nelson writes:
 >  Hi all.  I hope this hasn't been discussed before.  I Googled for 
 > "perl6 meta-operators" and found nothing; likewise practically 
 > nothing searching the perl6-language archive for meta-operators.  
 > 
 > 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).  I'm thinking 
 >  it'd be widely useful in the core; it'd do a lot of the digraphs (like 
 >  += and those), and I can think of uses for it outside the core too.  
 > 
 >  Anyway, do we get them?  


there was some discussion in the thread under 

but there was no "last word" about it. either this is something perl
*trivially* will have due to its powerful grammar capabilities or it
is something perl will *avoid* to dwell in , or ... 

but it is interesting if perl will ( or already is ) be able to do
something like 

sub operator:tensor:[] ( Code &op  is parsed( ... ) , 
 Array|Hash|Scalar @a , 
 Array|Hash|Scalar @b )
{ ... return array/hash/whatever  of  @a[i] op @b[k] for  all pairs (i,k) }   
   
if that or something like that is possible , we will not need vector
operators "built in" the language  -- they will be just one of the 

sub operator:v:[] ( Code &op  is parsed( ... ) , 
 Array|Hash|Scalar @a , 
 Array|Hash|Scalar @b )
{ ... return array/hash/whatever  of  @a[i] op @b[i] for  
  all i present in both arrays ( if intersection ) or 
  all i present in one or another  array ( if union )  
}

but I dont know . Just wishes from someone who dont see the whole
picture .

arcadi .

Re: This week's Perl 6 Summary

[fearcadi]

Piers Cawley writes:
 > 
 >   FMTWYENTK about ":="
 > Bravely declining to expand the acronym in his subject, arcardi posted a
 > summary of his current understanding of the behavior of ":=", the

its "far more then what you ever need to know"
and after Damian Conway answer it becomes JEOWYNTK - 
"just enough of what you ever need to know" .

( is it ??? ) 

arcadi . 

RE: Selfbootstrapping compilers (Was: faq)

[Brent Dax]

Gopal V:
# If memory serves me right, Markus Laire wrote:
# > Miniparrot can then be used to build everything else, including full
# > parrot, perl6, other parrot-supported languaged, etc..
# > 
# > This 2nd step might be e.g. Bytecode-compiled perl6-program which is
# > simple enough to work with miniparrot.
# 
# Please for heaven's sake don't write a perl6 compiler in 
# perl6 ... It's
# *very* frustrating if I have to download version 1 to compile 
# 1.1 and so on... (imagine compiling CVS head with a chain of 

We have to--otherwise we can't have the self-modifying parser Larry
desperately wants.  But don't worry--we'll ship it already bytecompiled.

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)

Re: Selfbootstrapping compilers (Was: faq)

[Nicholas Clark]

On Wed, Nov 13, 2002 at 08:25:52AM -0800, Brent Dax wrote:
> Gopal V:
> # If memory serves me right, Markus Laire wrote:
> # > Miniparrot can then be used to build everything else, including full
> # > parrot, perl6, other parrot-supported languaged, etc..
> # > 
> # > This 2nd step might be e.g. Bytecode-compiled perl6-program which is
> # > simple enough to work with miniparrot.
> # 
> # Please for heaven's sake don't write a perl6 compiler in 
> # perl6 ... It's
> # *very* frustrating if I have to download version 1 to compile 
> # 1.1 and so on... (imagine compiling CVS head with a chain of 
> 
> We have to--otherwise we can't have the self-modifying parser Larry
> desperately wants.  But don't worry--we'll ship it already bytecompiled.

This is actually very similar to perl5, which strictly you can't actually
build from scratch without an existing copy of perl5.

However, all the header files generated by perl scripts (the target
make regen_headers) are shipped with the source kit. Once you've built a
perl5 from the distribution source you can actually run (by hand) them
without installing that perl, if you really want to.

I believe that this is directly comparable with shipping the perl6 parser
precompiled. It also means that we must be careful to prevent the compiled
perl6 parser becoming trojaned (as cc and login reportedly were on early unix
systems). Yes, I've only thought of this because of the recent tcpdump
trojan. But I think it's something we need to bear in mind.

Nicholas Clark

Re: [CVS ci] JIT bug fix

[Daniel Grunblatt]

On Wednesday 13 November 2002 11:48, Leopold Toetsch wrote:
> Daniel Grunblatt wrote:
>  > On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote:
>  >>I could localize a long outstanding bug in JIT causing 4 perl6 tests to
>  >>fail.
>  >
>  > I wonder who was the #%$# that introduced that bug . D'OH! :)
>
> Wow, Daniel, the lost son himself ;-)
>
:)
:
> So I immediately have a question (or some):
>
> I'm currently studying jit.c and I'm wondering, it it wouldn't be better
> to allocate registers for a whole basic block, and only store/load the
> used registers for non JITed sections when necessary. These normally
> don't have a lot of IRegs, so we could save a bunch of store/load's.

Oh yes, the optimizer doesn't do any cross section analisis yet, I'll fix
that.
see:
http://groups.google.com/groups?selm=20020805215944.GB301%40Bagpuss.unfortu.n
et

> And 2), when doing this, I would change
>
> char intval_map[INT_REGISTERS_TO_MAP] =
>  { emit_EDI, emit_EBX, emit_EDX, emit_ECX };
>
> to use callee saved regs first (ebx, edi, esi), and then (edx, ecx),
> which would mean, that the first 3 registers wouldn't be globbered by
> external functions. The current usage of esi could be done by ebp, I
> think. This would need some defines, how many/which registers are callee
> saved (like CALL_USED_REGISTERS in gcc/config/*).
>
> What do you think of this?

Good idea.

Daniel Grunblatt.

> leo

Re: [CVS ci] JIT bug fix

[Steve Fink]

On Nov-13, Leopold Toetsch wrote:
> Daniel Grunblatt wrote:
> 
> > On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote:
> >
> >>I could localize a long outstanding bug in JIT causing 4 perl6 tests to
> >>fail.
> 
> > I wonder who was the #%$# that introduced that bug . D'OH! :)
> 
> Wow, Daniel, the lost son himself ;-)

Wow, it really is him! Here, quick, are these fixes correct? (The
emit_is8bit isn't a fix, but seemed clearer) I've been periodically
having various test failures with the jit, and trying to track them
down. This particular one was nasty -- if I added or removed
completely unrelated instructions, the bug would disappear. Which now
makes sense, given the following fix:

Index: jit/i386/jit_emit.h
===
RCS file: /cvs/public/parrot/jit/i386/jit_emit.h,v
retrieving revision 1.9
diff -p -u -b -r1.9 jit_emit.h
--- jit/i386/jit_emit.h 13 Oct 2002 10:03:59 -  1.9
+++ jit/i386/jit_emit.h 13 Nov 2002 17:45:32 -
@@ -72,7 +72,7 @@
 static int 
 emit_is8bit(long disp)
 {
-return (((disp > -129) && (disp < 128)) ? 1 : 0);
+return (disp & 0xff) == 0;
 }
 
 static char *
@@ -132,7 +132,7 @@ emit_r_X(char *pc, int reg_opcode, int b
 }
 /* modrm sib disp */
 else { 
-*(pc++) = (emit_is8bit ? emit_Mod_b01 : emit_Mod_b10 ) 
+*(pc++) = (emit_is8bit(disp) ? emit_Mod_b01 : emit_Mod_b10 ) 
 | reg_opcode | emit_b100;
 emit_sib(pc++, scale, i, base);
 return emit_disp8_32(pc, disp);
@@ -843,7 +843,7 @@ emit_jcc(Parrot_jit_info_t *jit_info, in
 offset += 
 jit_info->optimizer->cur_section->branch_target->load_size;
 
-if (emit_is8bit(offset)) {
+if (emit_is8bit(offset - 2)) {
 emitm_jxs(jit_info->native_ptr, code, offset - 2);
 }
 else {
@@ -876,7 +876,7 @@ emit_jump(Parrot_jit_info_t *jit_info, o
 if (opcode <= jit_info->op_i) {
 offset = jit_info->arena.op_map[opcode].offset -
 (jit_info->native_ptr - jit_info->arena.start);
-if (emit_is8bit(offset)) {
+if (emit_is8bit(offset - 2)) {
 emitm_jumps(jit_info->native_ptr, offset - 2);
 }
 else {

Re: Primitive Vs Object types

[Larry Wall]

On Mon, Nov 11, 2002 at 08:51:50PM +1100, Damian Conway wrote:
: You will. But they won't be entries of a hash. They'll be
: separate variables and associated accessor methods.
:  So maybe something like this:
: 
:   foreach my $attr (qw(foo bar baz))
:   {
:print "$attr: $self.$attr()\n";
:   }

Note that if you call the accessor method, you may in fact be getting
a subclass's wrapper around the actual attribute.  To get at the actual
attributes, you'd need something like:

foreach my $attr (qw(foo bar baz))
{
 no strict 'syms';
 print "$attr: $.$attr\n";
}

Which is another good reason for the "." secondary sigil.  For some
value of "good"...

Larry

POD Formatting (was Re: Literal Values)

[Michael Lazzaro]

Jonathan Scott Duff wrote:

Or number the sections like this:

=section # blah
=section ## subblah
=section ### subsubblah
=section ## subblah2
=section # blah2

And let the author only worry about "sectioning" and not about
numbering at all.


I like that decently.  Obviously, making authors specify section 
numbers would be absurd.

It still seems like we have a lot of issues in general with things like 
bullets, etc., not easily knowing when they're only one paragraph vs. 
more than one paragraph.  I'm still not sure what the preferred 
"generic grouping" mechanism is for cases like this, where you need to 
specify where a previous format ends.

In any event, this is good enough for now.  Let's redirect all 
discussion on A Better Pod to the Pod-people list, and go with what we 
have unless and until they tell us otherwise.

Sean M. Burke wrote:
On the Pod-people list, we have mostly decided that those inference 
rules are more trouble than they are worth, precisely because they are 
unpredictable, and typically there's no way to disable them.  I am 
entirely happy with a future for Pod where no formatter (or, god help 
us, a parser) thinks it its duty to turn "an O(N) solution" into "an 
C solution".

You are my hero.

MikeL

Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)

[Larry Wall]

On Tue, Nov 12, 2002 at 06:49:57PM -0700, Sean M. Burke wrote:
: Larry Wall wrote on Tue, 12 Nov 2002 11:40:05 -0800:
: >could certainly talk about improvements.  As for per-document policy, 
: >there should certainly be some kind of
: >
: >=use module
: >
: >directive that, like Perl's C, is something more than just an 
: >"include".
: 
: I thought about putting something of the sort into perldpodspec and 
: Pod::Simple, but didn't see a particularly clean way to have it so that 1) 
: you wouldn't have to depend on a particular Pod-parsing module, and which 
: 2) could work in cases where the Pod-parser and the formatter are sanely 
: segregated.

I'd say that neither of those characteristics is true of Perl 5's C,
and yet that's how we got CPAN.  Cleanliness is nice, but extensibility
is crucial.

Larry

Literals, take 2

[Angel Faus]

Hi,

Many thanks for all the feedback about the literals document. 

This new version integrates most of the changes. I've also added a 
subsection about Inf and NaN, directly coming from Michael's  
perlval.

I've also changed the pod syntax to =section, as suggested. I've used 
the:

=section ** 

syntax to specify level, because this is the one I prefer, but I'll 
change this once we agree in the final format.

Comments welcome,

-angel



=section Literal Values

=section * Literal numbers

=section ** Integers

There are many ways to specify literal numeric values in perl, but 
they default to base 10 for input and output. Once the number has 
been read by perl it becomes just a magnitude. That is it loses all 
trace of the way it was originally represented and is just a number. 
This code for instance prints the literal value 14.

 my $x = 14;  # stores the integer 14 in $x
 print $x;

You can represent the literal value in any other base, using the
C syntax.

For example:

 my $i = 2:101110;# binary
 my $j = 3:1210112;   # tertiary
 my $k = 8:1270;   # octal

Printing these would give 46, 1310, and 696 respectively. When the 
base is greater than 10, there is a need to represent digits that are 
greater than 9.

You can do this in two ways:

=over

=item *

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.

 my $l = 16:1E3A7; # hexadecimal

=item *

Separating by dots: You can also write each digit in its decimal 
representation, and separate digits using the C<.> character.

 my $m = 256:255.255.255.0;# 256-base

=back

For example, the integer 30 can be written in hexadecimal base in two 
equivalent ways:

  my $x = 16:1D
  my $x = 16:1.14

These two representations are incompatible, so writing something like 
C<16:D.13> will generate a compile-time error.

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
 
Finally, you can create negative integers by prepending the C<-> 
character.

For example:

 my $x = 18;
 my $y = -18;

Perl allows the underline character, C<_>, to be placed as a separator 
between the digits of any literal number. You can use this to break 
up long numbers into more readable forms. There aren't any rules to 
it; you can use it however you like: 

 123_456_000.000   (floating point)
 2:0110_1000   (binary)
 16:FF_88_EE   (hexidecimal)

=section ** Floating-Point Numbers

You can use the decimal representation of the number and the standard 
exponental notation.

 my $x = -2.542;
 my $x = 7.823e12;

Perl lets you operate integer numbers with floating-point numbers, so 
the following operation is correct:

 print 3.5 + 2;  # prints 5.5

You can use the C<_> separator too in Floating-Point numbers:

 my $x = 1312512.25;   # floating-poing number
 my $x = 1_312_512.25; # the same

=section ** Pseudo-numbers

The terms C<+Inf> and C<-Inf> represent positive and negative 
infinity; you may sometimes use these to create infinite lists. 

The value C ("Not a Number") may be returned by some functions 
or operations to represent that the result of a calculation  (for 
example, division by zero) cannot be represented by a  numeric value. 

=section * Literal strings

Duble quotes or single quotes may be used around literal strings:

 print "Hello, world";
 print 'Hello, world';

However, only double quotes "interpolate" variables and special 
characters such as newlines ("\n"):

  print "Hello, $name\n"; # works fine
  print 'Hello, $name\n'; # prints $name\n literally
 
  my $x = 'world';
  print "Hello, $x";# Hello, world

You can type any character including newlines and tabs in literal 
strings: 

 my $x = 'Look mum, I can type 
 newlines and   tabs too!';

If you use a Unicode editor to edit your program, Unicode characters 
may occur directly within the literal strings. 

Unicode characters can also be added to a double-quoted string using 
the C<\x{...}> notation. The Unicode code for the desired character, 
in hexadecimal, should be placed in the braces. For instance, a 
smiley face is C<\x{263A}>.  

Perl provides escapes for easily inserting characters that have a 
codepoint below 256:

 print "\xB"  # Hexadecimal - character number 16:xB
 print "\024" # Octal   - character number 8:33

Aditionally, you can use the C<\N{...}> notation and  put the official 
Unicode character name within the braces, such as C<\N{WHITE SMILING 
FACE}>.

See the L section for a full explanation of the interpolation 
mechanism and a list of special characters in double-quoted strings.

=section ** String as vector of ordinals

Literals of the form C are parsed as a string composed of 
characters with the specified ordinal

Re: Literals, take 2

[Andrew Wilson]

On Wed, Nov 13, 2002 at 07:26:06PM +0100, Angel Faus wrote:
> For example, the integer 30 can be written in hexadecimal base in two 
> equivalent ways:
> 
>   my $x = 16:1D
>   my $x = 16:1.14
> 
> These two representations are incompatible, so writing something like 
> C<16:D.13> will generate a compile-time error.

So, can we specify floats in other bases?  if we can why is 16:D.14 an
error?  Why isn't it a floating point number?  I think we can and we
need to demonstrate this with a three digit hex number.  We also need to
point out that there is a problem with the two digit example.

andrew
-- 
Taurus: (April. 20 - May 20)
After years of zoological study and careful consideration, you've
decided that what separates us from the animals is a clever system of
ditches and barriers.



msg24062/pgp0.pgp
Description: PGP signature

Outline: Numeric Types and Values

[Michael Lazzaro]

Since we're having trouble finding a common voice, let's drill into one 
particular aspect of Section 1: Numerics, since that's what we've been 
talking about (and we have Angel's text to work from.)

Forget the rest of Section 1, let's just do this one small fragment.

There are a number of topics which must be covered when exploring how 
basic typed/untyped numbers will work in Perl6.  At minimum:

-

- introducing the basic numeric types, C, C, C

- literal values   (Angel's doc)
- integer and decimal literals
- scientific/exponential notation
- binary/octal/hex
- radix
- using letters
- using dots
- how underscore may be used
- Infinity
- NaN

- how numbers behave in other contexts
- boolean context
- string context
- ints in num context, nums in int context, etc.

- converting strings to numbers
(note that stringified numbers aren't literals,
 and have different rules in Perl5)
- reading a string as a number
- reading a string as a bin/oct/hex/radix (formatted) number

- converting numbers to strings
- writing a number as a string
(what the rules are for how it will look)
- writing a number as a formatted string
(how you write something as bin/oct/hex/radix)
(how you write something w/ other formatting)

- Int vs. int, Num vs. num, Bit vs. bit

- numeric precision and overflow/out-of-range errors
- (when it happens, what happens)
- (issues with floating point numbers)

- a full reference to all numeric types
(all the things like 'u_long' needed for C libraries, etc.)

-

Though the ordering here might be wrong, and we're probably still 
missing things, EACH of these represents a subsection in the tree 
(something that a user will want to be able to find by name) and EACH 
needs at least a paragraph and a few code samples to describe it.

It's also probably a good assumption that someone looking for how to 
write a numeric literal is more interested in "numerics" than in 
"literals", which implies that we describe literal numbers in the 
numerics section, and literal strings in the string section, rather 
than the perl5 approach of describing them both together.  So that's 
where we snip the sections.

(Again, a very crude example of a depth-first structure like this is at 
http://cog.cognitivity.com/perl6/val.html.  It's got some errors, and 
isn't divided out as much, but it shows that it is possible.)

-

Does anyone want to work on individual parts of this section?  (Angel's 
got the literal values part going pretty good).

If so, say so here, so someone else doesn't duplicate your work!!

MikeL

Re: Literals, take 2

[Jonathan Scott Duff]

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

> Perl allows the underline character, C<_>, to be placed as a separator 
> between the digits of any literal number. You can use this to break 
> up long numbers into more readable forms. There aren't any rules to 
> it; you can use it however you like: 
> 
>  123_456_000.000   (floating point)
>  2:0110_1000   (binary)
>  16:FF_88_EE   (hexidecimal)

1_2_3_4__5___6   (absurd, but doable)

> You can use the C<_> separator too in Floating-Point numbers:

If you're going to mention _ in floating point numbers here, the above
floating point example should be moved to here or extirpated IMHO.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Literals, take 2

[Jonathan Scott Duff]

On Wed, Nov 13, 2002 at 06:38:08PM +, Andrew Wilson wrote:
> On Wed, Nov 13, 2002 at 07:26:06PM +0100, Angel Faus wrote:
> > For example, the integer 30 can be written in hexadecimal base in two 
> > equivalent ways:
> > 
> >   my $x = 16:1D
> >   my $x = 16:1.14
> > 
> > These two representations are incompatible, so writing something like 
> > C<16:D.13> will generate a compile-time error.
> 
> So, can we specify floats in other bases?  

Why would you want to?

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Outline: Numeric Types and Values

[Luke Palmer]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 13 Nov 2002 11:01:26 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> - converting numbers to strings
>  - writing a number as a string
>  (what the rules are for how it will look)
>  - writing a number as a formatted string
>  (how you write something as bin/oct/hex/radix)
>  (how you write something w/ other formatting)

I'll do this part.

Luke

Re: Outline: Numeric Types and Values

[Angel Faus]

Looks good. 

I'll rewrite the literals section to match this better outline.

-angel

Re: [CVS ci] JIT - i386

[Daniel Grunblatt]

You will see it running as fast as mops.c compiled with -O3 if you change 
REDO: sub I4, I4, I3
for
REDO: dec I4
But that's obviously part of a higher level optimizer.

On Wednesday 13 November 2002 15:10, Leopold Toetsch wrote:
> Watch the mops ;-)
>
> leo

Re: faq

[Marius Nita]

On Wed, Nov 13, 2002 at 11:08:08AM +0200, Markus Laire wrote:
> On 12 Nov 2002 at 16:40, Marius Nita wrote:
> 
> > Hello,
> > 
> > I have a question about the Parrot FAQ. I hope it's not too
> > off-topic for this list. The FAQ mentions that "it would be nice to
> > write the Perl to Bytecode compiler in Perl" and that there is no
> > bootstrap problem. 
> > 
> > Does this mean that the perl6 compiler is written in perl5 and it
> > will be rewritten in perl6 when a large enough subset of perl6 is
> > implemented? I figure Perl5 will be obsolete at some point in the
> > future... 
> 
> perl6, or parrot, or something else which runs on parrot.
> With parrot you have a lot of possibilities on which languages to use 
> (once it's complete).

Thanks, this makes sense. There would still be 'a bootstrapping problem' since
the compiler would have to be rewritten in perl6. As I understand things,
Parrot is a bytecode compiler/interpreter, but a 'language compiler' has to be
written in some other language which already compiles to parrot assembly. (or
has a compiler in general -- like C) So if the perl6 compiler is
written in Cola/Jako/C/etc, it would have to be rewritten in perl6 once perl6
can be compiled with this (Cola/Jako/C/etc) compiler. Or a small subset of
perl6 can be implemented in perl5, and then it can be incremetally
implemented, at each stage using only the current available subset of perl6.
(which is classic bootstrapping)

I don't know how big of an issues this rewriting part is. I was just wondering
why the FAQ saw it as a non-issue, which led me to wonder whether rewriting is
necessary to begin with. I think it is.

Thanks,
marius

> > I noticed that the current incomplete perl6 implementation is written
> > in perl5 using Parse::RecDescent, but I figured it's just a test
> > implementation until the "real" compiler is written in C... 
> 
> perl5 won't be used anywhere when all is ready.
> 
> There will be small 'miniparrot' (currently in development), which 
> can be build with just C compiler [was anything else required?].
> 
> Miniparrot can then be used to build everything else, including full 
> parrot, perl6, other parrot-supported languaged, etc..
> 
> This 2nd step might be e.g. Bytecode-compiled perl6-program which is 
> simple enough to work with miniparrot.
> 
> (Here might be some mistakes, but this is as I understand this, based 
> on active lurking here)
> -- 
> Markus Laire 'malaire' <[EMAIL PROTECTED]>
> 

Re: [CVS ci] JIT - i386

[Leopold Toetsch]

Daniel Grunblatt wrote:


You will see it running as fast as mops.c compiled with -O3 if you change 
REDO: sub I4, I4, I3
for
REDO: dec I4


I didn't want to change the test case ;-)



But that's obviously part of a higher level optimizer.


Yes, with constant propagation the (todo) optimizer would see a
sub I4, I4, 1 giving a dec I4 and when looking at I4, the whole loop 
would then be
set I4, 0 ;-)

leo

Re: Selfbootstrapping compilers (Was: faq)

[Dan Sugalski]

At 5:16 PM +0530 11/13/02, Gopal V wrote:

If memory serves me right, Markus Laire wrote:

 Miniparrot can then be used to build everything else, including full
 parrot, perl6, other parrot-supported languaged, etc..

 This 2nd step might be e.g. Bytecode-compiled perl6-program which is
 simple enough to work with miniparrot.


Please for heaven's sake don't write a perl6 compiler in perl6 ... It's
*very* frustrating if I have to download version 1 to compile 1.1 and
so on...


Oh, absolutely not. That's way too much of a headache, and too much 
of a dependency.

The goal is for Parrot to require a C compiler and a platform shell 
or Make tool (either one) and that's it. We will ship with bytecode 
files that have the bits needed for the build precompiled, so if the 
perl compiler's partially written in perl, we'll ship a perl6.pbc in 
the distribution.

Yes, this will mean that people doing development on parrot will need 
a working parrot setup, but as that should be easy enough to get 
(given that it'll be available as a standalone distribution) it 
shouldn't be a problem except on new and unusual platforms. Hopefully 
not there, even, if proper tweaks to the core C code can be made.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Quick note on JIT bits

[Dan Sugalski]

I'm about to do exceptions, and as such I wanted to give a quick 
warning to everyone who does Odd Things. (Which would be in the JIT, 
mainly :)

Because of the way exceptions are going to work, we need to make sure 
that the code emitted for each individual opcode is self-contained, 
relative to the system stack. That is to say, when an opcode is done 
it can't leave any cruft on the system stack, and it shouldn't expect 
there to be any information on the system stack.

The exception system's going to be based on setjmp/longjmp[*], with a 
setjmp done just before entering the runloop, and longjmps done when 
an exception is thrown. The low-level exception handler will then 
unwind the interpreter stacks until it finds an exception handler, at 
which point it'll enter the runloop at the point the exception 
handler dictates. (The point that the parrot-level exception system 
noted that it was supposed to resume at)

This'll generally mean that the system stack'll be pretty mushed, and 
the runloop code won't have any guarantees as to what's on the stack, 
but execution must continue properly from that point on. So recursive 
calls to parrot functions can't recursively use the system stack or 
anything, as that'll get unwound by the low-level exception scheme 
and Bad Things Will Happen. And we wouldn't want that...

[*] Well, their signal-safe equivalents at least
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Unifying invocant and topic naming syntax

[Larry Wall]

On Mon, Nov 11, 2002 at 11:48:06PM -0600, Me wrote:
: Are placeholders only usable with anonymous
: subs, or named subs too?

Placeholders are not intended for use with named subs, since named
subs have a way of naming their parameters in a more readable fashion.
However, it may well fall out that if you say

sub foo { $^b <=> $^a }

it would effectively mean the same thing as

sub foo ($a, $b) { $b <=> $a }

But note that there's no placeholder equivalent for a forward declaration:

sub foo ($a, $b) { ... }

: Switching briefly to currying, can one curry
: a method?

Hmm.  We can allow what makes sense.  I suppose a class should be
allowed to curry one of its own methods on any non-invocant parameter,
since that's just equivalent to defining a new method in the same class.
(Generally, outside of a class, if you want to make the signatures of
the methods look different, the standard way is to derive a new class.)

Currying on the invocant is different, since it essentially turns
a method into a subroutine, and treats a class as a mere module.
This could be construed as antisocial.  However, as a special case,
one might often want to curry a set of methods to assume a particular
invocant.  But the syntax for that should probably involve the class
rather than the individual methods.  Saying

use DB_Connection.assuming(self => new DB_Connection)

could import all of DB_Connection's public methods into the current
class or module as subroutines, and then you don't have to do the
sort of I'm-a-class-no-I'm-a-module shenanigans that modules like
CGI currently do.

Larry

Re: on Topic

[Larry Wall]

On Wed, Nov 13, 2002 at 03:11:32PM +0200, [EMAIL PROTECTED] wrote:
: so if I understand correctly , 
: 
: Every topicalizer defines a topicalizer scope in which there is
: implicit declaration 
: 
: my $_ ; 
: 
: and then lexical $_ ( implicitely ) is bound to ( or assigned to )
: whatever it should in this particular topicalizer. And from that on $_
: is just another lexical variable .

Yes.

: Question(s) : 
: 
: with no "use strict vars" any "just another variable" is taken by perl as
: being global -- it is implicitly "our $just_another_var;" (???) 
: about any lexical veriable ( just_another_variable ) Perl have to be
: explicitly informed as being such . is $_ just_another_variable in
: that respect too ??? 

$_ is always a lexical.  Every file scope has an implicit "my $_" at the top.
Every nested scope either sets up its own lexical $_ or aliases to an outer $_.

: in other words , what happens if I just use $_ ( that is , without
: previous declaration ) *outside any topicalizer* ?

There is no "outside any topicalizer" from that standpoint.  However,
$_ does start off undefined in an implicit topicalizer, and we may
well disallow "break" to such an implicit topicalizer at file scope,
and maybe at subroutine scope.

: * will it be implicitly "our $_" ( probably not , because it is
:   always lexical )

Correct, $_ is always lexical.  But...

: or  * will it be implicitely "my $_" -- class/package lexical 

There's no such thing as a "class/package lexical".  I think you
mean file-scoped lexical here.

: or  * will it be error to just use it without declaration  
:* with "use strict vars" 
:* with "no strict vars " 
: 
: will  it be an error to declare it as "our $_" ; 

No, in this case, $_ is still considered a lexical, but it just happens
to be aliased to a variable in the current package.

: and to repeat the question from previous post , 
: what will perl do when it see 
: 
: $My_Package::_ = 1 ; 

It'll set the $My_Package::_ variable to 1, I presume.  Whether that
has any influence on the value of $_ depends on how $_ is currently
aliased.  But the name $_ will always be interpreted according to the
lexical definitions set up by "my" and "our" (including the implicit
outer "my").

Larry

Re: Superpositions and laziness

[Larry Wall]

On Fri, Nov 08, 2002 at 08:35:00PM +1100, Damian Conway wrote:
: What you want are conversion-to-(num|str|bool) methods:
: 
:   sub a_pure_func(Num $n) returns Num {
:   class is Num {
:   has Num $cache;
:   sub value { $n * $n }
:   method operator:+ ($self:) { +($cache //= value ) }
:   method operator:~ ($self:) { ~($cache //= value ) }
:   method operator:? ($self:) { ?($cache //= value ) }
:   }.new
:   }

Just a nit, but those are probably prefix: rather than operator:, since
we may need more clues than just the arguments to distinguish:

prefix:
infix:
postfix:
circumfix:   (or should that really be outfix:?)

Larry

Re: Superpositions and laziness

[Larry Wall]

On Tue, Nov 12, 2002 at 09:03:22PM +, Piers Cawley wrote:
: Hang on, couldn't you rewrite things to not use the cache?
: 
: class is $class {
:   sub value { &func(*@args) }
:   method operator:+ ($self is rw:) { +($self = value) }
:   method operator:~ ($self is rw:) { ~($self = value) }
:   method operator:? ($self is rw:) { ?($self = value) }
: }.new
: 
: I don't know if I hope that works or hope it fails miserably. 
: 
: Also note that, if you were feeling sufficiently lazy with numbers,
: you could define the set of binary operators for your deferred
: numbers:
: 
:   method operator:+ ($self: Num $other) is lazy { +($self) + $other }
:   method operator:* ($self: Num $other) is lazy { +($self) * $other }
:   method operator:/ ($self: Num $other) is lazy { +($self) / $other }
:   method operator:- ($self: Num $other) is lazy { +($self) - $other }
: 
: Or would that just be evil, Bad And Wrong?

I believe the correct term is "opaque".  And I don't mean that
in the good sense...

Larry

More junctions

[Luke Palmer]

When junctions collapse, is that reflected back in the original
junction, as it should be (QM-wise)?

$foo = 1 | 2 | 4
print $foo;
# Foo is now just one of (1, 2, 4); i.e. not a junction

If so, what is perl going to do about the computationally expensive
entanglement thingy?

$x = 0 | 1;
$y = 0 | 1;
$z = $x * $y; 

print $z; # 0 with 0.75 probability and 1 with 0.25
# If 0 was printed, then $x | $y == 0
# If 1 was printed, then $x & $y == 1

Here, are $x and $y collapsed yet, or are they still in an entangled
superposition?

Luke

Re: Unifying invocant and topic naming syntax

[Nicholas Clark]

Apologies for raising the dead (horse)

On Thu, Nov 07, 2002 at 03:27:51PM -0600, Me wrote:
> Damian:
> > ["it" will be passed to about 5% of subs,
> >  regardless of whether the context is your
> >  10 line scripts or my large modules]
> 
> If the syntax for passing "it" to a sub
> remains as verbose as it currently is,
> you are probably right that "it" won't
> be used to achieve brevity! I think it's
> a pity given that the core point of "it"
> is to achieve brevity.
> 
> Why do you think your estimate of Perl 6
> usage of "it" is so much lower than is
> true for the standard Perl 5 functions?

If a subroutine explicitly needs access to its invocant's topic, what is so
wrong with having an explicit read-write parameter in the argument list that
the caller of the subroutine is expected to put $_ in?

It makes it clear.

If I understand all this correctly, as is, this "access caller's topic"
is an unrestricted licence to commit action at a distance.

Accessing the caller's topic is the default in perl5. And there is still a
steady stream of bugs to p5p where core perl modules are doing something
(typically a while loop) which tramples on $_, and so makes something go
wrong in their caller. (possibly several levels down)

(And for that matter the "obvious" solution of local ($_) in perl5 is also
action at a distance if $_ is tied, as local is an immediate fetch and a
store at end of scope. Special case local on $_ ?)

Nicholas Clark
-- 
perl6 better than perl (this week)?   http://www.perl.org/advocacy/spoofathon/
[Alledgedly some judging activity soon. Yeah, right. Pull the other one]

Re: Unifying invocant and topic naming syntax

[Luke Palmer]

> Date: Wed, 13 Nov 2002 20:34:49 +
> From: Nicholas Clark <[EMAIL PROTECTED]>
> 
> 
> If a subroutine explicitly needs access to its invocant's topic, what is so
> wrong with having an explicit read-write parameter in the argument list that
> the caller of the subroutine is expected to put $_ in?
> 
> It makes it clear.
> 
> If I understand all this correctly, as is, this "access caller's topic"
> is an unrestricted licence to commit action at a distance.
> 
> Accessing the caller's topic is the default in perl5. And there is still a
> steady stream of bugs to p5p where core perl modules are doing something
> (typically a while loop) which tramples on $_, and so makes something go
> wrong in their caller. (possibly several levels down)
> 
> (And for that matter the "obvious" solution of local ($_) in perl5 is also
> action at a distance if $_ is tied, as local is an immediate fetch and a
> store at end of scope. Special case local on $_ ?)

Indeed.  And also mind that many (IIRC all, but I could be wrong)
Perl5 builtins used $_ as the I, and if a parameter was
supplied it would use that.

My favorite was from ages ago:

sub bar(;$foo //= $_) {...}

'Course that could be mistaken for defaulting to the current $_ in
C's lexical scope.  Regardless, IMO it is better style to always
use $_ as just a default, rather than a requirement.  Is there a good
reason to have subs like this:?

sub bar($foo) is given($baz) {...}

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) {...}

That duplicated parameter looks strange, and people will be wary of
using it that way (as I was).  I don't know what it looks like, but it
doesn't look like $baz gets $_ if not, well, C.

Luke

Re: Literals, take 2

[Andrew Wilson]

On Wed, Nov 13, 2002 at 01:10:05PM -0600, Jonathan Scott Duff wrote:
> On Wed, Nov 13, 2002 at 06:38:08PM +, Andrew Wilson wrote:
>> On Wed, Nov 13, 2002 at 07:26:06PM +0100, Angel Faus wrote:
>>> For example, the integer 30 can be written in hexadecimal base in two 
>>> equivalent ways:
>>> 
>>>   my $x = 16:1D
>>>   my $x = 16:1.14
>>> 
>>> These two representations are incompatible, so writing something like 
>>> C<16:D.13> will generate a compile-time error.
>> 
>> 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.

andrew
-- 
Capricorn: (Dec. 22 - Jan. 19)
You will be chained to a rock, upon which eagles will devour your liver
for all eternity, after you steal the secret of a great marinara sauce
from the gods.



msg24080/pgp0.pgp
Description: PGP signature

Re: Literals, take 2

[Jonathan Scott Duff]

On Wed, Nov 13, 2002 at 07:53:05PM +, Andrew Wilson wrote:
> On Wed, Nov 13, 2002 at 01:10:05PM -0600, Jonathan Scott Duff wrote:
> > On Wed, Nov 13, 2002 at 06:38:08PM +, Andrew Wilson wrote:
> >> On Wed, Nov 13, 2002 at 07:26:06PM +0100, Angel Faus wrote:
> >>> For example, the integer 30 can be written in hexadecimal base in two 
> >>> equivalent ways:
> >>> 
> >>>   my $x = 16:1D
> >>>   my $x = 16:1.14
> >>> 
> >>> These two representations are incompatible, so writing something like 
> >>> C<16:D.13> will generate a compile-time error.
> >> 
> >> 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.

I can't imagine someone would want to write something like this:

2:10.01 # 2.25 decimal
8:2.2   # same
16:2.4  # same

except for obfuscatory purposes.  Besides, if we allow dots for
floating point numbers how do we represent this integer:

256:234.254

?

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Literals, take 2

[Dave Whipp]

> except for obfuscatory purposes.  Besides, if we allow dots for
> floating point numbers how do we represent this integer:
>
> 256:234.254

Using this notation is cute: a generalization that lets us specify a strange
thing. That are the reasons for using such a thing?

1) an alternative to C
2) an IP address.

Creating a byte-string is not a common thing (in most modules). Its the type
of thing that is better done as a function than as syntax (especially if
functions can be evaluated at compile time).

The most common reason for dotted decimal notation is for IP addresses. If
that is the motivation, then the cute trick doesn't suffice: I can't use it
to specify IPv6 addresses (which are hex numbers, separated by colons; with
double-colon representing a zero-padding in the middle). syntax for bases 2,
10 and 16 seems like a good thing. If that syntax generalizes then fine: but
do we really need to go beyond base 36? If so, is dotted-decimal notation
the most appropriate (I might want to use dotted-hex???).

The original question (snipped) concerned the use of the binary point (for
specifying floating point numbers. Such things are used, though only in
restricted domains. For example, IEE754 single-point numbers use a 23 bit
mantissa, which is simply the 23 bits that follow the binary point (well,
almost). Sure, we don't usually write it that way; but the concept is valid.

I'd prefer to use the dot as a floating-point, in whatever base the number
is specified. Why should base-10 be an exception to a generalization? IP
addresses are probably better represented with an explicit prefix: e.g.
IP:255.255.255.0; or maybe even a function that accepts raw string input
(another example of such things is C).


Dave.

Re: Literals, take 2

[Larry Wall]

:   1_2_3_4__5___6   (absurd, but doable)

Nope, _ is allowed only between digits (counting a-f as digits in hex).

Larry

Re: Literals, take 2

[Jonathan Scott Duff]

On Wed, Nov 13, 2002 at 12:33:09PM -0800, Larry Wall wrote:
> : 1_2_3_4__5___6   (absurd, but doable)
> 
> Nope, _ is allowed only between digits (counting a-f as digits in hex).

Ah, good.  It has always mildly annoyed me in prior perls that 1__2
was a literal 12.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Literals, take 2

[Joseph F. Ryan]

Jonathan Scott Duff wrote:


On Wed, Nov 13, 2002 at 06:38:08PM +, Andrew Wilson wrote:
 

On Wed, Nov 13, 2002 at 07:26:06PM +0100, Angel Faus wrote:
   

For example, the integer 30 can be written in hexadecimal base in two 
equivalent ways:

 my $x = 16:1D
 my $x = 16:1.14

These two representations are incompatible, so writing something like 
C<16:D.13> will generate a compile-time error.
 

So, can we specify floats in other bases?  
   


Why would you want to?

-Scott




 

Well, why would you want a float in any radix?
To represent a fractional part of a whole digit in
that radix, of course.  If different radii are going
to be supported, I think its best to at least
support them fully.  For instance, what would
happen if you did this without floating point
support for different radii?

my $x = 16: 6;
my $y = 16: C;
my $z = $x/$y;
# $z should equal 6/C, aka 16: 0.8

Re: Literals, take 2

[Paul Johnson]

On Wed, Nov 13, 2002 at 03:00:07PM -0600, Jonathan Scott Duff wrote:
> On Wed, Nov 13, 2002 at 12:33:09PM -0800, Larry Wall wrote:
> > :   1_2_3_4__5___6   (absurd, but doable)
> > 
> > Nope, _ is allowed only between digits (counting a-f as digits in hex).
> 
> Ah, good.  It has always mildly annoyed me in prior perls that 1__2
> was a literal 12.

In that case you should turn on warnings.  Then you can be mildly
annoyed both by the result and by the warning ;-)

$ perl -Mwarnings=FATAL,syntax -e 'print 1__2'
Misplaced _ in number at -e line 1.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: Selfbootstrapping compilers (Was: faq)

[Nicholas Clark]

On Wed, Nov 13, 2002 at 03:06:03PM -0500, Dan Sugalski wrote:

> The goal is for Parrot to require a C compiler and a platform shell 
> or Make tool (either one) and that's it. We will ship with bytecode 
> files that have the bits needed for the build precompiled, so if the 
> perl compiler's partially written in perl, we'll ship a perl6.pbc in 
> the distribution.

I believe that it can be done with just a C compiler. (no make tool or shell
needed). If we use an equipped machine to unroll the makefile into the correct
steps (in the correct order), and turn that into C code that runs each in
turn, then we can bootstrap enough to run bytecode. (and a bytecode make tool)

Please archive this message and hold it against me when the time comes, and
you're looking for someone to prove it by making it work.

Nicholas Clark
-- 
vapourware better than perl?http://www.perl.org/advocacy/spoofathon/

Re: Selfbootstrapping compilers (Was: faq)

[Josh Wilmes]

At 20:47 on 11/13/2002 GMT, Nicholas Clark <[EMAIL PROTECTED]> wrote:

> On Wed, Nov 13, 2002 at 03:06:03PM -0500, Dan Sugalski wrote:
> 
> > The goal is for Parrot to require a C compiler and a platform shell 
> > or Make tool (either one) and that's it. We will ship with bytecode 
> > files that have the bits needed for the build precompiled, so if the 
> > perl compiler's partially written in perl, we'll ship a perl6.pbc in 
> > the distribution.
> 
> I believe that it can be done with just a C compiler. (no make tool or shell
> needed). If we use an equipped machine to unroll the makefile into the correc
t
> steps (in the correct order), and turn that into C code that runs each in
> turn, then we can bootstrap enough to run bytecode. (and a bytecode make tool

We've actually already reached that point.

We currently generate a shell script with the build commands in it.  We 
could generate a .c file just as easily.

However, it's still necessary to tell it how to compile something somehow.

I think we can figure out the details when the time comes though- the 
current shell script (which assume gcc/unix) is enough for now.  We can 
add other .bat/.com files for other platforms, just to get things 
bootstrapped.

Once we get to the point that miniparrot is actually part of the parrot 
build process, then we can revisit exactly how to build it.

My inclination is to provide a configure script for platforms where that 
works, as well as native shell/bat/whatever is guaranteed to be available 
on that platform (including .or .c, if appropriate) for 
more unusual platform.


--Josh

Re: More junctions

[Deborah Ariel Pickett]

Luke wrote:
> When junctions collapse, is that reflected back in the original
> junction, as it should be (QM-wise)?
> 
> $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?  If we're trying to get away from the whole
"Quantum Superposition" name, why do we want to still have an implicit
collapse on $foo when it's used in certain contexts?  To collapse like
this doesn't make sense unless you're still thinking in quantum terms.

Perhaps the above should just print JUNCTION(0x1234) or something, like
the other built-in types do.  If you really want to collapse the
superposition, use an explicit collapse($foo) or observe($foo) or
pick($foo) or whatever you want to call it.

Just a thought from someone vaguely in the Cozens Camp.

-- 
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
 "The city lights shine seaward, swirling in a trance, her eyes upon the water
   alone in her last dance." - _Oh Life (There Must be More)_, Alan Parsons

Re: This week's Perl 6 Summary

[Deborah Ariel Pickett]

>   Supercomma!
> [snip]
> Larry then confessed that he was thinking of changing the declaration of
> parallel for loops from:
>   for @a ; @b ; @c - $a ; $b ; $c {...}
> to something like:
>   for parallel(@a, @b, @c) - $a, $b, $c {...}

Assuming that semicolon is no longer going to be a supercomma in these
situations, does that mean that we C addicts can have C back to do
the kinds of loops that we mean when we say "for loops"?  I really
don't much like the C keyword.

  for ($i = 1; $i < 10; $i++) { ... }

(Or is there still some syntactic ambiguity that I haven't thought of?)

-- 
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
 "The city lights shine seaward, swirling in a trance, her eyes upon the water
   alone in her last dance." - _Oh Life (There Must be More)_, Alan Parsons

Re: More junctions

[Smylers]

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.  If you really want to collapse the
> superposition, use an explicit collapse($foo) or observe($foo) or
> pick($foo) or whatever you want to call it.

That sounds the least scary behaviour: it may not do anything
particularly useful by default but at least it's obvious what's
happened.  Having C Huffman-encoded to nothing at all sounds
unnecessary for those that need it.

> Just a thought from someone vaguely in the Cozens Camp.

That, however, does sound scary -- I didn't know Simon had gone into the
holiday resort market.  Is The Cozens Camp anything like Butlins?

Smylers

re: This week's Perl 6 summary

[Damian Conway]

Deborah Ariel Pickett wrote:

> Assuming that semicolon is no longer going to be a supercomma in these
> situations, does that mean that we C addicts can have C back to do
> the kinds of loops that we mean when we say "for loops"?

I hope not.


> I really don't much like the C keyword.
>
>   for ($i = 1; $i < 10; $i++) { ... }
>
> (Or is there still some syntactic ambiguity that I haven't thought of?)

No. It's more a cognitive ambiguity.

One of the goals was to reduce (or preferrably eliminate) syntactic homonyms
in Perl 6. You'll notice that one of the Cs has been renamed to C.
And one of the Cs has become C. And I sincerely hope that the Cs
and Cs will be similarly disambiguated.

For several discussions of why this particular feature of natural languages
*doesn't* map well onto programming languages, see:

	http://www.csse.monash.edu.au/~damian/papers/#Human_Factors_in_Programming_Languages
	

Damian (an unrepentant homonymophobic)

Access to caller's topic (was Re: Unifying invocant and topic naming syntax)

[Me]

> "access caller's topic" is an unrestricted
> licence to commit action at a distance.

Right.

Perhaps:

 o There's a property that controls what subs
   can do with a lexical variable. I'll call
   it Yours.

 o By default, in the main package, topics are
   set to Yours(rw); other lexicals are set to
   not Yours.

 o A mechanism exists for a sub to bypass this
   access control for use with library routines.

--
ralph

Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)

[Sean M. Burke]

At 09:43 2002-11-13 -0800, Larry Wall wrote:

I thought about putting something of the sort into perldpodspec and 
Pod::Simple, but didn't see a particularly clean way to have it so that 
1) you wouldn't have to depend on a particular Pod-parsing module, and 
which 2) could work in cases where the Pod-parser and the formatter are 
sanely segregated.
I'd say that neither of those characteristics is true of Perl 5's C, 
and yet that's how we got CPAN.  Cleanliness is nice, but extensibility is 
crucial.

Well, I have been writing Pod::Simple with the goal of it being the only 
Pod parser anyone would ever want to use.
But I wouldn't object if it were the only Pod parser anyone could ever use 
-- or at least "=use" with.  After all, like XML::Parser (well, plus SAX), 
it presents every kind of sane markup interface anyone would ever want.

--
Sean M. Burkehttp://search.cpan.org/author/sburke/

Re: on Topic

[fearcadi]

Larry Wall writes:
 > Correct, $_ is always lexical.  But...
 > 
 > : or  * will it be implicitely "my $_" -- class/package lexical 
 > 
 > There's no such thing as a "class/package lexical".  I think you
 > mean file-scoped lexical here.

ooo, now I understand : *scope* is orthogonal concept to class/module
symbol-tables . scope is related only to ( current ) lexical
symbol-table. and the outmost scope is file scope . all other ( inner
) lexical scopes are enclosed by  closure braces wheither it is a
definition of class , subroutine or loop . 

 > 
 > : will  it be an error to declare it as "our $_" ; 
 > 
 > No, in this case, $_ is still considered a lexical, but it just happens
 > to be aliased to a variable in the current package.
 > 

which variable ? it seems that "our $_" is something like that (???)

my $_ # implicit -- at the beginning of file ( or actually any other
  # lexical scope
.. 
..
..
our $_ ; # translated to : our $Main::_ := $_ ; 
..# or $_ := $Main::_ 
..
..
???

( i have in mind that "our $thing " is something like this : "dont
worry , $thing is variable from current package ) 

but that would be strange , because I thaought that my/our manipulate
names in symbol-table , while aliasing is compleatly orthogonal to
that. or "our $_" is just special case with perl making additional
magic . 

 > aliased.  But the name $_ will always be interpreted according to the
 > lexical definitions set up by "my" and "our" (including the implicit
 > outer "my").
 > 


arcadi 

Re: Unifying invocant and topic naming syntax

[Andrew Wilson]

On Wed, Nov 13, 2002 at 08:34:49PM +, Nicholas Clark wrote:
> If a subroutine explicitly needs access to its invocant's topic, what is so
> wrong with having an explicit read-write parameter in the argument list that
> the caller of the subroutine is expected to put $_ in?

It's the difference between this:

print;

and this:

print $_;

It is as far as I'm concerned exactly what topic is all about.  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.

> It makes it clear.
> 
> If I understand all this correctly, as is, this "access caller's topic"
> is an unrestricted licence to commit action at a distance.
> 
> Accessing the caller's topic is the default in perl5. And there is still a
> steady stream of bugs to p5p where core perl modules are doing something
> (typically a while loop) which tramples on $_, and so makes something go
> wrong in their caller. (possibly several levels down)

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.

andrew
-- 
Gemini: (May 21 - June 21)
Disappointment is yours when you overestimate the power of the
human spirit.



msg24096/pgp0.pgp
Description: PGP signature

Re: on Topic

[Larry Wall]

On Thu, Nov 14, 2002 at 04:28:17AM +0200, [EMAIL PROTECTED] wrote:
:  > 
:  > : will  it be an error to declare it as "our $_" ; 
:  > 
:  > No, in this case, $_ is still considered a lexical, but it just happens
:  > to be aliased to a variable in the current package.
:  > 
: 
: which variable ? it seems that "our $_" is something like that (???)
: 
: my $_ # implicit -- at the beginning of file ( or actually any other
:   # lexical scope
: . 
: .
: .
: our $_ ; # translated to : our $Main::_ := $_ ; 

No, that's backwards.

: .# or $_ := $Main::_ 

More like that, except a new lexical name is introduced as with "my".

: ( i have in mind that "our $thing " is something like this : "dont
: worry , $thing is variable from current package ) 

Well, it has that effect, but it does so by pretending it's a lexical.

: but that would be strange , because I thaought that my/our manipulate
: names in symbol-table , while aliasing is compleatly orthogonal to
: that. or "our $_" is just special case with perl making additional
: magic . 

No special magic.  For any variable, saying

package P;
our $foo;

is very much like

my $foo ::= $P::foo

Larry

Re: More junctions

[Luke Palmer]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Deborah Ariel Pickett <[EMAIL PROTECTED]>
> Date: Thu, 14 Nov 2002 09:05:16 +1100 (EST)
> Cc: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> 
> Luke wrote:
> > When junctions collapse, is that reflected back in the original
> > junction, as it should be (QM-wise)?
> > 
> > $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?  If we're trying to get away from the whole
> "Quantum Superposition" name, why do we want to still have an implicit
> collapse on $foo when it's used in certain contexts?  To collapse like
> this doesn't make sense unless you're still thinking in quantum terms.
> 
> Perhaps the above should just print JUNCTION(0x1234) or something, like
> the other built-in types do.  If you really want to collapse the
> superposition, use an explicit collapse($foo) or observe($foo) or
> pick($foo) or whatever you want to call it.

You want these two subs to behave differently, then?

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".

It seems that collapsation on examination is somewhat essential to
logical flow, when substituting a junction for a solid value.  A piece
of code could certainly "be ready" for junctions (using C and
C), but if not, very obscure bugs could surface (like this
one) when a junction is trying to behave like a real value.

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?

Luke

RE: More junctions

[Brent Dax]

Luke Palmer:
# 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";
# }
# }

More simply, !($x == 4) is no longer exactly equivalent to ($x != 4).

# 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?

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).  This is much
scarier than it sounds--it's a lot like the !(x || y) == (!x && !y)
rule.

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)

Re: Docs Data Format (was Re: Project Start: Section 1)

[Dave Storrs]

[examples of how to create the glossary links snipped]

Assuming that we do go with the "maintain a unique list of keys in %glossary, then do 
an s///" approach, I'd be willing to maintain the list of terms.

--Dks

Re: Project Start: Section 1

[Dave Storrs]

On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote:
> 
> I wonder if it'd be feasible to do lists something like:
> 
> [...]
> 
> =*> level1
> =>> level2
> =+>>> level3
>   =* level4
> =>>>  level3
> =>  level1
>

I personally like the idea of keeping the '=' required, to be consistent with other 
commands.  However, I see no reason why it needs to be required at each level.  Maybe 
we could take a page from Doxygen's book, and have the POD parser use whitespace 
smartly:

=list

- level one, unordered
-# level two, ordered (because of the number sign)
- level three
- level four
- level three again
-# level two again (must be consistent about use of number sign)
- level one again

=endlist


--Dks

Re: Project Start: Section 1

[Dave Storrs]

On Tue, Nov 12, 2002 at 12:16:53PM -0600, Jonathan Scott Duff wrote:
> On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote:
> > Or if the leading = really must be required:
> > 
> > =*> level1
> > =>> level2
> > =+>>> level3
> >   =* level4
> > =>>>  level3
> > =>  level1
> 
> What about this for bulletted lists:
> 
> =item * level1
> =item ** level2
> =item *** level3
> =item  level4
> =item *** level3
> =item * level1
> 
> and this for ordered lists:
> 
> =item # level1
> =item ## level2
> =item ### level3
> =item  level4
> =item ### level3
> =item # level1

FWIW, I would not want ot have to count '#'s in order to tell how many levels of 
indentation I was getting.

But maybe we could hit a middle ground?

=item 1# Foo
=item 2 Bar
=item 2 Baz
=item 3 Jaz
=item 4 Quux
=item 1# Raboof

Produces this:

1. Foo
* Bar
* Baz
* Jaz
* Quux
2. Raboof

(Yes, I deliberately used 4 space indent instead of 8; I wanted to make sure I could 
fit 4 levels of indentation on one line.  Holy wars are two doors down at /dev/null.)

I propose that the author would be required to be consistent about the use or non-use 
of '#' at a particular level, just to keep things clear.

--Dks