On Mon, Jun 08, 2020 at 01:28:34PM -0700, ToddAndMargo via perl6-users wrote: > On 2020-06-08 02:45, Richard Hainsworth wrote: > > Ok Todd, let me have a go at this issue. > > > > From what I understand, you see 'multi' and think 'there are more than > > one', which leads to the question 'where are they?' > > > > My understanding of 'multi' is 'there COULD be more than one', which > > leads to the question 'are there any?' > > > > This is actually a very powerful aspect of Raku. > > > > There are (as has been stated in this thread) four types of which multi > > = 'could be more than one' and only = 'only one' . > > > > If the developer wrote 'only sub' then, no one else could write a sub > > with that name. For a developer of a program or a module, that might be > > OK, because it's unlikely anyone else would need/want to use that name. > > But for a compiler, the probability is reversed. Someone will want to > > use it. That is why in many other languages there are 'reserved words' > > which you are not allowed to use. > > > > In Raku, if you develop a new type, for example say a quodion, and you > > want to 'add' quodions, then you CAN use + because it can be overloaded. > > It is defined as a multi. > > > > Or in your most overused example 'needle' can be rewritten to take a > > quodion, which may yield a spectrum of results because that's what > > quodions are for. > > > > Since needle is defined as a 'multi', if you write a 'needle' method for > > quodions, the needle for strings STILL exists, and Raku will correctly > > call the method you wrote for quodions if a quodion is implied, but call > > the default needle if a string (or any other type) is used. > > > > Since you have developed the quodion method entirely for your paid > > subscribers, the module is NOT available to the public, so you wont tell > > anyone about it. So it doesn't have to be in the documentation. > > > > Is this making any sense to you? > > > > Richard > > > Hi Richard, > > You are perfectly clear and beautifully well written. > You did make me look up "quodion". > > :-) > > And I am feeling guilty because I did already know all > this and it looks like you spent a considerable amount of > time getting into my head to formulate an answer that > was perfect for me. > > Here is the thing. I have no objecting to the developer > calling something a "multi" or an "only" depending on his > needs. That is entirely "HIS" call, "NOT" mine. > > And I hope the above statement ends all the well meaning, > helpful folks who are trying the re-explain the concept > to me. I got it a LONG time ago. > > My objection is when there actually exists more than > one and they are not experimental or otherwise hidden > for some reason and are truly, actually part of the > distribution, then they also should be documented. > Updates to the documentation should be part of > the code check in process, and in all probability, are. > > So, basically what I am saying is when multiples are > there and are open to the public, than it should be > documented. In this situation, why would the > developer want his hard work hidden?
OK, let me try to give you another example. If I'm too long-winded,
there will be an abstract at the end :)
Say somebody is writing a library that should serve as the standard
library for the C language. Now, there is a published, adopted standard
for the C language that all C compilers and C standard libraries
follow[1].
Now, the C language standard says that there may be more than one
library - one called "libc" as "the C library" providing pretty much all
of the functions, and another one called "libm" as "the mathematics
library" providing some additional functions for more-or-less precise
mathematical operations[2]. The standard says that the C library must
provide a function called printf() that prints out all kinds of things
according to a specific format, and that the maths library must provide
a function called trunc() that pretty much rounds a real number down to
the nearest integer that is not larger than it (so trunc(3.0) would return
3, trunc(4.5) would return 4, and trunc(-3.5) would return -4).
OK... So somebody is writing a "libc" that must provide the printf()
function, and they suddenly realize that, in order to be able to print
out real numbers with, say, two digits after the decimal point, one of
the easiest ways is to have a function that rounds a real number down.
So they write such a function, let's call it printf_trunc(), and they
hide it, they make it internal to the "libc" library, so your programs
can't see it. Right? Everything's fine, there is an internal function
that nobody can access.
So the next thing they do is turn to the maths library, and they realize
that they have to write a trunc() function, and the lightbulb comes on:
they have *already written* a function that rounds a real number down,
but for various reasons that *only matter to the author of the library*,
not to the users of the library, that function needs to live in the
"libc" library, not in the "libm" library.
OK, but they do not want to do the work twice, they do not want to have
the same code in both libraries, do they? So they want to make the
trunc() function in the maths library call the printf_trunc() function
in the standard C library. But... but that means... that means that
printf_trunc() may no longer be internal - it *must* be exposed, at least
to the maths library, and the way the C language works[3], this means
that *any* program that uses the standard C library can now see
the printf_trunc() function. That means that anybody who takes the time
to look at the source of the library can figure out that there is such
a function and, if they feel adventurous, they may actually call it in
their own program.
But! and this is the important point. THEY DO NOT WANT TO.
The author of a program - not the author of the library! - but the
author of a program that uses that library, that is you, that is me,
this author *does not want* to call a function that is not defined in
the C standard. This author - you and me - can guess that this function
is probably an internal one used by some of the other libraries
developed along with the standard C library. But they don't need to
guess: they KNOW, from reading the documentation, that this function is
NOT part of the specification of the C language. Moreover, they KNOW, by
reading the documentation of the "libc" library, that this function is
NOT listed there.
So, even though you and I can see the printf_trunc() function, we never
want to call it.
There is a very important reason for that: it is a function that is
written solely for the needs of the maths library, and if tomorrow the
next version of the maths library needs this function to operate in
another way, maybe add another argument, maybe drop an argument because
something is handled elsewhere, the C library's printf_trunc() function
*will change*. And if you or I had used it in our programs, our programs
would break.
Then, if we go to the author of the library and complain about using the
printf_trunc() function that is not in the specification of the C
language and that is not listed in the documentation of the "libc"
library... the author would say, and I quote, "Huh?!" They would say,
"Wait... *why* are you using this function? How do you know about... no,
wait, nevermind how you know about it... *why* are you using a function
that is neither part of the language specification, nor listed in the
documentation of this implementation of the language?"
So, you see, the hard work of the author of the library is not hidden.
It is there for us to see in the printf() function from "libc" and in
the trunc() function from "libm". Every time we use one of these
well-known and well-documented functions, we make use of the hard work
of the author. We do not need to call the internal function to do that.
So, to recap:
- there are two libraries, "libc" and "libm"
- "libc" has a function that wants to round numbers down
- "libm" must have a function that wants to round numbers down
- the common function to be used by both libraries has to be placed in
"libc", but it needs to be visible so that "libm" can use it
- somebody curious enough can look into the sources of "libc" and see
this function
- but this somebody must realize that this is an internal, undocumented
function that serves some purpose for the combination of "libc" and
"libm" and that is *not* supposed to be used by anything outside these
two libraries
- so this somebody will shrug it off, say "hey, there's some kind of
implementation detail, there's some kind of internal function, okay,
forget about it"
Hope that helps!
G'luck,
Peter
[1] ...and to everyone who cringed at that statement... sorry! :)
Let's go with that for now and push the pain away :)
[2] ...and to everyone who cringed at *that* statement... sorry! :)
[3] ...let's go with "the C language" here, not get into details about
compilers and linkers and foreign functions and stuff
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
