On Fri, Sep 14, 2018 at 9:42 PM ToddAndMargo <toddandma...@zoho.com> wrote: > > 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
That is only true if you don't add :U If you do add it, then assigning a defined value produces an error > 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 think that it is because of how you read. The way your brain figures out what is written, is slow. To compensate your brain often guesses instead. Which is faster, but sometimes wrong. I think that my visual, auditory, and language parts of my brain have a lot of connections. So it is very easy for me to notice misspellings, or incorrect words. Actually I think there are links to other parts of my brain because some words and numbers have a "personality". There are even some pots that I use which have a "personality". > > :-) > > 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
