Performance of matrix arithmetic in Raku

[Parrot Raiser]

There's a post online comparing Python's performance of matrix
arithmetic to C, indicating that Python's performance was 100x (yes, 2
orders of magnitude) slower than C's.

If I understand it correctly, matrix modules in Raku call GNU code
written in C to perform the actual work.

Does that make Raku significantly faster for matrix work, which is a
large part of many contemporary applications, such as AI and video
manipulation? If it does, that could be a big selling point.

Re: Multiline/embedded comments

[Parrot Raiser]

> On 12/22/20, Vadim Belman  wrote:
>>
>> You interpret it incorrectly. The problem is in your '#`{' comment

On 12/23/20, Parrot Raiser <1parr...@gmail.com> wrote:
> Removing the space between the #` and { changes the error message to:
>
> ===SORRY!=== Error while compiling /home/guru/bin/comment_test
> Couldn't find terminator } (corresponding { was at line 12)
> at /home/guru/bin/comment_test:19
> --> ⏏
> expecting any of:
> }
>
> Should the parser not ignore anything between the start of the comment
> and the corresponding right-hand end, regardless of what is inside,
> whether it looks like code or not? Obviously, it has to go through the
> text to find the matching end character, but should it be looking for
> pairs inside? If it would be unreasonably difficult to change the
> mechanism, then it needs to be described.
>
> A note in the documents about the significance of whitespace after the
> backtick would be good.  I'd suggest changing the second line of the 
> definition from:

"bracketing character, and end with the matching closing bracketing
character. Only the paired "

to read:

bracketing character, and end with the matching closing bracketing
character.  Whitespace is not permitted between the backtick and the
bracketing character; it will be treated as a single-line comment.
Only the paired...

If the internal pairing is to be required, I suggest the line in the
last paragraph be changed from:

"until the very end of the string. You may also use multiple curly braces.."

to read

until the very end of the string.  If the opening bracketing character
occurs in the body of the comment, e.g. #`[ This is a box [ of stuff ]
], it must have a paired closing character, as shown. You may also use
multiple curly braces...

Multiline/embedded comments

[Parrot Raiser]

While playing around with the bounding characters for the #` form, I
encountered an unexpected feature, which may or may not be a bug. If
the left bounding character (e.g. the { in #`{ occurs unbalanced in
the commented text, the compiler apparently treats it as code,
searches for the right bounder, and generates an error if it can't
find one. e.g.

 1 #! /home/guru/bin/raku
  2
  3 #  comment_test
  4
  5 #  Input
  6 #  Purpose of program - test multi-line comments
  7
  8 #`(
  9  put " () fails";
 10 )
 11
 12 #` {
 13  put "\{ fails";
 14 }
 15
 16 put "Done";
 17
 18 # End comment_test Last changed: 2020-12-22 19:40:07

produces

===SORRY!=== Error while compiling /home/guru/bin/comment_test
Unexpected closing bracket
at /home/guru/bin/comment_test:14
--> ⏏}

Removing the escape \ on line 13 generates a different but related error.

Is this a limitation that should be mentioned in the description of
the form, or the compiler mistakienly working on something it's just
been told to ignore?

Rakudo update due?

[Parrot Raiser]

The current version of Rakudo* is 2019.03, which makes it 5 months old.
Is there likely to be an update soon? (The underlying compiler seems
to have had a few fixes.)
 (No pressure, I just want to stay as up-to-date as possible.)

Diagnostics?

[Parrot Raiser]

I've been fiddling with multi-line comments and the bounding
characters. Naturally-paired characters  e.g. #`(...)  #`[...] #`{...}
all work well, but with other boundary characters like #`@@ or
#`!! produce odd, displaced, diagnostic messages. Reproducing them
is so easy, I'll leave it as "an exercise for the reader".

If unpaired boundary characters like these are legal, presumably
there's a problem with the parser or compiler?
If they aren't, maybe a) the docs should be more explicit, and b), the
diagnostics should say so, immediately?

perl6 -v
This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03

Re: "put" vs "say"

[Parrot Raiser]

Thanks for the suggestions. I ran a couple of tests:

my $data_list = 1..1001;
say $data_list;

produces
1..1000

real0m0.357s
user0m0.435s
sys 0m0.048s

my $data_list = 1..1001;
put $data_list;

produces the list of integers from 1 to 1001 (obviously a single string).


real0m0.470s
user0m0.452s
sys 0m0.058s

Changing the list to an array,

say produces
[1 2 3 4 5 6 () 98 99 100 ...]

real0m0.435s
user0m0.484s
sys 0m0.056s

put result is unchanged in

real0m0.424s
user0m0.445s
sys 0m0.068s

Further research is clearly required, as all good research reports say.

On 10/21/18, Timo Paulssen  wrote:
> put is meant for machines, while say is meant for humans.
>
> this is implemented by having say call the .gist method and put calling
> the .Str method.
>
> Try using say and put on a list of a thousand elements or more and
> you'll see what I mean.
>
> HTH
>   - Timo
>
> On 21/10/2018 18:29, Parrot Raiser wrote:
>> "put" and "say" seem to be redundant, but I'm sure there's a good
>> reason for having 2 output commands.
>>
>> Would anyone care to comment on how they differ and why, or point to
>> an explanation?
>

"put" vs "say"

[Parrot Raiser]

"put" and "say" seem to be redundant, but I'm sure there's a good
reason for having 2 output commands.

Would anyone care to comment on how they differ and why, or point to
an explanation?

Re: $? and $! equivalents

[Parrot Raiser]

OK, different paradigm, different methods.

Thanks.

Another couple of entries for the "differences" list? Even a note the
thing doesn't exist saves fruitless further searching.

On 9/14/18, Brad Gilbert  wrote:
> On Fri, Sep 14, 2018 at 5:08 PM Parrot Raiser <1parr...@gmail.com> wrote:
>>
>> This is probably going to be a forehead-slapper, but I can't find a
>> reference in either perlintro.com or http://docs.perl6.org/
>> (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
>> P6.What are they?
>>
>> I want to be able to "run" or "shell" programs, then examine return
>> codes and errors. (The immediate case is to see if a program name is
>> already in use by running  "which $progname". )
>
>my $proc = run , :out, :!in;
>say $proc.out.slurp;
>say $proc.exitcode;
>

$? and $! equivalents

[Parrot Raiser]

This is probably going to be a forehead-slapper, but I can't find a
reference in either perlintro.com or http://docs.perl6.org/
(5to6-perlfunc or top-down)  for the equivalents of $? and $! in
P6.What are they?

I want to be able to "run" or "shell" programs, then examine return
codes and errors. (The immediate case is to see if a program name is
already in use by running  "which $progname". )

Re: 3 kinds of yadda

[Parrot Raiser]

> Bash is treating ! as the history substitution character, and either erroring 
> out or substituting a previous command line.

Thanks; that struck me between the time I hit send and got confirmation. :-)*

3 kinds of yadda

[Parrot Raiser]

There are 3 kinds of yadda, yadda operator:

!!! dies with a message: Stub code executed
  in block  at yad1 line 2

... dies with an identical message

??? produces the message, but continues operating.

The only difference I can find between !!! and ... is that !!!
produces bizarre behaviour  when run from the command line.
(Bash appears to be interpreting !! as "rerun the previous command",
even when quoted.)

What is supposed to be the difference between !!! and ...?

3 kinds of yadda

[Parrot Raiser]

There are 3 kinds of yadda, yadda operator:

!!! dies with a message: Stub code executed
  in block  at yad1 line 2

... dies with an identical message

??? produces the message, but continues operating.

The only difference I can find between !!! and ... is that !!!
produces bizarre behaviour  when run from the command line. (Bash
appears to be editing the code before P6 sees it.)

What is supposed to be the difference between !!! and ...? (And bonus
points if you can explain what bash is doing.)

Reading documentaion offline?

[Parrot Raiser]

What's the simplest way of downloading current language documentation
for reading offline?

Best practices?

[Parrot Raiser]

What would be the criteria for deciding whether to name P6 constants
using  lower-case or UPPER_CASE names?

Generally,  system constants and variables use upper-case, so
lower-case keeps user variables in a separate name space. Do
user-defined constants belong there, or in upper-case to indicate that
they are global?

Apologies in advance if this starts a vicious ideological conflict.

Re: Naming debate- what's the location for it?

[Parrot Raiser]

On 2/10/18, Darren Duncan  wrote:

> I think if we want to keep "Perl" in the name we should use "C" as a 
> precedent.
> Other related languages keeping "C" include "Objective C", "C#", "C++",
> >

Perl++ would work.

Re: Naming debate- what's the location for it?

[Parrot Raiser]

Looking at possible candidates from a search-engine results and
alternative manings test. some possible choices:
 Mu,  (the root object class),
Camelia, (the spokesbug taking over),
Shesh, (the female form of 6 in Hebrew, but unfortunately also in the
Urban Dictionary - look it up for yourself).



On 2/9/18, Steve Pitchford  wrote:
> Well, for what it's worth, as an outsider - IMHO, leaving "perl" behinds a
> good thing. Love it or loath it, we live in a js/python/jvm leaning world.
> Perl was great, but it's dated. Why have the baggage? Rakudo is a new
> language. Treat it as such - best hope for it. In layman's terms an
> informal "Perl V2", ridiculous as that may be to the community.
>
> Steve
>
> On 8 Feb 2018 10:18 pm, "Darren Duncan"  wrote:
>
> My personal favorite resolution is to officially name the language Rakudo,
> full stop.
>
> The implementation that was/is using the name would be renamed to something
> else so it isn't the same as the language.
>
> Then we say "Rakudo" is a sibling language of "Perl", full stop.
>
> Then "Perl 6" becomes a deprecated alias for Rakudo, used informally rather
> than formally from now on, and officially considered a historical footnote
> rather than anything still cited in official documentation or marketing.
>
> The unqualified name "Perl" continues to refer to the original lineage
> (currently at version 5.x) such as what 99% of the world means when they
> refer to it.
>
> Remember, we can still say "Rakudo is a sibling of Perl" for all the
> reasons we currently do without actually calling it any kind of "Perl" as
> an individual; we don't actually lose the family thing.
>
> For documentation/marketing materials and to help with continuity, we can
> typically reference "the Rakudo language, a sibling of Perl", where the
> latter part is then more of a description.
>
> This is what I really think should and that I would like to happen.
>
> -- Darren Duncan
>
> On 2018-02-08 12:47 PM, yary wrote:
>
>> ...and "rakudo" even better by that criterion. And then there's how
>> "rakudo" is already named in many files, databases, websites, and that's
>> enough to make me think it's a "good enough" name. Though I'd like to
>> change that implementation's name to something else if we start calling
>> the
>> language Rakudo!
>>
>>
>> I quite like having the distinction between the language and its
>> implementations. No one confuses C with cc, gcc, pcc, tcc, mvcc, XCode,
>> or
>> Borland. Using the name "rakudo" to mean the language makes me feel a
>> little bad in that it muddies that distinction further, and gives this
>> current implementation a special status. A status which it earned, we're
>> not talking about calling the Perl6 language "pugs" or "parrot" or
>> "niecza"
>> for a reason. /me shrugs.
>>
>

Documentation for error messages

[Parrot Raiser]

Where's the best current description of error messages from file
"open" commands, and how to control them?

(I'm thinking of things like the effect of adding "\n" to "die" messages in P5.)

Re: Is this a bug?

[Parrot Raiser]

It may make it clearer if I explain the broader objective. I'm trying
to learn P6 thoroughly by developing training courses to teach it from
scratch. (Fans of Gerald Weinberg may recognise the idea.) Obviously,
while doing so, I want to explore pathological cases, both to clarify
the concepts and to anticipate the mistakes that students might make.
Sometimes, it's necessary to do so to resolve ambiguities in whatever
sources are available.

The language is far too deep and complex to absorb in one pass, and
contains a great deal which is of interest to advanced system software
developers, but not to someone who just wants to do some simple
processing or file manipulation. My aim is to develop a series of
successively deeper courses, each of which will be complete within
itself. The first level is procedural. O-O is the next.

Topics should proceed logically from the basics, each building on the
previous, without having to drag in extraneous topics or diversions.
(Examples should not require forward references or bouncing around in
the text.) That's why I don't want to introduce .say at this stage, if
I can help it.

On 9/18/16, Trey Harris <t...@lopsa.org> wrote:
> On Sun, Sep 18, 2016 at 16:49 Parrot Raiser <1parr...@gmail.com> wrote:
>
> say { $_ } was the correct thing to use there. (I'm trying to avoid
>> any mention of O-O for the moment.)
>>
> “Trying to avoid any mention of O-O” seems like a Perl 6 obfuscation or
> golf constraint, not a desirable development or learning goal. Perl 6
> doesn’t *force* you to write programs in an object-oriented style; you can
> do it in functional or procedural or whatever style suits you. But you’re
> going to have a bad time if you try to deny Perl 6’s fully OO nature. This
> is in stark contrast to Perl 5, where OO was bolted on, and you could say
> that the non-OO core was more “real” than the object-oriented sugar found
> in modules you had to use.
>
> Writing something like say($_) for reverse lines — which is what I think is
> closest to what you wanted — isn’t any more or less “object-oriented” than
> the more idiomatic .say for reverse lines;. In Perl 5, some rather
> byzantine rules governed the use of the implicit $_; almost all of the
> convenience afforded by those rules can be gained through the use of
> topicalized objects, so the byzantine rules are gone — but the convenience
> is gone too unless you’re willing to use the topic in the .foo style.
>
> I think perhaps you see a dot, and dot signifies OO, so the .say... version
> might *look* more OO than the say(... version in some sense, but that’s
> pretty much cosmetic. You’re *using* some objects by interacting with the
> Perl 6 core either way. It’s your choice not to write your logic in an OO
> style, but you can’t prevent OO from happening during execution.
>
> (This really isn’t some half-hearted attempt to force you into OO through
> the backdoor; you really can skip OO for all *your* logic. You just can’t
> pretend you’re not using an object-oriented language when you have to touch
> code you’re not in control of, whether an OO library or the Perl 6 core.
> But pretty much the entirety of what you need to know about OO if you
> choose to do that is various syntax and some desiderata about the calling
> semantics.)
>
> say {} was a "what happens if I do this" exercise.
>>
>> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
>>
>> On 9/18/16, Brent Laabs <bsla...@gmail.com> wrote:
>> > Remember you can call a block with parentheses:
>> >
>> >> say { 11 + 31 };
>> > -> ;; $_? is raw { #`(Block|140268472711224) ... }
>> >> say { 11 + 31 }();
>> > 42
>> >
>> >
>> > On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen <l...@dijkmat.nl>
>> > wrote:
>> >
>> >> I think you want:
>> >>
>> >>   .say for reverse lines;
>> >>
>> >> not sure what you are trying to achieve otherwise, but:
>> >>
>> >>say { }
>> >>
>> >> producing something like
>> >>
>> >>-> ;; $_? is raw { #`(Block|170303864) … }
>> >>
>> >> feels entirely correct to me.   :-)
>> >>
>> >>
>> >> Liz
>> >>
>> >> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
>> >> >
>> >> > This code:
>> >> > 1 #! /home/guru/bin/perl6
>> >> > 2
>> >> > 3 # Ask for some lines and output them in reverse
>> >> > 4 # Work out the appropriate EOF symbol for the OS
>> >> > 5
>> >> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
>> >> > 7
>> >> > 8 say "Please enter some lines and end them with $EOF";
>> >> > 9
>> >> > 10 say { for reverse lines() {} };
>> >> > 11
>> >> > 12 # End
>> >> > produces this:
>> >> > Please enter some lines and end them with CTRL-D# obviously from
>> >> line 8
>> >> > -> ;; $_? is raw { #`(Block|170303864) ... }#
>> >> > but
>> >> this?
>> >>
>> >>
>> >
>>
> ​
>

This seems to be wrong

[Parrot Raiser]

This code:
#! /home/guru/bin/perl6

# Ask for some numbers from 1 - 7
# and verify that they are in range

my @names = < fred betty barney dino wilma pebbles bamm-bamm >;

my @inputs = lines();

for @inputs {
if $_ ~~ 1..7 {
say @names[$_-1];
}
else {
   say "$_ out of range 1..7";
}
}

# End

Works for single-digit values:
7
3
8
2
1
0
4
bamm-bamm
barney
8 out of range 1..7
betty
fred
0 out of range 1..7
dino

but seems to have a problem with larger numbers:

7
3
21  <- This
2
1
0
4
bamm-bamm
barney
(Any)  <--- Produces this
betty
fred
0 out of range 1..7
dino

(Usage adopted from http://tinyurl.com/hd2bxyv ; am I misreading that?)

Is this a bug?

[Parrot Raiser]

This code:
1 #! /home/guru/bin/perl6
2
3 # Ask for some lines and output them in reverse
4 # Work out the appropriate EOF symbol for the OS
5
6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
7
8 say "Please enter some lines and end them with $EOF";
9
10 say { for reverse lines() {} };
11
12 # End
produces this:
Please enter some lines and end them with CTRL-D# obviously from line 8
-> ;; $_? is raw { #`(Block|170303864) ... }# but this?

Re: Justification for the "reversed" instruction format

[Parrot Raiser]

There is a "flip" in P6, to reverse the characters in a string, and a
"reverse", to return the elements of a list. Would either of those be
an equivalent?

On 9/6/16, Trey Harris <t...@lopsa.org> wrote:
> There’s a very common functional programming pattern, usually called flip;
> its implementation in Haskell is simply:
>
> flip   :: (a -> b -> c) -> b -> a -> cflip f x y =  f y x
>
> Getting the same behavior out of a bespoke function in Perl 6 would be easy
> for any particular case, but writing a general version of flip that would
> work universally with all binary operators would be a pain to get right
> (while maintaining *exactly* the same behavior and errors as the original
> in all conditions), wouldn’t it?
>
> If so, R is syntactic sugar, but very helpful syntactic sugar.
>
> On Tue, Sep 6, 2016 at 12:59 PM Aaron Sherman <aaronjsher...@gmail.com>
> wrote:
>
> Oh, and note that you can pass R'd reductions as if they were normal prefix
>> ops:
>>
>> $ perl6 -e 'sub dueet(, *@list) { op @list }; say dueet
>> :<[R-]>,
>> 1..100'
>> -4850
>>
>>
>>
>> On Tue, Sep 6, 2016 at 12:51 PM, Aaron Sherman <aaronjsher...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> $ perl6 -e 'my @numbers = 1..100; say [-] @numbers; say [R-] @numbers'
>>> -5048
>>> -4850
>>>
>>> In general, it's kind of pointless with bare infix ops, as you can just
>>> reverse the arguments, but when reducing or the like, it becomes much
>>> more
>>> valuable.
>>>
>>>
>>>
>>> On Tue, Sep 6, 2016 at 12:43 PM, Parrot Raiser <1parr...@gmail.com>
>>> wrote:
>>>
>>>> I've just stumbled across "reversed operators", e.g. say 4 R/ 12; # 3
>>>> in the documentation. I'm curious to know why the language includes
>>>> them? I'm having trouble understanding where they would be useful.
>>>>
>>>
>>>
>> ​
>

Help mechanism in REPL?

[Parrot Raiser]

This isn't a request for a feature, merely a thought experiment. We're
still in the phase where it's more important to ensure that existing
features work properly than add new ones.

How difficult would it be to include a mechanism within the REPL to
select either documentation or an example, (possibly from the test
suite), for a particular command? Selection might be by some control
key combination,  cursor positioning, or an alternative to "enter" at
the end of the line. The purpose would be to speed development, by
enabling an inexperienced developer to look up details while testing.

Syntax errors generate messages which attempt to provide help; could
this provide the basis for a "help" mechanism? Would this be useful?

Opinions?

Justification for the "reversed" instruction format

[Parrot Raiser]

I've just stumbled across "reversed operators", e.g. say 4 R/ 12; # 3
in the documentation. I'm curious to know why the language includes
them? I'm having trouble understanding where they would be useful.

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

[Parrot Raiser]

Is this particular change one that could be implemented
algorithmically, or at least partially so?
(E.g. For all modules
 check for the presence of a ":D".
 If it's there, no action.
 If not, insert a line of code. Run a test.
 If successful, post change.
 If not, alert a human)

Does Perl 6 use $a and $b in sorting?

[Parrot Raiser]

Because of the the special significance of $a and $b in Perl 5's sort
comparison, I always avoid using the names in examples, lest it set a
booby-trap for later.

I've noticed "a" and "b' being used in some P6 examples. Are they no
longer significant, or are they just a poor choice of identifier?

Re: Language design

[Parrot Raiser]

Subsets will be absolutely essential, if it is to be possible to learn
it with a reasonable amount of time and effort.

On 6/16/15, Paweł Murias pawelmur...@gmail.com wrote:
 I think Perl 6 tries to include too much rather than too little.
 It will be possible to just use a subset

 On 16 June 2015 at 10:32, Michael Zedeler mich...@zedeler.dk wrote:

 On 06/12/15 15:54, Parrot Raiser wrote:

 Has somebody been following the discussions on types?
 http://xkcd.org/1537/ :-)*

 Perl6 has something similar to example 9.

 Ranges, hyper-operators as well as the invocation operators .+ and .*
 doesn't make any sense to me. Those constructs made me stop using Perl
 and
 look elsewhere. It was a hard decision since I've used the language for
 at
 least 15 years.

 I hope Perl6 regexes will make it far beyond Perl itself and the notion
 of
 being able to introduce custom dsl parsed on equal terms as the rest of
 Perl 6 is really sweet.

 Regards,

 Michael.

 --
 Michael Zedeler
 70 25 19 99
 mich...@zedeler.dk

 dk.linkedin.com/in/mzedeler | twitter.com/mzedeler | github.com/mzedeler

Language design

[Parrot Raiser]

Has somebody been following the discussions on types? http://xkcd.org/1537/ :-)*

Synopses size and revision state

[Parrot Raiser]

Without doing too much work, can anyone offer an estimate of the
volume of the Perl 6 Synopses? I'm assuming that by now, they are
unlikely to undergo serious modification.

I'm trying to estimate the cost of rendering them to dead-tree
versions for study. (Personal limitation; I can look up a command
definition online, but for study and mental integration, it's got to
be something like a real book.)

Re: Jargon

[Parrot Raiser]

On 6/13/14, Will Coleda w...@coleda.com wrote:
 See:

 https://github.com/perl6/specs/blob/master/S99-glossary.pod
 which is nicely formatted here:
 http://perlcabal.org/syn/S99.html


Great, thanks.
Looks as though I was late, not premature.

Jargon

[Parrot Raiser]

As typically happens with any complex project, Perl 6 development has
produced a jargon that is almost impenetrable to outsiders. (It's
mostly on top of general Perl parlance, with some CS insertions.)

In order to explain 6 to the world in general, a Rosetta Stone is
going to be necessary. The first step in compiling one is to get
people to note when they are using a specialised term, and what it
means, or else get a scribe/junior linguist to recognise and record
it.

Do we have any mechanism to get that underway, or is the suggestion premature?

Re: [perl6/specs] 89cc32: Spec Bag.kxxv

[Parrot Raiser]

 1. For the last few years almost all discussion is entirely on #perl6.

 Which seems to be working extremely well...just not for me. I can't
 manage to track these discussions (even via the logs). I find the
 interleaving of multiple threads utterly impossible to cope with.

Thank you for saying that. I thought only I was confused and/or stupid.

 I do think Perl 6 is an incredibly good fit for teaching both CS in general
 and programming paradigms in particular.

To catch on, Perl 6 has to do at least one of two things;
a) solve some current general problem uniquely well, (as Perl 4 did
for system administration and 5 for Web work).
b) get stratified into digestible layers (or chunks), so that it's not
necessary to grok all 29 synopses (or however many there are now), in
order to start doing useful things.

It's an awesome language, which is exactly the problem. Inspiring
awe is not far from inducing panic and terror, especially in people
who aren't feeling too confident in the first place. We want to be
accessible to the people who start looking nervous when the modulus
operator is added to the basic four mathematical signs as operators.

Just as KR starts with Hello, World, producing visible results from
the beginning, there has to be a path from basic operations enabling
mastery of mundane chores. Increasing in complexity and abstraction,
to the vaporous worlds of operating systems, compilers, and program
generators. It won't be linear, more like a spiral, but each stage
will be useful. That provides the reward that lures the student deeper
into our clutches. (Sorry, the evil mastermind got out of his cage for
a moment.)

I've made a number of futile stabs at mapping a route, but the
language keeps wriggling and morphing as it develops. It's bad enough
climbing a steep cliff, without adding tectonic activity.

Sorry if I'm being boringly repetitive, but I do see complexity as a
barrier to world domination.

Re: Defining Perl 6 for the masses

[Parrot Raiser]

Minor corrections:

 may smply be my personal limitations).

s/smply/simply/

 dumb noob questions.

By my fairly harsh definition.

 with the sage of IBM's attempt to develop One Language To Rule Them All,

s/sage/saga/

Defining Perl 6 for the masses

[Parrot Raiser]

This is related to the conversation on the Synopses, but its
sufficiently different that it probably justifies its own thread.

I want to start by making it clear that I'm not criticising the design
of Perl 6, or any of the people working so hard to make it great. I'm
just trying to address what I see as an obstacle to its adoption, (but
may smply be my personal limitations). I've been following the project
from the beginning, and have Perl 6 and Parrot (2nd. ed),
http://shop.oreilly.com/product/9780596007379.do  which I understand
is no longer relevant.

People on this list are undoubtedly familiar with the uncomfortable
feeling that they're the smartest person in the room. I get it
occasionally, but usually in the Perl community, I can relax. When
giving training classes, however, it wasn't uncommon. Generally,
groups would appear quite comfortable when shown the first four
arithmetic operators, (+,-,*,/), but when the modulus operator was
introduced they would become clearly uneasy. That meant I was in for
some work, but it's the level of enthusiasm I think we have to
consider.

People working on open-source projects naturally want to solve the
sort of problems that interest them. Languages developed by compiler
writers and language theorists will tend to address questions which
ordinary coders will not even understand, let alone want to solve.

The development team obviously need a vocabulary to discuss such
topics, so on top of natural obscurity, they've develped an IRC
culture nearly impenetrable to outsiders, (at least this one). I've
tried to follow it, but don't want to get in the way and slow down
people doing useful work by asking too many dumb noob questions.
However, some of the topics seem pretty esoteric.

It takes time and effort to understand features of a language, so
unless they are necessary to a problem, in a sense they become bugs.
Solutions should not generally be more difficult than the problems
they are supposed to solve.

The vertical view of the specification presented by the Synopses,
exploring each area in depth, makes perfect sense as a design
document, but presents an enormous challenge to a human memory trying
to load the whole language at once. This is compounded by them not
necessarily reflecting what the language should actually do at any
moment, either
because the feature hasn't been implemented yet, or because it has
been revised and the Synopsis hasn't.

I've made a couple of attempts to get up to speed by writing sample
programs, but I keep crashing into obstacles. Translating Mastering
Algorithms in Perl to Perl 6 stumbled almost instantly, because it
uses CPAN modules, so I turned to the Unix utilities for
specifications. wc seems like a simple task, but even that promptly
ran into the question
of $.'s replacement, which doesn't appear to work as advertised.

Reading Perl 6 examples on Rosettacode helps a little, but the site's
structure makes it a rather cumbersome process.

Having recently read Herbert Simon's The Sciences Of The Artificial,
(and listened to TIMTOWDI's State Of The Onion addresses),  I wonder
if a layered approach is the answer to Perl 6's sheer size? A series
of defined subsets of increasing abstraction, from the basics up to
the sophistication of grammar redefinition, would let beginners solve
simple problems with a simple language, but offer a path to more
advanced topics as far as they wish to go. (Just as Perl 5 goes from
Llama to Camel and onward to Jaguar.)

Even a guru has to take the path to enlightenment one step at a time.
Unfortunately, the starting point and boundaries of the path aren't
well-defined. This leaves the sage wandering a plain of obscurity, in
pursuit of ever more tenuous metaphors.

One particular historical analogue that occurs to me is PL/1. You may
be familiar with the sage of IBM's attempt to develop One Language To
Rule Them All, but in case you aren't, it goes something like this.
After tossing Cobol, Fortran, and Algol into the cauldron,
IBM kept stirring vigorously, to the point where scope creep was
putting the development behinder the longer it went on. The lab at
Hursley finally took on the project and delivered something, by
nailing down the subset of features they could promise to implement,
with the rest to follow later. (An early example of Agile practices,
I suppose.)

If a reasonably immutable basic language exists and can be published,
we can get on with learning it, preparing exercises and training
materials regardless of the obscure controversies over object
interface properties going on at the internal levels. Areas clearly
marked not done yet, do not try this can be bypassed. It might not
be release 1.0, but at least 0.nn (nn  0.5).

Is that realistic, or have I missed something vital?

Re: Commensurability as Key

[Parrot Raiser]

Let's get the basics nailed down and working so that we can learn
them, before wandering any further into theoretical CS.

On 8/18/13, James Bowery jabow...@gmail.com wrote:
 Of the two key conceptual gaps in current programming language philosophy
 -- commensurability and change propagation -- commensurability, if filled
 with due rigor, has the greatest potential for clearing up confusion by
 recasting other core features as derivative.  Change propagation (eg:
 properly voiding memoization in lazy functional evaluation aka incremental
 tabling maintenance in relational evaluation) is something I attempted to
 address in Perl back in 1999 but was blocked by a bug in recursive use of
 the tie machinery.  However, since that time I've come to the conclusion
 that as important as change propagation is to put into the core machinery,
 it isn't nearly as fundamental as is commensurability.

 Let me introduce commensurability with the seemingly trivial example of
 units conversion.

 Units conversion is normally tacked on as an after-thought in programming
 languages.  (Digression: One programming language that had units built into
 the compiler was the PLATO system's TUTOR programming language -- a
 generally nasty language which I encountered while programming
 Spasimhttp://en.wikipedia.org/wiki/Spasim -- that,
 nevertheless, pioneered some interesting concepts due to the relative lack
 of precedent in programming languages targeting ordinary people like
 teachers.) However, while doing real world calculations, correct handling
 of units via automatic conversion is, in fact, more important than type
 checking.  Underlying units checking (and conversion) is commensurability.
  For example, apples are not, in general, commensurable with oranges:  a
 ton of apples should _not_, in general, be added to 3000 kg of oranges --
 although adding a ton of apples to 3000kg of apples makes sense as we are
 dealing with commensurable quantities although in differing units.
  Moreover, by incorporating dimensional analysis into the arithmetic
 machinery, not only can units conversion be automated, but arithmetic
 expressions themselves can frequently be automatically inferred from the
 inputs provided along with the units of the output demanded (see the
 semicolon ';' operator of the Calchemy units
 calculatorhttp://www.testardi.com/rich/calchemy2/
 ).

 While well-designed type machinery, based on things like assertions and
 coercions, can be adapted to implement automatic units conversion (hence
 checking), that is getting the cart before the horse.  Here's why:

 If we accept the idea that the higher level of expression we allow the
 programmer, the better (as it leads to more disciplined separation of 'how'
 pragmas from 'what' specification during the authoring process) then we
 should recognize that relational expression should be core since functions
 are (sugarably) degenerate (many to 1) relations and procedures are
 (sugarably) degenerate (state-transition) functions.  If we have relational
 expression as core, commensurability, hence units handling, falls out of
 what Bertrand Russell called relation arithmetic in Principia Mathematic
 volume IV.  The most advanced work in applying relation arithmetic to
 programming language design was done by the late Tom Etter while at Paul
 Allen's thinktank Interval Research, with Tom's follow-on work at HP
 funded under my (very limited) authority there.

 Tom's paper, Relation Arithmetic
 Revivedhttp://www.boundaryinstitute.org/bi/articles/Relation-arithmetic_Revived_v3.pdf
 documents Russell's conflation of relational similarity with relational
 congruence as the mistake that blocked practical application of relation
 arithmetic in Codd's work on relational algebra -- hence things like the
 object relational impedance mismatch.  However, if we look deeper into
 what was going on, we find that the very idea of sets -- hence the normal
 notion of data types -- is similarly ill founded, as we can, and should,
 bootstrap set theory from a more fundamental theory of relative (or
 relational)
 identityhttp://www.boundaryinstitute.org/bi/articles/Three-place_Identity.pdf
 .

 Just how far do the implications of this go?

 Well, for starters, the core laws of quantum mechanics fall out as
 completely general theorems of relation arithmetic generalized to include
 negative relationships (opt cit).  Among the implications of this are
 core programming language constructs for quantum information systems.

 Sorry if this throws a monkey-wrench at, if not into, the works -- but the
 Perl culture is one of the few places that is has the philosophical
 equipment to take such a lofty concept as commensurability and commit just
 enough Ockham's Chainsaw Massacre to retain much of its value in practical
 programming systems.

Re: Perl 6 in Perl 6?

[Parrot Raiser]

On Thu, Oct 18, 2012 at 3:59 AM, Moritz Lenz mor...@faui2k3.org wrote:

 The priorities for most compiler hackers is to provide good compilers over
 complete bootstrapping, and I guess most users agree with that goal.

Agreed.

I'm most concerned about a reliable and consistent set of features
being defined, so I can learn them once, without having to backtrack
when they change.

No disrespect to the people working so hard to make it happen, but
Perl 6 is conceptually so big. It's hard to carve out a mind-size
chunk to learn and reinforce when things keep wobbling.

The Secret of a Successful Programming Language? A Really Great Beard

[Parrot Raiser]

http://www.wired.com/wiredenterprise/2012/06/beard-gallery

Maybe we should ask Larry to give up shaving for a while?

Re: The trouble with awesome

[Parrot Raiser]

On Mon, Jun 4, 2012 at 12:01 AM, Peter Scott pe...@psdt.com wrote:

 We need multiple paths.  The term beginner creates problems

I meant beginner with respect to Perl 6, but I think that Peter
basically paraphrased my arguments about the problem.

Although programming experience is an important variable, after one's
third (or so) language, especially among related languages like the C
family, there are few surprises, just choices. How much complexity the
learner wishes to absorb depends on the level of their problem.

There is no point in offering solutions more complicated than the
original issue, especially to someone who would really rather not be
solving them in the first place. (You might be surprised at the number
of people who will assert that I'm not really a programmer, in a
tone that suggests it's a social status only slightly above
paedophile.) They program because their real job requires it.

Re: The trouble with awesome

[Parrot Raiser]

On Wed, May 30, 2012 at 6:00 AM, Moritz Lenz mor...@faui2k3.org wrote:

 I'd still start with simple script files, because that's what most
 programmers are most familiar with.

I'd do them in Huffman order; the interpreter involves the least
typing to start, and it's useful for demonstrating concepts. Usually,
an abstract principle needs some specific examples to clarify it.

 Where would you put nested data structures and custom classes?

Assuming you're talking about things like arrays of arrays, I'd put
them between structured and unstructured data. A simple table of
results by month can get into that sort of structure. Custom classes
are definitely around the higher order.

Re: The trouble with awesome

[Parrot Raiser]

 There are a lot of programmers who know several programming languages already,
 and who don't  want to read a whole page on how to print 'Hello World', 5 
 pages on
 if-statements and while-loops  and another 10 pages explaining lists and 
 iteration.

However experienced a programmer may be, there are certain minimum
levels of knowledge one needs to get into a new language.

What class of language is it? Machine code, assembler, compiler,
interpreter, executed from source, like Java? (Obviously, we know
that, but for the few sentences it takes to explain it, it might as
well be stated anyway for newcomers.) A couple of paragraphs can
explain where it might be expected to run, and what's required to
start using it.

 That's the purpose of Hello, world programs; not to babble inane
greetings, but to show simply to run something in the language.  Even
there, Perl 6 is unusually rich in options; interactive mode, command
line, argument, and stand-alone executable. Each step requires
slightly more input, so that's the order I would introduce them.

When introducing a programming language, as opposed to teaching
programming from scratch, it should not be necessary to explain what a
variable is, or why decision statements are required. The reader's
questions are more in the nature of what's a valid variable name or
how are blocks bounded?

Without the basics of of statement syntax, variable name rules, block
structure, how decisions are  delimited, and how to iterate, how does
one interpret more complex concepts? Certainly, they can be explained
by reference to some previous standard; The rules for  are
exactly the same as in Perl 5, except when . These rules are
.. That allows the Perl maven to skip forward enlightened, and
the beginner to keep learning.

Learning's a process of building on previous foundations, and so is
programming. Somebody creating simple tabulations may never need the
techniques of the compiler writer, but the compiler creator had to
learn the rules for variable names.

 But much more is needed. Please help us with it.

Specifying the problem was meant to be the first step. I wanted to get
the discussion going, (but not the bikeshedding about the language
name).

For the author of Perl 6 documentation, the problem is knowing the
language well enough to see the logical stages to extend basic
concepts and introduce new ones. Where are the rings of the onion?
For example, double  and single ' quotes are pretty much essential
from the start; when do the alternative forms begin to be necessary?

I see at least 3 levels of complexity, demanding increasing levels of
sophistication; basic computation on streams of structured I/O,
manipulation of unstructured data, like text, and higher order work,
like program-creating programs, compilers, c. Does this seem like a
reasonable taxonomy, or are other groupings a better fit?

The trouble with awesome

[Parrot Raiser]

Perl 6 is awesome.

Its design is based on the combined experience of many clever people.
It addresses a whole range of contemporary computing problems, in fields
as diverse as text processing and compiler development. It's being
developed by, and for, some of the smartest people I want to risk
approaching.

In short, Perl 6 is awesome: Extremely impressive or daunting, inspiring awe.
http://oxforddictionaries.com/definition/awesome?view=uk
That is a problem, if we want to get it adopted widely and quickly.

I've spent quite a lot of time teaching Perl 5 to a variety of normal
commercial programmers. An early part of the course was the arithmetic
operators, (+,-,*,/,%). A good many of the classes started to look
nervous and uncomfortable around the time I introduced the modulus operator,
because it was approaching the boundaries of their experience. (I don't
think it was just my deficiencies as an instructor that led them to feel
uneasy.)

One of the difficulties of teaching a complex subject to any but the
most motivated of students is overcoming their fear of that complexity,
the feeling that this is just too hard. There's also the practical
consideration that a solution more complicated than the problem it
addresses doesn't really deserve to be called a solution.

Trying to teach adults something they don't need to know is like trying
to teach a pig to sing. You will only succeed in annoying the pig. If all
you need to do is total some lists of numbers, the ability to construct
compilers is not a powerful attraction; it may in fact be a distraction.

It's not even a matter of the learner not being terribly bright. It's
sobering to visit the Software Carpentry site, software-carpentry.org
and remember that it is aimed at graduate  science students.

We all share common limitations to learning, e.g. the magic number 7,
plus or minus 2 http://cogprints.org/730/ Introducing too much at once
is counter-productive; it leads to confusion, not knowledge. For a concept
to stick around long enough to become an unconscious competence, it has to
be reinforced by practice. To encourage practice, it has to be rewarding,
i.e. reasonably easy to get right, and do something useful, quickly.

The problem we have is to provide a path for learning 6, that presents a
comprehensible but useful subset of the language to the average user
as soon as possible, while leading the programmer with more complex needs,
(and greater abilities), to the features they need or will appreciate.

The Synopses are comprehensive. They define the language in great depth,
feature by feature, (some features bordering on the pathological, do not
try this at home). Since they specify what the language is to become, not
what is implemented at present, they can be frustrating to follow. Maybe
it's just an effect of advancing age, but it's easy to forget the contents
of a previous synopsis by the time one has read the next. The Perl 6
Tablets have a similar organisation, and hence the same problem.

I haven't recently revisited the book in Rakudo*, but it struck me, last
time I looked, as a powerful deterrent to learning the language. It starts
with the tricky stuff. There's a paradox inherent in computer documentation;
people who thoroughly understand software are probably the wrong people to
try to explain it, because they know too much. (That's also true of the
current state of the error messages; they assume the reader understands
the issues as well as the author. It's forgivable at the present stage of
development, but still frustrating.)

Larry's metaphor of the Onion seems to be appropriate here. Present a core
set of features to make a useful language, (Perl 6 baby talk) and make a
series of increasingly sophisticated and esoteric aspects available as the
student becomes adept with the basics. For example, when discussing quoting,
single and double quotes are quite enough to start with. All the Q forms
can wait. Even then, they may be introduced in stages. Of course, when doing
this, the problem is not to make statements that will have to be
contradicted later.

This concept might even help define when a 6.0.0 is done enough to launch.
It's going to take a while for the more esoteric features of the language
to get used. If they aren't in the first version, it may not cause much
inconvenience as long as they are implemented Real Soon. If it does, the
inconvenienced might be motivated to help.

Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul

[Parrot Raiser]

 S19 uses hyphens for all of perl6's long-form command-line flags.

Command-line flags and methods are separate sets. Hyphens would be the
norm for flags.

 In S28, we find $*EXECUTABLE_NAME and %*META-ARGS listed
 within 10 lines of each other.

 S32-setting-library_IO.pod and S32-setting-library_Numeric.pod each have
 public multi-word method names with hyphens.

In both cases, hyphens are linking qualifying adjectives to nouns,
while hyphens separate distinct words.  One could argue that is not
inconsistent.

On 8/23/11, Patrick R. Michaud pmich...@pobox.com wrote:
 On Tue, Aug 23, 2011 at 05:36:27PM +0200, Damian Conway wrote:
 And I'd like there to be a more consistent approach than that
 (though I don't really care what it actually is).

 +1 to consistency.

 Pm

Close($file) required in Perl 6, unlike Perl 5

[Parrot Raiser]

The following program:

my $skeleton = bones\n;
my $new_file = grave;
my $handle   = open($new_file, :w);
$handle.print($skeleton);

opens the grave file, but leaves it empty. A last line:

close($handle);# close() generates an error message.

is required to get any contents in the file, unlike the equivalent Perl 5 code:

my $skeleton = bones\n;
my $new_file = grave;
open(my $handle, , $new_file) or die $!;
print $handle $skeleton;

This might be a perfectly reasonable design decision, but I haven't
noticed it mentioned.

Bug?

[Parrot Raiser]

When a subroutine is invoked with an empty parameter list, as follows:

run_stuff();

sub run_stuff {
my ($parm) = @_;
say Parameter is $parm;
}

@_[0] contains Any().

Should it?

Re: CPAN -- moving forward

[Parrot Raiser]

Part of the tension here may be coming from the attempt to debate too
many levels of structure at once.

One of the common factors that has contributed to the longevity of
Unix (in the generic sense), and the Internet, is their layered
architectures. The kernel does its thing, the shell sits on top, shell
tools and applications attend to their matters, and as long as they
abide by some standard conventions, revolutions can occur at one level
without disturbing others. Similarly, co-ax, twisted pair, power
lines, fibre-optics and pigeons can all carry IP packets for UDP or
TCP, that might be VoIP or HTTP, and apart from some latency issues
with the pigeons, the various layers don't care what's happening
either side of them.

If this discussion can be split into clear layers,  (what gets stored,
where, how, c.) it might be easier to produce results.