On 09/14/2018 07:16 PM, Brad Gilbert wrote:
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 <toddandma...@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.


Thank you.

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)


HTH,
-T

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
was.

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
about them.

---

Thanks for the input.

Hopefully I can make changes that will make it easier for you
to understand.

I plan on sending you an email as soon as I am done with
the rewrites.
Feel free to remind me if I don't get to it soon.


Hi Brad,

Technical writing does not get the appreciation it deserves.
There is both talent and hard work involved!

When I said "yet", I presumed the a variable can be
redefined at will:

$ p6 'my $x; say $x.perl;
         $x="abc"; say $x.perl;
         $x=Nil; say $x.perl;'
Any
"abc"
Any

And that the receiving method only cares what you feed it
at the time it is called.

Thank you for appreciating my input.  Since I am so new to Perl 6,
I will trip across things a lot.

I have found with myself that after I know what is suppose to
be there, I often see what I think I see -- what is suppose
to be there -- and not what is actually there.  You have
probably seen this with all the typos I make.  And I
do proof read what I write.  So I am perfect for this.
And as I tell my wife "Sometimes it pays to be an idiot."

:-)

I look forward to your second iteration.  Kaizen (constant
improvement) is the name of the game.  You guys help me
so much, it is the least I can do to help out.

-T

Reply via email to