develooper Front page | perl.perl6.users | Postings from September 2018

Re: .kv ?

Thread Previous | Thread Next
Brad Gilbert
September 15, 2018 02:17
Re: .kv ?
Message ID:
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 <> wrote:
> On 09/14/2018 09:26 AM, Brad Gilbert wrote:
> > You can read for more information
> >
> > Tell me if you find any of the Perl 6 section confusing.
> >
> >
> 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.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About