Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 20:20 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 10:28, Trey Harris wrote:
> > B is not a subset of A. That is the relationship of uint and int—two
> > distinct types whose values happen to overlap in a way that describes a
> > subset. Perl isn’t Prolog; a logical relationship between two types is
> > not a first-class entity of the language.
> >
> >
> >
> > I know, I am slicing the baloney thin here, but uint is
> > not a static C variable. It can change into an int with
> > the position of the moon.
> >
> >
> > I’m STILL waiting for you to show me ONE example of a `uint` turning
> > into `int`. Not `Int`, via auto-boxing, `int`, via who-knows-what.
> > Either do that, or stop making the assertion it does that; if you don’t
> > show a reproducible example, I am going to conclude you are lying if you
> > persist.
>
> $ p6 'my uint8 $u; say $u.^name;'
> Int
>
I’m done. I haven’t killfiled anyone in over twenty years. Congratulations,
you’re the first this century.

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 18:39 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 15:32, ToddAndMargo via perl6-users wrote:
> > `DWORD cbData`
>
> cbData is a 32 bit unsigned integer.  It follows
> all the rules for unsigned integers.  You do not
> terminate it.  WinAPI knows it is 32 bits long.
>
> lpData (Long Pointer Data) is where you put the
> 0x at the end, if you are using it as a string.
> lpData is an array of bytes of your chosen length.
>

 You keep telling me about fields I’m not asking about.

Let me quote you to you, from
:

> This all came up when I tried to match
>
>RegSetValueExW(
>_In_ HKEY hKey,
>_In_opt_ LPCWSTR lpValueName,
>_Reserved_ DWORD Reserved,
>_In_ DWORD dwType,
>_In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
>_In_ DWORD cbData
>
> where CbData can either be a UTF little endian C string,
> terminated by a nul or a four byte little endian
> unsigned integer (no two's complement allowed) depending
> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)

I would like to know about “where CbData can either be a UTF little endian
C string, terminated by a nul or a four byte little endian unsigned integer
(no two's complement allowed) depending on the value of lpValueName
(REG_SZ, REG_DWORD, etc.)”. That is what I and others find so bizarre. That
doesn’t seem to need reference to anything except cbData and lpValueName.

I’m just curious about this thing that can (again, quoting you) be “EITHER”
a UTF string ”OR a four byte little endian unsigned integer (no two’s
complement allowed)”. Tell me about that please. Just that.

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 17:52 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 14:20, Trey Harris wrote:
> > I don’t care about IpData or ValueData—those are completely unremarkable
> > fields. Showing me more code relating to them—or any other fields
> > besides cData—isn’t helpful to understanding how the 3-bytes UTF + null
> > cData field works.
>
> hi Trey,
>
> I think what I am missing is your "3-bytes UTF + null" question.
>
> It is only four bytes long when addressed as a REG_DWORD
> (32 bit unsigned integer).  There is no nul at the end.
>
> The bounds are 0x0..0x_.  No boxing allowed
>
> $cbData = 4;
>
>
> If your are addressing is as a REG_SZ (registry string),
> it can be as many bytes as you want when.  You just have
> to terminate it with a 0x
>
> $cbData = $lpData.elems * 2;  # words are two bytes long
>
> Does that help?


Could you show the API definition again, please? The copy I see says that
field is a `DWORD cbData`. I don’t see the “as many bytes as you want when.
You just have to terminate it with a 0x” part of the definition. Could
you highlight it?

Re: stolen uint's

[Trey Harris]

I’m still asking you the same question I asked in
https://www.nntp.perl.org/group/perl.perl6.users/2020/01/msg8029.html

I don’t care about IpData or ValueData—those are completely unremarkable
fields. Showing me more code relating to them—or any other fields besides
cData—isn’t helpful to understanding how the 3-bytes UTF + null cData field
works.

Could you please confine your answer to cData, and only in the case where
it’s UTF + Null and not a numeric value? It creates such bizarre
restrictions on what it can hold that I’m trying to wrap my head around how
it works in practice. That’s all I want to know.

Also, you could show code where a ‘uint’ becomes an ‘int’ unbidden, or say
you were mistaken and confused the uppercased auto-boxed ‘Int’ for the
lowercased native ‘int’.

Finally, you could also explain if the multis suggested for solving your
type-checking issue are what you wanted or not.

Thank you.

On Wed, Jan 29, 2020 at 16:40 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 13:01, Trey Harris wrote:
> >
> > On Wed, Jan 29, 2020 at 15:28 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > "Todd" would convert to
> >   84 00 111 00 100 00 100 00 00 00
> >
> >
> > I’m sorry, you misunderstood me. I wasn’t asking how to convert text
> > into UTF. I was asking for an example of the 3-byte UTF plus 32-bit null
> > cbData field. “Todd\0” is not 3-bytes + null, it’s 4 bytes + null. (You
> > can see that from your groupings above—every two pairs make an octet,
> > and there are 5 pairs. That’s 40 bits, not 32.)
> >
> > Also, I assume you used that because it’s your name—could you use an
> > example from the actual registry dataset like what you’re processing,
> > please, and not one that you’ve invented yourself? I’m trying to see how
> > it’s _used_ in real life, not how you’re imagining it could be used.
>
>
> Hi Trey,
>
> In the following example, I am not messing
> with a key that Widows actually uses, but should,
> don't you think?
>
>  The registry hive is: HKEY_LOCAL_MACHINE
>  The key location is:  SOFTWARE\Microsoft\Windows NT\CurrentVersion
>  The key is:   BestLookingEngineer
>  The key type is:  REG_SZ  (means a string)
>  and the "True" turns on debugging
>
> perl6 -I. -e "use NativeConstants; use WinReg :WinRegSetValue; say
> WinRegSetValue( HKEY_LOCAL_MACHINE, Q[SOFTWARE\Microsoft\Windows
> NT\CurrentVersion], Q[BestLookingEngineer], REG_SZ, 'Todd', True );"
>
>
> WinRegSetValue Debug
>   ValueType  REG_SZ  (1)
> KeyName  BestLookingEngineer
> lpValueName  66 101 115 116 76 111 111 107 105 110 103 69 110 103
> 105 110 101 101 114 0
>  dsType  1
>   ValueData  Todd
>  lpData  84 111 100 100 0
>lpData.elems  5
>  cdData  10
>
>
> lpValueName is comes from
>
>  sub to-UTF16-c-str( Str $RakuStr ) returns CArray[uint16] is
> export( :to-UTF16-c-str )  {
> # Converts a UTF8 Raku string into a UTF16 little endian C string
> # Note: C Strings are always terminated with a nul.  WinAPI will
> malfunction without it
>
> my $CStr = CArray[uint16].new();
> $CStr = CArray[uint16].new( $RakuStr.encode.list, 0 );  # add a
> nul to the end
>
> return $CStr;
>   }
>
>
> I have yet to figure out a way to break
>
> my $CStr = CArray[uint16].new();
>
> into bytes for analysis, but it is UTF16 little endian.
> The "W" at the end of "RegSetValueExW" requires it.
>
> In the real world, I check the LUA key
>
>
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
>
>   "EnableLUA"=dword:
>
> to make sure it is zero, so I can mount and dismount
> hidden drive partitions.  The same module will
> unset the LUA for you on a prompt.
>
> -T
>

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 15:28 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> "Todd" would convert to
>  84 00 111 00 100 00 100 00 00 00


I’m sorry, you misunderstood me. I wasn’t asking how to convert text into
UTF. I was asking for an example of the 3-byte UTF plus 32-bit null cbData
field. “Todd\0” is not 3-bytes + null, it’s 4 bytes + null. (You can see
that from your groupings above—every two pairs make an octet, and there are
5 pairs. That’s 40 bits, not 32.)

Also, I assume you used that because it’s your name—could you use an
example from the actual registry dataset like what you’re processing,
please, and not one that you’ve invented yourself? I’m trying to see how
it’s _used_ in real life, not how you’re imagining it could be used.

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 14:39 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 11:32, Trey Harris wrote:
> > On Wed, Jan 29, 2020 at 13:50 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > Why don't use use
> >
> > typeMappings[type_index( typeid(char) )] = "char";
> >
> > Finally, a definition I can work with...
> >
> > We can treat this as a request for typeid(); the mapping creation and
> > lookup is an implementation detail.
> >
> > So: the C++ typeid operator works in two modes, static (which happens at
> > compile-time and is inlined) and dynamic (which happens at runtime and
> > is subject to polymorphism). Do you want the static or the dynamic
> behavior?
>
>
> I thought that was C not C++, but ...


The `typeid` operator is C++. Some stdlib extensions have a `typeid` in C,
but it’s non-standard.

Also, your example given below is C++, not C.

As variables in Raku get boxed and coerced
> all the time, I guess I am asking for dynamic.


In that case, you have it already as was mentioned much earlier. See
https://gist.github.com/treyharris/0ce541c07a1f94b41af61207563e7807

with
```perl6
proto check_type($ --> Str) { * }
multi check_type(uint $var) { return "uint" }
multi check_type(Int $var) { return "Int" }

my uint $ui = 42;
say "Value is $ui"; # Value is 42
say check_type($ui); # uint
say ".^name is {$ui.^name}"; # .^name is Int
say check_type($ui); # uint

# .abs autoboxes
say check_type($ui.abs); # Int

# abs() does not
say check_type(abs $ui); # uint
```

Is that what you’re going for?



>
> I am after what the variable is at the moment I
> ask.
>
> Is Raku written in C or C++?


You can go to https://github.com/rakudo/rakudo and determine this for
yourself—click the colored bar to see the language breakdown. (92.6% at the
moment is written in Raku itself; it’s mostly a self-hosted language.)

One of the guys on the C group wrote me this:


That was C++, for the record.

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 14:01 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 06:34, Trey Harris wrote:
> > I was going to ask about that (but it seemed out of Raku-world, and I
> > don’t even play someone who knows about Windows on TV), but, okay, I’ll
> > bite... what are some examples of the precisely 3-byte + 32-bit null UTF
> > strings you imagine being encoded by this interface? I have never heard
> > of such a small fixed-width UTF data structure before because it’s just
> > so bizarre, and then mandating a null termination so you lose the 4th
> > byte that would make this structure at least somewhat coherent as a
> > UCS-4 codepoint... since there’s no such thing as UTF-24, I assume this
> > is three UTF-8 bytes packed (which I guess is what you mean by “little
> > endian C string”, but that becomes at best ill-defined abutted next to
> > “UTF”)... But, what on earth is it being used for?
> >
> > I’m fascinated, in the way a cat is fascinated by a snake
>
> Trey,
>
> You are basically setting up a buffer of bytes
> and then telling the WinAPI how long the
> data in the buffer is as well as what type of
> data the buffer contains.


That is clear from the document linked at
https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw

But what I was asking about and what I don’t understand is what you meant
when you wrote:
> where CbData can either be a UTF little endian C string,
> terminated by a nul or a four byte little endian
> unsigned integer (no two's complement allowed) depending
> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)

Can you explain just this part:
> where CbData can… be a UTF little endian C string,
> terminated by a null

That’s the part I’m fascinated by because it’s just so strange. What’s an
example of a valid value of this type and not the “unsigned integer (no
two’s complement allowed)”?

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 13:50 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Why don't use use
>
> typeMappings[type_index( typeid(char) )] = "char";
>
Finally, a definition I can work with...

We can treat this as a request for typeid(); the mapping creation and
lookup is an implementation detail.

So: the C++ typeid operator works in two modes, static (which happens at
compile-time and is inlined) and dynamic (which happens at runtime and is
subject to polymorphism). Do you want the static or the dynamic behavior?

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 13:28 Trey Harris  wrote:

> whose values happen to overlap in a way that describes a subset. Perl
> isn’t Prolog;
>

It isn’t either, but that’s irrelevant; I meant Raku obviously. Thinko.

>

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 13:04 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-29 09:19, Trey Harris wrote:
> >
> > The first line of https://docs.raku.org/type/UInt is:
> >  > The `|Int`| is defined as a subset of `|Int|:`
> >
> > How does that not “reflect that UInt is not a unique [type, I assume you
> > meant], but a subset of Int”?
>
> You are correct.  Mumble, mumble.
>
>
>
>
> > 2) that uint is not a native type, but a subset of int.
> >
> >
> > But `uint` is not a subset of `int`; they’re both native types so can’t
> > be subtypes as the constraints would have to hook to the metamodel,
> > which uint and int lack because they’re unboxed. (A “sticker on the
> > “box” is where you write the constraints, if you want to think of it
> > that way.)
>
> So long as it is treated as a subset of int, it is a subset.


“treated as a subset”?

I don’t know what you mean:

```console
> int.does(uint)
False
> uint.does(int)
False
> int.isa(uint)
False
> uint.isa(int)
False
> UInt.does(Int)
True
> Int.does(UInt)
True
> UInt.isa(Int)
True
> Int.isa(UInt)
False
```

If I write:

```
class A { has Int $.value }
class B { has Int $.value where * ≥ 0; }
```

B is not a subset of A. That is the relationship of uint and int—two
distinct types whose values happen to overlap in a way that describes a
subset. Perl isn’t Prolog; a logical relationship between two types is not
a first-class entity of the language.

>

> I know, I am slicing the baloney thin here, but uint is
> not a static C variable. It can change into an int with
> the position of the moon.


I’m STILL waiting for you to show me ONE example of a `uint` turning into
`int`. Not `Int`, via auto-boxing, `int`, via who-knows-what. Either do
that, or stop making the assertion it does that; if you don’t show a
reproducible example, I am going to conclude you are lying if you persist.

Re: stolen uint's

[Trey Harris]

Argh! Editing error...

On Wed, Jan 29, 2020 at 12:19 Trey Harris  wrote:

> The first line of https://docs.raku.org/type/UInt is:
>>
> > The `Int` is defined as a subset of `Int:`
>

Should have been (and is in that URL) “The `UInt` is defined as…”

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 11:58 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 22:16, Veesh Goldman wrote:
> > Hi Todd,
> > I'd just like to point out one thing. Your confusion here (and in a few
> > related posts) is that you aren't grokking the difference between uint
> > and UInt.
>
> Hi Veesh,
>
> I am well aware of the difference between UInt and uint.  Two
> weeks ago I was not.
>
> And because they are different, when I ^name on a variable,
> I don't want to see some different come back than what I
> declared it as.
>
> Now Perl variables are not "Static" variables as in C.  They
> have structures assigned to them that allow for all kinds on
> interesting things not allowed in C.  Inside these structures
> is the definition of what the thing is, otherwise you
> could not unbox them, etc..  I want both ^name and .range
> to accurately reflect what is in the structure's definition.
>
> And especially since this is even possible with C, It should
> be possible with Raku being that Raku is written in C.
>
> typeMappings[type_index( typeid(unsigned int) )] = "unsigned int";
>
> And C has no structures to inquire from.
>
> Basically, if I ask a banana what it is, I don't want
> to be told it is an apple.
>
>
> >
> > Please correct me if I'm wrong. But if there needs to be an update to
> > docs, it probably should be to a document that clarifies the difference.
>
> I would like to see the docs updates to
>
> 1) reflect that UInt is not a unique variable, but a subset
> of Int


The first line of https://docs.raku.org/type/UInt is:
> The `Int` is defined as a subset of `Int:`

How does that not “reflect that UInt is not a unique [type, I assume you
meant], but a subset of Int”?


>
> 2) that uint is not a native type, but a subset of int.


But `uint` is not a subset of `int`; they’re both native types so can’t be
subtypes as the constraints would have to hook to the metamodel, which uint
and int lack because they’re unboxed. (A “sticker on the “box” is where you
write the constraints, if you want to think of it that way.)


>
> 3) that uint and int are not "static" (in the C sense)
> variables and can be changed to other things with
> coercion and boxing.  A discussion on when and how
> that is done would be appreciated.


The indexing of Auto-boxing and linking to it where appropriate should
solve this. Please open a doc issue stating exactly this (and not a request
for 1 and 2, which are not valid).

Re: stolen uint's

[Trey Harris]

On Wed, Jan 29, 2020 at 03:44 Tobias Boege  wrote:

> On Tue, 28 Jan 2020, ToddAndMargo via perl6-users wrote:
> > This all came up when I tried to match
> >
> >   RegSetValueExW(
> >   _In_ HKEY hKey,
> >   _In_opt_ LPCWSTR lpValueName,
> >   _Reserved_ DWORD Reserved,
> >   _In_ DWORD dwType,
> >   _In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
> >   _In_ DWORD cbData
> >
> > where CbData can either be a UTF little endian C string,
> > terminated by a nul or a four byte little endian
> > unsigned integer (no two's complement allowed) depending
> > on the value of lpValueName (REG_SZ, REG_DWORD, etc.)
> >
> > I wound up doing this:
> >
> > subset StrOrDword where Str | UInt;
> > sub WinRegSetValue( WinRegHives $Hive, Str $SubKey, Str $KeyName,
> ValueNames
> > $ValueType, StrOrDword $ValueData, Bool $Debug = False )
> > returns DWORD is export( :WinRegSetValue ) {
>
> Are you really 100% sure that you interpreted this API correctly? I see how
> a DWORD cbData can be a four-byte unsigned integer: it gives the length of
> lpData in bytes, as documented [1].


>
> But then a DWORD is 4 bytes long. Reusing these 4 bytes for an alternative
> interface where you may pass a UTF-whatever string that is at most 4 bytes
> encoded, including the NUL terminator... seems too insane.


I was going to ask about that (but it seemed out of Raku-world, and I don’t
even play someone who knows about Windows on TV), but, okay, I’ll bite...
what are some examples of the precisely 3-byte + 32-bit null UTF strings
you imagine being encoded by this interface? I have never heard of such a
small fixed-width UTF data structure before because it’s just so bizarre,
and then mandating a null termination so you lose the 4th byte that would
make this structure at least somewhat coherent as a UCS-4 codepoint...
since there’s no such thing as UTF-24, I assume this is three UTF-8 bytes
packed (which I guess is what you mean by “little endian C string”, but
that becomes at best ill-defined abutted next to “UTF”)... But, what on
earth is it being used for?

I’m fascinated, in the way a cat is fascinated by a snake

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 22:03 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Hi Trey,
>
> Any chance of you sneaking in on the doc pages
> for ^name and range to explain the things you
> explained to me?



For `.^name`—I suppose, though I’m not sure what would be appropriate
there—anything beyond that native-typed variables will show the autoboxed
type? I don’t think a description of autoboxing itself is relevant there. I
just noticed the “Auto-boxing” section of
https://docs.raku.org/language/numerics is unindexed, though, so that
should probably be fixed (and it should be aliased so typing either
autoboxing or auto-boxing into the search box both turn it up).

For range (lower-cased), absolutely not. If my proposal for adding
front-matter to routine pages is eventually adopted, that would be
reasonable. But right now, when routine pages are entirely auto-generated
from snippets elsewhere, that would mean adding information to
https://docs.raku.org/type/X::OutOfRange#method_range — and the behavior
that tripped you up has nothing even tangentially to do with the
`X::OutOfRange` exception.

Re: stolen uint's

[Trey Harris]

For doing that sort of thing, learning a little glue C would probably be
very useful (IMO, every systems-oriented programmer is helped immensely by
knowing enough C to be able to munge low-level data structures). This is a
lovely little example of a numeric library using native arithmetic where
most of the work is shunted into C but the interface is native Raku:

https://github.com/p6-pdf/Base64-Native-p6


On Tue, Jan 28, 2020 at 21:50 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 18:18, Trey Harris wrote:
> > my uint $z = -32;
> > 224
>
> Another misunderstanding on my part.  I thought it
> would barf.
>
> All I really need to know is what is expected.
> To me I am getting wrong answers back, but as
> long as they are consistent answers I can deal
> with it:
>
> if $ValueData.^name  ne "Int"  || $ValueData < 0  {   # UInt gets "boxed
> to an Int
>
> Thank you for all the time you have spent with me on this!
>
> -T
>
> This all came up when I tried to match
>
>RegSetValueExW(
>_In_ HKEY hKey,
>_In_opt_ LPCWSTR lpValueName,
>_Reserved_ DWORD Reserved,
>_In_ DWORD dwType,
>_In_reads_bytes_opt_(cbData) CONST BYTE * lpData,
>_In_ DWORD cbData
>
> where CbData can either be a UTF little endian C string,
> terminated by a nul or a four byte little endian
> unsigned integer (no two's complement allowed) depending
> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)
>
> I wound up doing this:
>
> subset StrOrDword where Str | UInt;
> sub WinRegSetValue( WinRegHives $Hive, Str $SubKey, Str $KeyName,
> ValueNames $ValueType, StrOrDword $ValueData, Bool $Debug = False )
>  returns DWORD is export( :WinRegSetValue ) {
>

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 21:18 Trey Harris  wrote:

> Nope. If I give you:
>
> 0x41
>
> and tell you that’s a single octet, and that’s all you have, and I and ask
> you whether that’s an “A” or a decimal 97 or something else described by
> 0101, how do you answer? You can’t.
>

Sorry, editing mistake; I started out with a different example. Of course I
meant decimal 65.

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 21:18 Trey Harris  wrote:

> values, such as 'undefined' and 'Nil' as well as its type.
>
>
And that’s another thing: you’ll notice if you define a `my uint8 $x;` it
will be set to 0. No undefined, no Nil. That doesn’t happen with non-native
numeric values.


> Nope. If I give you:
>
> 0x41
>
> and tell you that’s a single octet, and that’s all you have, and I and ask
> you whether that’s an “A” or a decimal 97 or something else described by
> 0101, how do you answer? You can’t.
>
> Raku knows at compile time—otherwise, it couldn’t autobox into an ‘Int’
> vs. a ‘Real’ for an int32 vs. a num32, for example—but that’s not currently
> exposed to the runtime; you can pitch a new feature, but it would be
> necessary to know what one would use it for to design an interface for it.
>
> An ability to cause a failure or exception to be thrown if a given value
> is autoboxed would be much more defensible, I think—“I need to ensure this
> thing doesn’t get munged by something unexpected into a form that my native
> call will barf at” seems more reasonable (though unboxing should prevent
> that in cases where you’re not round-tripping outside of Raku before your
> native call).
>

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 20:59 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

>
> > Ah You got ‘int’—lowercase ‘int’, not uppercase ‘Int’?? I didn’t see
> > that example and I can’t find it scrolling back. Would you repost it,
> > please? That would change things (and possibly indicate a bug).
>
>  > my uint $u= 0xFF44; say $u.^name
> Int
>
> It was upper case Int.  Again, wrong answer.  It should
> have been "UInt"


No—it’s the right answer, because it’s a type constraint, and you can
assign a negative integer to a uint and you’ll get the complement. See the
difference:

```console
> my UInt $x = 32;
32
> $x = -32;
Type check failed in assignment to $x; expected UInt but got Int (-32)
 in block  at  line 1
> my uint $z = -32;
224
```

You can argue that it _should_ barf on negative integers instead, but that
would make working with a number of Unix C std lib native calls that use
unsigned values in... historical interesting ways difficult. That’s perhaps
a niche-enough case that I think you could reasonably argue for autoboxing
into UInt instead. But that would be a behavioral change; *answering*
`UInt`, when it’s absolutely autoboxing into an `Int`, would be wrong; Raku
would be lying to you.
To answer your other questions in your prior mail:

On Tue, Jan 28, 2020 at 20:32 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 17:17, Trey Harris wrote:
> >  > Write me a C program to do the equivalent, then, please. You will
> >  > segfault. If you don’t, then you’re asking a question we might
> > be able
> >  > to answer.
> >
> > I can't write in C
> >
> >
> > Perhaps that’s why you don’t understand. Assembler? COBOL? PL/I? Any
> > language with pointer arithmetic?
>
> I used points all the time in Modula2.  And reference pointers in Perl5


Pascal and its descendants used type-safe pointers. You’d have to have
experience with a language with unsafe pointers to get my point there.

>
> You’ve
> > shown multiple examples of autoboxing. So... you could request Raku add
> > a pragma or trait that would result in a fatal exception being thrown if
> > autoboxing occurs.
>
> What?  I am not wanting to crash anything.  he phrase "the unbox type
> is" will do fine.  Gives perfect warning.


Finding an example of where that’s generally useful is the question. It’s a
type constraint in addition to being a storage type, so if you don’t
violate the constraint, and you don’t coerce it into something else, it
will be what you constrained it to be.

To want to interrogate that doesn’t seem to have a point beyond just being
mistrustful of the language. If you can articulate the usefulness, then you
could look at it—an `nqp::typeof` existed until a few years ago, and I
imagine it could be re-exposed (which would be the first step, since the
native API offers no way to get at that information from Raku code AFAICT).
But you’d have to show a need for a new low-level call like that.

> You can already wrap the variable in a class that
> > keeps the native value immutable so that it can’t be autoboxed.
> >
> > You can compare a native value to another in a way that will tell you if
> > the are or aren’t the same. From that last, you could build something
> > rather crude that created a value of every type you’re interested in,
> > compared your value to each, and then told you if any matched
> > bit-for-bit, which might be sufficient for your purposes (which I still
> > don’t understand)?
> >
> > But what you *can’t* do is ask what it is without autoboxing it. An
> > unsigned 32-bit int is just 32 bits that are entirely used to express an
> > integer—there’s no room to mark what it is, so asking it what it is is
> > meaningless—and once it’s autoboxed, it’s different than it was before
> > the autoboxing.
>
> My misunderstandings
>
> 1) I though 'uint' and 'int' were both separate native types.
> The manual does state such.


They are; show me an example of getting ‘int’ (unboxed) rather than ‘Int’
(autoboxed) from a ‘uint’, though. Do the above test of assign `-32` to a
`uint` vs. an `int` and you’ll see, they’re different, even though they
both autobox into `Int`—the `int` will be -32 rather than the complement.

2) I thought 'unit' had a structure that went along with it,
> as does a string.  And inside that structure were unicorn
> values, such as 'undefined' and 'Nil' as well as its type.


Nope. If I give you:

0x41

and tell you that’s a single octet, and that’s all you have, and I and ask
you whether that’s an “A” or a decimal 97 or something else described by
0101, how do you answer? You can’t.

Ra

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 20:32 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 17:17, Trey Harris wrote:
> > On Tue, Jan 28, 2020 at 20:04 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > On 2020-01-28 17:00, Trey Harris wrote:
> >  > On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users
> >  > mailto:perl6-users@perl.org>
> > <mailto:perl6-users@perl.org <mailto:perl6-users@perl.org>>> wrote:
> >  >
> >  > On 2020-01-28 16:56, Trey Harris wrote:
> >  >  > In other words—yes, you want Raku to attempt to provoke a
> >  > segmentation
> >  >  > fault, then recover and tell you whether it faulted or not.
> >  >
> >  > Huh?  I just want to know what the variable actually is.  I
> >  > do not wnat to crash anything.
> >  >
> >  > Write me a C program to do the equivalent, then, please. You will
> >  > segfault. If you don’t, then you’re asking a question we might
> > be able
> >  > to answer.
> >
> > I can't write in C
> >
> >
> > Perhaps that’s why you don’t understand. Assembler? COBOL? PL/I? Any
> > language with pointer arithmetic?
>
> I used points all the time in Modula2.  And reference pointers in Perl5
>
> >
> > I just want the correct answer back.  If the wrong answer is coming
> > back, why even have the function available.
> >
> >
> > You haven’t shown one example of the “wrong answer… coming back”.
>
> I got back 'int' for 'unit'.


Ah You got ‘int’—lowercase ‘int’, not uppercase ‘Int’?? I didn’t see
that example and I can’t find it scrolling back. Would you repost it,
please? That would change things (and possibly indicate a bug).

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 20:04 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 17:00, Trey Harris wrote:
> > On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > On 2020-01-28 16:56, Trey Harris wrote:
> >  > In other words—yes, you want Raku to attempt to provoke a
> > segmentation
> >  > fault, then recover and tell you whether it faulted or not.
> >
> > Huh?  I just want to know what the variable actually is.  I
> > do not wnat to crash anything.
> >
> > Write me a C program to do the equivalent, then, please. You will
> > segfault. If you don’t, then you’re asking a question we might be able
> > to answer.
>
> I can't write in C


Perhaps that’s why you don’t understand. Assembler? COBOL? PL/I? Any
language with pointer arithmetic?

I just want the correct answer back.  If the wrong answer is coming
> back, why even have the function available.


You haven’t shown one example of the “wrong answer… coming back”. You’ve
shown multiple examples of autoboxing. So... you could request Raku add a
pragma or trait that would result in a fatal exception being thrown if
autoboxing occurs. You can already wrap the variable in a class that keeps
the native value immutable so that it can’t be autoboxed.

You can compare a native value to another in a way that will tell you if
the are or aren’t the same. From that last, you could build something
rather crude that created a value of every type you’re interested in,
compared your value to each, and then told you if any matched bit-for-bit,
which might be sufficient for your purposes (which I still don’t
understand)?

But what you *can’t* do is ask what it is without autoboxing it. An
unsigned 32-bit int is just 32 bits that are entirely used to express an
integer—there’s no room to mark what it is, so asking it what it is is
meaningless—and once it’s autoboxed, it’s different than it was before the
autoboxing.

>

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 19:58 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 16:56, Trey Harris wrote:
> > In other words—yes, you want Raku to attempt to provoke a segmentation
> > fault, then recover and tell you whether it faulted or not.
>
> Huh?  I just want to know what the variable actually is.  I
> do not wnat to crash anything.
>
Write me a C program to do the equivalent, then, please. You will segfault.
If you don’t, then you’re asking a question we might be able to answer.

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 19:55 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 16:52, Trey Harris wrote:
> > On Tue, Jan 28, 2020 at 19:46 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> >  > my uint $u= 0xFF44; say $u.^name
> > Int
> >
> > Wrong answer
> >
> > It’s absolutely the right answer. You autoboxed it by running a
> > method—`.^name`—on it. A uint can’t respond to `.^name`, so you can
> > never get that as the right answer. If you try assigning a negative
> > value to it after doing `.^name`, you’ll be able to, but if you read it
> > back, it will be the complement.
> >
> > You seem to be asking for Raku to intentionally provoke, then recover
> > from, a segmentation fault, and then tell you whether or not it faulted.
> > Is that what you’re asking for?
>
> How am I suppose to know when something gets altered by my
> observation of it?  Seriously.
>
> If it is a uint, I want to see uint.  If it
> is being altered, I want to see that too.
>
In other words—yes, you want Raku to attempt to provoke a segmentation
fault, then recover and tell you whether it faulted or not.

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 19:46 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> > my uint $u= 0xFF44; say $u.^name
> Int
>
> Wrong answer
>
It’s absolutely the right answer. You autoboxed it by running a
method—`.^name`—on it. A uint can’t respond to `.^name`, so you can never
get that as the right answer. If you try assigning a negative value to it
after doing `.^name`, you’ll be able to, but if you read it back, it will
be the complement.

You seem to be asking for Raku to intentionally provoke, then recover from,
a segmentation fault, and then tell you whether or not it faulted. Is that
what you’re asking for?

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 19:06 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 15:37, Trey Harris wrote:
> >
> >
> > On Tue, Jan 28, 2020 at 18:09 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > Observer effect (physics)
> > https://en.wikipedia.org/wiki/Observer_effect_(physics)
> >
> >   In physics, the observer effect is the theory that
> >   the mere observation of a phenomenon inevitably
> >   changes that phenomenon ... An especially unusual
> >   version of the observer effect occurs in quantum
> >   mechanics, as best demonstrated by the double-slit
> >   experiment
> >
> > Seems Quantum theory has come to Raku, only we call it "unboxing".
> >
> >
> > As I wrote in your Raku/problem-solving issue (#154), your question is
> > not well-formed. A native value has no metadata, so how can it have a
> > type? Any experience at all with a language with pointer arithmetic
> > should make this clear.
> >
> > And you issue doesn’t seem to be with unboxing—as far as I can tell,
> > you’re unboxing (assigning to a native) just fine, it’s the autoboxing
> > that’s giving you fits.
> >
> > If you can show a language that can do what you want—whether it’s a
> > `typeof` equivalent or a binary data validity checker or a magic number
> > heuristic or something else, then we may be able to help you, but right
> > now you seem to be asking for something akin to wanting to know what
> > color the bits in your uint32 are—it’s not a question with meaning.
>
> Trey,
>
> If I ask what something is, I want an accurate answer back.


What does “accurate” mean for a native value? It’s a binary blob. It has no
type in the memory, only in the runtime. If you successfully assigned it
and haven’t done any OO operations on it, as far as the runtime’s
concerned, it’s still the type it was when you assigned it. If you have
done OO operations on it, then it’s been autoboxed and you can do `.^name`
against it.

I’ve only asked three times, but I’ll try once more: a problem statement
would be helpful here.  What are you trying to achieve other than poking
the spot to see if it still hurts when you poke it? It may be possible to
do what you want with either anonymous variables or with a class serving as
a container for a native attribute (which can ensure that the attribute
can’t be autoboxed).

But just saying “I want to run this method that is undefined on this thing
and has no well-formed answer for this thing apart from what I can see by
inspecting the code” isn’t helpful in understanding what you want. “And I
want it to give me an *accurate* answer” doesn’t help to understand what
that is, either.

>

Re: stolen uint's

[Trey Harris]

On Tue, Jan 28, 2020 at 18:09 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Observer effect (physics)
> https://en.wikipedia.org/wiki/Observer_effect_(physics)
>
>  In physics, the observer effect is the theory that
>  the mere observation of a phenomenon inevitably
>  changes that phenomenon ... An especially unusual
>  version of the observer effect occurs in quantum
>  mechanics, as best demonstrated by the double-slit
>  experiment
>
> Seems Quantum theory has come to Raku, only we call it "unboxing".


As I wrote in your Raku/problem-solving issue (#154), your question is not
well-formed. A native value has no metadata, so how can it have a type? Any
experience at all with a language with pointer arithmetic should make this
clear.

And you issue doesn’t seem to be with unboxing—as far as I can tell, you’re
unboxing (assigning to a native) just fine, it’s the autoboxing that’s
giving you fits.

If you can show a language that can do what you want—whether it’s a
`typeof` equivalent or a binary data validity checker or a magic number
heuristic or something else, then we may be able to help you, but right now
you seem to be asking for something akin to wanting to know what color the
bits in your uint32 are—it’s not a question with meaning.

Re: range doc page

[Trey Harris]

Sorry to keep replying to myself...

On Tue, Jan 28, 2020 at 15:13 Trey Harris  wrote:

> All core class Exception objects, as a matter of convention, start with
> `X::`.
>

...to which a natural question arises: what about non-core Exception
objects?

Raku lets you call Exceptions whatever you want, so putting convention
aside, anything is possible.

But one case that is typical for non-core modules is for, e.g.,
`My::Library` to define a `class My::Library::Exception is Exception {...}`
as an “abstract class”, and then define the library’s exceptions as `class
X::MySpecialException is My::Library::Exception`. This allows the author to
refer to their own exceptions as a group using `My::Library::Exception`,
and to still use shorter `X::` names for things that they throw.

It isn’t necessary to do this, and some libraries derive all the exceptions
directly from `Exception`. (And some do `My::Library::X::...` or other
idiosyncratic naming schemes.) But they _tend_ to still start with the
`X::` name for convention.

Trey

>

Re: range doc page

[Trey Harris]

On Tue, Jan 28, 2020 at 15:13 Trey Harris  wrote:

> (And, in case you were unaware, _every_ page in the /routine/... doc tree
> is autogenerated from content elsewhere; those headers and links are added
> to get you back to the context where the content canonically appears.)
>
And I just submitted a Raku/problem-solving issue to consider changing
this:
https://github.com/Raku/problem-solving/issues/155

Re: range doc page

[Trey Harris]

On Tue, Jan 28, 2020 at 15:06 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-28 11:59, Trey Harris wrote:
> >
> >
> > On Tue, Jan 28, 2020 at 14:55 ToddAndMargo via perl6-users
> > mailto:perl6-users@perl.org>> wrote:
> >
> > No I am really confused:
> >
> > What part of
> >
> >   my int8 $u = 0xF8; $u.range
> >
> > is not following
> >
> >   method range(--> Range:D)
> >
> > ?
> >
> > Unless you’re getting the line `method range(--> Range:D)` from
> > somewhere else, you’re looking at
> > https://docs.raku.org/routine/range, which says
> >
> >  > Documentation for method |range| assembled from the following types:
> >
> >  > class X::OutOfRange <https://docs.raku.org/routine/range#___top>
> >
> > `int8` is not an `X:OutOfRange` object (which is an Exception), so it
> > can’t participate in the method you reference.
> >
>
> Okay, I think I get it.  I missed the "X:OutOfRange"
> and expected the qualifier to be in the definition line.
>
> What exactly is "X:OutOfRange" anyway?


With a single colon? Nothing; I typo’d. Assuming we both meant
“X::OutOfRange”
That text is a link; if you click it to go to
https://docs.raku.org/type/X::OutOfRange you’ll see that it’s an exception,
specifically an “Error due to indexing outside of an allowed range”.

All core class Exception objects, as a matter of convention, start with
`X::`. It is frequently the case that Exceptions carry in their payloads
references to the data structure that gave them trouble, so the accessor
methods to reference them (such as `range`) frequently overlap with the
names of constructors (at least, case-insensitively). So on a routine
auto-generated page, you’ll frequently see methods on `X::...` objects;
they almost never go along with the other non-exception versions of that
routine name.

(And, in case you were unaware, _every_ page in the /routine/... doc tree
is autogenerated from content elsewhere; those headers and links are added
to get you back to the context where the content canonically appears.)

Re: range doc page

[Trey Harris]

On Tue, Jan 28, 2020 at 14:55 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> No I am really confused:
>
> What part of
>
>  my int8 $u = 0xF8; $u.range
>
> is not following
>
>  method range(--> Range:D)
>
> ?
>
Unless you’re getting the line `method range(--> Range:D)` from somewhere
else, you’re looking at
https://docs.raku.org/routine/range, which says

> Documentation for method range assembled from the following types:

> class X::OutOfRange 

`int8` is not an `X:OutOfRange` object (which is an Exception), so it can’t
participate in the method you reference.

Re: range problems

[Trey Harris]

On Tue, Jan 28, 2020 at 08:27 Trey Harris  wrote:

> On Mon, Jan 27, 2020 at 23:57 ToddAndMargo via perl6-users <
> perl6-users@perl.org> wrote:
>
>> Hi Al,
>>
>> Now what am I doing wrong?
>>
>>  > my Int $u = 0xF8; say $u.Range;
>>
>> Invocant of method 'Range' must be a type object of
>> type 'Int', not an object instance of type 'Int'.
>> Did you forget a 'multi'?
>>
>> When is an Int not an Int?
>
>
> This false statement illustrates: “0xF8 (248) is evenly divisible by 31.
> 248 is an Int. Therefore, an Int is evenly divisible by 31.” That’s the
> difference. One is the idea of an Int, the other is a particular Int.
>
> In practice, this means that you can get a .Range operation out of the Int
> type (without arguments, a.k.a. just `Int.Range`, it is the range of all
> integers from -Inf to Inf), but not out of a particular Int.
>
> That would not be well-defined: would it be the range of Ints from zero to
> the given Int, from 1 to the given Int, or from something different
> depending on if the Int is a positive or negative number, and would
> $negativeInt.Range go backwards of forwards?
>

Actually, going back to typed lambda calculus, there is one well-defined
definition: from the given integer to infinity away from zero.

Since Ranges in Raku are always ordered in one direction (that is,
Inf..-Inf is a void range, as is any range where the beginning is larger
than the end), this definition is unimplementable, so it’s for the best
that Range fails for Int:D.


>
>>
>> Perplexed,
>> -T
>>
>

Re: range doc page

[Trey Harris]

On Tue, Jan 28, 2020 at 01:07 Kevin Pye  wrote:

> There's no need to ask essentially the same question three times.
>

And I answered before noticing there was more activity in another thread.


> https://docs.raku.org/routine/range 
> is quite clearly the wrong page. That's about a method on the class
> X::OutOfRange, and not a method on Int. You want
> https://docs.raku.org/routine/Range, which will unfortunately not be much
> more useful.
>
> Your original error message "Invocant of method 'Range' must be a type
> object of
> type 'Int', not an object instance of type 'Int'" is much more useful.
>
> Your variable $u contains a variable of type Int. What the method Range
> wants is a "type object of type 'Int'" which is not the same thing.This is
> what you would get with a definition like "my UInt $u;". $u is now a
> variable containing no definite value, but is of type UInt. If you were to
> "say $u" you would get "(UInt)", which is a type object. "say $u.Range"
> would then give "0..^Inf".
>
> This is related to the ":D" and ":U" forms in signatures. "sub x(Int:D
> $arg)" would require the subroutine to be passed an actual object of type
> Int. "sub y(Int:U $arg)" would need to be passed a "type object of type
> 'Int'". If you were to check the source you would find the signature of
> Range to be something like "method Range(Int:U --> Range)".
>

I’d say in general, ToddAndMargo seems to be stuck on signatures of `:D` vs
`:U` and how they relate to the type system and definedness. Perhaps this
relates to the very different ways in which we relate to undefined values
in Raku vs. Perl5.

In Perl5, undefinedness meant something that it still _can_ mean, and in
the course of ordinary “business logic” programming perhaps still most
often means: a yet-to-be-filled container, an unassigned value. In Perl5 it
was also very obviously a sort of falseness and frequently used in that
manner.

In Raku, “an undefined Int” means not only the above but also what it means
in English: the notional value of Int-ness. If you try to use rvalue
“undef” in Raku as you would in Perl5, you’ll get a very nice error message
to explain:

```console
> undef
===SORRY!=== Error while compiling:

Unsupported use of undef as a value; in Perl 6 please use something more
specific:
an undefined type object such as Any or Int,
:!defined as a matcher,

Any:U as a type constraint,
Nil as the absence of an expected value
or fail() as a failure return

--> undef
```

So, to distill and recap:

1. In signatures, `:D` and `:U` mean “defined value” vs. “undefined value”

2. At least as often as `T:U` (where `T` is some type) literally means “a
container of type T that has not yet been assigned a value”, it means “the
notion of T” or simply “the literal type value, `T`”. Since types are among
the things that define namespaces, a unary routine `routine-name` with a
`T:U` parameter often means, “something you can usefully call as
`T.routine-name”

3. In Perl5 it’s quite rare that a routine (or rather, for Perl5, func
and/or sub) works on a variable before it’s assigned to but fails after. In
Raku it’s quite common, as `.Range` shows. This may be a source of
confusion, but if you remember that definedness doesn’t just mean
“assignedness” but “notionality vs. concreteness”, it makes more sense.

4. All that said, in the case of multis it’s not unknown to use `:U` for
the “unassigned” rather than “undefined” connotation, as one might use a
top-level sub guard, to fail with a useful diagnostic directing one to the
proper usage of a routine.

5. `Int` is a type value. Type values are always undefined. `my Int $x;`
creates a $x which is a container to hold an Int, but until it does, it
_is_ still an `Int`, an undefined `Int`, which makes it exactly equal to
the literal `Int`—i.e., a type object. It’s not great programming practice
to use a single container as both a type value and a concrete value, but in
diagnostics such as the one for Range that surprised you, you need to be
aware that it _can_ work that way.

Trey

Re: range problems

[Trey Harris]

On Mon, Jan 27, 2020 at 23:57 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Hi Al,
>
> Now what am I doing wrong?
>
>  > my Int $u = 0xF8; say $u.Range;
>
> Invocant of method 'Range' must be a type object of
> type 'Int', not an object instance of type 'Int'.
> Did you forget a 'multi'?
>
> When is an Int not an Int?


This false statement illustrates: “0xF8 (248) is evenly divisible by 31.
248 is an Int. Therefore, an Int is evenly divisible by 31.” That’s the
difference. One is the idea of an Int, the other is a particular Int.

In practice, this means that you can get a .Range operation out of the Int
type (without arguments, a.k.a. just `Int.Range`, it is the range of all
integers from -Inf to Inf), but not out of a particular Int.

That would not be well-defined: would it be the range of Ints from zero to
the given Int, from 1 to the given Int, or from something different
depending on if the Int is a positive or negative number, and would
$negativeInt.Range go backwards of forwards?


>
> Perplexed,
> -T
>

Re: Using raku/perl6 as unix "cat"....

[Trey Harris]

On Mon, Jan 20, 2020 at 19:03 Trey Harris  wrote:

> On Mon, Jan 20, 2020 at 02:59 William Michels via perl6-users <
> perl6-users@perl.org> wrote:
>
>> Hi Yary (and Todd),
>>
>> Thank you both for your responses. Yary, the problem seems to be with
>> "get". I can change 'while' to 'for' below, but using 'get' raku/perl6
>> actually returns fewer lines with "for" than it did with "while":
>
>
> If you want to do line-oriented input, use `.lines` with `for`; it returns
> something `for` can iterate over.
>

Sorry, in a setting where a handle isn’t the context, I meant `lines`, not
`.lines`, though I was referring _to_ a thing called `.lines`, the multi
method. I don’t think we’ve all yet agreed on how multis that can be called
as plain routines should be referred to in umbrella term. `.lines` is more
“correct”, but it’s less likely to actually work without understanding
more, which is a strange conundrum for documentation.

Trey

Re: Using raku/perl6 as unix "cat"....

[Trey Harris]

On Mon, Jan 20, 2020 at 19:01 Norman Gaywood  wrote:

>
> On Tue, 21 Jan 2020 at 03:12, Brad Gilbert  wrote:
>
>> .say for lines
>>
>
> Since .say calls gist(), would it be not be better/safer to call .put
> instead?
>
>.put for lines
>

If being set directly from `lines`, I can’t see when there would be a
difference unless you’re playing with encodings. If you entire program is
just this, they’re the same for normal Unix files. (I have no idea what
happens in the case of sparse files, abnormal files, devices, etc.)

And “safer” is in the eye of the beholder... if you’re outputting
diagnostics for immediate human consumption, a gist is less likely to ruin
formatted output.

Trey

Re: Using raku/perl6 as unix "cat"....

[Trey Harris]

On Mon, Jan 20, 2020 at 02:59 William Michels via perl6-users <
perl6-users@perl.org> wrote:

> Hi Yary (and Todd),
>
> Thank you both for your responses. Yary, the problem seems to be with
> "get". I can change 'while' to 'for' below, but using 'get' raku/perl6
> actually returns fewer lines with "for" than it did with "while":


If you want to do line-oriented input, use `.lines` with `for`; it returns
something `for` can iterate over.

`.get` is the wrong tool for the job; it returns a single line. To get all
lines, you must call it repeatedly; so you’d need to run an infinite loop
(either using `loop`, `while` with a true value, or `for` with a
never-ending sequence) and break out when you reach the end of the file.

This _works_ just fine, but it’s very weird:

perl6 -e 'loop { last if $*IN.eof; $_ = $*IN.get; .say }' < abc_def.text

You’d typically use “get” in a case where you’re doing low-level I/O, not
for writing a POSIX-like line-oriented filter.  `for lines -> $line { ...
}` is what you want in programs, but `.say for lines` (or put instead of
say, they’re equivalent here) in a one-liner.

>

Re: GIT PR Help

[Trey Harris]

On Fri, Jan 17, 2020 at 17:35 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> Hi Trey,
>
> I wanted to add an example to
>
> https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT
>
> Do I Git the entire documentation project to do so?
> Can I jsut Git that page?  If so, where do I find
> it to Git?
>
> And when I ask for an evaluation, do they have to dig
> through the entire project to find my additions?


You described yourself as a sysadmin at one point, so as a former sysadmin,
I may have been assuming a certain basis of shared knowledge we do not
have. If you simply weren’t familiar with Git, I’d have some suggestions
for ways to fake it. But if you’re not familiar with the concepts of a
unified diff, how patchfiles are generated and applied, or commits as tree
deltas over time, then I’d suggest you simply post your suggested example
in a Github Issue and explain that you don’t understand Git well enough to
do this yourself.

Re: GIT PR Help

[Trey Harris]

On Fri, Jan 17, 2020 at 15:44 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-17 12:20, Trey Harris wrote:
> > If the issue is that you aren’t comfortable enough with Git¹, I assume
> > as part of the basic toolkit of a sysadmin you know how to generate a
> > unified diff patchfile (with `diff -ruN` or equivalent)?
> >
> > If so, if you generate one and upload it attached to a GitHub issue, we
> > can figure out how to turn it into a PR rather trivially (and if I’m the
> > first to pick it up, I’ll include step-by-step instructions on how to do
> > it as a Git PR in the future).
>
> Now I am confused.  Exactly what is going on with a PR?


A “PR” is a “pull request”—in Git terminology, a request to apply a patch.
It formalizes and standardizes the process that existed on many FOSS
project dev mailing lists (most notable the Linux kernel’s) that consisted
of someone emailing the list with a unified patchfile, someone else with
the right to directly commit replying with requested changes, a new
patchfile being generated, and so on until finally the changes in the patch
were judged okay and the patch was applied. A plain unadorned Git PR flow
is nothing more than this in a very standardized format, with tools to do
the fiddly bits.

When using GitHub, the tools have been melded to ones allowing for
line-by-line code comments and approvals, visual side-by-side diffing, etc.


> What I am after is to add an example to a document page.
> Is there any special thing about this other than just
> asked for it?  It sounds like I download my own copy
> of the page (with git), then make the alterations,
> then request others evaluate it?


That’s all. You edit the file in your working directory where you want
something changed, commit those changes locally to your personal Git repo
clone, and submit it. It’s like modifying a wiki except that the changes
aren’t immediate.

The very easiest way (IMHO) to do this for a GitHub-hosted project like
this is to navigate to the official repo on GitHub (here,
https://github.com/raku/doc) while logged in to your GitHub account, and
click “fork”. So you’ll have a toddandmargo/doc instead of raku/doc that
forked from raku/doc at the moment you forked it.

Then make your changes either of two ways:

1. More flexible but requiring more Git knowledge: clone your fork with its
“remote origin” and “upstream” set such that you can run the “git pull”
command to pull changes to the original docs repo through your fork and
into your local working copy. The GitHub web UI gives instructions right
there by the “clone” button on your fork’s page on how to do this. Then you
make your changes locally, commit them locally, and push them up. When you
visit your fork on the webpage (at, e.g.,
https://github.com/toddandmargo/docs) it will notice you just did this and
offer a friendly notification complete with green button to turn your
changes into a PR right there and take care of the fiddly bits.

2. Less flexible but easier, especially for small changes: use the GitHub
web UI editing tools to just edit the files inline in your fork (at, e.g.,
https://github.com/toddandmargo/docs). GitHub will automatically generate
the commits and again display a friendly prompt to create a pull request
when you’re ready.

Trey

Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer

[Trey Harris]

If the issue is that you aren’t comfortable enough with Git¹, I assume as
part of the basic toolkit of a sysadmin you know how to generate a unified
diff patchfile (with `diff -ruN` or equivalent)?

If so, if you generate one and upload it attached to a GitHub issue, we can
figure out how to turn it into a PR rather trivially (and if I’m the first
to pick it up, I’ll include step-by-step instructions on how to do it as a
Git PR in the future).

—
¹ Though in searching through the email logs to see what familiarity you’d
shown with Git in the past, it seems like this is something that’s held you
back enough that learning it would likely pay large dividends in the future.

On Fri, Jan 17, 2020 at 14:56 Tom Browder  wrote:

> On Fri, Jan 17, 2020 at 1:44 PM ToddAndMargo via perl6-users
>  wrote:
> ...
> > Was this what you were referring to?
> >
> > https://github.com/Raku/doc/blob/master/CONTRIBUTING.md
>
> No, check this link:
>
>
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request
>
> -Tom
>

Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer

[Trey Harris]

On Thu, Jan 16, 2020 at 15:04 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-16 11:00, Trey Harris wrote:
> and your apparent misapprehension that
> merely explaining away a statement that some took offense to, without
> any outward sign of contrition, inoculates you from any further offense.

>
[...]

Offense can not be given, only taken.


That is an execrable meme forwarded, I think, only by people who either
haven’t examined the notion closely, or else who feel they are immune from
offensive statements (they believe, by choice rather than circumstance) and
assume everyone else has that same luxury. It’s basically a perversion of
“sticks and stones”, which was never meant to be weaponized into
victim-blaming by the sources of offense—as in “but words will never hurt
*you*”—but as a comfort to the targets of offense.

In the context of online discussion words are all there is, so this meme is
essentially tantamount to a declaration that no statement made online can
have *any* emotional impact unless willingly chosen by the reader, which is
absurd. (Unless offense is somehow thought to be a singular emotional
reaction with the magical property of being entirely voluntarily to
experience.)

Some folks take offense out of anything.


But your prior statement of that meme should make this statement equivalent
to “there exist things which some folks take offense from”—which would be
an oddly meaningless position to take. As I assume you weren’t stating a
tautology for no reason, I take it you mean some folks are especially prone
to taking offense from things that reasonable people would find inoffensive.

But you can’t say on the one hand that offense can’t be given, only taken,
but on the other hand suggest that there are both validly offensive and
purely inoffensive statements. A spectrum of offensiveness can’t coexist
with the notion that offense is solely determined by the tetchiness of the
target.

On 2020-01-16 11:00, Trey Harris wrote:
> and your apparent misapprehension that
> merely explaining away a statement that some took offense to, without
> any outward sign of contrition, inoculates you from any further offense.

Contrition if I do something wrong first.  [...] After endless explaining
> what I meant, those still taking offense AFTER the explanation are the ones
> that need to be apologizing.


And your steadfast refusal—as Richard began this thread by observing—to
accept any admission of wrong is the reason people continue to take
offense. Wrong can exist absent intention. I could very sincerely mean it
when I say “the square root of 20 is 5”, and my error could have been
totally unintentional, but it’s still wrong. I don’t need to beat myself up
about it or flagellate myself in front of everyone who heard my mistake,
but I do still need to do at least the minimum of saying “oops, sorry” if I
made the statement in a context that required the response of others in
some way. And that’s in a context where offensiveness and other emotional
concerns are nearly absent.


> > The thing about /true/ contrition (and I haven’t read anything from you
> > on this that seems to amount even to lip-service of contrition) is that
> > you have to put up with a certain amount of what you may perceive as
> > sour grapes before complaining about it. You can welcome magnanimity,
> > but you can’t demand it. And until you do show true contrition, the
> > timer on when those grapes sour can’t even start.
> >
> > “What, I already apologized, won’t you just drop it?!” would already be
> > a bad look; “I have told you and others ENDLESSLY [that my behavior
> > wasn’t something I ever needed to apologize for in the first place]” is
> > quite a bit worse.
>
> My, my is not the sky a pretty shade of blue today?


You appear to be trying your damnedest to force a context in which you can
really make that become an offensive statement.

Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer

[Trey Harris]

On Thu, Jan 16, 2020 at 12:19 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> As far as the Dog remark, I have told you and others
> ENDLESSLY what that meant.  That you continue to
> deliberately misrepresent me on this is a moral
> issue on your part.


The issue is not, now, just the dog remark—if you and JJ agree that it was
a previously-established in-joke, that *could be* water under the
bridge—though again, the issue of a lack of perspective here appears to be
why you’re not understanding why it continues to be brought up: most
readers will not be aware of such an in-joke, and will be (perhaps
erroneously) offended on behalf of JJ if you don’t explain it *at the time*.

No; the issue is your ongoing response to being called out for the remark.
Your histrionic reactions, such as “Oh Great And Mighty Gatekeeper of the
Documentation!” and your apparent misapprehension that merely explaining
away a statement that some took offense to, without any outward sign of
contrition, inoculates you from any further offense.

The thing about *true* contrition (and I haven’t read anything from you on
this that seems to amount even to lip-service of contrition) is that you
have to put up with a certain amount of what you may perceive as sour
grapes before complaining about it. You can welcome magnanimity, but you
can’t demand it. And until you do show true contrition, the timer on when
those grapes sour can’t even start.

“What, I already apologized, won’t you just drop it?!” would already be a
bad look; “I have told you and others ENDLESSLY [that my behavior wasn’t
something I ever needed to apologize for in the first place]” is quite a
bit worse.

Trey

—
(p.s.: I don’t know your gender identity, but it reads to me like you’re
overtly mansplaining here. But other than calling you out on it, I’m not
going to go any farther into that particular minefield on a public list.
Feel free to disagree but don’t bother doing so in a list reply: I won’t
encourage such behavior by even reading it, so I’m going to assume any
reply you make to this email is just responding to the remarks before this
postscript. If you feel you really must respond to this, you can email me
privately if you like, and I promise I’ll read it and reply. If I’m making
an incorrect assumption about your gender identity—the “I have told you”
remark is still enormously patronizing, even if it isn’t mansplaining.)

>

Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer

[Trey Harris]

On Wed, Jan 15, 2020 at 17:39 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-15 14:18, Elizabeth Mattijsen wrote:
> > Thank you Richard for this long and thoughtful answer.
> >
> > I have already given up on Todd, I'm glad to see others haven't (yet).
> What will follow is probably a response that is either: a. everybody is
> against me, b. the Raku community won't listen, c. the various variations
> on those themes.  I sincerely hope that I'm wrong.
> >
> > Liz
>
> Hi Liz,
>
> Richard has not liked me for a long time.  There
> is really not anything I can do about it but
> maybe wait him out.  I can say the sky is a lovely
> shade of blue and he would find something offensive
> in the remark.


And there’s another example of exactly the sort of things Richard brought
up.

How about: “I feel like Richard has not liked me for a long time, and that
there’s nothing I can do about it. I feel like I could say almost anything
and he would find something offensive about it.” If you feel you must make
such statements, frame them from their correct perspective—as coming from
your feelings, not as objective fact—and drop the hyperbole (“I can say the
sky is a lovely shade of blue”) and gamesmanship (“not anything I can do...
but maybe wait him out”).


>
>   "a. everybody is against me, b. the Raku
>   community won't listen, c. the various variations
>   on those themes"
>
> U.  I complain about the documentation and the
> difficulty in try to get it fixed.  The rest of Raku,
> I absolute adore and have said so, so many times
> that I fear I am being tiresome.
>
> And the "everybody is against me" remark is in your
> head.  I have NEVER said anything like this.  Complaining
> about the state of the documentation is not complaining
> that everyone is against me.


Again, you seem to be missing the matter of perspective. Stating, as
objective fact, that the documentation is in a poor state, is written
badly, “seems designed to confuse”, etc., can only be heard, by its
authors, as a judgment of them—the documentation did not just appear on
GitHub one day from nowhere.

>
And I even like you too.  You help me with things
> and you don't even like me.  That is a good character
> trait on your part.  I will wear you down eventually.


A statement like this, in this context, does not appear magnanimous as it
seems you meant it to be. It can only be so if you show some modicum of
contrition first, which you have not—you’ve simply stated as fact that you
have done nothing wrong.

I have not devoted the time or energy this time into pulling down and
grepping your emails as I did once before (since a data-based approach
didn’t appear to help then, why should I go to the effort?), but I’d in
general observe that you seem to: a) consistently state as bald fact your
impressions of the internal states of other people, and b) consistently
state as bald fact your own opinions without marking them as even
potentially wrong.

A few “I think that...”, “I’ve noticed that...”, “From reading X it seems
like...” would do a world of good here. Coming to grips with what IS simple
fact—that none of us have direct access to others’ mental states—and
adjusting your statements about others accordingly would do another world
of good.

No, I’m not talking about artificially puffing up your language; that would
help no more than your artificially-hyperbolized reference to JJ helped
anything after previously calling him a dog. I’m talking about a
perspective shift in your writing, thinking about the source of knowledge
and opinions you (believe) you have and stating that knowledge or opinion
acknowledging that basis, rather than writing yourself as the omniscient
narrator in all things.

Trey

Re: OT: Git Hub repositories

[Trey Harris]

On Sat, Jan 4, 2020 at 18:14 ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

> On 2020-01-04 14:40, Trey Harris wrote:
> > All the tooling (that cares at all about repos, anyway) generally expect
> > one repo per exportable product (e.g., a module).
> >
> > This shouldn’t be an issue unless you typically use modules directly
> > from their repos without installing them—which is a bad practice you
> > should avoid, particularly if you’re a module author.
> >
>
> This is the confusion I was trying to get around:
>
> In my WinMount.pm6 module, I import three of my other modules:
>
> use NativeConstants;
>
> use WinMessageBox :WinMsg;
>
> use WinReg :WinReadRegKey;
>
I don’t see why that needs to be confusing—lots of modules (in both the
language and the publishing senses) import other modules (in either sense)
all the time.

If you take advantage of $PERL6LIB and its ilk by assuming an on-disk
location, or hardcode a `use lib`, of course you’ll get into trouble.
That’s why it’s best to use proper tooling so you can “make install”. (This
also lets you test changes in isolation, even if you have edits in progress
simultaneously in several repos whose products depend on each other.)

Re: OT: Git Hub repositories

[Trey Harris]

On Sat, Jan 4, 2020 at 17:40 Trey Harris  wrote:

> All the tooling (that cares at all about repos, anyway) generally expect
> one repo per exportable product (e.g., a module).
>

Argh, overloaded English: I meant “publishable product”, and “CPAN-like
module”. Not export and module as in the language concepts


> This shouldn’t be an issue unless you typically use modules directly from
> their repos without installing them—which is a bad practice you should
> avoid, particularly if you’re a module author.
>
> On Sat, Jan 4, 2020 at 17:30 Simon Proctor 
> wrote:
>
>> I go with one repository per module.
>>
>> On Sat, 4 Jan 2020, 21:16 ToddAndMargo via perl6-users, <
>> perl6-users@perl.org> wrote:
>>
>>> Hi All,
>>>
>>> Over in Git Hub land, would you create a repository
>>> for each module you place on Git?  Or like my modules,
>>> the all support/import each other, would you place them
>>> all in the same repository?  What would be the best for
>>> sharing with folks on this list?
>>>
>>> Many thanks,
>>> -T
>>>
>>> --
>>> ~
>>> When we ask for advice, we are usually looking for an accomplice.
>>> --  Charles Varlet de La Grange
>>> ~
>>>
>>

Re: OT: Git Hub repositories

[Trey Harris]

All the tooling (that cares at all about repos, anyway) generally expect
one repo per exportable product (e.g., a module).

This shouldn’t be an issue unless you typically use modules directly from
their repos without installing them—which is a bad practice you should
avoid, particularly if you’re a module author.

On Sat, Jan 4, 2020 at 17:30 Simon Proctor  wrote:

> I go with one repository per module.
>
> On Sat, 4 Jan 2020, 21:16 ToddAndMargo via perl6-users, <
> perl6-users@perl.org> wrote:
>
>> Hi All,
>>
>> Over in Git Hub land, would you create a repository
>> for each module you place on Git?  Or like my modules,
>> the all support/import each other, would you place them
>> all in the same repository?  What would be the best for
>> sharing with folks on this list?
>>
>> Many thanks,
>> -T
>>
>> --
>> ~
>> When we ask for advice, we are usually looking for an accomplice.
>> --  Charles Varlet de La Grange
>> ~
>>
>

Re: Fwd: Raku, docs, help [was: Re: vulgar?]

[Trey Harris]

On Mon, Dec 9, 2019 at 9:53 PM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:

On 2019-12-09 09:44, Trey Harris wrote:
> > Signatures are important to Raku.
>
> Trey,
>
> The signatures are very important to the developers.
> They only confuse the programmer.
>
I explained in the context surrounding the sentence you clipped out why
this is not true. (Assuming you’re defining “developers” as “programmers
who work on Raku compiler and language internals” and “programmers” as
“developers who have a working knowledge of Raku and use it regularly, but
do not work on internals”. If you made this distinction explicit somewhere,
I haven’t seen it.)

As I wrote in that earlier email, Raku puts a great deal of what would in
other languages be considered *language syntax into* routine signatures,
and Signatures in Raku can do things that no other language is capable of.
(Most individual features thereof, there are other languages that include
them. But I don’t think any other language has put such a rich set of them
together before, especially in the context of multi dispatch.) This means
they *are* important to the “programmer” in your construction.

And, in fact, I find it difficult to understand why you’d think most
routine signatures would be *more* useful to “developers” vs. “programmers”
in your formulation: if one is modifying a routine in core or in the
compiler, one has the definition, including signature, right
there—signatures in the docs are not intended for them. If one is *using* a
routine in internals/core, or needs to refer to other versions of a multi,
then that “developer” is acting as a “programmer” at that moment—they are
using, not modifying, the routine in question, and yes, the doc signatures
are useful to them, but no more so than for any other Raku programmer.

Let me make an observation on one of your earlier “keeper” emails, the one
that has been memorialized in the archive
<https://www.nntp.perl.org/group/perl.perl6.users/2019/12/msg7418.html>. In
it, beginning with the line where you repeat the signature verbatim, here’s
a few lines of what you’ve written:

multi method contains(Str:D: Cool:D $needle, Int(Cool:D) $pos --> Bool)

"multi method"
 This means there are multiple ways to address this, as in

  multi method contains(Str:D: Cool:D $needle --> Bool)
  multi method contains(Str:D: Str:D $needle --> Bool)
  multi method contains(Str:D: Cool:D $needle, Int(Cool:D) $pos
--> Bool)
  multi method contains(Str:D: Str:D $needle, Int:D $pos --> Bool)

"Str"
 means it want to be fed data as a string.  Str.foo
[...]
"-->Bool"
 means it return True or False

in total, you spend 44 lines describing the signature. My observation is
this:

*Your English description of the method’s signature could be
programmatically generated from the Signature itself.* (At least, adjusting
slightly for standardizing the description.)

The only way in which this assertion *isn’t* true is your use of words like
“haystack” to try to explain the purpose of the arguments and verbs other
than neutral ones like “passes”, “references”, and “returns” and instead
use ones that are specific to the purpose of .contains—plus your mention of
“Index starts at zero by way of string convention in Perl 6”—which I don’t
entirely understand. (But if desired, all those qualities could be added as
machine-readable annotations to .contains and other routines’
self-documenting Pods.)

I think there are two interesting conclusions to be drawn from this:

   1.

   If you think these 44 lines are tremendously useful and would be more
   useful than the signatures, then they could, in fact, be programmatically
   generated and inserted into every single routine’s documentation. Since
   this would add a great deal of bulk to the docs, perhaps this could be done
   as hover text (perhaps even so that each part of your description appeared
   as you hovered over the relating Signature text), or something that is
   found under a disclosure button.

   There would, of course, be some routines for which this autogenerated
   description would be insufficient. But those are the ones where docs text
   is already given over to usage descriptions.
   2.

   With the prior point stipulated, the question is raised: if you know
   enough of Signatures to write what you wrote, how do you not “know
   signatures”? If it’s because you spent a great deal of trial-and-error to
   figure out what you wrote below the signature, where those of us who
   understand Signatures just see (for the most part) an algebraic expansion
   into 44 lines of English and formatting—then perhaps the exercise of doing
   exactly what’s described in the prior point would be a useful new feature
   for the docs framework.

   But for those of us who can read a signature and interpret it as an
   extremely brief form of those 44 lin

Re: How do I do literal quotes in a regex?

[Trey Harris]

On Mon, Dec 9, 2019 at 03:54 Fernando Santagata 
wrote:

> On Mon, Dec 9, 2019 at 9:38 AM Fernando Santagata <
> nando.santag...@gmail.com> wrote:
>
>> It can be used this way:
>>
>> $ raku -e'say „Hello!“'
>> Hello!
>> But it must be used with that closing quote '“' (U+201C); it cannot be
>> used paired with itself:
>>
>
> There's another quotation mark that can be used with '„', it's '”'
> (U+201D). I know, it's difficult to see the difference :-)
>

It’s easier to see in serif typefaces. Traditionally, pairing „Hello!“
(with U+201C) is how German used it and „Hello!” (with U+201D) is how Dutch
used it. But those conventions aren’t as rigidly set as in some other
languages. In any case, it makes sense to allow either left- or
right-closing double quotation mark in closing.

Re: Fwd: Raku, docs, help [was: Re: vulgar?]

[Trey Harris]

On Mon, Dec 9, 2019 at 10:25 Simon Proctor  wrote:

> I *highly* advise learning how signatures work.
>

This, this, a thousand times this.

ToddAndMargo, I have watched you on these lists and on GitHub issues for
years. I’ve engaged a few times but have generally pulled back again,
always in reaction to the same pattern of behavior:

1. You ask a question about something.

2. It is explained in various ways until you say you get it (and offer
sample code to show that you do, indeed, seem to get it).

3. You complain the docs do not describe it in a way that you (or
anyone—you frequently invoke yourself as the avatar of the “ordinary
programmer” as opposed  to, for example, the “IEEE member”.

4. You’re invited to fix the docs. You do not. (Here’s where I’ve engaged
more than once: suggesting specific new text and asking if it would have
clarified for you. You’ve either ignored it or simply replied that it would
not without further constructive feedback.)

5. And then—a few months later, you bring the very same issue up in
slightly different form.

If, as you implied when suggesting your “grand idea”, you believe you are
capable of writing decent documentation, may I suggest you do so in any
form whatsoever—and then start referring to it *yourself*? Then, perhaps we
could start to have your repetitive complaints be repetitive only in form
and not in substance as well, which would at least constitute some sort of
progress.

But as for the particular issue you’ve homed in on and for which you’ve
used such disparagement: it’s been observed by at least six different
people in the past couple of years (just from searching my mail) that your
eyes seem to slide over signatures, and they seem to offend you (as this
“IEEE” comment reiterates), so you gain no insight from their being there.

Perl 5 is not a language where signatures are precise enough to lend much
insight, so it’s totally unsurprising that its docs do not rely on
signatures beyond extremely schematic ones (“LIST”, “VARIABLE”,
“EXPR”)—which you find easier to understand. Fine.

But Raku, on the other hand, is a language that has pushed its syntax into
signatures at a level that I think might be unique among languages (at
least insofar as how many things can be done with those signatures that
would ordinarily be in the language grammar).

This may seem unPerlish, but it has had the enormous advantage of giving
Raku the Perlish “DWIMminess” while still having an actual specification,
so as to avoid Raku repeating Perl’s issue of being an “empirical language”
that can only be defined by its own implementation. It also allows library
programmers to do language munging in ways that previously often required
complex and fiddly messing around with Perl innards, often in XS or C.

So: Signatures are important to Raku. *Extremely* important. Your demand
that they be swept under the rug and hidden from docs because they’re
cryptic to you  is unreasonable. Learn how Signatures work—books, blog
posts and tutorials are available to explain at least the basics, and the
Signature class’s docs itself is quite readable. Then, and only then, will
you be in a position to judge whether their prominent inclusion in
documentation is an asset or not.

Trey

Re: How to use sub/method 'dir'

[Trey Harris]

On Mon, Nov 26, 2018 at 19:26 Trey Harris  wrote:

>
>
> On Mon, Nov 26, 2018 at 04:56 Fernando Santagata <
> nando.santag...@gmail.com> wrote:
>
>> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert  wrote:
>>
>>> The reason `dir('a', test => { .IO.d })` doesn't work like you expect
>>> is that it is passed strings.
>>>
>>
>> Thank you!
>> I could have inferred that from the declaration of the 'test' argument
>> here https://docs.perl6.org/routine/dir where the test is being done
>> against '.' and '..', two strings:
>>
>> subdir(Cool $path = '.', Mu :$test = none('.', '..'))
>>> method dir(IO::Path:D: Mu :$test = none('.', '..'))
>>>
>>
>> but I guess it's a long stretch.
>> Maybe a note in the docs would be useful to others.
>>
>>
>>> I would argue that inside of the `test` that `$*CWD` should be set to
>>> `a`, and/or the values should be IO objects.
>>> (They are going to become IO objects eventually anyway.)
>>>
>>
>> Indeed I think that even tough one can do any kind of test on the
>> directory's content, the most usual ones are those using the file test
>> operators, so defaulting to IO is probably more useful than defaulting to
>> Str.
>>
>
> I'm not sure that's true. I think it's a question of following the
> Principle of Least Surprise.
>
> The only substantive difference between `my $i = "foobar".IO` and `my $s =
> "foobar"` besides needing to stick the `.IO` in when you want to do IO-y
> things with `$s` is that `$i` retains the knowledge of $*CWD at the time of
> instantiation. But `dir` always returns paths that stringify _relative to
> `$*CWD` at the time of the `dir` call._ Notice the difference between
> `$i.gist` (which, if evaluated, will not consistently re-create the
> original object) and `$i.perl` (which will):
>
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
> :CWD("/home/trey/perl6/rakudo-star"))
> > chdir "/tmp"
> "/tmp".IO
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
> :CWD("/home/trey/perl6/rakudo-star"))
>

Oops, ignore the changing variable names here; I was copying lines from a
REPL session where I'd used `$f`, and then I changed `$f` to match `$i` in
the text before it and didn't fully complete the renaming. It's just a
single variable.


> The string, OTOH, is also relative to the `$*CWD` at the time of the
> `dir()` call, but if you call `.IO` on it after changing directories, the
> path object is interpreted relative to the new directory. This is
> unsurprising; what _would be_ surprising is if a string changed as a result
> of external program state.
>
> Large-scale file-munging operations have always been squarely in Perl's
> wheelhouse, and doing fancy operations with complex subtrees (such as
> syncing, normalizing, archiving, collating, etc.) are common.
>
> The string doesn't offer as much in the way of features, but I think it
> behaves much more predictably when doing these sorts of operations. If you
> `chdir $dest` after the `dir` but before doing your munging, then you must
> remember to prepend the old working directory if you need to access the
> original file (i.e., `$src = $*CWD;  for @files -> $f { $src.add($f) ...
> }`), while the new files would just be `$f`. If you don't change
> directories, then you must say `$dest.add($f)` to refer to the new files,
> while the old file is just `$f`. But in either case, it's unsurprising and
> predictable.
>
> If, OTOH, these were IO objects, if you changed directories, you'd think
> from the gist that you'd do the same. And if you don't change directories,
> you _could_ do the same (`$dest = "/destdir".IO; $dest.add($f)` works using
> the gist). But if you do change directories, it's now the _old file_ that's
> just `$f`; the new file becomes `$*CWD.add($f)`. This feels quite strange
> and surprising to me.
>
> The very slight keystroke-saving convenience of not requiring the outputs
> of `dir` to be followed with `.IO` before doing IO operations on individual
> IO objects in-place doesn't seem worth the strangeness of their behavior
> when doing bulk operations on them from a distance.
>
> (I was thinking through possible have-your-cake-and-eat-it-too solutions
> like `.gist` and `.path` of IO objects created from strings changing their
> string representation if and only if you changed working directories and
> these all seem to just Waterbed Complexify the problem elsewhere. Perhaps
> someone can come up with an everybody-wins solution—but except for moving
> the filetest operations into `Cool` so they work like in Perl 5, a ship
> that's already sailed, I can't think of one.)
>

Re: How to use sub/method 'dir'

[Trey Harris]

On Mon, Nov 26, 2018 at 04:56 Fernando Santagata 
wrote:

> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert  wrote:
>
>> The reason `dir('a', test => { .IO.d })` doesn't work like you expect
>> is that it is passed strings.
>>
>
> Thank you!
> I could have inferred that from the declaration of the 'test' argument
> here https://docs.perl6.org/routine/dir where the test is being done
> against '.' and '..', two strings:
>
> subdir(Cool $path = '.', Mu :$test = none('.', '..'))
>> method dir(IO::Path:D: Mu :$test = none('.', '..'))
>>
>
> but I guess it's a long stretch.
> Maybe a note in the docs would be useful to others.
>
>
>> I would argue that inside of the `test` that `$*CWD` should be set to
>> `a`, and/or the values should be IO objects.
>> (They are going to become IO objects eventually anyway.)
>>
>
> Indeed I think that even tough one can do any kind of test on the
> directory's content, the most usual ones are those using the file test
> operators, so defaulting to IO is probably more useful than defaulting to
> Str.
>

I'm not sure that's true. I think it's a question of following the
Principle of Least Surprise.

The only substantive difference between `my $i = "foobar".IO` and `my $s =
"foobar"` besides needing to stick the `.IO` in when you want to do IO-y
things with `$s` is that `$i` retains the knowledge of $*CWD at the time of
instantiation. But `dir` always returns paths that stringify _relative to
`$*CWD` at the time of the `dir` call._ Notice the difference between
`$i.gist` (which, if evaluated, will not consistently re-create the
original object) and `$i.perl` (which will):

> $f.gist
"foobar".IO
> $i.perl
IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
:CWD("/home/trey/perl6/rakudo-star"))
> chdir "/tmp"
"/tmp".IO
> $f.gist
"foobar".IO
> $i.perl
IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
:CWD("/home/trey/perl6/rakudo-star"))

The string, OTOH, is also relative to the `$*CWD` at the time of the
`dir()` call, but if you call `.IO` on it after changing directories, the
path object is interpreted relative to the new directory. This is
unsurprising; what _would be_ surprising is if a string changed as a result
of external program state.

Large-scale file-munging operations have always been squarely in Perl's
wheelhouse, and doing fancy operations with complex subtrees (such as
syncing, normalizing, archiving, collating, etc.) are common.

The string doesn't offer as much in the way of features, but I think it
behaves much more predictably when doing these sorts of operations. If you
`chdir $dest` after the `dir` but before doing your munging, then you must
remember to prepend the old working directory if you need to access the
original file (i.e., `$src = $*CWD;  for @files -> $f { $src.add($f) ...
}`), while the new files would just be `$f`. If you don't change
directories, then you must say `$dest.add($f)` to refer to the new files,
while the old file is just `$f`. But in either case, it's unsurprising and
predictable.

If, OTOH, these were IO objects, if you changed directories, you'd think
from the gist that you'd do the same. And if you don't change directories,
you _could_ do the same (`$dest = "/destdir".IO; $dest.add($f)` works using
the gist). But if you do change directories, it's now the _old file_ that's
just `$f`; the new file becomes `$*CWD.add($f)`. This feels quite strange
and surprising to me.

The very slight keystroke-saving convenience of not requiring the outputs
of `dir` to be followed with `.IO` before doing IO operations on individual
IO objects in-place doesn't seem worth the strangeness of their behavior
when doing bulk operations on them from a distance.

(I was thinking through possible have-your-cake-and-eat-it-too solutions
like `.gist` and `.path` of IO objects created from strings changing their
string representation if and only if you changed working directories and
these all seem to just Waterbed Complexify the problem elsewhere. Perhaps
someone can come up with an everybody-wins solution—but except for moving
the filetest operations into `Cool` so they work like in Perl 5, a ship
that's already sailed, I can't think of one.)

Re: detecting running under the repl

[Trey Harris]

On Tue, Nov 6, 2018 at 1:24 PM Joseph Brenner doom...@gmail.com
 wrote:

How do you write code that detects whether it's running under the repl?
>
The variable $*PROGRAM (or $*PROGRAM-NAME; they interpolate identically so
I’m giving them raw to say below)—with the caveat that it isn’t perfect:

% perl6
To exit type 'exit' or '^D'
> say $*PROGRAM, " ", $*PROGRAM-NAME
"interactive".IO interactive
>
% perl6 -e 'say $*PROGRAM, " ", $*PROGRAM-NAME'
"-e".IO -e
% newscript /tmp/interactive perl6
% cat >> /tmp/interactive

say $*PROGRAM, " ", $*PROGRAM-NAME;
% cat /tmp/interactive
#!/usr/bin/env perl6

say $*PROGRAM, " ", $*PROGRAM-NAME;
% /tmp/interactive
"/tmp/interactive".IO /tmp/interactive
% cd /tmp
% ./interactive
"./interactive".IO ./interactive
% path+=.
% interactive
"interactive".IO interactive

But since $*PROGRAM is automatically an uninstantiated IO::Path object, you
could add a check $*PROGRAM.e which will usually work unless you

   1. have . in your PATH (not smart), and
   2. happen to be in the same directory as a file named *interactive*

(FYI, newscript is just a self-created shell function that creates a script
with a shebang line and makes it executable, and the path+=. is (I think?)
a Zsh-ism for path=$path . that doesn’t add . if it’s already a member.)

Diamond <> or fileinput-like input handling (was Re: what type $in,$out and $err is)

[Trey Harris]

On Mon, Nov 5, 2018 at 11:54 AM Ralph Mellor
[ralphdjmel...@gmail.com](mailto:ralphdjmel...@gmail.com)

wrote:

On Sun, Oct 28, 2018 at 7:26 PM Xiao Yafeng  wrote:
>
>> Besides, just curious, why choose '_' as default it looks strange
>>
>
> Turns out it's deprecated in 6.d:
>
> https://marketing.perl6.org/id/1541379592/pdf_digital
>
Is it, for Proc objects, in addition to for &open as mentioned in the
ChangeLog ?

They mean different things (that simply happen to semantically overlap
frequently):

   - In &open , use of '-' indicates $*IN
   or $*OUT for read-only or write-only uses respectively.
   - In Proc , the default of '-'
   indicates standard POSIX-like practice of inheriting stdin, stdout and
   stderr from the parent, no matter how the parent (or its parent(s)) have
   duped or redirected them.

>From the respective code, I think it is not; as the ChangeLog states, it’s
deprecated for &open, but not for Proc.

This passage
 from
the built-in variables doc is interesting:

Argument related variables

   - $*ARGFILES An IO::ArgFiles 
   (an empty subclass of IO::CatHandle) that uses @*ARGS as source files,
   if it contains any files, or $*IN otherwise. When $*IN is used, its
   :nl-in, :chomp, :encoding, and :bin will be set on the IO::ArgFiles
    object.

As of 6.d language, $*ARGFILES *inside* sub MAIN
 is always set to $*IN,
even when @*ARGS is not empty.

   - @*ARGS Arguments from the command line.

This is getting at the issue with replicating the common “while diamond”
operation (originally just while (<>)) in Perl 5, which allowed easy
replication of Unix/POSIX default line-oriented file-handling behavior:
namely, concatenating the lines of each filename given in the optional
positionals, unless the filename was the single hyphen "-", in which case
lines from standard input were read instead; when the positionals were
empty, an implicit "-" was assumed.

(If you haven’t played with this behavior directly, it’s very easy to just
use cat or grep to observe this behavior; with no files, stdin is used;
with files, stdin is usually not used, but - alone can be used to switch to
stdin after reading named files. And not just “after”—it’s permissible,
although a bit unusual, to put - between file names, in which case lines
from the named files preceding the hyphen are processed, then lines from
stdin are processed until stdin closes, then files named after the hyphen
are processed. It’s even allowable to include the single hyphen more than
once, which forces reopening of stdin for another round of input until it’s
closed again. This behavior is ubiquitous in the Unix world; Perl 5 had it
built-in, Python has its fileinput module
, and so on.)

How to replicate this behavior in Raku without handling all the
args-handling and opening/closing logic yourself is now… unclear, at best,
and may simply be missing.

In this passage  from
the Perl 5-to-6 guide (which, as an ancillary help document, does not have
any authority for language specification), we read:

Note that reading line-by-line from a filehandle has changed.

In Perl 5, it was done in a while loop using the diamond operator. Using for
instead of while was a common bug, because the for causes the whole file to
be sucked in at once, swamping the program’s memory usage.

In Perl 6, for statement is *lazy*, so we read line-by-line in a for loop
using the .lines method.

while ()  { } # Perl 5

for $IN_FH.lines { } # Perl 6

$IN_FH is, I think, given in the latter example in a hand-wavy way. The
thing that comes *closest* to cat, grep, Perl 5’s diamond, or Python’s
fileinput is—I believe—the unadorned routine lines()
:

for lines() -> $line { ... }

but it has the nonstandard behavior (which may be a bug) of only observing
the first hyphen found in the argument list and ignoring any successive
ones (at least in 6.c). Also, while I’m having trouble getting a 6.d to
work for me right now, I think Raku will give a deprecation notice when it
encounters that first hyphen—so to get the same behavior you’ll again need
to handle all hyphens on the command line yourself.

Just fyi — It’s entirely possible I’m wrong here, and just haven’t found
the right bit of the docs, or that once I get 6.d built I’ll find that
$*ARGFILES.lines — which would *seem* to me to be the right thing to use —
works for this purpose.

I’m not clear why its behavior is changed in sub MAIN—obviously, you can
handle the positionals y

Re: bitwise or?

[Trey Harris]

On Fri, Oct 5, 2018 at 8:33 AM Timo Paulssen t...@wakelift.de
 wrote:

It's important to point out that inside metaoperators ("composed
> operators", "combined operators", ...) the [ ] are just for bracketing
> things together — sometimes it's needed to disambiguate, but you can put
> it in anyway to make things clearer.
>
> This has nothing to do with [+] 1, 2, 3, which is a way to spell "add
> these three numbers together".
>
Timo—is this fact formalized in the docs? I can’t find it.
https://docs.perl6.org/routine/= doesn’t mention it, and while
https://docs.perl6.org/language/operators#Assignment_operators gives an
example of using it (with +=, -=, min= and ~=), I can’t find the
metaoperator version’s definition.


> On 05/10/2018 14:26, Brad Gilbert wrote:
> > Note that = is actually a meta operator that can take an infix
> > operator as an argument
> >
> > So
> >
> > $a += 1
> >
> > is really short for
> >
> > $a [+]= 1
> >
> > On Fri, Oct 5, 2018 at 1:02 AM Todd Chester 
> wrote:
> >>
> >>
> >> On 10/4/18 12:13 PM, Brandon Allbery wrote:
> >>> It's fine syntactically, but I think has no effect because it'd be '$v
> =
> >>> $v' after the '+|='. Conceivably some future version of rakudo could
> >>> warn about it having no effect.
> >> That explains it.  Thank you!
>

Re: routine declaration line question

[Trey Harris]

On Fri, Oct 5, 2018 at 2:10 PM Brandon Allbery  wrote:

> Haskell supports it via typeclass resolution, which is mostly a source of
> confusion to newcomers who assume (read :: Read a => String -> a) must be
> deciding what to produce based on the String because they're not expecting
> return type polymorphism. It doesn't seem to be a problem otherwise.
> (Multiparameter typeclasses have a bigger problem, return type polymorphism
> being only one of several ways to expose it.)
>

D’oh, of course; I do that all the time. (My weirdness in Haskell being my
first real language and Perl being my second shows in cases like this; I
forget how to map things *back* from other languages into Haskell-isms.)

But thinking about that, to me that’s so ingrained into how a
type-inferring strict functional language works that it’s not the same
thing as “polymorphism”; I only barely recognize that the thing that we do
in Haskell more often than not, defining degenerate cases as separate
function definitions, qualifies as “polymorphism”. (Elm doesn’t do it and
it drives me batty.)
​


>
> On Fri, Oct 5, 2018 at 2:03 PM Trey Harris  wrote:
>
>>
>>
>> On Fri, Oct 5, 2018 at 1:13 PM Brandon Allbery 
>> wrote:
>>
>>> My problem with it being in the signature is still that it doesn't say
>>> which part of the contract it applies to; it appears to be claiming it's
>>> part of dispatch, when it's not.
>>>
>>
>> Explicit argument polymorphism has been shown to be useful and increasing
>> in elegance more often than it causes debugging complexity, while return
>> polymorphism has generally been a nightmare in languages that have tried
>> it, no? True that no other polymorphic language (AFAIK, but haven’t looked
>> lately) has true multimethods, but my guess is that return polymorphism
>> would be even worse within multiple dispatch than in single-dispatch
>> languages.
>>
>> Not that I thought you were arguing that --> *should* apply to dispatch,
>> just trying to get everyone on the same page in case we’re not (and maybe
>> I’m the one who needs my page flipped to the same place in the hymnal).
>>
>> But right now we have a situation where “everything within the signature 
>> *except
>> for* the return constraint can participate in multi dispatch”, which
>> does feel weird. But is that actually true? Something’s nagging at me that
>> there’s something else in this category as well, but I can’t think what.
>> (Recursive multi dispatch on signatures of multi Callable arguments,
>> maybe? I would try but my machine’s offline upgrading….) If there are more
>> rules about what participates in multi dispatch than “change anything in
>> the signature to the left of the --> and you’re good”, then it’s
>> probably acceptable for --> to not participate either—it’s already more
>> complex than it looks.
>> ​
>>
>>
>>
>>>
>>> On Fri, Oct 5, 2018 at 12:01 PM Larry Wall  wrote:
>>>
>>>> On Thu, Oct 04, 2018 at 09:35:08PM +0200, JJ Merelo wrote:
>>>> : El jue., 4 oct. 2018 21:21, Brandon Allbery 
>>>> escribió:
>>>> :
>>>> : > I don't think we've reached the point of such conventions yet. And
>>>> there's
>>>> : > some history here, in --> not having done anything in the early
>>>> days except
>>>> : > possibly slow things down, and between --> and 'returns' (which is
>>>> now
>>>> : > deprecated).
>>>> : >
>>>> :
>>>> : Not yet. Maybe never...
>>>>
>>>> --> generalizes to pointy blocks and such.  'returns' doesn't.
>>>>
>>>> --> allows return of explicit literal Nil and True and 42.  'returns'
>>>> doesn't.
>>>>
>>>> --> makes the return an official part of the routine's contract.
>>>> 'returns' doesn't.
>>>>
>>>> For various purposes it would be nice to know we have the entire in/out
>>>> contract
>>>> before we start processing all the oh-by-the-way traits that can turn
>>>> the contract
>>>> into a time-traveling brain pretzel.  For instance, what if one of the
>>>> phaser traits
>>>> needs to know will be returned, and the 'returns' comes after that?
>>>> Putting in error
>>>> messages that say "Too late for returns trait" is a design smell...
>>>>
>>>> So never say never.  :)
>>>>
>>>> Larry
>>>>
>>>
>>>
>>> --
>>> brandon s allbery kf8nh
>>> allber...@gmail.com
>>>
>>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
>

Re: routine declaration line question

[Trey Harris]

On Fri, Oct 5, 2018 at 1:13 PM Brandon Allbery  wrote:

> My problem with it being in the signature is still that it doesn't say
> which part of the contract it applies to; it appears to be claiming it's
> part of dispatch, when it's not.
>

Explicit argument polymorphism has been shown to be useful and increasing
in elegance more often than it causes debugging complexity, while return
polymorphism has generally been a nightmare in languages that have tried
it, no? True that no other polymorphic language (AFAIK, but haven’t looked
lately) has true multimethods, but my guess is that return polymorphism
would be even worse within multiple dispatch than in single-dispatch
languages.

Not that I thought you were arguing that --> *should* apply to dispatch,
just trying to get everyone on the same page in case we’re not (and maybe
I’m the one who needs my page flipped to the same place in the hymnal).

But right now we have a situation where “everything within the
signature *except
for* the return constraint can participate in multi dispatch”, which does
feel weird. But is that actually true? Something’s nagging at me that
there’s something else in this category as well, but I can’t think what.
(Recursive multi dispatch on signatures of multi Callable arguments, maybe?
I would try but my machine’s offline upgrading….) If there are more rules
about what participates in multi dispatch than “change anything in the
signature to the left of the --> and you’re good”, then it’s probably
acceptable for --> to not participate either—it’s already more complex than
it looks.
​



>
> On Fri, Oct 5, 2018 at 12:01 PM Larry Wall  wrote:
>
>> On Thu, Oct 04, 2018 at 09:35:08PM +0200, JJ Merelo wrote:
>> : El jue., 4 oct. 2018 21:21, Brandon Allbery 
>> escribió:
>> :
>> : > I don't think we've reached the point of such conventions yet. And
>> there's
>> : > some history here, in --> not having done anything in the early days
>> except
>> : > possibly slow things down, and between --> and 'returns' (which is now
>> : > deprecated).
>> : >
>> :
>> : Not yet. Maybe never...
>>
>> --> generalizes to pointy blocks and such.  'returns' doesn't.
>>
>> --> allows return of explicit literal Nil and True and 42.  'returns'
>> doesn't.
>>
>> --> makes the return an official part of the routine's contract.
>> 'returns' doesn't.
>>
>> For various purposes it would be nice to know we have the entire in/out
>> contract
>> before we start processing all the oh-by-the-way traits that can turn the
>> contract
>> into a time-traveling brain pretzel.  For instance, what if one of the
>> phaser traits
>> needs to know will be returned, and the 'returns' comes after that?
>> Putting in error
>> messages that say "Too late for returns trait" is a design smell...
>>
>> So never say never.  :)
>>
>> Larry
>>
>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
>

Re: routine declaration line question

[Trey Harris]

Right; that's what I meant by "stylistically" — a `--> Mu` can highlight
that something is being returned (and that side-effects are not the primary
purpose), while nothing indicates that the return value, though it exists,
is incidental and probably from "falling off the end" or using `return` as
a control-flow jump.
On Thu, Oct 4, 2018 at 15:04 Brandon Allbery  wrote:

> Arguably it should be --> Any, since Mu vs. Any has meaning with respect
> to Junctions. But in this case it's just not stating a redundancy.
>
> The way you'd phrased it makes it sound like it's an explicit
> no-meaningful-result, as opposed to 'we don't know or care'.
>
> On Thu, Oct 4, 2018 at 3:02 PM Trey Harris  wrote:
>
>> Ah (replying to both Brandon and JJ since their replies crossed):
>>
>> So `--> Mu` is not a sufficient and/or correct return constraint for
>> things like AT-POS because why, then?
>> On Thu, Oct 4, 2018 at 14:56 Brandon Allbery  wrote:
>>
>>> I think they meant more like my AT-POS example: the point is the return
>>> value, but you can't say ahead of time what type it will have.
>>>
>>> On Thu, Oct 4, 2018 at 2:48 PM Trey Harris  wrote:
>>>
>>>>
>>>>
>>>> On Thu, Oct 4, 2018 at 02:13 JJ Merelo  wrote:
>>>>
>>>>>
>>>>>
>>>>> El jue., 4 oct. 2018 a las 3:36, Trey Harris ()
>>>>> escribió:
>>>>>
>>>>>> _All_ routines in Perl 6 return _something._ A lack of a "-->" simply
>>>>>> indicates stylistically that the return is not useful because it's 
>>>>>> whatever
>>>>>> "falls off the end". (There's a bit of variance here as I'm not sure 
>>>>>> it's a
>>>>>> convention everyone has followed.) It's equivalent to "--> Mu" because
>>>>>> anything that could "fall of the end" is Mu.
>>>>>>
>>>>>
>>>>> No, it means that it's not constrained to a type. It can still return
>>>>> something, but it can be anything.
>>>>>
>>>>
>>>>
>>>> I get all that, except for the "No" at the front. ;-)
>>>>
>>>> Or were you talking about the "not useful" bit? Yes, of course in any
>>>> given codebase, the lack of a return value has no more or less meaning than
>>>> a lack of any constraint. The programmer may not like using constraints at
>>>> all and treats Perl 6 like Perl 5 in the respect of wanting arbitrarily
>>>> mungible values.
>>>>
>>>> But the word "stylistically" was important, as I was responding to
>>>> Todd's question about the docs—I think a lack of a return value in the docs
>>>> (at least, the ones I could come up with in a grep pattern on my checkout
>>>> of docs) does tend to indicate that the return is not useful, that the
>>>> routine is a "procedure" run for its side effects rather than for
>>>> evaluation.
>>>>
>>>> Is that what you meant?
>>>>
>>>> If you were saying in "it can still return something, but can be
>>>> anything", that "anything ⊃ (is a strict superset of) `Mu`", then I
>>>> don't understand, because I thought all values conformed to Mu.
>>>>
>>>>
>>>
>>> --
>>> brandon s allbery kf8nh
>>> allber...@gmail.com
>>>
>>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
>

Re: routine declaration line question

[Trey Harris]

Ah (replying to both Brandon and JJ since their replies crossed):

So `--> Mu` is not a sufficient and/or correct return constraint for things
like AT-POS because why, then?
On Thu, Oct 4, 2018 at 14:56 Brandon Allbery  wrote:

> I think they meant more like my AT-POS example: the point is the return
> value, but you can't say ahead of time what type it will have.
>
> On Thu, Oct 4, 2018 at 2:48 PM Trey Harris  wrote:
>
>>
>>
>> On Thu, Oct 4, 2018 at 02:13 JJ Merelo  wrote:
>>
>>>
>>>
>>> El jue., 4 oct. 2018 a las 3:36, Trey Harris ()
>>> escribió:
>>>
>>>> _All_ routines in Perl 6 return _something._ A lack of a "-->" simply
>>>> indicates stylistically that the return is not useful because it's whatever
>>>> "falls off the end". (There's a bit of variance here as I'm not sure it's a
>>>> convention everyone has followed.) It's equivalent to "--> Mu" because
>>>> anything that could "fall of the end" is Mu.
>>>>
>>>
>>> No, it means that it's not constrained to a type. It can still return
>>> something, but it can be anything.
>>>
>>
>>
>> I get all that, except for the "No" at the front. ;-)
>>
>> Or were you talking about the "not useful" bit? Yes, of course in any
>> given codebase, the lack of a return value has no more or less meaning than
>> a lack of any constraint. The programmer may not like using constraints at
>> all and treats Perl 6 like Perl 5 in the respect of wanting arbitrarily
>> mungible values.
>>
>> But the word "stylistically" was important, as I was responding to Todd's
>> question about the docs—I think a lack of a return value in the docs (at
>> least, the ones I could come up with in a grep pattern on my checkout of
>> docs) does tend to indicate that the return is not useful, that the routine
>> is a "procedure" run for its side effects rather than for evaluation.
>>
>> Is that what you meant?
>>
>> If you were saying in "it can still return something, but can be
>> anything", that "anything ⊃ (is a strict superset of) `Mu`", then I
>> don't understand, because I thought all values conformed to Mu.
>>
>>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
>

Re: routine declaration line question

[Trey Harris]

On Thu, Oct 4, 2018 at 02:13 JJ Merelo  wrote:

>
>
> El jue., 4 oct. 2018 a las 3:36, Trey Harris () escribió:
>
>> _All_ routines in Perl 6 return _something._ A lack of a "-->" simply
>> indicates stylistically that the return is not useful because it's whatever
>> "falls off the end". (There's a bit of variance here as I'm not sure it's a
>> convention everyone has followed.) It's equivalent to "--> Mu" because
>> anything that could "fall of the end" is Mu.
>>
>
> No, it means that it's not constrained to a type. It can still return
> something, but it can be anything.
>


I get all that, except for the "No" at the front. ;-)

Or were you talking about the "not useful" bit? Yes, of course in any given
codebase, the lack of a return value has no more or less meaning than a
lack of any constraint. The programmer may not like using constraints at
all and treats Perl 6 like Perl 5 in the respect of wanting arbitrarily
mungible values.

But the word "stylistically" was important, as I was responding to Todd's
question about the docs—I think a lack of a return value in the docs (at
least, the ones I could come up with in a grep pattern on my checkout of
docs) does tend to indicate that the return is not useful, that the routine
is a "procedure" run for its side effects rather than for evaluation.

Is that what you meant?

If you were saying in "it can still return something, but can be anything",
that "anything ⊃ (is a strict superset of) `Mu`", then I don't understand,
because I thought all values conformed to Mu.

Re: routine declaration line question

[Trey Harris]

On Wed, Oct 3, 2018 at 22:21 ToddAndMargo  wrote:

> >> On 04/10/2018 03:07, ToddAndMargo wrote:
> >>> Hi All,
> >>>
> >>> In another thread, Timo wrote me:
> >>>
> >>> The "-->" part of the signature is optional. If there isn't
> >>> one, it defaults to Mu, which is the type that everything
> >>> conforms to, i.e. the sub or method that either has "--> Mu"
> >>> explicitly, or has it by leaving it out, may return
> >>> absolutely whatever it wants.
> >>>
> >>> After all, the "-->" part is a constraint, and it gets
> >>> validated at compile time every time a sub or method
> >>> returns.
> >>>
> >>> I got to thinking, some routines do not return anything.  Without
> >>> the "-->" constraint, how am I to determine if something is
> >>> being returned?
> >>>
> >>> Yours in confusion,
> >>> -T
>
> On 10/3/18 6:44 PM, Timo Paulssen wrote:
> > I just spotted a grave mistake in my earlier mail:
> >
> > the --> constraints are validated at *run* time, not *compile* time;
> > that's a very big difference, and an important one. Of course "every
> > time a sub or method returns" doesn't make much sense if i had meant
> > "compile time", but I felt i should really point it out before causing
> > too much confusion.
> >
>
> Hi Timo,
>
> Thank you for the help over on the chat line with IN!
>
> My confusion is not that it returns something (Mu).
>
> My confusion is "what" it returns.


I'm not clear on what you mean. When "--> XXX" is given, then an XXX is
returned. When no "-->" is given, it technically returns Mu but you can
pretend it is like a Pascal/Module "procedure" that does not return
anything.

And not all subs
> return things, like "say" and "print".


That's not the case. "say" and "print" return something that conforms to -->
 Bool:D (in most cases, True).


>
> I am presuming I am to pick the "what" from context
> from the examples?


What context or examples are you referring to? Both docs rather clearly
state that True is typically returned, and in the case of
https://docs.perl6.org/routine/say the very second code example states this
in English and then shows it with an example.


>
> -T
>
>
> --
> ~~
> Computers are like air conditioners.
> They malfunction when you open windows
> ~~
>

Re: bitwise paper?

[Trey Harris]

Todd,

Assuming you are suggesting your examples are showing differences between
the languages, in all your examples of differences between Perl 6 and Perl
5 below, you are using the wrong operator or you changed one of the
arguments between the Perl 5 and Perl 6 examples.

I won't go through them each, but for example '> 3' is the greater-than
operator in Perl 5; 0b0001_0100 (20) is greater than 3, so the answer is 1
(true). And in your bitwise shift left, you're shifting by 2 in Perl 6 but
by 3 in Perl 5. And so on.

If you weren't trying to show differences between the languages but had
some other reason for changing multiple controls at once, never mind me; I
don't know how your "keeper file" works.

(But I should point out that since you at least at some point suggested
it's the sort of stuff you'd like to see in the docs, we don't give Perl 5
comparisons in the part of the docs that don't relate to Perl 5 (just in
the Perl 5 to Perl 6 Guide docs and _very_ rarely in a couple of other
cases that represent bad traps for those who might assume something works
like it does in Perl 5), and when we do give side-by-side examples of two
things, authors have tried to give example that change the minimum required
to show the difference and no more.)


On Wed, Oct 3, 2018 at 22:16 ToddAndMargo  wrote:

> My keeper file so far:
>
> Perl: bitwise operators:
>
> alias p5='perl6 -E'
> alias p6='perl6 -e'
>
>
> Bitwise AND:
>  $ p6 'my $v = 32 +& 16; say $v;'
>  0
>
>  $ p5 'my $v = 32 & 16; say $v;'
>  0
>
>
> Bitwise OR:
>  $ p5 'my $v = 32 | 16; say $v;'
>  48
>
>  $ p6 'my $v = 32 +| 16; say $v;'
>  48
>
>
> Bitwise shift left:
>  $ p6 'my $v = 0b0100 +< 2; say $v;'
>  16
>
>  $ p5 'my $v = 0b0100 << 3; say $v;'
>  32
>
>
>
> Bitwise shift right:
>  $ p5 'my $v = 0b00010100 > 3; say $v;'
>  1
>
>  $ p6 'my $v = 0b00110100 +> 3; say $v;'
>  6
>
>
> Bitwise XOR:
>  $ p5 'my $v = 0b00101101 ^ 0b1001; say $v;'
>  36
>
>  $ p6 'my $v = 0b1101 +^ 0b1001; say $v;'
>  4
>
>
> Bitwise Compliment (flip the bits):
>  $ p5 'my $x = 0b00101101; my $y= (~$x); my $z= (~$y); say
> "$x\n$y\n$z"; '
>  45
>  18446744073709551570
>  45
>
>  $ p6 'my $x = 0b00101101; my $y= (+^$x); my $z= (+^$y); say
> "$x\n$y\n$z"; '
>  45
>  -46
>  45
>
>
> Bitwise "IN" (Does y exist in x):
>
>  $ p6 'my $x=0b1001; my $y=0b0101; my $z=$x +& $y; say so $y == $z;'
>  False
>
>  $ p6 'my $x=0b1001; my $y=0b1001; my $z=$x +& $y; say so $y == $z;'
>  True
>
>  p5 not figured out yet
>

Re: routine declaration line question

[Trey Harris]

_All_ routines in Perl 6 return _something._ A lack of a "-->" simply
indicates stylistically that the return is not useful because it's whatever
"falls off the end". (There's a bit of variance here as I'm not sure it's a
convention everyone has followed.) It's equivalent to "--> Mu" because
anything that could "fall of the end" is Mu.

On Wed, Oct 3, 2018 at 21:07 ToddAndMargo  wrote:

> Hi All,
>
> In another thread, Timo wrote me:
>
> The "-->" part of the signature is optional. If there isn't
> one, it defaults to Mu, which is the type that everything
> conforms to, i.e. the sub or method that either has "--> Mu"
> explicitly, or has it by leaving it out, may return
> absolutely whatever it wants.
>
> After all, the "-->" part is a constraint, and it gets
> validated at compile time every time a sub or method
> returns.
>
> I got to thinking, some routines do not return anything.  Without
> the "-->" constraint, how am I to determine if something is
> being returned?
>
> Yours in confusion,
> -T
>

Re: bitwise paper?

[Trey Harris]

On Wed, Oct 3, 2018 at 20:56 ToddAndMargo  wrote:

> On 10/3/18 1:50 PM, Trey Harris wrote:
> >
> > On Wed, Oct 3, 2018 at 13:38 ToddAndMargo  > <mailto:toddandma...@zoho.com>> wrote:
> >
> >  > Go to docs.perl6.org <http://docs.perl6.org>
> > <http://docs.perl6.org>. Type "bitwise" into the
> >  > search box. You will see a popup, "Numeric bitwise AND operator".
> > Click
> >  > it to be taken to
> >  >
> >
> https://docs.perl6.org/language/operators#index-entry-Numeric_bitwise_AND_operator
> ,
> >
> >  > which will tell you the bitwise AND operator in Perl 6 is +&.
> >  >
> >  > Run the same command with +& and you will get the answer 0.
> >  >
> >  > If, on the other hand, you go to docs.perl6.org
> > <http://docs.perl6.org> <http://docs.perl6.org>,
> >  > and type "&" into the search box, you will see under "Infix"
> > (since you
> >  > used the operator between two things, it is Infix, as the docs
> > say if
> >  > you type "infix" into the search box and click the first entry
> under
> >  > "Reference"; I have no idea how you'd divine that such a thing is
> > called
> >  > an infix operator aside from common programming parlance, but if
> you
> >  > have an idea how that might be expressed it can easily be added
> > to the
> >  > index) that the first entry is "&".
> >  >
> >  > Click on this "&" and you are taken to
> > https://docs.perl6.org/routine/&;
> >  > which rather clearly says it returns an all Junction.
> >  >
> >  > So I wonder why were you under the impression that the above
> "should
> >  > give [you]  "?
> >  >
> >  > Trey
> >
> >
> > Thank you.
> >
> > Looks like I am going to have to look them up one at a time.
> >
> >
> > Just because you get to a specific place on a page by typing something
> > into the search box doesn't mean you can't scroll up and down on the
> > page anyway. You can do the same from +& and see the other operators,
> too.
> >
>
> Hi Trey,
>
> That page only give me one page and nothing to scroll up or down on.



I'm looking at
https://docs.perl6.org/language/operators#index-entry-Numeric_bitwise_AND_operator
right now and it has entries for every bitwise operator. I suggest you hold
down the SHIFT key and press reload to clear your browser cache.


>
> But, now that I know what to look for, I will find the rest, so
> no one offer additional help, unless they just want to.
>
> My goal is to write up a Keeper file for this.  I will post it
> back on this thread when I finish.
>
> -T
>

Re: bitwise paper?

[Trey Harris]

On Wed, Oct 3, 2018 at 13:38 ToddAndMargo  wrote:

> > Go to docs.perl6.org . Type "bitwise" into the
> > search box. You will see a popup, "Numeric bitwise AND operator". Click
> > it to be taken to
> >
> https://docs.perl6.org/language/operators#index-entry-Numeric_bitwise_AND_operator,
>
> > which will tell you the bitwise AND operator in Perl 6 is +&.
> >
> > Run the same command with +& and you will get the answer 0.
> >
> > If, on the other hand, you go to docs.perl6.org ,
>
> > and type "&" into the search box, you will see under "Infix" (since you
> > used the operator between two things, it is Infix, as the docs say if
> > you type "infix" into the search box and click the first entry under
> > "Reference"; I have no idea how you'd divine that such a thing is called
> > an infix operator aside from common programming parlance, but if you
> > have an idea how that might be expressed it can easily be added to the
> > index) that the first entry is "&".
> >
> > Click on this "&" and you are taken to https://docs.perl6.org/routine/&;
> > which rather clearly says it returns an all Junction.
> >
> > So I wonder why were you under the impression that the above "should
> > give [you]  "?
> >
> > Trey
>
>
> Thank you.
>
> Looks like I am going to have to look them up one at a time.


Just because you get to a specific place on a page by typing something into
the search box doesn't mean you can't scroll up and down on the page
anyway. You can do the same from +& and see the other operators, too.

Re: bitwise paper?

[Trey Harris]

On Tue, Oct 2, 2018 at 23:57 ToddAndMargo  wrote:

> Hi All,
>
> Does anyone know of a paper out in web land showing how to
> do bitwise operations?  DuckDuckGo give me tons of hits
> for Perl 5.
>
> Trying to AND 0010  with 0001 
>
> $ p6 'my $v = 32 & 16; say $v;'
> all(32, 16)
>
> should give me  .


"Should give you"? Why do you say that?

Go to docs.perl6.org. Type "bitwise" into the search box. You will see a
popup, "Numeric bitwise AND operator". Click it to be taken to
https://docs.perl6.org/language/operators#index-entry-Numeric_bitwise_AND_operator,
which will tell you the bitwise AND operator in Perl 6 is +&.

Run the same command with +& and you will get the answer 0.

If, on the other hand, you go to docs.perl6.org, and type "&" into the
search box, you will see under "Infix" (since you used the operator between
two things, it is Infix, as the docs say if you type "infix" into the
search box and click the first entry under "Reference"; I have no idea how
you'd divine that such a thing is called an infix operator aside from
common programming parlance, but if you have an idea how that might be
expressed it can easily be added to the index) that the first entry is "&".

Click on this "&" and you are taken to https://docs.perl6.org/routine/&;
which rather clearly says it returns an all Junction.

So I wonder why were you under the impression that the above "should give
[you]  "?

Trey

Re: need doc help with []

[Trey Harris]

On Tue, Oct 2, 2018 at 21:10 ToddAndMargo  wrote:

> If you have a free moment, speaking to "have", the diagram here
> is a work of art:
>
> https://www.freethesaurus.com/have
>
> I know there a lot of English as a second language speaker on this
> group.  The above thesaurus uses diagrams and is wonderfully
> well done.


It's nice, certainly, but I think you miss my point.

None of the words in that diagram can be used as a substitute for "$x" in
"I $x already seen that movie". There is no word in English that can be
placed there instead. "Have" in English, like [] in Perl, has some
extremely low-level purposes that are very difficult to describe in the way
we can describe most words.

Asking for a thesaurus-like explanation of those purposes is not merely
unreasonable; it's literally impossible. That doesn't mean those
definitions _should not be_ in the document; they MUST be in the document,
if it is to have any claim to being an exhaustive reference. Yet there is
no way to set forth the definition without using some abstruse terminology
that, if you look up _its_ definitions, will get you no closer to
understanding $x above.

These low-level definitions WILL confuse anyone who is merely seeking
meaning at a "common knowledge" level. Omitting them is impossible. Making
them understandable to the common-knowledge-level user of the document is
also impossible.

So including these very arcane definitions—even at the risk of confusion to
those who will look at a definition expecting to be able to understand 100%
of it on first reading—is necessary; confusing those common-knowledge
seekers is a necessary evil. The lexicographers must assume that those
learning English will learn these purposes of "have" elsewhere; otherwise
they would need to embed an entire grammar of English under the definition
of "have".

So it is for the [] postcircumfix. For those of us who have been following
Perl 6 development for 18 years, the fact that it—and almost every other
low-level particle—can be described at all in such a way is a remarkable
triumph of the language. But that cannot coexist with your desire to look
at the perl6 doc for [] and understand all of it as a non-expert Perl 6
programmer.

Trey

Re: need doc help with []

[Trey Harris]

What Curt said, but also, this is a bit like trying to understand English's
word "have" with a dictionary. No one who speaks English natively looks up
"have" in the dictionary. Anyone who does so will find definitions like,
"Used in forming the perfect aspect and the past perfect aspect." Well,
that's not very good at all, how could any common speaker be expected to
understand that? Could any fluent English speaker reverse engineer that
definition? Obviously, considering common cases like "I *have* already seen
that movie", how you _should_ write that definition is... well...

The [] postcircmfix is so low-level to how Perl (both 5 and 6) work that
squinting at its solitary definition to try to divine meaning is not
particularly useful. Eventually you will know Perl 6 well enough that this
document might be of interest to you when you're trying to implement your
own indexing or postcircumfix operator. But it's not useful for learning
what [] _does_ in practice, because it's so basic to the language that one
can only really learn it through seeing it used, or in a tutorial where it
comes up as a topic.
On Tue, Oct 2, 2018 at 20:21 Curt Tilmes  wrote:

> Remember within the few days people sent you links to read more about
> signatures?  Go read them, then re-ask any remaining questions.
>
> I can cut/paste bits from them them under each of your questions, but it
> would really be better for you to just read the existing docs and try to
> understand signatures more holistically.
>
> https://opensource.com/article/18/9/signatures-perl-6
> https://docs.perl6.org/type/Signature
> https://perl6advent.wordpress.com/2013/12/21/day-21-signatures/
>
> and some videos:
> https://vimeo.com/42051800
> https://www.youtube.com/watch?v=obYlOurt-44
>
>
> On Tue, Oct 2, 2018 at 8:14 PM ToddAndMargo  wrote:
>
>> Hi All,
>>
>> I use postcircumfix [] all the time.  But I don't
>> understand the documentation.
>>
>> https://docs.perl6.org/routine/[%20]#language_documentation_Operators
>> 
>>
>> would someone please explain what the crypto line means:
>>
>> sub postcircumfix:<[ ]>(@container, **@index,
>>  :$k, :$v, :$kv, :$p, :$exists, :$delete)
>>
>> 1  Why the <[]>?  I have always used [] with out the <>.
>> Why would I want to use one over the other?
>>
>> 2)  Where does it state that the <> is optional?
>>
>> 3)  What is a **@?  *@ is a slurp all remaining.   A
>>  super duper slurp?
>>
>> 4)  What is :$k, :$v, :$kv, :$p, :$exists, :$delete
>>  and where are they defined?
>>
>> 5)  Why does :$k, :$v, :$kv, :$p, :$exists, :$delete
>>  have colons in front of them?
>>
>> 6)  Where is the --> return described?
>>
>> Yours in confusion,
>> -T
>>
>

Re: case insensitive "contains"?

[Trey Harris]

And my response to his response that also was unintentionally off-list.

(Todd, if you don't mind resending your last private response—since your
other response was quoted below—in reply to this, please do.)

On Mon, Sep 10, 2018 at 22:00 ToddAndMargo  wrote:
> So you get to iteratively pick what the regex will be.
> I can see where this would be very powerful. Thank you!
>
> Also, really a bad idea to use in documentation
> as it "presumes" that the reader is very advanced in
> his knowledge of regex's. In which case he would
> not need to read the documentation anyway.

Pardon? I don't follow. "Really a bad idea to use" what?

Personally, I get rather annoyed when I have to sift through Yet Another
Introduction to Regexes just in order to find out how to use regexes in a
particular language or library. The documentation for a regex library
shouldn't explain regexes, if that's what you're saying. Most programmers
will be coming to any new language already knowing regexes of some sort.

I don't see what's "very advanced in... knowledge of regex[es]". Those
examples don't even use quantifiers; they're just fixed text matches with
case-insensitivity. If you find that "advanced", you should do one of the
many excellent regex tutorials available in whatever languages or
programmable editors you already know—trying to learn regexes and a new
language simultaneously will be a bit overwhelming, as regexes are a
language and practice unto themselves.

Perl 6's regex syntax is rather different from other languages' (a bit
amusingly, since in the meantime other modern languages have mostly
coalesced around adopting something close to Perl 5's), but you'll be much
better-equipped to understand them in Perl 6 if you understand them in
general first.


On Tue, Sep 11, 2018 at 18:49 Trey Harris  wrote:

> Oops— I sent the following yesterday and it somehow didn't go to the list:
>
> On Mon, Sep 10, 2018 at 19:02 ToddAndMargo  wrote:
>
>> Question, what the heck is
>>
>>   my $rx1 = rx:i/a/;
>>
>> Are they talking over beginner's heads again?
>>
>
> In the sense of "beginners to Perl", perhaps, since "rx" is familiar to
> Perl 5 programmers.
>
> Though if you search docs.perl6.org for "rx" you'll see a choice in the
> pop-down, "rx (quote)", which leads to:
>
> https://docs.perl6.org/language/regexes#index-entry-quote_%2F_%2F-quote_rx-quote_m-Lexical_conventions
>  and
> that says:
>
> ```
>
> Perl 6 has special syntax for writing regexes:
>
> m/abc/; # a regex that is immediately matched against $_
>
> rx/abc/;# a Regex object; allow adverbs to be used before regex
>
> /abc/;  # a Regex object; shorthand version of 'rx/ /' operator
> ```
>
> That entire section of the documentation is worth reading as it describes
> everything discussed in this thread.
>
> But in case it isn't clear, it just means that if you do
>
> my $result = "Juli 2018" ~~ m:i/jul/;
>
> then you'll get a match containing "Jul" as a result.
>
> It so happens in this case, when using ~~ against a literal like above,
> m// and rx// are pretty much interchangeable.
>
> But you could also do:
>
> my $pattern = rx:i/jul/;
> my $result = "Juli 2018" ~~ $pattern;
>
> and get the same result.
>
> If you tried to do
>
>my $pattern = m:i/jul/;
>
> You'll get an exception unless the $_ topic variable happens to contain a
> thing that can be regex-matched (like a string). The `m` explicitly causes
> the match to happen immediately.
>

Re: case insensitive "contains"?

[Trey Harris]

Oops— I sent the following yesterday and it somehow didn't go to the list:

On Mon, Sep 10, 2018 at 19:02 ToddAndMargo  wrote:

> Question, what the heck is
>
>   my $rx1 = rx:i/a/;
>
> Are they talking over beginner's heads again?
>

In the sense of "beginners to Perl", perhaps, since "rx" is familiar to
Perl 5 programmers.

Though if you search docs.perl6.org for "rx" you'll see a choice in the
pop-down, "rx (quote)", which leads to:
https://docs.perl6.org/language/regexes#index-entry-quote_%2F_%2F-quote_rx-quote_m-Lexical_conventions
and
that says:

```

Perl 6 has special syntax for writing regexes:

m/abc/; # a regex that is immediately matched against $_

rx/abc/;# a Regex object; allow adverbs to be used before regex

/abc/;  # a Regex object; shorthand version of 'rx/ /' operator
```

That entire section of the documentation is worth reading as it describes
everything discussed in this thread.

But in case it isn't clear, it just means that if you do

my $result = "Juli 2018" ~~ m:i/jul/;

then you'll get a match containing "Jul" as a result.

It so happens in this case, when using ~~ against a literal like above, m//
and rx// are pretty much interchangeable.

But you could also do:

my $pattern = rx:i/jul/;
my $result = "Juli 2018" ~~ $pattern;

and get the same result.

If you tried to do

   my $pattern = m:i/jul/;

You'll get an exception unless the $_ topic variable happens to contain a
thing that can be regex-matched (like a string). The `m` explicitly causes
the match to happen immediately.

Re: Functions and subroutines?

[Trey Harris]

To get directly at your question: in Perl 6, this is not an important
delineation, so there are no simple names for the two Pascal/Modula
concepts. Perl's never made a distinction between "procedures" and
"functions" in the Pascal sense; they were all just subs. Eventually Perl
gained classes and blessed objects and so we got "methods", but in Perl 5
they were just gussied-up subs.

The delineations that matter in Perl 6 are subs vs. methods vs. blocks (as
yary and Simon have said previously in the thread).

Perl allows you to do very naughty things, such as define a method that
modifies its invocant, some of its parameters, returns a result that can
indicate a failure, and throws exceptions. Doing all these things is
allowed but would almost certainly be quite unwise. But when you try to
find the 1:1 mapping of some other language's construct to another's, you
always get one of four answers:

1. There is a thing exactly like the other language's thing at the same
level of complexity using similar syntax and semantics.
2. There is a analogous thing in semantics, but it's not very similar in
syntax.
3. There is a thing that's similar in syntax, but very different in
semantics.
4. There is no thing like the other language's thing in syntax or semantics.

The issue you get into in Perl 6 is that it's _such_ a flexible language
that it pretty much never says number 4. It usually says both 2 and 3. The
old joke went that you could write FORTRAN in any language. Well, you can
write any language in Perl 6. That doesn't mean it's a good idea.

My suggestion would be: if you call it with a dot, it's a method. If you
don't, it's a sub. Whether a sub returns something or not should be obvious
from the purpose and how you name it. Whether a sub alters something or not
should also be obvious from how you call it. The signatures are different,
but the names don't matter.
On Tue, Sep 11, 2018 at 11:31 Simon Proctor  wrote:

> There are also Blocks like : my $a = do { 5 }; say $a; (Gives 5);
>
> Blocks turn up all over the place big different between blocks and
> Routines (Sub or Method) is you can't return from them. They will return
> the last thing evaluated within them though. But a return statement inside
> one raises and Expection. (Might be a Failure)...
>
> On Tue, 11 Sep 2018 at 16:24 yary  wrote:
>
>> And looking at questions in other threads- there are subroutines declared
>> with "sub", those get called without an invocant.
>>
>> sub i-am-a-sub() { say "Hi from subroutine land!" }
>>
>> i-am-a-sub; # says "Hi from subroutine land!"
>>
>> and methods are declared inside a class, and are called with an invocant
>> of that class type.
>>
>> class sample-class {
>>   method speak-to-me {say "We are classy"}
>> }
>> my sample-class $object;
>> $object. speak-to-me; # Guess what it says
>>
>> ... subroutines and methods, in the perl6 class hierarchy, are both
>> subclasses "Routine"
>> maybe that's the word your looking for!
>>
>> -y
>>
>> On Tue, Sep 11, 2018 at 8:12 AM, yary  wrote:
>>
>>> I would call them subroutines, since that's the long form of "sub"
>>>
>>> -y
>>>
>>> On Tue, Sep 11, 2018 at 3:47 AM, ToddAndMargo 
>>> wrote:
>>>
 Hi All,

 I use subs like ducks use water.  It is about time
 I learned what to properly call them.

 I come from Modula2 and Pascal (as well as bash), "functions"
 return a value outside the declared parameters and "(sub)routines"
 only can modify values through the declarations parameters.

 Sort of like
 function:   sub add($a, $b){return $a+$b}
 routine:sub add($a, $b, rw $c){$c = $a+$b}

 In Perl, what is the proper terminology?

 Many thanks,
 -T

 I no longer use "rw $c".  I always use "return".
 The guys told me this was the best way on the
 chat line, so I adopted it.

>>>
>>>
>> --
> Simon Proctor
> Cognoscite aliquid novum cotidie
>

Re: EVAL?

[Trey Harris]

Just a small stylistic thing to mention:

On Thu, Jun 14, 2018 at 1:59 AM Todd Chester  wrote:

p6
>if not $dir.IO.d.bool {}
>for  slice  "\n", $WebStr   ->  $Line { }
>
>   and on and on and so forth.  I know a lot of them by heart now.
>
By .bool, I assume you meant .Bool, but in any case, it isn’t necessary
since the context of a not forces it to be boolean.

If you want the opposite—a boolean without the sense-negation, you can use
so, but in the context of an if, it should rarely, if ever, be necessary.

In the same way that so is used to explicitly truthify, unary + is used to
explicitly numify.

E.g., once you know that an IntStr 
dual value gives a result reminiscent of Perl 5’s string numbers (except
that without going to crazy lengths, you can easily supply exactly the
number and string you want):

my $x = IntStr.new(42, "The Answer");
my $y = IntStr.new(0, "Nothing");
for ($x, $y) -> $z {
  printf "\$z: '%s', so \$z: '%s', +\$z: '%s'\n",
$z,so $z,+$z;
  say "  Double it: ", $z * 2;
  say "  or 'double' it: ", $z x 2;
}

gives results:

$z: 'The Answer', so $z: 'True', +$z: '42'
  Double it: 84
  or 'double' it: The AnswerThe Answer
$z: 'Nothing', so $z: 'False', +$z: '0'
  Double it: 0
  or 'double' it: NothingNothing

In case you’re wondering, you’ll usually have no reason to explicitly
construct a dual value like that; you generally get a NumStr or its
counterparts like IntStr when reading input or expecting command-line
arguments.

(Also note that the stringification equivalent to so and unary + is ~, but
it wasn’t necessary above since the %s template to sprintf forces
stringification. Also note that using s/printf at all is not encouraged—but
it was useful above, just to make things explicit.)
​

Re: What is P6 for P5 `use Term::ReadKey`?

[Trey Harris]

On Sat, Sep 9, 2017 at 3:55 PM ToddAndMargo toddandma...@zoho.com
 wrote:

On 09/09/2017 07:00 AM, Timo Paulssen wrote:
> > This should be enlightening: https://docs.perl6.org/routine/getc
> >
>
> Problem: also from the link:
>
>  method getc(IO::Handle:D: --> Str:D)
>  multi sub getc (IO::Handle $fh = $*ARGFILES --> Str:D)
>
> This is very frustrating to me as it mean ABSOLUTELY NOTHING
> to me.  Without an example, which the link does not provide,
> I have not the slightest idea what they are talking about.
>
So excuse my going off-topic here, but I hear your frustration and think
you’ll find it valuable to learn what you need to know to not be frustrated
rather than hoping the docs will over time get more verbose with sundry
examples for each possible use of language features (it probably won’t, for
the most part).

If you’re coming from Perl 5, which is mostly an explicit-type-less
language, or many other minimally or dynamically-typed languages, these
cryptic lines *can* be frustrating; learning-by-example is usually the best
way to “grok” a feature intuitively.

I think it’s important to learn to read them, rather than simply ask for
examples (as drove most of the P5 perldoc for builtins). To explain why: in
Haskell, a language which greatly influenced Perl 6, the type declarations
alone are often all the Haskell programmer needs to fully understand a
function; prose or examples are entirely superfluous. The power of well-
and expressively-typed routines for documentation is inarguable in
efficiency, precision, and concision. The downside is the necessary
investment in overcoming the learning curve required to read them.

To return to the lines that frustrated you, let’s try to make them
understandable—or, at least, make them mean more to you than “ABSOLUTELY
NOTHING”. :-)

Let’s start at a high level:

method getc(IO::Handle:D: --> Str:D)  # L1
multi sub getc (IO::Handle $fh = $*ARGFILES --> Str:D) # L2

You see getc defined twice here; they’re each distinct code (that are
documented once because they do much the same thing) due to their
*declarators*.

L1 is an “ordinary method” (denoted, obviously enough, with the declarator
method), which as described in the Typesystem
 doc, “defines objects
of type Method  and binds them to the
provided name in the scope of a class.” An ordinary method is usually
called using dot syntax, i.e., $object.getc(...).

L2 is a “multisub”, that is, a sub handled via “multi-dispatch” (in most
languages with the concept, called multimethod dispatch). Multi-dispatch
allows a single routine name to refer to different code (“polymorphism”) on
axes other than the traditional object-oriented paradigm of “invocant” to
include number, type, definedness, and even value of arguments at call
time. (In this case, there being only one, it may seem superfluous, but it
allows for other modules to introduce getc variants of their own without
having to invent new names or muck about with namespaces.) Being a sub, it
will be called most often using normal sub-calling syntax, such as getc($x).

Now let’s turn to the *return values,* which are what functional
programmers are usually looking at first. They’re marked by --> (though
some old documentation may use returns). Conveniently, both variants L1 and
L2 return the same thing (not uncommon, for multi routines): Str:D. The Str
part is a reference to the string type Str .
The :D suffix says that the value is *defined*; in other words, getc will
never return the undefined value. (A :U suffix would indicate that the
return is always *undefined*; the default, a lack of any suffix, can be
made explicit with :_, and means—as in Perl 5—that the return might or
might not be defined.)

That gets you to the *arguments* of the two variants. Each are *unary;*
they take just one argument.

(In the case of the method, its arity depends on your definition of the
invocant being an argument; if you subscribe to the view that a method’s
invocant doesn’t count, then method getc is a nullary, taking no argument.
But the view that the invocant counts as an argument is useful here, so
let’s use that definition, making the two both unary routines.)

Both routines’ single argument is of type IO::Handle. They also both
require definedness, but in different ways. The method uses the :D suffix
we’ve already seen; in effect, that allows $my-handle.getc to work provided
$my-handle has been set to a defined IO::Handle object. But if the variable
was declared with my IO::Handle $my-handle; but never assigned to,
$my-handle.getc will not work; neither will IO::Handle.getc (which would
work if :D weren’t included in the signature; one way of getting “class
methods” in Perl 6 is to create methods with :U invocants).

The multisub L2 also requires definedness, but does it in a different way.
The IO::Handle $f

Re: Startup performance on OS X

[Trey Harris]

That is really lovely. I don’t know what criteria are used for Rosetta
Code, but the article’s implementation is the clearest “program as concrete
explication of algorithm” I’ve ever seen. It took me *years* to understand
RSA’s internals to the point that I could explain it if asked to in an
interview, but I suspect if I’d had that code as my example I’d have just
gotten it.

It’s hard for me to be certain because I *do* know the algorithm now, of
course. But from Damian’s YAPC keynote and looking at the primality tests
and whatnot, I suspect my intuition is right—but for the hyperoperators,
which are certainly a bit difficult for folks who haven’t done much
functional programming or MapReduce-type programming, Perl 6 is some of the
niftiest pseudocode I’ve ever seen. That it *runs* is just gravy. :-)

On Mon, Oct 3, 2016 at 11:03 AM Patrick R. Michaud pmich...@pobox.com
 wrote:

On Mon, Oct 03, 2016 at 04:26:10PM +0200, Elizabeth Mattijsen wrote:
> > > On 02 Oct 2016, at 11:00, Thor Michael Støre 
> wrote:
> > > Is this normal startup performance?
> >
> > https://www.promptworks.com/blog/public-keys-in-perl-6
> >
> > I wonder what would be needed to run this in Perl 5, module wise, and
> CPU wise.
>
> This also seems like an interesting task for Rosetta Code (the RSA key
> generation part).
>
> Rosetta Code already has an entry for RSA encryption/decryption in Perl 6
> (but not Perl), but I'm wondering if the article's version is better than
> Rosetta Code's existing Perl 6 entry.
>
>http://rosettacode.org/wiki/RSA_code#Perl_6
>
> Pm
>
​

Re: what should be the default extension?

[Trey Harris]

In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:
Yet, does my proposal *force* this? Is it not possible for the magical 
resource locator to coexist with a mechanism to allow local control?


Yes--through C blocks and munging, you can get whatever 
complicated, platform- or machine- or configuration-dependent behavior you 
desire.  But the *declarative* core structure of Perl should be 
platform-indepedent.  There shouldn't be anything in the language to 
facilitate non-portable code, except just what is necessary to make 
programs work given the reality of the existence of different platforms. 
I think we have that already.



But what about
#use GetUserResponse in 'smpl_ui.pm'; # when debugging
use GetUserResponse in 'our_gui.pm';


Compile-time directives work better for that anyway.  (You can have a 
BEGIN block that checks an environment variable, so you don't have to edit 
the code, or you can have "smpl_ui.pm" in a standard directory and in a 
debug/ directory, and can just arrange to reorder @INC as necessary.)


True. Yet this implies all Perl programmers write for platform independence. 
My experience has been that when I was using perl under windows, I had to use 
ppm made available by ActiveState. Whereas for Linux, I could use CPAN 
directly. This indicates a conversion procedure and rules of best practice 
for software whose authors want it to be used cross-platform.


ppm versus the CPAN shell is a development environment difference, which 
will always differ to some degree from platform to platform.  We're 
talking about *code* here, which should strive to be portable until it's 
really necessary to be otherwise.


"Here's standard Perl--which won't work on $SOME_OS unless you add this 
voudou" is somewhere we don't want to go.  We want it to be easier to 
write portable code than not.


Trey

Re: what should be the default extension?

[Trey Harris]

In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:


May I suggest the following extension to the 'use ' pragma, viz.
use  in constrained by local system>


Oh please, no.

The entire point of the wording currently in the synopsis is so that we 
can have platform-independent location of libraries.  The "name mangling 
capability" hypothesized lets the same C get the requested resource, 
regardless of the file (or database location!) where the resource is 
actually located on the platform running Perl.


Your proposal would force us to have platform-dependent locations, and 
hence platform-dependent programs.  Do you really want to see dozens of 
switches like


  given $?OS {
 when m:i:/win/ { use Foo in WinFoo.pm }
 when m:i:/nix/ { use Foo in UnixLikeFoo.pm }
  }

at the top of programs?

The broken operating system, or rather family of systems (and I converted 
away from them about three years ago), still is used by 90% of users. In 
practice, it does matter what happens in that environment.


Yes--but better for implementators to make that decision than for each and 
every Perl programmer (most of whom will have no experience with most OS's 
Perl runs on, so will be making such decisions blind!) to make them 
separately (and differently).


But also consider, whatever operating system is in use, it has to know how by 
default to handle a file - interpret it as a script, run it as a native 
executable, pipe it to an editor or renderer etc. That information has to be 
associated with the file in some way. One operating system uses name 
extensions, another looks at the first line for a #! etc.


Personally, I find it useful to have a visible clue in the name (via an 
extension) as to the content of the file. This seems to me more widespread 
than just an OS requirement, as otherwise why have *.tar *.tar.gz *.pdf *.doc 
*.png etc or even .* for hidden files in unix?


The .tar, etc., are typically named for transport, where you may need to 
know the filetype without having the benefit of its contents for 
examination.  *.pdf and *.doc are filetypes that did not exist until after 
Windows did, and so the required-extension behavior ossified.  The .* 
convention merely came about because it was a convenient kludge put into 
ls for the purpose.


By way of illustration,
   % mv foo.png foo.jpg
does not convert the file's image type.  If it did (or if it refused to do 
the move) you'd have an argument there.


If it doesnt matter - as far as perl6 is concerned - how the module is named 
(see Larry Wall's response regarding unicode and case-sensitivity), then the 
extensions too are irrelevant, no? So if I choose to call my perl6 scripts 
*.p6 it should not matter? Other than for the sake of tradition or conformity 
with the tribe's sense of propriety :)


Sure, knock yourself out.  Call it ".perl6" if you like, or 
".niftynewlanguagethatisn'tquitecompatiblewith.pl" (except those violate 
eight.3 rules).


And that brings me to another question. Should it matter what the name of the 
file is? For modules in perl5 as far as I can discern, the name of the module 
in the file name has to conform with the package name inside the script. I 
have found this default behaviour annoying at times.


To do otherwise is to again require platform-dependence.  If you truly 
want to force it, load the code manually with C in a C 
block.


By extending the 'use' pragma to include information about which container it 
can be found in, filenames become truly irrelevant.


Quite to the contrary--they become much more relevant.

Moreover, the initiation file for a large project might just be a 
configuration file containing all the module names, together with "use 
Main  in ProjectDebugStage.v03"


And that configuration file would be a huge comb of $?OS and $?OSVER 
switches in a typical platform-independent development.  And even so, the 
whole thing would be far more brittle than the automatic-location system 
we have today, as problematic as it is (not very, actually...).


Trey

Re: pugs bugs (or features?)

[Trey Harris]

In a message dated Fri, 7 Sep 2007, Wim Vanderbauwhede writes:


On 07/09/2007, Chas Owens <[EMAIL PROTECTED]> wrote:
Even

if strict weren't in effect this code should not work since the $x in
the closure is not the one created after the closure:

perl -le 'my$r=sub{print $x+1};my $x = 2;$r->()'

That Perl 5 code prints 1 because undef plus one is one.



I am sorry, but if you put it in a script that Perl 5 code prints 3:
[wv]$ cat test_softref.pl
my $r=sub {print $x+1,"\n" };
my $v='x';
$$v=2;
&$r();
[wv]$ perl test_softref.pl
3
[wv]$


Putting it into a script isn't all you changed.  As your filename implies, 
you're using a symbolic reference (sometimes called a "soft" reference) in 
this Perl 5 code.  Your Perl 6 doesn't have any symbolic references. 
Your Perl 6 closure refers to a variable, $x, that has not yet been 
declared, which is illegal; the fact that there is a $x by runtime is 
irrelevant.  Perl (5 or 6) is not Tcl; it is compile time that matters for 
variable binding, not runtime (unless you specifically delay the binding 
somehow to runtime).


Trey

Re: Trying to use Perl5 modules

[Trey Harris]

In a message dated Mon, 11 Sep 2006, Richard Hainsworth writes:
I am trying to find out how to use (in perl6) perl5 modules that contain 
subroutines.


Imports from Perl 5 modules don't currently work.

You can workaround this using .can, see below.


use perl5:Time::gmtime;

my $gm = gmtime();
printf "The day in Greenwich is %s\n",
(qw(Sun Mon Tue Wed Thu Fri Sat Sun))[ $gm.wday() ];
# note the change from -> to .


  use v6-alpha;
  use perl5:Time::gmtime;
  our &gmtime := Time::gmtime.can('gmtime');

  my $gm = gmtime();
  say "The day in Greenwich is {()[ $gm.wday ] }";

There is no printf.  You can use a string closure as above, or 
say/print with sprintf.


The same goes for your other example:


use perl5:Text::Balanced qw(extract_tagged);

my $txt = 'now and thensome text';

my @ret_pars = extract_tagged($txt); # this is line 8

print join("\n",@ret_pars),"\n";
#print "[EMAIL PROTECTED]" if $@;
# commented this out as caused a compile error, probably another
# variable should be used for errors.


  use perl5:Text::Balanced;
  our &extract_tagged := Text::Balanced.can('extract_tagged');

  my $txt = 'now and thensome text';

  my @ret_pars = extract_tagged($txt); # this is line 8

  .say for @ret_pars;
  say $! if $!;


$@ is no more, it's $! for all errors whatever their provender.  In this 
case there's no need for a join, but you could have written it:


  say @ret_pars.join("\n");

if you liked.

All that said, there's a problem with Text::Balanced running under pugs; 
@ret_pars is reversed from what it should be.  I'm not sure what's going 
on.


Trey

Re: the CGI.pm in Perl 6

[Trey Harris]

In a message dated Sat, 9 Sep 2006, Mark Stosberg writes:

I do share your sentiment that CGI.pm shouldn't be a clone of how P5
works. I'd like the HTML building methods to stay out, which wasn't even
one of the differences you cared about yourself.


I agree with the sentiment, but as a practical matter, not having HTML 
methods in CGI.pm could drastically limit Perl 6 adoption.


If Perl 5 programmers get used to how they can mechanistically port their 
programs to Perl 6, they will do so with the same sort of "ah-hah" moments 
you've posted about on the Pugs blog, and it will be a good experience.


In other words, if they can port at a very low level (more like 
paraphrasing a complicated text for a child than like translating from 
Chinese to English) they won't feel that *everything* has changed under 
their feet, and over time they'll start to nibble at more advanced 
features, and before long they'll be translating automatically rather than 
paraphrasing mechanically.


But the HTML methods are used everywhere.  And the more novitiate the 
programmer, the more likely they are to be using them spaghetti-like 
throughtout their code. If they discover that every time they see a 
C it's going to entail new coding, they're going to rapidly 
get discouraged about porting to Perl 6.


I'd suggest that perhaps a more workable solution is to just buck up and 
accept that the HTML methods have to get ported along with the rest of 
CGI.pm, but put them into a separate distribution and have documentation 
in Differences and its successors that say something like:


  was: use CGI ':standard';

  now: use CGI;
   use CGI::HTMLgenerators; # Available separately, deprecated

perhaps with some scary-sounding warnings about how you should only use 
the latter if you have lots of preexisting code needing the generators, 
that it's better to use these other good solutions, you may shoot your 
eye out, etc. etc.


I know I seem to veer from wanting everything to change to wanting nothing 
change, but it really comes down to whether the changes will not just be 
good for us in an eat-your-spinach kind of way, but will lead to a more 
pleasant programming experience as well.  Adoption of Perl 6 will depend 
on whether programmers like it, regardless of how stable or 
beautifully-architected its systems are.


Trey

Re: the CGI.pm in Perl 6

[Trey Harris]

In a message dated Sat, 9 Sep 2006, Mark Stosberg writes:

I do share your sentiment that CGI.pm shouldn't be a clone of how P5
works. I'd like the HTML building methods to stay out, which wasn't even
one of the differences you cared about yourself.


I agree with the sentiment, but as a practical matter, not having HTML methods 
in CGI.pm could drastically limit Perl 6 adoption.


If Perl 5 programmers get used to how they can mechanistically port their 
programs to Perl 6, they will do so with the same sort of "ah-hah" moments 
you've posted about on the Pugs blog, and it will be a good experience.


In other words, if they can port at a very low level (more like paraphrasing a 
complicated text for a child than like translating from Chinese to English) 
they won't feel that *everything* has changed under their feet, and over time 
they'll start to nibble at more advanced features, and before long they'll be 
translating automatically rather than paraphrasing mechanically.


But the HTML methods are used everywhere.  And the more novitiate the 
programmer, the more likely they are to be using them spaghetti-like 
throughtout their code. If they discover that every time they see a 
C it's going to entail new coding, they're going to rapidly get 
discouraged about porting to Perl 6.


I'd suggest that perhaps a more workable solution is to just buck up and accept 
that the HTML methods have to get ported along with the rest of CGI.pm, but put 
them into a separate distribution and have documentation in Differences and its 
successors that say something like:


  was: use CGI ':standard';

  now: use CGI;
   use CGI::HTMLgenerators; # Available separately, deprecated

perhaps with some scary-sounding warnings about how you should only use the 
latter if you have lots of preexisting code needing the generators, that it's 
better to use these other good solutions, you may shoot your eye out, etc. etc.


I know I seem to veer from wanting everything to change to wanting nothing 
change, but it really comes down to whether the changes will not just be good 
for us in an eat-your-spinach kind of way, but will lead to a more pleasant 
programming experience as well.  Adoption of Perl 6 will depend on whether 
programmers like it, regardless of how stable or beautifully-architected its 
systems are.


Trey

Re: cperl-mode.el: twigils and opers

[Trey Harris]

In a message dated Mon, 4 Sep 2006, Steffen Schwigon writes:

First you could try an older revision, I recommend r7845 or r10822 of
pugs repository.


No, neither of those work.  To see what I'm talking about, just create a 
file containing:


use v6-alpha;

class Point {
has $.x;
has $.y;
}

and try creating more code under the "has $.y" line, and notice that 
indenting and highlighting after that point don't work because emacs 
thinks it's in the middle of a y///.



Second, there are known issues with two, hm, how to say?, "different
highlighting models" that seem to rival each other. Bind a key to
re-fontify and see what happens. In my emacs config I use

 (global-set-key [f3] 'font-lock-fontify-buffer)

and pressing f3 corrects the wrong highlighting. I don't know why
that's the case. Dark Ages are calling.


No, that doesn't help either, at any of rHEAD|r10822|r7845.


*Maybe* a clear fork away from the original cperl-mode would make
sense. We could refactor with the help of other lisp coders and throw
away backwards compatibility issues we don't know about. But it's a
very big "maybe". Having one mode for all perl versions and for both
major Emacs variants with high backwards compatibility is a big plus
and there is much knowledge in original cperl-mode that progresses
itself, even as we speak. Currently I wouldn't fork it.


Well, a fork for cperl6-mode wouldn't be the worst thing... at least then 
it would be possible to have working syntax highlighting and indention for 
Perl 6.  Right now I'm reduced to either turning off cperl-mode or 
choosing my attribute names based on what Emacs can deal with, both of 
which are maddening.



BTW, I work with XEmacs 21.4.7.
What's your Emacs?


XEmacs 21.4.14 and Emacs 22.0.50.1 (Aquamacs).  Both show the same 
behavior in this case.


Trey

cperl-mode.el: twigils and opers

[Trey Harris]

This has been driving me mad, and an hour of hacking at cperl-mode.el has 
only convinced me that I don't know elisp well enough to solve the 
problem


Variables with twigils whose name matches something else are getting 
recognized incorrectly.  For example, $.x is getting interpreted as $. 
followed by the x operator, $.system as $. and system, and so on.  Worst 
of all are $.s, $.y, $.q and so on, because emacs is looking for the 
closing quote, wrecking all the syntax highlighting and indention from 
then on.  It also appears that @.foo and %.foo aren't being interpreted 
correctly either, even when foo doesn't match anything else.


This observation is of the cperl-mode.el from the pugs repository.

Can anyone help fix cperl-mode with twigils?

Trey

--