First off, let me weigh in on Damian's original point: I agree that
Junction!eigenvalues should be renamed to more accurately reflect what
it is (perhaps to something like Junction!seedvalues, since what it's
really trying to produce is a list of the values that it's using to
define the Junction), and that some means of generating a junction's
actual eigenvalues ought to be employed.

Personally, I don't think that it should be a public method: one thing
about junctions is that you can use them interchangeably with ordinary
scalars; giving them a public method breaks that.  In particular, code
that makes use of a Junction public method would break if you were to
hand it a non-Junction.  (Generalizing this, Junction should never
have any public methods.)  But I could see a function that passes an
item through as a one-item list (unless, maybe, it's a nil value, in
which case it might return an empty list?), but passes a junction
through as a list of all values that match the junction.  To
illustrate:

    those(Nil)           # ()
    those(1)            # 1
    those(any(1, 2, 3))  # 1, 2, 3
    those(all(1, 2, 3))  # ()
    those(one(1, 2, 3))  # 1, 2, 3
    those(none(1, 2, 3)) # infinite list of everything except 1, 2, 3

I went with "those" because it's more layman-friendly than
"eigenvalues"; and as a plural word, one would expect it to produce a
list.  Note also that if Damian's transjunction idea does indeed
auto-eigenvalue in list context, then "those($x)" would be equivalent
to forcing list context onto a transjunction: if "select" is the
transjunction constructor, then "@( select(...) )" ought to be exactly
equivalent to "those(...)".

As for the bit about sets vs. lists: personally, I'd prefer that there
not be quite as much difference between them as there currently is.
That is, I'd rather sets be usable wherever lists are called for, with
the caveat that there's no guarantee about the order in which you'll
get the set's members; only that you'll get each member exactly once.
The current approach is of much more limited value in programming.

-- 
Jonathan "Dataweaver" Lang

Reply via email to