On Mon, Mar 20, 2023 at 10:42:45PM +0000, Ralph Mellor wrote:
> On Mon, Mar 20, 2023 at 12:49 AM rir <rir...@comcast.net> wrote:
> >
> > I did, and do, recognize the validity of the problem of 'undefine' not
> > not aligning with '.defined'.
>
> But do you understand the problem I was trying to communicate?
Possibly not. "Truthiness" has always seemed sensible when read, but
today I submitted an issue to get it in the doc's glossary. It seems
just a neologism for 'evaluates True in boolean context.'
> What you're writing suggests to me you know some other PL(s) that
> have notions of truthiness and definedness that don't match Raku's,
> and thus you don't recognize the problem, thinking it's just some trivial
> name clash between `undefine` and `.defined`. It isn't. I'll have another
On reflection, my use of 'undefine' was pure dwimery without reference
to the documentation. That cuts both ways on the _problem_ I was focused
upon: the small loss of utility, the recommended replacements are not as
comprehensive.
> go at explaining. I apologize in advance if I again miss the mark, but I
> still hope the penny will drop if I persevere. Wish us luck!
Banked in the mind--a penny's a pound.
> Let me first summarize relevant parts of Raku's design. These are not
> going to change. They've been in place for 2 decades and work great.
> In Raku, whether or not something is considered definite is determined
> by an approach called "definiteness". An instance is definite. A type object
> is indefinite. There are no other possibilities. This notion of definiteness
> corresponds to the linguistic one that arises in many human languages.
> Consider a tree. One either means a definite tree, that large oak at the
> corner of the street, or an indefinite one, the idea of a tree. An instance,
> that oak, is definite. The idea, the type object `Tree`, is indefinite.
Well said. To restate: indefinite lacks, in some manner, a boundary;
definite is bounded and so indicates a specific tree or identifiable set
of trees.
> In Raku, whether or not something is considered defined is determined
> by an approach called "definedness". If a value is indefinite (eg the type
> object `Tree`) then it is not defined. Always. By contrast, definite values
> (instances) *are* defined by default, but there are exceptions. A `Failure`
The default inherited from Mu.
> instance is definite (because it's an instance, per the previous paragraph),
> yet it is undefined (because it's an instance of a failure).
This is unhelpful. The 'previous paragraph' is good common English but
lacks a technical focus. I see `my $f = Failure` and `my $i = Int`
as very similar, but that the Int type object is apt to indicate
something that never arrived or died away, whilst the Failure type
object is likely soon to be born.
Your
my @a := Array;
is helpful as it demonstrates a container action which I never
considered.
And, in language/control, I found:
Assigning Empty will effectively undefine an Array ...
which is definitely not the text which I previously read.
Be well,
Rob
