Commits

Anonymous committed 99e12a5

Commited.

Comments (0)

Files changed (5)

t2/links.html.wml

 software freedom and other oddities.
 </p>
 
+<h3><a href="http://www.linuxmafia.com/~rick/">Rick Moen</a></h3>
+
+<p>
+Net-geek for hire and Linux Guru extra-ordinaire. Contains more philosophical
+than technical information about Linux, but still useful stuff. Includes: why
+forking does not happen a lot and is not a threat, and a guide to establishing
+a successful Linux User Group.
+</p>
 
 
 </div>

vipe/prog-evolution/index.html.wml

+#include '../template.wml'
+<subject "My Evolution as a Programmer" />
+
+<p>
+This is an auto-biography of myself as a software engineer with many interesting
+ancedotes. It is work in progress. I hope you'll find it amusing and a bit
+instructive.
+</p>
+
+<h2>Chapters</h2>
+
+<define-tag doc:versions>
+<set-var url="%0" />
+<td>
+<a href="<url />.html">HTML</a>
+</td>
+<td>
+<a href="<url />.pod">Perl POD Source</a>
+</td>
+<td>
+<a href="<url />.txt">Text</a>
+</td>
+</define-tag>
+
+<table style="border-width: 1">
+<tr>
+<td>
+The Pre-Elpas Years
+</td>
+<td>
+describes Shlomi Fish
+as a child and teenager programmer before his first serious work as one.
+</td>
+<doc:versions "pre-elpas" />
+</tr>
+</table>

vipe/rindolf/Makefile

-BASE = rindolf-spec
-
-all: $(BASE).html $(BASE).txt
-
-$(BASE).html: $(BASE).pod
-	pod2html $< > $@
-
-$(BASE).txt: $(BASE).pod
-	pod2text $< > $@

vipe/rindolf/index.html

-<html>
-<body bgcolor="white">
-
-<h1>Rindolf Specification</h1>
-
-<p>
-<a href="rindolf-spec.pod">POD File (source)</a>
-</p>
-
-<p>
-<a href="rindolf-spec.html">HTML (viewable online</a>
-</p>
-
-<p>
-<a href="rindolf-spec.txt">Plain-Text</a>
-</p>
-
-</body>
-</html>

vipe/rindolf/rindolf-spec.pod

-=head1 Rindolf Specification Document
-
-=head1 Version
-
-0.1.15
-
-=head1 Introduction
-
-This document is meant to describe the Rindolf programming language which
-is a dialect of Perl. It describes the main changes between it and Perl version
-5.6.x.
-
-Good knowledge of Perl is assumed.
-
-=head1 Author
-
-Shlomi Fish
-
-E-mail: shlomif@vipe.technion.ac.il
-
-Homepage: http://t2.technion.ac.il/~shlomif/
-
-=head1 Philosophy
-
-The purpose of this section is to explain the motivation behind Rindolf,
-what it is meant to accomplish, and what not. This section should be
-consulted before one wishes to add new functionality to Rindolf, in
-order to see if it corresponds with the philosophy.
-
-=head2 The Assumptions behind Rindolf
-
-1. Perl is a B<family> of programming languages.
-
-2. Perl 5 is a good language.
-
-3. Perl 5 is not good enough.
-
-4. Rindolf aims to be an improved and re-engineered Perl 5.
-
-=head2 Explanation
-
-There are in fact several languages that can be thought of as Perl dialects.
-Perl 4, Perl 5, and Perl 6, and to a slightly less extent, PHP, are all members
-of the Perl family of languages. Rindolf aims to be another one, based mostly 
-on Perl 5, with many extensions and ideas borrowed from other languages 
-(whether Perlish or otherwise) and elements that I thought of myself, but may
-have a precendant somewhere.
-
-The purpose of Rindolf is to take Perl 5 and create a language that is more 
-consistent, more powerful, cleaner (as far as its recommended coding style
-is) and more fun. It is not the perfect language for anything, and it is 
-possible that some people will still not like it.
-
-Many times one hears the claim that Perl 5 code is by nature "obfuscated", 
-"hard to understand", "does not scale to large codebases", and so on. Part 
-of the reason for such claims, is that people did not get very used to Perl. (
-to quote Euclides, "There is no King's Road to Mathematics"). But another
-facotr is the various inconsistencies one faces when having to write and 
-maintain large or semi-large Perl codebases.
-
-To me it seems that Perl 6 aims to integrate all or most of the things people
-expect to see in any computer language. Some kind of Common Lisp in regard to 
-Perl. However, it also breaks a lot of compatibility and so will be hard
-to port existing Perl 5 code to. Perl 6 may eventually be a wonderful language.
-"But it's not going to be Perl".
-
-Rindolf aims to be a Perl 5 derivative that will fix the critical problems
-with Perl 5. Things like only one class in a namespace, too much magic,
-obscure global variables, or a limited set of operators. It would be a Perl
-that people can port existing Perl 5 code to with relative ease, yet will
-give them powerful extensions and additions, if they are willing to use
-it exclusively.
-
-=head2 Why another Programming Language?
-
-Paul Graham answers the same question in the Arc FAQ. (Arc is a new 
-dialect of Lisp which he develops at the moment). I realize there's 
-an inflation of languages around. However, I happen to like Perl and
-would like to see a dialect of it, that will fit my expectations perfectly.
-
-I'm not too content with Perl 6, and some elements of Perl 5 frustrate me,
-so that puts the entire future of Perl in jeopardy as far as I'm or many
-people like me are concerned. Being an individiualist, I decided to 
-start my own dialect, so I and others can enjoy all the power of 
-Perl 5 with as small an amount of its inconsistencies as possible.
-
-=head2 What Rindolf is
-
-1. A dialect of Perl that is mostly compatible with existing Perl 5 code.
-
-2. A good language for writing most programs, that are not very time-sensitive
-and a good deal of programs that are.
-
-3. It aims to take Perl 5 and make it cleaner, more consistent, more powerful,
-and thus, hopefully, more fun.
-
-4. A language in which the more estoric and least used or understood 
-features of Perl 5 will be deprecated and can generate warnings or even
-exceptions. (see below)
-
-5. Rindolf is more conservative about integrating paradigms and features
-than Perl 6. Some features which users find useful in other languages
-may not be integrated because they don't fit the general philosophy of
-the language, or are not commonly used enough to justify it.
-
-=head2 What Rindolf is not
-
-1. It is not a language optimal for doing intense, number-chrunching, 
-calculations. It should be able to embed such code, however.
-
-2. It does not aim to be a back-end for several distinct languages by itself.
-For this, one have to rely on its underlying virtual machine (Parrot, the JVM,
-.NET, etc)
-
-3. It is not a replacement for Python, Ruby, Tcl, Bash, APL, Lisp, Scheme, 
-Haskell or whatever. Not every language is suitable for every task.
-
-4. It is not, and does not aims to be the least common multiple of all 
-existent computer languages. There are some things that can be easily
-done in other languages which won't be very straightforward in Rindolf.
-
-5. It aims to support most of the existing central programming paradigms
-(Structured Programming, OOP, Functional Prog, Literate Prog, Programming
-through Patterns, Meta-Data Programming, etc.). However, it does not enforce
-those paradigms onto the programmer.
-
-=head1 Compatibility (or incompatibility) with Perl 5
-
-=head2 The C<.> and C<-E<gt>> Operators will Remain the Same
-
-I'm keeping C<.> for string concatenation and C<-E<gt>> for dereferencing. 
-This is done as opposed to the Perl 6 Apocalypses in which C<_> was assigned
-as string concatentation and C<.> was assigned for dereferencing.
-
-=head2 our() to be an Alias for C<use vars qw( ... )>
-
-I read about our() in the L<perlfunc> man page and it seemed like an 
-exceptionally bad idea. I'd like to simply make it an alias for 
-C<use vars( ... )>, with slightly better appearance. I'm doing it 
-because our() seems like the most cognitively sound choice for such 
-a keyword out of the keywords that I can think of.
-
-=head2 Scalar context
-
-I don't like scalar context, and the C<scalar()> or C<wantarray()>
-keywords very much. The way I see it, most people will cognitively
-think of C<scalar()> as a function rather than as a directive
-that enforces a scalar context.
-
-In Rindolf scalar context will be deprecated, and use of it can be 
-toggled to generate a warning (although perhaps not by default). To get
-the length of an array one can use C<count(@myarray)>. Likewise, there
-will be a dedicated function to reverse a string (which will be shorter to
-write than C<scalar(reverse(...))>) and so forth.
-
-Perl makes it perfectly possible to write more functions or closures 
-to fill in the void, instead of having a scalar and an array 
-function ambiguity. 
-
-Another issue: at the moment C<"hello" x 5> produces a string,
-while C<("hello") x 5> produces an array. Since the former is equal to
-C<join("", ("hello") x 5)>, or to a function or specialized operator 
-that will be assigned to it, I'd like to make the C<x> operator 
-non-ambiguous. Again, backward compatibility is an issue one must consider 
-before making such a decision.
-
-=head2 Throwing Exceptions when Issuing Warnings
-
-In Rindolf it would be possible to expand warnings (or specific classes of
-them) into exceptions. That way, a programmer can be sure that a
-warning is trapped, and not just goes unnoticed on the command-line.
-
-
-=head2 A Better Thread-Safe Replacement for most Special Variables
-
-=head2 Non-magical C<do { ... }> construct
-
-Do use C<do { ... } while();> in Perl. I avoid it like a plague because I
-can think of at least three better ways to achieve it and it confuses
-the debugger senselessly. I'd like to make C<do { ... }> something
-like C<eval { ... }>, but without catching exceptions.
-
-=head2 Extended Prototypes
-
-In Rindolf the concept of function prototypes will be extended, so that
-functions similar to all built-in functions can be expressed in their
-terms. 
-
-At the moment, a prototype of a procedure is a flat list of tokens
-which each indicates the type of the argument that needs to come in its
-place. A better and more flexible alternative needs to be thought of
-while consulting L<perlfunc> for such functions. 
-
-My best idea so far consists of an expression for them, that will
-remind many people of regular expressions. (say, with question marks 
-indicating optional variables).
-
-=head1 New Additions to the Language
-
-=head2 Namespace-scoped Classes.
-
-The C<class MyClass { ... }> construct will behave much like the 
-C<sub MyFunc { ... }> construct and will allow to declare namespace-scoped 
-classes. A namespace scoped class is a "lightweight" namespace, which is 
-accessible from the outside, but will be over-ridden by explicit 
-namespaces of the same name.
-
-Declaring a class inside this class construct is similar to using the 
-package-scoped class. The purpose of this construct is to:
-
-1. Allow scripts or modules to be self-contained OO-wise.
-
-2. Enable to construct classes on the fly.
-
-=head2 Classes as First-Order Objects
-
-The expression C<$myvar = class { ... };> will assign a lexically scoped 
-class variable to C<$myvar>. The following operators can be used to
-manipulate classes:
-
-C<extend> - Extends a class with new variables.
-
-C<expand> - Expands a class into the current namespace. It's kind of like
-a non-persistent run-time inheritance.
-
-To accompany with this change, the special variable C<@ISA> can also
-hold class references, and C<bless()> also accepts them too.
-
-=head2 Two New Primary Namespaces
-
-The namespace C<this> will point to the current package. For instance, if
-we are in C<MyPack> and we want to access C<MyPack::MyClass> we can
-use C<this::MyClass> instead. Specifying a class which is not prefixed
-by C<main> or C<this> will try either one or both, depending on the 
-name-mangling parameters of the run-time program.
-
-Similar to C<this>, C<theclass> accesses the current class, even if it's 
-not a proper package. For example:
-
-    #!/usr/bin/perl
-    # Or is /usr/bin/rindolf ...
-
-    class Parent
-    {
-        class Child
-        {
-            sub myfunc
-            {
-                print "myfunc() was called!\n";
-            }
-        }
-
-        sub ya_func
-        {
-            theclass::Child::myfunc();
-        }
-    }
-
-    this::Parent::ya_func();
-    # Prints myfunc() was called!
-
-I am not entirely sure about it, but I may also introduce an C<up> namespace
-which works similarily to the C<..> directive in UNIX path-names.
-
-=head2 A Basic File Primitive 
-
-Perl will feature a basic file primitive which is a first order object. 
-Typeglobs will in fact provide a small amount of convenience and syntactic 
-sugar to it, but will not be the only way to use it. (In fact, typeglobs could
-theoretically also be used for things other than files).
-
-This primitive will support all the basic file operations and even those 
-provided by open2(), open3(), sockets, etc. It may reside in its own hard-coded
-namespace or may simply have an awkward prefix like aFile_open(), aFile_read() 
-so mortals will not want to use it.
-
-This primitive will also have several built-in classes that use it to implement
-lexically scoped files. I find that using them would be preferable over 
-Typeglobs. Therefore, Typeglobs will exist, but they would be slightly 
-deprecated, and can be warned against by using C<use warnings;> or the C<-w>
-flag.
-
-=head2 Preprocessor
-
-Rindolf source files will be preprocessed using a preprocessor. The 
-preprocessor will be Turing Universal, will have a built-in ad-hoc analysis
-of Perl code, and will have diversion mechanism similar in spirit to m4
-or WebMetaLanguage. The reason why I don't opt for a simpler one is because
-otherwise people cannot rely on it to accomplish everything they'd like to.
-
-The Preprocessor will fill the following purposes: (among the many uses
-that users can find to it)
-
-=over 4
-
-=item Declaring new operators
-
-See below. Note that newly declared operators do nothing by default and need
-to be bootstrapped with something using Perl code.
-
-=item Defining Useful Macros
-
-Stuff like C<map { ... } @myarray> that will be expanded to 
-C<mapblock block { ... } @myarray>.
-
-=item Loop Unrolling and other such tricks.
-
-=back
-
-=head2 Adding new operators
-
-The preprocessor will enable the addition of new operators to the language in
-some manner or the other. After compilation the syntax of the language will
-cannot be modified in any way, however. It would be possible to define
-prefix, postfix, infix, surrounding, etc. operators.
-
-The reason I am introducing them is this: when I worked with PDL I quickly
-realized that Perl 5's C<*> operator was made the element-wise multiplication
-of two matrixes, while C<x> was the matrix multiplication. In Matlab, which PDL 
-aims to replace, C<*> is matrix multiplication while C<.*> is an 
-element-by-element multiplication of it. If you ask me, C<x> should better
-be used as a Kronecker Multiplication, but naturally the PDL people
-did not have much of a choice.
-
-This is just one example, where the inability to introduce new operators can
-actually make it very hard on the API designer. Therefore, adding operators
-of various precedence would be possible in Rindolf and the PDL people
-can bind C<.*>, C<.**>, etc to their hearts' content.
-
-This will complicate the implementation, and will make it necessary to compile
-the tokenizer and the LALR parser on the fly (if we can use them at all). 
-Nevertheless, I think it is feature that is worth the extra programming 
-and possibly run-time overhead.
-
-=head2 Literate Programming
-
-I plan for Perl to have a support for various Literate Programming systems,
-while maintaining such things as line number consistency, etc. I encountered
-various such schemes and I thought or been suggested more:
-
-=over 4
-
-=item TeX/LaTeX based
-
-=item DocBook SGML/XML based.
-
-=item Perl POD 
-
-Not exactly literate programming but a similar idea, technically
-
-=item JavaDoc/Doxygen style code in comments 
-
-Probably should not bother us, but nonetheless existent. I'm also not sure
-it's literate programming
-
-=item HTML based
-
-=item Something proprietary that the user may come up with
-
-=back
-
-I suggest that the front-end of the Rindolf implementation will have a generic
-way for extracting the code and maintaining its consistency. Perhaps
-the preprocessor will be enough to implement them, but it is possible that
-a separate pass will be needed.
-
-=head2 Proper-Tail Recursion
-
-The primitive C<pt_return> will behave much like C<return> except for being
-implicitly properly tail recursed whenever possible. C<line_return> on the
-other hand, would be explicitly non-properly tail recursed. (C<pt> stands
-for "proper-tail" or "point").
-
-C<return> will be one or the other, depending on the default set by the user. 
-Rindolf will have a flag for specifying which one of the options is the default,
-and there will be a pragma to toggle it:
-
-    use recursion 'default' => 'pt';
-
-The reason both ways are possible is because proper tail recursion is faster,
-but improper tail recursion is easier to debug. So there should be more
-than one way to do it.E<lt>tmE<gt>.
-
-=head2 Key-Value Pairs
-
-An idea borrowed from Perl 6, in Rindolf Key-Value Pairs would be atomic.
-The C<=E<gt>> operator will construct them, and will no longer be 
-synonymous with the comma (C<,>). I find it essential to maintain hash
-integrity and make sure values don't turn into keys when initializing
-long hashes.
-
-The "Key" of a Key value pair may be a reference, which should allow for more
-elaborate tricks and greater flexibility. More over, a hash reference may be
-"locked" (not in the multi-threading sense), so that no new keys can be added. 
-This will make it easier for objects to avoid typos, and may eliminate the
-I<StrictHash> CPAN module or make its job easier and faster.
-
-=head2 Array Locking
-
-Similar to hash locking one can also lock arrays, so that one cannot write
-to elements beyond C<$myarray[count(@myarray)]>. One can take this further
-and specify that writing is not allowed, or only C<push()> may be used, etc.
-
-I believe all of those things can be accomplished using L<perltie>, but
-they would be nice to have in the core language.
-
-=head2 Unlimited post-line iterators and conditionals
-
-Perl 5 limits the types of loops and conditionals that can be presented 
-after the statement. In Rindolf, however one can have all of the builtin 
-ones without limit as long as the statement is a single line (not a compound
-statement) or a C<do { ... }> or C<eval { ... }> call.
-
-For example:
-
-    # Let's generate the list of primes up to 10,000 with a very
-    # inefficient algorithm
-    @primes=(2);
-    push @primes, $a
-        unless (grep { $a % $_ == 0 } @primes)
-            foreach $a (3..10000);
-
-    # Eat your heart out, Haskell. (Well, not really)
-
-=head2 Full Unicode Support and Behaviour
-
-Rindolf will have a full internal support for Unicode 
-input/output, text processing and the various issues that arise from it. Since
-I myself rarely use or generate internationalized text, or code i18n stuff,
-I'd like to out-source the job of forming a model for it.
-
-Note that I would still like to approve the API, because I want it to
-be consistent with the rest of the language.
-
-=head2 An "out-of-scope" Stub for Values
-
-At presnet, if a Perl programmer wishes to get acknowledgement that a scalar
-went out of scope, he needs to use a class or some I<perltie> games. To
-remedy this fact, Rindolf will have a function for assigning a callback 
-in case a value went out of scope. That way, people can implement a user-land 
-object system without relying on Perl's to bootstrap them.
-
-Its temporarily assigned name will be C<on_destroy()> until someone suggests a
-name that is equally descriptive, about as long or shorter, and is more
-exotic. Here's a simple example:
-
-    sub myfunc
-    {
-        my $a = "hello";
-        my $b = 500;
-
-        on_destroy($a, 
-            sub { 
-                print $b, "\n";
-            }
-            );
-        
-        print "\$b is ";
-    }
-
-    &myfunc();
-
-    # prints "$b is 500"
-
-=head1 LISP-like Features
-
-Prof. Mayer Goldberg of the Ben-Gurion University once referred to Perl 5 as
-"LISP with cancer". Undoubtedly, Perl 5 has many features that exist in 
-LISP dialects such as Scheme and Common Lisp. The purpose of Rindolf is to 
-continue this trend while adding more LISP-like features and enhancements.
-
-Yet, I'm not going to convert Rindolf to use S-Expressions. ;-) That's what
-Scheme or Common-Lisp or Arc are for, and Rindolf does not aim to be a 
-replacement for them. On the other hand, it will try to give most of their
-power without too much loss of generality.
-
-One feature that is missing is LISP-macros proper. Since implementing such
-mechanisms require passing the macro an argument that is a syntax tree, I'd
-rather keep this out of Rindolf in order to not complicate the parser too 
-much.
-
-=head2 Re-usable Blocks
-
-Rindolf will have re-usable blocks as first-order objects. The syntax would be 
-something like that:
-
-    my $myblock = block {
-        $result += $iter;
-    };
-
-A block will be compiled and error-checked at compile time (recursively), but 
-the variables contained in it may or may not be available where it was
-constructed. A block can be executed in an arbitrary number of times and 
-places. 
-
-For example, the following snippet uses $myblock:
-
-    my ($result);
-    for my $iter (1 .. 100)
-    {
-        expand($myblock);
-    }
-    print "The sum of numbers from 1 to 100 is $result;\n"
-
-expand() is a the block running function whose name is subject to change
-in further versions of this Spec, as I'm not sure about it.
-
-One can see that using blocks it is possible to implement functions similar to
-map(), sort() and grep() in user-land. In order to start an implicit block 
-without using the block function, one can use the preprocessor for this 
-purpose.
-
-=head2 Re-usable Virtual Machines Instances
-
-Rindolf will enable one to spawn an arbitrary number of the interpreter's 
-instances, without multi-processing games. Those VMs would be special objects
-that can be used to execute, stop, save the state or examine another Rindolf 
-VM. (all while using only Perl code)
-
-=head2 Parsing and Analyzing of Rindolf Code
-
-Rindolf will supply the user with the possibility of analyzing a subroutine 
-or block's code, by providing a tree of the block's expressions. This tree
-should be a generic tree type that will be derived from a more general class
-for parsing and analyzing general syntax of programs. 
-
-Accessing the subroutine's tree can be done directly, without parsing its 
-human-readable code first. 
-
-=head2 C<eval> on a Different Environment
-
-In akin to some implementations of Scheme (and to the theory put forth in 
-the fourth chapter of I<Structure and Interpretation of Computer Programs>),
-Rindolf will support a primitive that will give a reference to the environment
-structure in its scope, and an eval that will accept an optional environment
-argument.
-
-This will enable running C<eval> with different scopes than the C<eval>'s 
-calling scope. For example:
-
-    my $the_env;
-    
-    sub create_frame
-    {
-        my $var = shift;
-
-        $the_env = environment();
-        
-        return sub {
-            print "\$var is \"$var\"\n";
-        };
-    }
-
-    my $closure = create_frame("Hello");
-
-    eval '$var = "Something Else"', $the_env;
-
-    $closure->();
-
-    # Prints:
-    # $var is "Something Else"
-
-=head1 Minor Enhancements
-
-=head2 accum and accum_r
-
-These are two accumulators similar to Haskell's C<foldl> and C<foldr>. For 
-example:
-
-    # Sum up all the @numbers
-    my $sum = (accum { $r = 0; } { $r += $_ } @numbers);
-
-    # Assign result as 5.833
-    # This is equivalent to (accum { $r = 1} {$r = $_/$r;} (7,6,5));
-    my $result = (accum_r { $r = 1; } {$r /= $_ } (5,6,7));
-
-=head2 Hashes as Sets Operations
-
-I'd like Rindolf to have some hard-coded functions for operations on hashes
-as sets. Things like Union, Intersection, Slice, etc. What should be noted
-is that the user may wish different stuff to happen to the hashes' values
-in the process.
-
-=head2 Module that will Contain Common Accumulators
-
-These are some common accumulators that can be used to perform various
-operations on lists. Examples include C<Accum::min>, C<Accum::max>, 
-C<Accum::sum> and C<Accum:product>.
-
-=head1 Implementation Constraints
-
-=head2 Proper Garbage Collection
-
-Rindolf will not leak memory, in case self-circular references get out of 
-scope. I believe Self-circular data, while being relatively rare, can prove to
-be a useful tool when building abstractions. Even doubly-linked lists require
-them. Thus, Rindolf will have a garbage collector that is good enough to 
-ensure such leaks do not happen.
-
-=head2 An Easier to Use Bindings and Embedding Interface
-
-At the moment, extending Perl with C extensions or Embedding it, is notorious
-for being relatively difficult and picky process. One of the goals that
-should be placed for an implementation of Rindolf is that it would be 
-more straightforward.
-
-=head2 Inherent Instantization and Multi-Threadability
-
-The Perl Run-Time Library can be instantized by a hard-coded program that
-embeds it an arbitrary number of times. Each instance will not interfere
-with one another.
-
-Further more, every instance would be multi-threaded. perl 5.6.1 can be
-compiled as other non-multi-threaded or with two distinct threading models. 
-In Rindolf I'd like to reduce the number of compile-time options to a 
-minimum, in order to make sure a programmer can rely on features to be 
-present everywhere. Therefore, a unified multi-threading model will be
-present in the interpreter, to prevent confusions.
-
-=head1 Perl 6 Elements that will be Kept out of Rindolf
-
-From my impression and from my understanding of the Perl 6 RFC process, Perl 6
-was meant to include a lot of things that anyone can possibly want in Perl. 
-While this may actually be a good idea for designing a language, I am trying
-to have Rindolf fix the critical things with Perl 5, rather than provide
-everything everybody can possibly want.
-
-That's why I reject some (if not most) of the ideas which I encountered in 
-the Perl 6 Apocalypses. Here is a brief list of those that need some 
-explanation why.
-
-=head2 Lazy Lists
-
-Lazy lists (and lazy evaluation in general) are no doubt a powerful 
-abstraction, as I have learned from doing some Haskell programming. However, 
-effectively having them require building an entire Lazy-evaluation engine
-into the Perl language which has been almost completely iterative until now.
-
-This is not something I'd like to put into the language, in order to not
-over-complexify the implementation, and not confuse the users too much. 
-However, I do not rule out people having lazy lists and lazy evaluation
-mechanics in user-land, but it won't enter the core language for now.
-
-=head2 A Mandatory Type System
-
-Perl is dynamically-typed and most Perl programmers are very fond of this
-idea. Statically-typing a variable by coercing it to be an integer, an 
-arbitrary-precision integer, a floating point number, a string or whatever 
-can greatly aid in execution time due to the nature of the underlying 
-virtual machine. 
-
-However, this is a feature I'd rather not put in the first release of the 
-language because it has many caveats and stuff like that (an array which is
-a 3*5*10 matrix of integers, a hash whose keys are strings and values are 
-longs). I believe the extra overhead of not having a static type system will
-be worth it, for keeping the language simpler.
-
-If someone wishes to write a very fast numeric code, he should use compiled
-C code, or Parrotized Jakko or whatever. Perl is not good for anything, and 
-the way I see it, it should not be.
-
-=head2 Batch Operations on Tensors
-
-I am reluctant to insert them into the core language from the same reason as 
-in the previous section: Perl is dynamically typed and has arbitrary-length
-arrays, etc. What should we do if we wish to have an element by element 
-addition of those two arrays:
-
-    ([ 5, 6, 7, 8, 9], [2, 3]) @@+ ([500, 600], [100, 200, 300, 400, 500, 600])
-
-Should we pad them with zeros to make the sub-arrays the same length? Or
-perhaps truncate them? I believe that with the "insanity" that Perl data 
-structures can assume, defining such operators in the core language 
-would be useless.
-
-Again, since one can declare new operators in Rindolf, such operations
-can be defined in user-land, by over-loading the operator for the first time. 
-The PDL people can do it for their tensors, because they are implemented 
-as memory buffers, and they make many type and dimension checks. 
-Furthermore, developers may code such mechanics for Perl data 
-structures using their own heuristic for what happens at any point. 
-I, on my part will neither sanction nor reject such behaviour.
-
-By the way, one can add two arrays together by using the following code:
-
-    sub add_arrays
-    {
-        my ($x, $y) = @_;
-        
-        return [ (map { $x->[$_] + $y->[$_] } (0 .. min($#$x, $#$y))) ];
-    }
-
-It would probably be faster if it were implemented in C. Nonetheless, 
-it shows that this feature is something that can be done in user-land and
-quite efficiently. (It gets a bit messier when having multi-dimensional 
-tensors, but can be made to be quite elegant.)
-
-=head1 Joke
-
-"How can one make a language that will be good for anything, if you cannot
-even make such a screw-driver?"
-
-I<Chen Shapira>
-
-=head1 Thanks
-
-I'd like to thank Larry Wall for designing and implementing Perl up to Perl 5 
-and making a tremendous computer language. My feelings toward Perl 6 range
-from the ambivalent, to the complete "Why do I need it for?", but I respect
-him for at least making an effort into designing a better dialect of it. Those
-who do not do anything, don't achieve anything either.
-
-I'd like to thank my real-life and/or electronic friends who inspired me into
-making this hubris-ful step and try to design my own dialect: Mulix, Chen 
-Shapira, Omer Mussaev, Dave Goehrig, Omer Zak, Guy Keren and others.
-
-I'd also like to thank Omer Zak for giving some early suggestions (which I did
-not like too much) and for suggesting that I write a preliminary specification 
-before I proceed further. I'd also like to thank Dave Goehrig (again) for 
-giving me some useful input on programming languages and paradigms, and on
-giving some insights on the way things are implemented in the perl 6 
-interpreter. (and from talking me out of needlessly removing some features
-that would break backward compatibility with Perl 5 code).
-
-I want to thank Damian Conway for encouraging me to pursue this interest, and 
-for suggesting that I choose a different name than "Perl 5 - The Next 
-Generation" which was my original idea for a name. Also, Prof. Mayer 
-Goldberg for inspiring me to introduce more LISP-like features into Perl 
-and for reminding the importance of preprocessor diversions.
-
-To lesser extent one should thank all the language designers who introduced
-features that were integrated into Perl or Rindolf. And so forth all the way
-back to Aristotle for formulating his Organum (and beyond).
-