On Sun 20 Jan, Me wrote:
> > On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > > Is this list of special blocks complete and correct?
> > >
> > > BEGIN Executes at the beginning of compilation
> > > CHECK Executes at the end of compilation
> > > INIT Executes at the beginning of run
> > > EN
* Bryan C. Warnock ([EMAIL PROTECTED]) [20 Jan 2002 05:33]:
> On Saturday 19 January 2002 12:20, iain truskett wrote:
[...]
> > It's a worry. Also odd is that Slashdot hasn't picked it up yet.
> Developers' section.
/me fossicks through configuration.
Ah. Didn't have 'Collapse Sections' enabled
> > [concerns over conflation of post-processing and post-assertions]
>
> Having read A4 thoroughly, twice, this was my only real concern
> (which contrasted with an overall sense of "wow, this is so cool").
Larry and I discussed it over breakfast the next day, and concluded that
there will be a
> "given nothing...":
>
> given () { ... }
do { ... }
seems simpler.
> Suppose you want to preserve $_ and alias
>
>given $value -> $g {
'->' seems more visually noisy than it need be in this case.
Perhaps:
given $value as $g { ... }
for @foo as $f { ... }
But, I ca
On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > Is this list of special blocks complete and correct?
Close and close. As of two days ago, Larry's thinking was:
BEGIN Executes at the beginning of compilation
CHECK Executes at the end of compilation
On Sun, 20 January 2002, "Me" wrote
>
> - LAST
> (Per Damian's last (LAST/POST) post.)
Yup.
> - FIRST?
> (Symmetry.)
No. We feel that such code just goes at the start of the block. Of
course, there's an argument that you might have several entry points to
a block (via C labels) and still wan
On Sunday 20 January 2002 08:29, [EMAIL PROTECTED] wrote:
> On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > > Is this list of special blocks complete and correct?
>
> Close and close. As of two days ago, Larry's thinking was:
>
Note to self: Program flow
> BEGIN Executes
On Sun, Jan 20, 2002 at 05:29:39AM -0800, Damian Conway wrote:
> On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > > Is this list of special blocks complete and correct?
>
> Close and close. As of two days ago, Larry's thinking was:
>
> BEGIN Executes at the beginning of co
"Bryan C. Warnock" wrote:
>
>
> Is it POST, LAST or LAST, POST, at runtime?
Since POST is checking invariants, and LAST can have side effects, LAST
must be executed before POST.
Apo 4 said POSTs were executed in the reverse of the order seen, I
presume that would hold for LAST as well.
> How
Now it should be back to something "normal".
Daniel Grunblatt.
On Sun, 13 Jan 2002, Daniel Grunblatt wrote:
> It's slow because it calls Parrot::Jit::Assemble ~1time for each opcode
> and that implies calls to as and objdump.
>
> Daniel Grunblatt.
>
>
> On Sat, 12 Jan 2002, Simon Glover wrote:
"Bryan C. Warnock" wrote:
>
> No examples are given, but are we to assume that this:
>
> for ($x = 0; $x < 100; $x++) {
> ...
> }
>
> becomes this:
>
> loop $x=0; $x < 100; $x++ {
> ...
> }
Yes.
> How would you use an $x lexically scoped to the loop block?
[EMAIL PROTECTED] writes:
: Is it POST, LAST or LAST, POST, at runtime?
Obviously you want to put the assertion checking after the cleanup,
so LAST, POST.
: How does one enforce the no side-effects rule, and how deeply does it
: traverse?
Dunno. Could warn or fail on assignment to any non-l
I think the last jit patch broke config.
perl vtable_h.pl
perl make_vtable_ops.pl > vtable.ops
perl ops2c.pl C core.ops io.ops rx.ops vtable.ops
include/parrot/oplib/core_ops.hperl ops2c.pl CPrederef core.ops io.ops
rx.ops vtable.ops
include/parrot/oplib/core_ops_prederef.hperl ops2pm.pl core.op
[EMAIL PROTECTED] writes:
: Why the double semantics of 'when'?
:
: It implicitly breaks when used as a 'when' block, but does not as a 'when'
: statement. It seems that a when should be a when should be a when, and a
: when being a when would be a win.
I can see your point. But emember th
Damian Conway writes:
: "Bryan C. Warnock" wrote:
: >
: > No examples are given, but are we to assume that this:
: >
: > for ($x = 0; $x < 100; $x++) {
: > ...
: > }
: >
: > becomes this:
: >
: > loop $x=0; $x < 100; $x++ {
: > ...
: > }
:
: Yes.
:
:
: > How
On Sunday 20 January 2002 20:57, Larry Wall wrote:
> I expect PRE and POST could inherit automatically according to the
> usual rules of DbC, though how you implement that is something other
> people have thought about more than me. I think that LAST doesn't
> inherit. If you want to share commo
[EMAIL PROTECTED] writes:
:
: Interestingly, this one tweak to the whitespace rule also means that we'll
: be able to simplify the parentheses out of other similar built-in constructs:
:
: if $foo { ... }
: elsif $bar { ... }
: else { ... }
:
: while $more { ... }
:
: for
>
>make: *** No rule to make target `Parrot/Jit/i686Generic.pm', needed by
>`Parrot/Jit.pm'. Stop.
>[msmith@linux parrot]$
Had to patch Configure.pl as follows to get a build on my box.
-Melvin
Index: Configure.pl
===
RCS file:
At 5:57 PM -0800 1/20/02, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: How does one enforce the no side-effects rule, and how deeply does it
>: traverse?
>
>Dunno. Could warn or fail on assignment to any non-lexical or
>non-local lexical as a start. Maybe we could warn or fail on method
>cal
>
> [EMAIL PROTECTED] writes:
> :
> : Interestingly, this one tweak to the whitespace rule also
> means that we'll
> : be able to simplify the parentheses out of other similar
> built-in constructs:
> :
> : if $foo { ... }
> : elsif $bar { ... }
> : else { ... }
> :
> : whi
[EMAIL PROTECTED] writes:
: The two current examples of an evil expression block are do {} and eval {},
: which require a semicolon terminator. However, with eval {} leaving...
Er, eval {} isn't leaving exactly--it's turning into try {}, which is
also an expression block. Plus we potentially
On Sunday 20 January 2002 21:43, Larry Wall wrote:
>
> I think it's too easy to have accidental non-void contexts, which is
> why I'm wanting to outlaw bare blocks at the statement level. But I
> don't think that fact influences your argument one way or the other.
> There's definitely some merit
Fixed, Thanks.
Daniel Grunblatt.
On Sun, 20 Jan 2002, Melvin Smith wrote:
>
> >
> >make: *** No rule to make target `Parrot/Jit/i686Generic.pm', needed by
> >`Parrot/Jit.pm'. Stop.
> >[msmith@linux parrot]$
>
> Had to patch Configure.pl as follows to get a build on my box.
>
> -Melvin
>
>
> I
On Sun, Jan 20, 2002 at 07:25:17PM -0500, Damian Conway wrote:
> > How would you use an $x lexically scoped to the loop block?
>
> You can't...directly. Nor can a C or C. The new rule is that
> to be lexical to a block it has to be declared in the block, or in the
> block's parameter list.
>
> Y
Bryan C. Warnock asked:
> Is it POST, LAST or LAST, POST, at runtime?
LAST then POST I suspect. For reasons already given in someone else's
reply. But, just possibly: intermixed in reverse order of definition.
> How does one enforce the no side-effects rule, and how deeply does it
> traverse?
Bryan C. Warnock asked:
> Since the parentheses are no longer required, will the expressions
> lose or retain their own scope level? (I'm assuming that whatever
> rule applies, it will hold true if you do elect to use parantheses
> anyway.)
Err. Expressions don't have their own scope level, ev
Graham Barr wrote:
> If a POST is inside a loop, is it executed at the end of each
> iteration or only when the loop exits ?
Only on final exit.
> If it is only when the loop exits, will it be possible to designate
> a block to be multiple (eg both POST and NEXT)
One way to do that would be to
Me wrote:
> > "given nothing...":
> >
> > given () { ... }
>
> do { ... }
>
> seems simpler.
But doesn't have the same effect. A C inside a C responds to
the current value of the "subject" specified by any surrounding
topicalizer (i.e. C, C, C, etc.)
>
> > Suppose you want to prese
> Angel> Could we have:
>
> Angel> foreach $item in @arr {...}
>
> Angel> Instead of
>
> Angel> foreach @arr -> $item {...}
>
> Larry considered that, and declined. Not sure of the reasons.
* He didn't want a keyword that would become lost when lots of variables
or sub calls are used i
> >> It may be a bit before Ex4 is done. Damian's on a cruise ship at
> >> the moment, so even if he's got the time (and I don't think he
> >> does) he's likely lacking connectivity. I expect he'll give us
> >> word at some point what the schedule is.
> >
> >They've got connectivity all right.
Damian Conway wrote (apparently whilst on stupid pills):
> > Do KEEP and UNDO take the place of CATCH within a block? (ie, you
> > may either CATCH, or you may KEEP and UNDO, but not both?
>
> Correct. KEEP+UNDO = CATCH and you can only have one CATCH per block.
As Larry has already pointed ou
Piers Cawley writes:
: Yeah, that's sort of where I got to as well. But I just wanted to make
: sure. I confess I'm somewhat wary of the ';' operator, especially
: where it's 'unguarded' by brackets, and once I start programming in
: Perl 6 then
:
: for (@aaa ; @bbb -> $a; $b) { ... }
:
: w
Angel Faus writes:
: ¿are we going to have a iterator protocol? I am talking of python's
: iterators, not ruby ones (which are being discussed in a different
: post). The iterator protocol allows any object that implements a .next
: method to be used in a foreach loop. This is very handy for th
Sterin, Ilya writes:
: How would we then create a inner block scoped variable, as for counters
: or other variables not needed passed the scope. The only way would be
: to increment within the block itself.
The only way to declare a lexical variable outside a block for use only
inside the block
Michael G Schwern writes:
: On Sun, Jan 20, 2002 at 07:25:17PM -0500, Damian Conway wrote:
: > > How would you use an $x lexically scoped to the loop block?
: >
: > You can't...directly. Nor can a C or C. The new rule is that
: > to be lexical to a block it has to be declared in the block, or in
[EMAIL PROTECTED] writes:
: On Sunday 20 January 2002 20:57, Larry Wall wrote:
: > I expect PRE and POST could inherit automatically according to the
: > usual rules of DbC, though how you implement that is something other
: > people have thought about more than me. I think that LAST doesn't
: >
Damian Conway writes:
: Graham Barr wrote:
:
: > If a POST is inside a loop, is it executed at the end of each
: > iteration or only when the loop exits ?
:
: Only on final exit.
:
: > If it is only when the loop exits, will it be possible to designate
: > a block to be multiple (eg both POST a
Larry Wall:
# What I can't figure out is, when you write
#
# LAST $coderef;
#
# when would it actually do the %MY._LAST_list.push($coderef)?
# Unfortunately, I think it has to do it at compile time, or we can't
# guarantee that the LAST actually gets run if an exception is thrown
# early. And
Brent Dax writes:
: Larry Wall:
: # I think we'd often
: # have people trying to write things like:
: #
: # my $coderef = sub { ... };
: # LAST $coderef;
: #
: # and then wondering why it says "Undefined LAST block" or some such.
:
: Maybe all of the [A-Z]+'s get defined each time the blo
39 matches
Mail list logo
