The cancellation behavior makes no sense to me. I expect ?one(0, 1,
2, 2) to return false. That happens whether or not it collapses the
2's to one 2, but not if it ignores/cancels them.
The question is, what should ?one(0, 1, 1) return? I think it's
pretty clearly false, which implies that junc
HaloO
Jon Lang wrote:
Larry Wall wrote:
eqv and === autothread just like any other comparisons. If you really
want to compare the contents of two junctions, you have to use the
results of some magical .eigenmumble method to return the contents
as a non-junction. Possibly stringification will
On Thu, Nov 13, 2008 at 07:19:31PM -0600, Patrick R. Michaud wrote:
: S06:2362 says:
:
: You can get the current routine name by calling C<&?ROUTINE.name>.
: (The outermost routine at a file-scoped compilation unit is always
: named C<&MAIN> in the file's package.)
:
: Is this the sam
On 2008 Nov 14, at 12:14, Larry Wall wrote:
On Thu, Nov 13, 2008 at 07:19:31PM -0600, Patrick R. Michaud wrote:
: S06:2362 says:
:
: You can get the current routine name by calling C<&?
ROUTINE.name>.
: (The outermost routine at a file-scoped compilation unit is
always
: named C<&
On Fri, Nov 14, 2008 at 01:50:59PM -0500, Brandon S. Allbery KF8NH wrote:
> WHat *is* the outermost scope in that case? When is code in that scope
> executed? I could see this as being a hack to allow a module to be used
> either directly as a main, or "use"d; the former ignoring top level scop
Sex, 2008-11-14 às 09:14 -0800, Larry Wall escreveu:
> That's correct. We could fix it two ways. Either the mainline code
> gets a consistent new name, or the outermost scope is redefined to an INIT
> if there is a user-defined MAIN. I can argue it both ways.
I'd argue that there's an implicit
