Re: Collapsing Junction states?
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 junctions created by one() should not collapse duplicates. So we have a demonstrated desire for baglike junctions; I haven't seen a compelling need for setlike ones, but I could easily be missing something there. IOW, I tentatively agree with the proposal to just make all junctions baglike. On 11/14/08, Mark Biggar [EMAIL PROTECTED] wrote: Darren Duncan wrote: Larry Wall wrote: It seems simpler to say that one() produces bags rather than sets. If we don't make other modifications to the language then this would mean that a Junction is defined over a union type, Set|Bag with additional behaviors, depending on what operator constructed it. Now maybe that's fine. Or alternately, why not just redefine a Junction for consistency to say it is a Bag with additional behaviors rather than a Set with additional behaviors? Would doing this break anything? Do any intended uses of a Junction specifically versus a plain Set|Bag involve asking how many instances of a value there are, or asking how many distinct values or value instances are in the Junction? Aside from the 3 answers: exactly none, exactly one, one or more? The meaning of any() and all() do not change if the collection is allowed to be a Bag instead of a Set. There are two reasonable meanings for one(), either duplicates collapse done to single members of the collection or duplicates cancel (or are ignored, same thing). The later interpretation would mean that one(1,2,3,3) is the same as one(1,2), but constants aren't the interesting case, one(@a) is. I suppose we could define a :uniq(true|false) adverb to modify the meaning of one() so we could have both interpretations. Mark Biggar -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: Are eqv and === junction aware?
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 be sufficient, if
it canonicalizes the output order.
Perhaps there should be a way of disabling the autothreading?
I consider stringified junction comparison as second class that
we don't use for other objects either. An .eigenmumble definitely
needs a nicer name. So, don't we have an item enforcement operator?
If that would discharge junctions to mere objects we would have:
my $a = all(1,2,3);
my $b = $a;
if item $a === item $b { say junctions are identical }
And then we can invent some short form of that. Things that come
to my mind are =i=, =$= and =^= where the latter nicely reminds
one of the one() junction and also is the indicator for the meta
level where junctions loose their autothreading power and become
objects.
[..] and simply extracting its contents into a list or set won't
always do, since it might be Junction-specific details at which you
want to look.
Conversion to another type violates the requirement for === that
two objects of different types cannot be identical.
We have other operations that should not autothread but demote
junctions to objects:
any(1,2,3) ~~ Junction
Here it hardly makes sense to expand that to
1 ~~ Junction || 2 ~~ Junction || 3 ~~ Junction
Note that this demotion to object means that
any(1,2,3) ~~ Int
evaluates to false because the lhs is of type AnyJunction of Int.
To me this is the same as
[1,2,3] ~~ Int
which is false because there is an Array of Int not an Int.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: MAIN conflict in S06?
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 CMAIN in the file's package.) : : Is this the same MAIN that is described later in : Declaring a MAIN subroutine? It seems like that : section describes MAIN subroutines that are lexically : nested within the mainline code of the outermost : file-scoped compilation unit, and it seems a little : confusing if both are called MAIN. : : I'm guessing that the statement at S06:2362 is an artifact of : an earlier draft that didn't have the section on MAIN subroutines, : but I'm wanting to verify that this is the case (or seek further : clarification if it isn't). 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. Larry
Re: MAIN conflict in S06?
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 CMAIN in the file's package.) : : Is this the same MAIN that is described later in : Declaring a MAIN subroutine? It seems like that : section describes MAIN subroutines that are lexically : nested within the mainline code of the outermost : file-scoped compilation unit, and it seems a little : confusing if both are called MAIN. : : I'm guessing that the statement at S06:2362 is an artifact of : an earlier draft that didn't have the section on MAIN subroutines, : but I'm wanting to verify that this is the case (or seek further : clarification if it isn't). 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. 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 used; the former ignoring top level scope code, the latter ignoring MAIN. I think Python has something similar. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: MAIN conflict in S06?
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 used; the former ignoring top level scope code, the latter ignoring MAIN. I think Python has something similar. Python names the outermost scope __MAIN__ if the file is directly interpreted, but it gets a name related to the filename if it is used. That outermost code is always executed, but the standard idiom to have code that is only executed when the file is executed directly is to wrap it in an if test that compares the name against __MAIN__.
