Front page | perl.perl6.users |
Postings from September 2018
Re: .kv ?
From: Brad Gilbert
September 15, 2018 02:17
Re: .kv ?
Message ID: CAD2L-T3Ys4UU1c=Qujb7Ydak_nx=XQYMApJn2eJrKvErU4EErw@mail.gmail.com
The author greatly appreciates the time spent on writing this critique.
(I'm the author)
Responses written inline
On Fri, Sep 14, 2018 at 4:55 PM ToddAndMargo <ToddAndMargo@zoho.com> wrote:
> On 09/14/2018 09:26 AM, Brad Gilbert wrote:
> > You can read https://en.wikipedia.org/wiki/Option_type for more information
> > Tell me if you find any of the Perl 6 section confusing.
> > https://en.wikipedia.org/wiki/Option_type#Perl_6
> Hi Brad,
> I had to read to top over very slowly. Part of the issue was
> that I was not taught to read correctly. (I was taught
> "Look See", instead of "Phonics"). I kept seeing other words,
> other than "nullable" and "non-nullable". Eventually, I forced
> myself to use phonics and the words made sense. This is not the
> authors problem, but mine alone.
Yeah I remember thinking at the time that "non-nullable"
might be confusing.
When I read, I "hear" the words. (usually in my voice)
I will try to take into consideration to not use confusables
in the future.
> "There are as many null values as there are types, that
> is because every type is its own null. So all types are
> also their own option type."
> Well stated. Chuckle, in Modula2 a null is always 0H0000.
If I remember correctly, the only reason I wrote it was
so that I could write down those two sentences.
I think I even said them out loud to myself.
> 'To opt into a non-nullable version of a type add the :D
> "smiley" to it."
> This is confusing. And I don't think correct, but I could be wrong.
I stayed with the language that is on the rest of the page.
It is correct, but it needs some further refinement/clarification.
Really I should throw it out, and come up with a new sentence.
> Curt stated it a lot better:
> If I say "my Int $x",
> $x is now an Int, but an undefined Int.
> If I say "my Int $x = 42",
> $x is an Int, but set to a defined value, 42.
> ":D" means that the variable is "defined". "non-nullable" is
> a confusing way to state it.
That is not *exactly* what :D means.
It means it can only ever be a defined value of that type or subtype.
Curt was talking about something slightly different than what that
sentence talks about.
Perhaps I could have written:
“To exclude null values, a :D "smiley" can be added.”
I will think about this further when I am less tired.
> It is also possible to opt into a type that is only
> ever a nullable using the :U "smiley".
> Curt's description is explains this perfectly. "is only
> ever a nullable" is confusing. ":U" means that the
> variable has not got anything assigned to it yet.
No, :U means it can **never** have anything other than a null assigned to it.
Your statement was incorrect the moment you added "yet" instead of "ever".
This is part of the reason I asked for your input.
I wanted to know exactly where your thoughts diverged, and
where I was less than clear.
Now that I know both, I can hopefully make it so that people
who think and read like you do can understand it better.
> To me ":D" means that the variable has something assigned to
> and ":U" means that the variable has yet to have anything
> assigned to it.
my Any:U $t;
$t = Int;
$t = Str;
$t = 42; # error
Again "yet" is the wrong word.
> If I were to rewrite this, I'd reverse D and U as that
> is the way they evolve. All variables start out as :U.
> To designate a variable that does not have a value assigned
> to it yet and is still in the null state, use the :U designation.
> To designate a variable that must have a value assigned
> to it (not be in the null state), use the :D designation
I described :D first as that is more useful than :U
It is easier to describe.
It is also the default for the rest of the languages on the page.
After describing :D, it then becomes easier to describe :U
as it is exactly opposite
I may use your description of :D, at least as inspiration.
I will look into this further when I am less tired.
> The examples are excellent.
I remember worrying that it was so much longer than the rest of the
languages. (It's at least twice as long as the rest).
> Coming from Modula2 and Pasca, one of the issues I had to content
> with when I picked started coding in Perl 5 was that in Modula2
> a variable is just a spot in memory with a designated length.
> A new variable contains whatever junk was in that memory location
> when you started your program. You very quickly learn to pre-salt
> all your variables or you get caught in uninitialized variable hell.
> In Perl, variables are structures. There is a bunch of house keeping
> involved. The "my" declaration triggers this house keeping including
> where it is and all the rules to access it. The variable is pre-salted"
> (null) very much so. Perl is a ton easier to program in than Modula2.
> Chuckle, the Perl 5 guy never did forgive me for calling Reference
> Pointers "pointers". I constantly had to remind them
> that there were different kinds of pointers than those found
> in "C", which only points to a spot in memory. Perl's pointers
> point to the variables structure or "reference" and all the
> associated rules.
I think calling them pointers or references might bring along baggage
from other languages that doesn't apply.
That said, I have (almost) never programmed in a language that
directly deals with memory like that.
I know how it works (basically), I've just never done it.
I will note that in the first sentence where you used the word "content"
you actually meant "contend".
(It didn't "sound" right when I read it)
> They also got huffy with me calling hashes "associative arrays",
> which they are. When I quoted them Larry's reasoning on the
> subject (hash is easier to write), they shut up. But I
> could tell it still rankled.
> I don't know why they were so huffy. "Associative Array"
> help me wrap my mind around what exactly my favorite variable
It doesn't bother me what you call them.
That said if you seem new to Perl I would probably mention
that we call them hashes.
If for no other reason than it makes it easier to find information
Thanks for the input.
Hopefully I can make changes that will make it easier for you
I plan on sending you an email as soon as I am done with
Feel free to remind me if I don't get to it soon.