Sand: FAQ
From AJS.COM
This is the Sand FAQ.
Contents |
What is Sand
Sand is a programming language whose closest cousin is Perl 6. Perl 6 is, at this time, under development, and Sand aims to be a limited, simplified subset of its features that allows developers to play with some of the ideas.
Longer term, Sand aims to be a lower-level alternative to Perl 6 that will be useful to a different sort of developer community. The two should be able to co-exist quite happily.
Why remove @ and %
Sand provides a type system, which eliminates most of the need for these sigils. There are several advantages Perl derives from having multiple sigils for variables, but the primary value is in visual disambiguation. Instead of relying on symbols for this, Sand will use explicit typing where appropriate, thus freeing these sigils for potential other uses.
But Perl 6 uses @ and %
Perl 6 uses @ and % because it provides some very ambiguous data types which Sand does not.
Why not use braces to delimit anonymous hashes like Perl
In Sand, complex data is represented, not just visually, but structurally, as a "list". Lists are very flexible objects, and can do many things which Perl hashes cannot (e.g. provide ordered, associative lists; provide a mix of keyed pairs and indexed scalars, etc.)
This flexibility allows the sand programmer to build the data-structure that he or she feels is most appropriate for the work they are doing, and then to decide what type of variable to store it in. If a list is stored into an array typed variable, then it is transformed internally to support fast numeric indexing of ordered values. If it is stored into a hash, then it is transformed to support fast, unordered key lookups. These choices are simply deferred to the type system, rather than the grammar as they are in Perl. Neither approach is wrong, but each has its strengths.
Also, as with @ and %, only using one syntax to enclose all data structures allows Sand to simplify its grammar. In Perl, this is an ambiguous statement that the parser must "guess" about:
sub makeahash { { @_ } }
It turns out that the parser guesses "wrong" (that is, it guesses that you meant to put a block inside of the body of the subroutine, not an anonymous hash).
In Sand, there is never any ambiguity because data is unambiguous:
sub makealist(*$list) { [ *$list ] }
sub makeahash(*$list) { ::hash(makealist(*$list) }
What is a parser block
A parser block is a way of embedding a grammar (the structure of a programming language) into Sand that is not Sand's default. That is, you could place C programming language
code into a Sand program with the appropriate parser block. This allows the free mixing of grammatical structure in a controlled way. The simplest examples of parser blocks in Sand are strings:
qq{This is a string containing the variable \$x which is '$x'}
And rules:
re{ a+ [bc]? }
BlogMarks
del.icio.us
digg
Fark
Furl
Newsvine
reddit
Segnalo
Simpy
Slashdot
smarking
Spurl
StumbleUpon
Wists