On 9/28/18 6:28 PM, Larry Wall wrote:
On Fri, Sep 28, 2018 at 03:50:31PM -0700, ToddAndMargo wrote:
: On 9/27/18 12:40 AM, Laurent Rosenfeld via perl6-users wrote:
: > > I am NOT asking it to limit my request to Infinity.
: >
: >Yes you are, implicitly. If you don't pass any parameter for
: >$limit, $limit will take the default value supplied by the
: >signature, i.e. Inf.
:
: True, but that is not what the manual says Inf is.  Lower in this
: thread I made a suggest addition to the wording of Inf.  Would
: you mind looking at it and offering your criticism?

Why do you want to burden the definition of what something *is* with
all the things you can *do* with it?  The former is tractable, while
the latter is not.

It seems to me that you are applying a different standard to human and
computer languages here.  In both human and computer languages, what
something *is* has little to do with what something *does*.  These are
different abstraction levels.  You're fine with this in English, so
trying to flatten out all the abstraction levels is tending to work
against your understanding of computer languages here, I suspect.

The word "knife" is a noun, but if I "knife" someone, I'm using a noun
(what the word is) as a verb (what the word can do).  Human language is
full of these borrowings of abstraction level, so much so that linguists
even have a name for them in general, the "emic vs etic" distinction.
In non-linguistic terms, "what you said vs what you really meant".
What it is, vs what it does.

Originally these were coined on the phonetic vs phonemic level, so we
see lots of places in English where the phonetics don't match up with
how they are used:

     The prince made some prints.

Here you pronounce those words identically on a phonetic level, but on
a higher phonemic level (or even on a morphophonemic level), "prince" is
only one morpheme, while "prints" is two morphemes "print" and the plural
"s".  But this etic/emic distinction works at higher levels as well:

     Here's a you-can-even-use-a-sentence-as-an-adjective example.

Here the etic description of "you-can-even-use-a-sentence-as-an-adjective"
is that of a sentence.  That's what it *is*.  But language is flexible
enough that I can choose (emically) to slot the whole sentence in as
a adjective.  That's what the sentence can *do*.  (Or that's what you
can do with a sentence, if you prefer.)  The fact that you can do this
takes nothing away from what a sentence *is*, because that's at a lower
abstraction level.

Going up the linguistic stack even further, every time you read a metaphor
in a poem (or in a newspaper article for that matter), you are using
your knowledge of English to realize that the poet (or reporter) is
relying on you, the Gentle Reader, to realize that the writer is
using a metaphor.  A metaphor is when you say one thing but mean
something else by it.  The words of a metaphor are what it "is", but
the meaning it produces in your brain is what it "does".

The fact that the $limit is using a particular value with a particular
representation in memory ("what the manual says Inf is") has almost
nothing to do with how we choose to use it metaphorically in an interface,
except insofar as it's extremely convenient to have a floating-point value
that happens to compare as larger than any integer you want to name.
That comparison is a thing that Inf can *do*, which is the abstraction level on
which the $limit API is working.  The fact that it can be used this way
is not at all contradictory to the description of what the Inf value *is*.

But the description of what it can do really belongs on the many places
where it can be used in various metaphorical ways, not in the definition
of what it is.  The floating-point Inf value really has no clue whatsoever
about all the ways it might be used.  It probably doesn't even realize
it can be compared with an integer.  :)

Larry



Hi Larry,

I really enjoyed the read.  Thank you!

Now in my personal life, I am really guilty of telling
bad jokes:

    Two guys walked into a bar.
    A third guy ducked.

This goes to your beautifully written example of the
writer expecting the reader to realize he is using a
metaphor.  It is up to the "victim" of my bad joke to
realize that "bar" has two meanings: a place
where alcoholic beverages are sold and a metal rod.

In programming and in other things mathematical, you
expect definitions to be literal.  You do not expect
metaphors.  The "literal" definition of Infinity is
what made me realize what was happening.  I will
explain more in a follow paragraphs.

Now I do adore the "words" method and use it frequently.
When I went to the manual to see if there was any other way
to use it, I was astonished at how they got from point A
to point B.  This is because I took the definition of Inf
in the manual literally.

Now look up the definition of Infinity, which is to
be taken literally

   https://en.wikipedia.org/wiki/Infinity
      Infinity (symbol: ∞) is a concept describing something
      without any bound or larger than any natural number.

When I read the above, it dawned on me what they were trying
to accomplish by using "Inf" as an argument: Infinity literally
means "Without bound" or "no limit".  That made the light bulb go
off.  "That is what they are getting at and why they used it."

So the literal definition of Infinity was what made me understand
the "metaphor" that you speak of.  This is not a problem
with metaphors: this is poor wording.

The ONLY thing I do not like about Perl 6 is the routines
section of the documentation.  The documentation should be
written as a spoken language dictionary.  This is what the
word means and this is how it is used in context.

Now from your former creation, Perl 5, the "perldoc -f xxx"
gives a wonderful and concise definition of a function.
I hardly ever had to ask for help figuring them out.  In
your current wonderful clean up of Perl, EVEN when I know
how to use a method/sub, I can not understand the documentation.

I wrote you off line a while back asking you about a memory
issue with Perl 6 that a mentor over on the Perl 5 group
had pointed out.  This mentor took apart the one line definition of
"words" like this:

     >  multi method words(Str:D $input: $limit = Inf --> Positional)

     That's a multi-method using a definite string named $input
     as invocant, taking an optional,second argument named limit
     whose default value is 'no limit' ('infinity') and returning
     something which can be indexed.

     A 'definite string' means "a string and not a Str type object".

    'Multi-method' means one can have any number of method named
     words with different signatures, different number of arguments
     or different argument types, eg,

     multi method words(Str:U: -->Positional)
     [possibly, this may be grammatically wrong]

     and a words implementation is chosen and runtime based on
     the number and types of argument which were passed.

     In practice, this means that, in Perl 6, "function call
     overhead" is something to worry about which will make
     people who think every problem should be solved by employing
     the proper, unstructured sequence of 15 million steps very
     happy.

He doesn't even write in Perl 6 and he gave an explanation 20 times
more understandable than the Perl 6 docs.

He also took a swipe at Perl 6 (he is a Perl 5 die hard adn
thinks Perl6 is Java):

     It has been said that Perl 5 is supposed to make simple
     things simple and complicated ones possible. Judging from
     this short journey to the Perl 6 syntaxverse, this language
     seems to be based on the much more popular philosophy of
     making the simple things complicated and the complicated
     ones impossible.

He has a point, but only in the documentation.

I have programmed in Perl 5 and Perl 6 and I think Perl 6 is
far easier to write in that Perl 5, especially since I write
in Top Down and you wonderfully cleaned up the insane
subroutine headers.  Many things are far easier to use in
Perl 6 than 5.  And I really appreciate you starting everything
counting from zero too.  No guessing if things are $1 or $0.

I think maybe the issue with the routines documentation is that
whoever wrote it did not see it as a beginner would see it
and saw what he expected to see and not what was actually there.
This is why I am trying to poke in some perdocs style prose
into the documentation with RFE's.  I am trying to be part of the
solution instead of always gripping about the problem.

I do believe the confusion caused by the "words" documentation
would be clean up by inserting the following:

Proposed addition to "words":

     "$limits" is an optional argument.  When left empty, the
     value defaults to Inf (Infinity), meaning "without bound"
     or "no limit"

Proposed addition to "Inf":

     The value Inf (Infinity) represents "without bound" or
     "no limit" (meaning "all possible values") when used
     as an argument.

     Inf when used as an instance of Num and represents a
     value that's too large to represent in 64-bit double-precision
     floating point number

Oh my goodness gracious did you top yourself with Perl 6.  I love
it. You are some kind of freaking genius that only occurs in humans every 100 years of so. You do not want newcomers running screaming
in terror when they first see the documentation: "make simple things
complicated and the complicated ones impossible."

Was his criticism of Perl6's memory management justified?

Yes, I do tend to run on.

Question for you, in keeping with your beautiful subroutine
headers, when an argument is optional, it would be a lot
clearer if you used the "?":

      $limit? = Inf --> Positional

Love the term "syntaxverse".

I hope you are still speaking to me,

Yours in confusion,
-T

    A duck walked into a bar.
    Said to the bartender "pour me a drink
    and put it on my bill".

Reply via email to