Characterize the design of the perl6 language.

Many people, even in the perl community, even in the perl _6_ community,
have only a fuzzy impression of what perl6 is, why it is interest as a
language, and how it's design compares with other languages.

This file is an attempt to create a one to three paragraph answer to the
question "What is perl6?", asked from the perspective of language
design.  Rather than from that of say history, or of some user group.
Perhaps a more general "what_is_perl6" file is needed too.

The file is organized with a synthesis at the top, and then discussion
below.  Some todo's at bottom.

The work is in its infancy.

----------------------------------------------------------------------
First, a paper airplane warning.

The old saying is a paper airplane (one still on paper, in design,
untested, and not yet degraded by the effort to make it reality)
will always out fly (perform) a metal airplane.

Perl6 is a work in progress, both as a design and implementation.
And there are multiple implementations, which currently, and for
the foreseeable future, have varying characteristics.

----------------------------------------------------------------------
Current best synthesis

What is a characterization of the design of the perl6 language?

  Perl6 is a flexible hybrid language.


----------------------------------------------------------------------
Synthesis discussion

Might be nice to have a "summary by analogy".  Eg, a hybrid of perl,
haskell, and...?  A mix of scalia's mumble, foo's bar, ...?

Here is a "pile of stuff" version:

  Perl6 is a flexible hybrid language.  Tail-recursive.  Source (not
  image) based.


======================================================================
Topical discussion

----------------------------------------------------------------------
Unsorted questions

Tail recursion?  Yes.
Closures?  Yes.  First-class lexical closures.

Continuations?

  Yes, but?  Escape continuations yes.  But full continuations only on
  some implementations?

Macros?

  Yes.  ...
 
Pattern matching?  Yes.

Exceptions?  Yes.

Garbage collection?

  Yes.  Including optional guaranteed (ie block exit) prompt collection.

Pattern matching?

Assorted polymorphisms?

Assorted categories of types?

----------------------------------------------------------------------
Paradigm

Imperative? Yes.

Declarative?  Not so much.  But see discussion of flexibility/CPAN.

Functional? Yes.

Object-oriented? Yes.

Prototype/class-based?  Hybrid.

Concurrent?  Not so much.

Distributed?  Not so much.

Write once run anywhere?

  Not clear?  That is the perl tradition.  But it gets violated in that
  some core functions are not supported by some OSes.  Perl6 has
  aggressive capabilities that may not be supported on all
  implementations.  Eg, full continuations.

Event-driven?

  Unclear?  Dan's vision of parrot would have made pervasive
  event-drivenness possible.  Now?

Source/image?  Source.


----------------------------------------------------------------------
Typing

Description:




Static/dynamic?  Hybrid.
Strong/weak?  Hybrid.
Safe/unsafe?  Optional.
Nominative/structural/duck?  Mostly nominative, some structural.  Can duck.

Strongly typed?

  Maybe, it depends what you mean.

. () Yes, static typing. () Yes, compile-time checks. () Type safety...?
  Maybe.  See discussion elsewhere.  () No, type conversion.  () No,
  implicit type conversion.  () Maybe - It is not clear whether you can
  evade/deceive the type system. [but] () Yes, a complex, fine-grained
  type system with compound types.  () Maybe - It is not entirely clear
  if the type of a given data object can vary over that object's
  lifetime. [but] () No, no strong guarantees about the run-time
  behavior of a program.

  [but] At a minimum, the one can likely do this outside the core language.
  Definitional punchlist taken from 
    http://en.wikipedia.org/wiki/Strongly-typed_programming_language

Type conversion?

  Implicit type conversion?  Yes.
  Explicit type conversion / Casts?  Yes.
  Evade/deceive?  ???
  Alter an object's type / .become?  No?  ???

Static?

  Yes.

Dynamic?

   Yes.

Duck?

  As a capability, yes - it follows from dynamic typing.  As a design
  philosophy, it seems unlikely to play a major role.  Certainly not as
  much as in Ruby, simply because the type system is so flexible that
  there are many other organizational options.

Structural subtyping?

  OCaml: There is no built in formalism of type equivalence based on
  method signatures.  However, there are predicate types, and perl6 is
  fully reflective, so structural subtyping would depend only on the
  compiler implementing such optimizations as meet ones desire for
  performance.

Type inference?

  Yes.

======================================================================
Doables

So very, very, much.
Think up questions, answer them.
Distill current individual answers upwards into the synthesized answer.
Mine computer language comparisons and taxonomies for questions.