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.
