Front page | perl.perl6.users |
Postings from September 2018
Re: .kv ?
September 15, 2018 02:41
Re: .kv ?
Message ID: email@example.com
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 <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.
>> 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)
>> 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
> 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.
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;'
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.