
Haskell to Perl 6 - voihannena
https://docs.perl6.org/language/haskell-to-p6
======
kev6168
Perl 6 is for people who are very smart and have a great spirit in seeking and
having fun in programming, I really admire that. That's my thought after two
failed attempts (each lasted about two days) to learn it in 2012 and 2014. I
felt the use of sigils, syntax oddities and the cleverness were beyond my
ability to master the language. I should mention in 1998 I used (modified it a
little bit) Selena Sol's shopping cart script. Since then I have only written
a few small Perl 5 scripts, am not familiar with recent development. To learn
Perl 6 today, what kind of practice projects/applications, or approaches, one
can use?

~~~
johnisgood
> Perl 6 is for people who are very smart and have a great spirit in seeking
> and having fun in programming

Not sure why you felt the need to include this. How did you come to this
conclusion? Is this in comparison to Haskell, or what?

~~~
kev6168
It was tongue in cheek, haha... I was only frustrated by my own inability to
get the hang of Perl 6. As an old casual fan of Perl, I still want to take
another shot at learning it very much.

~~~
4thaccount
The perl6intro website shows you the essentials of what you need and the
ecosystem has matured a lot since 2014 as well as many good books being
published. Laurent Rosenfield has a Think Perl6 book that you can buy in paper
or read online for free. If you can already code, getting proficient in basic
Perl6 is easy. Becoming a master is outside my current grasp.

~~~
kev6168
Thanks for the recommendations.

One liners are fun, and life-saving. I am curious about this aspect compared
to Perl 5. With Perl 6's new syntax and language features, can we still easily
[ab]use one liners for fun and profit?

~~~
raiph
Cons:

* Rakudo -- the only P6 compiler for now (and likely many years, maybe forever) -- has a slow startup, around 0.1 seconds or so.

* Rakudo is still a work in progress. What's done is pretty solid but, for example, no one has implemented the `-a` awk/autosplit command line option (cf [https://gist.github.com/raiph/1d0cbefcb3cfe45b0b906282e6e405...](https://gist.github.com/raiph/1d0cbefcb3cfe45b0b906282e6e40519)) and command line usage is currently `use strict;` by default so you have to declare variables with `my`.

* Pros

P6 makes for sweet oneliners...

25 one liners being written up this month:
[https://perl6.online/category/advent-
calendar/](https://perl6.online/category/advent-calendar/)

9 categories last updated a year ago:
[https://github.com/dnmfarrell/Perl6-One-
Liners](https://github.com/dnmfarrell/Perl6-One-Liners)

[https://www.google.com/search?q=perl6+oneliners](https://www.google.com/search?q=perl6+oneliners)
[https://www.google.com/search?q=perl6+one+liners](https://www.google.com/search?q=perl6+one+liners)

------
rs86
Perl 6 feels a bit "ad hoc" to me... It looks like it has very interesting
features but it lacks the uniformity present in most languages...

~~~
nine_k
Perl has never been about uniformity.

Perl is a great experiment in language design, or, rather, a battery of
experiments. It's the opposite of a cleanly _designed_ language.

~~~
AnimalMuppet
No, it's designed. It's just not designed the way everyone expects a computer
language to be designed. It was designed by a linguist. He produced a language
with some of the flexibility (and messiness) of _human_ languages, which is
completely foreign as a goal to other languages.

One of the places this shows up to me is being able to say "it" (in essence).
That is, we humans, when talking to each other, we say things like "Read in a
line of input. If it looks like an XML tag, pass it to the XML handler
function". But you can't talk to a computer that way. The computer says, in
effect, "Read in a line of input _from where?_ And put it _where?_ And what do
you mean 'if it ends in a newline'? If _what_ ends in a newline?"

But in Perl, you can write it just like the humans say it, and Perl says,
"Well, you didn't say where to read the input from, so I assume I should read
it from the standard place (which is perfectly well defined in Perl). You
didn't say where to put the line of input, so I'll put it in the default
variable. You didn't say what to check to see if it looks like an XML tag, so
I will check the default variable." The default variable, essentially, plays
the role of "it" in human language.

And the whole language is like that. There are shortcuts that work most of the
time, and precise ways of saying things that work when the shortcut isn't what
you want. And what the shortcut does is well defined (in the docs; it can be
very opaque in code).

None of this makes Perl an ideal language. But it has a perspective on
language that is (as far as I can tell) unique among programming languages. It
is only fair to judge the coherence of the design within the framework of what
Perl is trying to be.

~~~
ricardobeat
Except the resulting code will look nothing like “the humans say it”, and
instead will be a cryptic charade requiring a ton of knowledge to decipher -
ending up being neither natural language nor machine code.

~~~
kbenson
> Except the resulting code will look nothing like “the humans say it”,

Actually, I find it maps rather directly to how a lot of people explain
things. For example, "Examine each number, and as long as it's greater than 10
and odd, then pass it to the the work function."

    
    
        for my $number ( @numbers ) {
            next unless $number > 10;
            next unless $number % 2;
            work($number);
        }
    

Perl generally allows you to structure your code as you would explain how to
accomplish something to another person. This can be beneficial or detrimental
depending on how deep you go with this concept. A lot of becoming a good Perl
programmer is learning where a sane line is for this, but each language
usually has a similar feature which the user needs to decide where the sane
point to stop is before taking it to an extreme that is detrimental.

There are definitely aspects of Perl that I think are better left untouched,
and thankfully the community has pretty much come to consensus about the most
problematic missteps the language allows.

~~~
chombier
One can write pretty much the same code in python/c++11/whatnot and it also
feels quite natural to read:

    
    
       for number in numbers:
           if number <= 10: continue
           work(number)
    

Do you have a better example where the Perl syntax would shine?

~~~
kbenson
Note: This is all in the context of Perl 5. You can assume the following works
with little or no changes in Perl 6, along with probably 3+ other new ways to
do it (which is actually one of my peeves about Perl 6).

There's a few things. Full word but lower precedence boolean operators (and,
or, not) which allows for combining statements in a way that &&, || and !
doesn't always facilitate, but really shine in making boolean statements more
readable. e.g.

    
    
        die "some problem" unless defined $some_var and not $some_var eq "foo";
    

But I think you somewhat missed my point. What you've done in your example, is
easy to read, but you've either unconsciously or consciously switched the
order of some statements so they are valid in the context of Python. This is
trivial and easy with simple conditionals, but if they are complex it can hide
the point of the statement, which is that this is a shortcut to the next loop
iteration. I find putting the "verb" first can make for much easier
understanding of what's going on when it gets more complex. A comparison of
that might be something like the following:

    
    
        for my $item ( @items ) {
            # Standard barrage of tests
            next if test1($item) or test2($item) or test3($item)
                or test4($item) or test5($item);
            # If it's a special item, do a couple more tests
            next if test_guard($item) and ( subtest1($item) or subtest2($item) );
            # If it's an end marker, skip the rest
            last if is_last_processable($item);
    
            ...
        }
    

Even though the actions are condensed, I quickly know what the _point_ of each
one is, and what it does. Condensing them also allows me to comment each
without feeling I'm cluttering the logic and making it more verbose than
needed (too verbose, and you raise the likelihood related code will be off-
screen or not as easily visually associated, which hampers comprehension), but
event without the comments having the defining action start the line helps
clarify intent. I imagine in Python, the continue statement would either be
far to the right from larger conditionals, or moved to a more traditional
scope underneath taking up an extra line, or split into multiple if
statements. This is also a good example in Perl of where the community has
come to a fairly good consensus that while you _can_ make very complex
postconditional statements, _don 't_, as it defeats the purpose (just split it
into multiple simple ones or use a traditional precontitional if formatted to
be more readable, or some other technique such as computing portions of the
condition separately and comparing them later).

Also, regarding if pre or post positioning, I feel that Perl allows the
statements to be expressed as you might say them or think of them. That's the
point of postconditionals in Perl. Also, like how you would express them
verbally to someone, a postconditional only works on a single statement (it
does not support blocks through braces). You wouldn't normally say "do X, do
Y, do Z if A is true" and expect it to apply unambiguously to tasks X, Y and
Z. On the flip side, a preconditional not only supports braces, it _reqiures_
them, since the simple one statement case is easily handled through the
postconditional. e.g.

    
    
        # Valid
        if ( $A ) {
            do_something();
        }
        if ( $A ) { do_something(); }
        do_something() if $A;
        
        # Invalid
        if ( $A ) do_something();
        { do_something(); } if $A;
    

This is an example of one of the places Perl not only allows you to use
natural expressions to express yourself, but guides you away from odd or
problematic ways of doing so (i.e. ambiguous speech patterns).

As for sigils, some people really dislike them, but I find the useful. I see
them a little signifiers of the nouns in any statement (and the type of noun,
of which there are only a few).

Finally, there's "context", which has a specific meaning in Perl, and is
probably the most interesting and unique thing about the language. It can be
very useful, but the complexities can sometimes cause interesting behavior
that was unintended or non-obvious initially. That said, its also what makes a
lot of the "magic" (really just the rules put into action) of the array and
hash data types work, so it's not something that could feasibly be removed
(and nor would I want it to be). Instead, knowledge of the problematic spots
is acknowledged by the community, so we try to avoid those problems, and for
the most part they are old problems (this is usually a function that may
produce multiple values being using within the definition of a hash or array
in list context, exemplified by decades old projects based on CGI.pm which has
been deprecated).

~~~
ricardobeat
Lots of other languages have postfix conditionals.

On the readable boolean ops, all the Perl people recommend shying away from
them except for a few specific constructs (do or die, eval or do, etc), since
the weaker precedence rules make it really easy to shoot yourself on the foot:

    
    
        $a = $b or $c;
    

Where $a will never be assigned the value of $c.

~~~
kbenson
> Lots of other languages have postfix conditionals.

I didn't make a case as Perl being the only language, just that it's an
interesting aspect of Perl. That said, I would be interested in what languages
you are referring to. I haven't seen many.

> On the readable boolean ops, all the Perl people recommend shying away from
> them except for a few specific constructs (do or die, eval or do, etc),
> since the weaker precedence rules make it really easy to shoot yourself on
> the foot:

They are perfectly acceptable in a boolean statement. You only need to shy
away from them when mixing them with assignments or higher precedence boolean
constructs. The only case where you would have to worry is in non-simple
boolean statements with assignment in the statement, or functions that omit
parens for arguments in some cases, or mathematical operations without
grouping parens, all of which I would argue should include their own grouping
parenthesis for clarity anyway.

That said, I devoted space in both of my comments in this thread to noting
that there are definitely places where you might shoot yourself in the foot
with some of these features, and you'll note the examples I used them in are
exactly as you've described, where they are either after a postconditional (in
which case it's kept to a simple boolean statement which has no ambiguity), or
to affect control flow (e.g. return or die), in which that assignment doesn't
matter anyway.

> Where $a will never be assigned the value of $c.

Which I never used as an example for that reason, but that's the _point_ of
those operators. Being lower precedence allows for some alternate constructs
than is possible in many other languages without them.

Someone asked for examples of constructs that help Perl match mental models of
how might think of an algorithm, so I decided to explain a few. The purpose
isn't to point out how Perl is better than Python or some other language, but
how it's different in an interesting way. A lot of that was planned, but
sometimes that came out to its benefit, and sometimes to its detriment. Like
most interesting new things (because at the time it was), it's not entirely
one thing or the other.

~~~
vram22
>I didn't make a case as Perl being the only language, just that it's an
interesting aspect of Perl. That said, I would be interested in what languages
you are referring to. I haven't seen many.

I'm not the one you replied to, but Python has got, not postfix conditionals,
but what I might call infix ones, for lack of a better name. Here is a nested
example:

Using nested conditional expressions to classify characters:

[https://jugad2.blogspot.com/2017/04/using-nested-
conditional...](https://jugad2.blogspot.com/2017/04/using-nested-conditional-
expressions-to.html)

------
hestefisk
Not to be trollish, but is anyone actually using Perl 6 for more than just for
kicks? It is a super interesting language, but has it been battle tested over
the years similar to Perl 5?

~~~
cutler
Perl 6 is still 9 times slower than Perl 5 when parsing log files with a
regex. I don't quite get why the feature which made Perl famous has now taken
a back seat. Why should I take a 9x performance hit?

~~~
vvillena
The Perl 5 core is hack upon hack, to the point that it's been mostly
abandoned due to how hard is to change things without breaking anything. Perl
6 was born as a specification, which allows for a "first make it right, then
make it fast" approach.

~~~
cutler
That's assuming it can be made fast. It's been stagnant around this level of
performance for quite some time now.

~~~
lizmat
Unfortunately, the performance of regexes has not been improved much in the
past years, that is true and on the radar. Yes, it can be improved (very much
indeed).

Most other subsystems of Rakudo Perl 6 __have __been improved significantly,
some by orders of magnitude. And then there 's work on the basic runtime of
MoarVM and its JIT that will benefit _all_ programs running on MoarVM.

The Perl Foundation recently approved another grant for the JIT:
[http://news.perlfoundation.org/2018/11/september-2018-grant-...](http://news.perlfoundation.org/2018/11/september-2018-grant-
votes.html) about [http://news.perlfoundation.org/2018/10/grant-proposal-
moarvm...](http://news.perlfoundation.org/2018/10/grant-proposal-moarvm-jit-
comp.html)

~~~
cutler
Perl with poorly-performing regexes is beta software, as far as I'm concerned.
Why OOP, junctions and all the less relevant stuff has taken priority over
regexes baffles me.

~~~
lizmat
Well volunteered!

------
justinator
It may be that it's of interest, as an early Perl 6 implementation was written
in Haskell (Pugs)

~~~
knbknb
I think this Haskell version (pugs) came at a time when perl6-development was
somewhat stuck, and it enabled the Perl 6 developers to test new language
constructs on an improved runtime (I believe); so Haskell was actually key to
Perl 6 development.
([https://gist.github.com/masak/479846/4908b28645b8815d1afe2b4...](https://gist.github.com/masak/479846/4908b28645b8815d1afe2b4d79efa164984b759c))

~~~
bmn__
HTML, more readable: [http://strangelyconsistent.org/blog/happy-10th-
anniversary-p...](http://strangelyconsistent.org/blog/happy-10th-anniversary-
perl-6)

------
empath75
It seems to me that Haskell programmers are the least likely to need something
like this.

~~~
kingofhdds
To be interested in programming languages generally, I think, is an inherent
feature of a passionate programmer.

~~~
tempodox
Being neither a Haskellian nor a Perlist, I found the article interesting and
I think you nailed the reason why.

------
ktpsns
Actually Perl 6 comes off badly in this comparison. The Haskell expressions
are almost always easier to read, understand, reproduce, and overall even
shorter.

Nevertheless it shows that Perl 6 can do real functional programming. Even if
the syntax looks exceptional sometimes, even for people familiar with Perl 5.

~~~
raiph
It's not a comparison. It's not an appetizer for P6 or ways in which P6 comes
off better than Haskell. It's not an overview or tutorial for learning P6 if
you come from a Haskell background.

It's for someone who has already decided they like P6, has learned the basics,
and wants to tighten up their understanding of P6 as it relates to Haskell
things they know. It deliberately picks things that are basic in Haskell even
if they're not so basic in P6.

That's why it says:

> Note that this should not be mistaken for a beginner tutorial or overview of
> Perl 6; it is intended as a technical reference for Perl 6 learners with a
> strong Haskell background.

~~~
ktpsns
You're certainly right, but that doesn't change my point that, by just looking
at the code, Haskell seems to have the better solutions for the problems.

This conclusion is clearly unfair because the author tried to port simple
Haskell solutions to Perl.

~~~
raiph
> You're certainly right, but that doesn't change my point that, by just
> looking at the code, Haskell seems to have the better solutions for the
> problems.

Sure. But that's an inevitable consequence of what the document aims to
achieve.

The problems chosen were the ones for which Haskell had simpler solutions.

The point of the document was to help someone who is already motivated to
learn P6 and knows Haskell to get to grips with P6.

If the point were to motivate someone who knows Haskell to want to learn P6
then the examples chosen would be ones for which the P6 solution is better
than the Haskell one.

------
devin
What’s the objective or rationale here? I don’t understand why this is
interesting.

~~~
giggzy2
Language compare and contrast is whats interesting to me.

I don't use either day to day but have had some exposure to both. I think both
languages will have influence on future of language design at a minimum.
Doubtful Perl does a phoenix routine but weirder things have happened.

------
cwyers
There's also a Python version of this[1], which starts with a discussion about
Perl 6's equivalent of print, which is put. This makes no sense to me
whatsoever, as print is both a much easier way to say it and _what was used in
Perl 5_, but not my circus, not my monkeys. But then it goes on to say:

> There is also say, which behaves similarly, but will call the gist method of
> its argument.

And after having read the linked-to docs for say[2] and gist[3], I not only
cannot understand what is being said, I have no idea how anyone else could,
either.

1) [https://docs.perl6.org/language/py-
nutshell](https://docs.perl6.org/language/py-nutshell) 2)
[https://docs.perl6.org/routine/say](https://docs.perl6.org/routine/say) 3)
[https://docs.perl6.org/routine/gist](https://docs.perl6.org/routine/gist)

~~~
_delirium
I've never used Perl6, but it took me about 30 seconds to figure out what
'say' and 'gist' do from the linked docs? 'gist' prints a string
representation of an object aimed at being human-readable at the expense of
not necessarily being a complete representation (e.g. the doc page gives an
example that an array has only its first 100 elements printed followed by a
'...'). 'say' is a version of 'put' that does this for every object being
printed.

~~~
cwyers
So, I sort of took that away from it, but there's stuff in the gist page like:

> The default gist method in Mu re-dispatches to the perl method for defined
> invocants, and returns the type name in parenthesis for type object
> invocants. Many built-in classes override the case of instances to something
> more specific that may truncate output.

And I have no idea how anyone that isn't already fluent in Perl 6 is expected
to read that.

EDIT: My point is mostly that it just seems... weird. Like, I get the
animating idea of Haskell, even if I don't understand all of the concepts.
Perl 6 just seems... alien. It's incredibly funky.

~~~
kqr
I have no problem reading that. Sure, I dont understand it in fine technical
detail (what's Mu? An implementation of Perl? A codename for Perl 6?) But I
believe I understand enough of it to start using it.

This specific example seems similar to the __repr__ vs __str__ thing in
Python, and not very alien at all.

~~~
xisukar
As pointed out by others, Mu is the most _undefined_ value there is in Perl 6
and the base root for the immediate child classes
([https://docs.perl6.org/images/type-graph-
Mu.svg](https://docs.perl6.org/images/type-graph-Mu.svg)). However, most
classes (both built-in and user-defined ones) don't inherit directly from it.
Instead, they inherit from Any, which in turns inherits from Mu.

More info about it:

\- [https://docs.perl6.org/type/Mu](https://docs.perl6.org/type/Mu)

\-
[https://en.wikipedia.org/wiki/Mu_%28negative%29](https://en.wikipedia.org/wiki/Mu_%28negative%29)

~~~
vram22
Right. Here's a blog post, which, while not directly about Mu (it's about m, a
shell script I wrote), has many excerpts about (the original) Mu (from which
Perl6's Mu descends, pun intended, ha ha) near the end - some may find them
interesting:

m, a Unix shell utility to save cleaned-up man pages as text:

[https://jugad2.blogspot.com/2017/03/m-unix-shell-utility-
to-...](https://jugad2.blogspot.com/2017/03/m-unix-shell-utility-to-save-
cleaned-up.html)

------
benbristow
I still can't take Perl 6 seriously with that butterfly logo. Website looks
like it's from 2003 as well.

~~~
xaduha
Use this one [https://rakudo.org](https://rakudo.org)

~~~
benbristow
See that looks nice and the website looks like it was made this decade.

------
herrosheep
I'd like to hear opinions on how the use of sigils and the other syntax
oddities like Int:D, Int:U, given, when, etc improves the
codabliity/readability of Perl 6 vs other languages. The examples vs Haskell
are not helping me understand. Personally I don't think the added verbosity is
helping in any way.

~~~
raiph
> The examples vs Haskell are not helping me understand. Personally I don't
> think the added verbosity is helping in any way.

It doesn't sound to me like you are the right audience for the document you're
reading.

Quoting from that page:

> this should not be mistaken for a beginner tutorial or overview of Perl 6;
> it is intended as a technical reference for Perl 6 learners with a strong
> Haskell background.

It is not wise to start with a technical reference unless you are already
fairly well versed in the basics of the technology you're learning and are
motivated to deepen your knowledge of it.

If you are interested in P6 you should start with overview or beginner
material. Then, if you have a strong Haskell background, you can refer to the
technical reference if and when the overview or beginner material isn't
working for you.

(If you are not genuinely motivated to have fun learning P6 then nothing
related to P6 will work for you. Are you genuinely motivated to have fun
learning P6?)

\----

> I'd like to hear opinions on how the use of sigils and the other syntax
> oddities

If you view childishly simple and natural syntax as "oddities" then your mind
is already made up that they are oddities.

So the rest of this comment is intended primarily for other readers and
secondarily for you on the off chance that you are able to transcend your
mind's confirmation bias against the following constructs actually being
simple and natural.

> use of sigils

Many programmers think in terms of three fundamental primitive data types from
which all other datatypes are composed:

* single items

* collections of numbered things

* collections of named things

P6 adopts this view and assigns three sigils to these three abstract notions.

This makes it both easier and quicker to both read and write code -- once
you've learned how they work. In P5 sigils were onerously complex. In P6 they
are childishly simple. So now it's also easy and quick to learn them as well
as to use them.[1]

> Int:D, Int:U

In P6, every type that's created using any of its type constructors is a sum
type with two sub-types. This includes types defined in the standard language
such as Int. The sub-types are named D and U. For example, to refer to Int's D
sub-type, use `Int:D`.

This makes it easy and quick to read and write code once you've learned what
they are. Fortunately, it's childishly simple to learn what they are.[2]

> given

The `given` keyword means essentially the same as the English word `given`.

This makes it easy and quick to read and write code once you've learned the
English meaning of `given`.[3]

> when

The `when` keyword hides a good deal of complexity. But one can hop on
Wittgenstein's Ladder easily. Because for the first rung, it just means the
same as the meaning of the English word `when` used in the context of
something that's `given`.

The keyword `when` makes it easy and quick to read and write code once you've
learned the English meaning of `when` in the context of `given` -- and it can
then be used in other contexts.[4]

\----

[1] 27 second vide clip covers it all:
[https://www.youtube.com/watch?v=Nq2HkAYbG5o&t=10m&list=PLRuE...](https://www.youtube.com/watch?v=Nq2HkAYbG5o&t=10m&list=PLRuESFRW2Fa77XObvk7-BYVFwobZHdXdK&index=92)

[2] They're called "type smilies" for a reason. :D is the definite, happy,
valuable type. What's `42`? Simple. Definite. Happy. Valuable. Unlike :D, the
other subtype, :U, is undefined, unhappy, not a value. What's `Int`? Is it
`42`? No, because that would be defined. Every value/object is either
definite/happy or it isn't.

[3] From dictionary.com: given: noun: "an established fact"

[4] From dictionary.com: when: conjunction: "in the event that"

~~~
xisukar
> In P6, every type that's created using any of its type constructors is a sum
> type with two sub-types. > This includes types defined in the standard
> language such as Int. The sub-types are named D and U. > For example, to
> refer to Int's D sub-type, use `Int:D`.

Probably your comment hints to this already in which case the following will
be redundant but I wanted to mention them more explicitly. This is mainly for
people unfamiliar with Perl 6.

Using the type smileys(:U, :D) are also ways to specifically match against a
type object (`Int`, `Str`, `Rat`, etc.) and an instance object of a type
object (-5, 'Hello', 1/5, etc.):

    
    
        Int ~~ Int:U;   # True
        -5  ~~ Int:U;   # False
        -5  ~~ Int:D;   # True
        Int ~~ Int:D;   # False
    

There is also the :_ smiley which is used by default whenever the other two
aren't specified:

    
    
        Int ~~ Int;     # True, same as: Int ~~ Int:_;
        -5  ~~ Int;     # True, same as: -5  ~~ Int:_;

~~~
raiph
> Probably your comment hints to this already

Regardless, I'm glad you've written your comment to clarify. :)

I'd be delighted to hear about any of the several big or small mistakes I am
about to make in the following.

Also an honest opinion about whether the following approach I take boils down
to one that is complete gibberish, vaguely interesting but terribly complex,
OK but meh, good but a bit abstract, enlightening, or something else. If you
do let me know, please clarify whether you mean what you say for just you, or
for what you think might be true for others that don't know P6 at all. TIA.

\----

Like a lot of P6 stuff this basic aspect of its type system is both childishly
simple but also so general, abstract, and high level, and comes at things from
such a different angle than pretty much all other languages, that it can be
difficult to explain.

Another attempt at what I was trying to get at in my second footnote in my GP
comment...

\----

A P6 type and its two standard sub-types are a simple and fun unification of
the universal/existential "quantification" that our inner logician loves and
the "article definiteness" distinction recognized by our linguistic side.

From
[https://en.wikipedia.org/wiki/Article_(grammar)](https://en.wikipedia.org/wiki/Article_\(grammar\)):

> The articles in English grammar are "the" and "a/an" ... In languages that
> employ articles, every common noun, with some exceptions, is expressed with
> a certain definiteness, definite or indefinite

From
[https://en.wikipedia.org/wiki/Quantifier_(logic)](https://en.wikipedia.org/wiki/Quantifier_\(logic\)):

> The two most common quantifiers mean "for all" [Universal] and "there
> exists" [Existential].

\----

:D denotes a definite thing.

It is directly analogous to "the".

The value `42` is considered definite.

Definiteness implies that a thing actually exists. Its the linguistic analog
of existential quantification.

Many coders talk about happy/sad path processing. :D is associated with the
happy path, perhaps because it has no existential crisis. :D

\----

:U is related to Universal quantification.

As a type, it is also related to "a". Quoting wikipedia:

> An indefinite article indicates that its noun is not a particular one
> identifiable to the listener.

:U corresponds to an indefinite thing, something that's only identifiable as a
Universal, not a Definite thing.

:U is also associated with Undefined things, even if they are _supposed to be_
undefined.

In the context of talk about happy/sad path processing, :U is associated with
the Unhappy path, because it can denote a thing that should be definite but
isn't.

\----

As a _value_ , a type name without a `:D` or `:U` smiley is the same as the
type name with a `:U`.

As a _type_ , a type name without a smiley is the same as the type name with a
`:_`, where the `_` denotes either `D` or `U`.

Thus:

* `Int`, as a thing in of itself, is the same as an `Int:U`.

* `Int`, as a type of thing, denotes either an `Int:U` or an `Int:D`.

~~~
xisukar
> ...the several big or small mistakes I am about to make in the following.

Everything you wrote seems fine to me and you even expounded on what I wrote!
However, even if it wasn't, I'd be hardly pressed to come up with a response
as clever and resourceful as your responses. For this reason, I quite enjoy
reading your comments whenever I come across them on /r/perl6 and
/r/programminglanguages.

> Like a lot of P6 stuff this... is both childishly simple but also so
> general, abstract, and high level... that it can be difficult to explain.

You're totally spot on. The most recent example of my struggle (mainly due to
my ignorance of Perl 6 and probably CS concepts too) was the concept of
containers and how they interface most assignments in Perl 6. I think the fact
that many Perl 6 constructs/concepts, which complex in nature, seem so natural
can deceive people who haven't tried it yet. This is because it's easy to
overlook (or plainly ignore) how much thought went into both integrating them
into the language and make them play nicely together.

\---

Thanks for your comments!

~~~
raiph
> Everything you wrote seems fine to me and you even expounded on what I
> wrote!

Given that your reply was just the right sort of clear answer that would make
up for my original footnote I was especially happy to riff off your answer and
get super detailed again. :)

> I'd be hardly pressed to come up with a response as clever and resourceful
> as your responses.

.oO ( Ever too clever by half )

> The most recent example of my struggle (mainly due to my ignorance of Perl 6
> and probably CS concepts too) was the concept of containers and how they
> interface most assignments in Perl 6.

Yeah. Simple on the outside so noobs can just do their thing. Rich on the
inside so gurus can develop new candy and gourmet meals.

Anyhoo, thanks for your reassuring feedback. :)

------
rurban
The lack of maybe or nullable types in perl6 with the need to check for
definedness at run-time (Int:D) is one of its major design blunders. Also this
syntax!

In cperl I rather use proper maybe types as in every other language. ?Int is
(Int | Undef) you cannot use Int? as this would confuse the parser to look for
the matching :

~~~
raiph
> The lack of maybe or nullable types in perl6

P6 supports something more powerful and uses that instead:

[https://en.wikipedia.org/wiki/Tagged_union](https://en.wikipedia.org/wiki/Tagged_union)

In P6 the symbol Int, when treated as a type by the compiler, denotes Int:_,
which is a sum type, with two subtypes, namely a generically existentially
quantified Int (Int:D) and a generically universally quantified Int (Int:U).

Thus Int can be used in the role of a nullable type, but is an improvement in
the sense that the equivalent to None (Int:U) encodes its type.

In P6 all constructable types are automatically sum types with :U and :D
subtypes.

> need to check for definedness

There is relatively little need for users to check definedness. The language
and compiler ensure basic type/memory safety and the user can just write code
and it'll automatically be type safe at this basic level.

When the need arises, the user only need type one or two characters in almost
all cases (either `:D` if writing a type constraint or `if foo` or `?foo` if
writing an explicit check).

> at run-time

In P6 definedness refers to the notion that something actually exists and this
is deliberately aligned with the notion that something exists _at run-time_.

Users seldom need to concern themselves with this but when they do the P6
approach is simple and convenient.

> one of its major design blunders. Also this syntax!

I see the Int, Int:D, Int:U semantics and syntax as a design triumph. See
another comment in this thread for an introduction to my view:
[https://news.ycombinator.com/item?id=18647590](https://news.ycombinator.com/item?id=18647590)

> I rather use proper maybe types as in every other language.

When I read things like "proper" and "as in every other language" in this
manner I experience them as appeals to authority.

Perl 6 is not a typical language. Just as Perl 5 isn't either.

For example, a P6 compiler is allowed to statically check that types match at
compile time:

    
    
        sub foo (Str $bar) {}
        foo 42
    

yields the compile time error:

    
    
        Error while compiling .code.tio
        Calling foo(Int) will never work...
    

but it doesn't view static type checking as a panacea any more than it
considers dynamic type checking as a panacea.

P6, like Perl, is designed around the notion of a this _and_ that view of
things rather than an _either_ / _or_ view.

