|author||Yorhel <firstname.lastname@example.org>||2012-02-19 11:21:32 +0100|
|committer||Yorhel <email@example.com>||2012-02-19 11:21:32 +0100|
doc: tanja.pod -> spec.pod + specify that wildcars are allowed in tuples
|-rw-r--r--||spec.pod (renamed from tanja.pod)||61|
1 files changed, 29 insertions, 32 deletions
@@ -1,8 +1,3 @@
-TODO: What about allowing wildcards in Tuples?
-TODO: Allow binary strings in tuples?
-TODO: Allow the value NULL/nil in tuples?
-TODO: More ordering constraints on message receival?
@@ -21,13 +16,20 @@ Each element may be of a different type. Allowed types are:
=item * Booleans
+I<TODO:> Get rid of booleans and stick with integers instead?
=item * Arrays with elements of allowed types
+The elements of the array do not have to be of the same type. A tuple itself is
+therefore also an array.
=item * Mapping between strings and allowed types
This includes hash tables and structs. The order of the key/value pairs should
not matter. The values in a map do not necessarily have to be of the same type.
+=item * Wildcards
A I<pattern> is similar to a tuple, but has a smaller set of allowed types:
@@ -44,12 +46,11 @@ A I<pattern> is similar to a tuple, but has a smaller set of allowed types:
-That is: Floating point numbers, arrays and maps are not allowed in patterns,
-but patterns do have a special I<wildcard> value.
+That is: Floating point numbers, arrays and maps are not allowed in patterns.
-All integers should be representable in either a signed (two's complement) or
-unsigned 64bit integer. Thus anything in the range of C<-2^63> to C<2^64-1>
-(both inclusive) are valid integer values.
+All integers should be representable in a signed (two's complement) 64-bit
+integer. Thus anything in the range of C<-2^63> to C<2^63-1> (both inclusive)
+are valid integer values.
The maximum precision of floating point numbers is dictated by the
implementation. In practice, this can be expected to be either single precision
@@ -57,6 +58,7 @@ or double precision IEEE 754 floating points.
Strings should be encoded in UTF-8.
Tuples are I<matched> using patterns. This is much like pattern matching in the
@@ -70,22 +72,22 @@ either of the following holds:
-=item 1. The element in the pattern is a wildcard
+=item 1. Either element is a wildcard
=item 2. The elements are of the same type, and their value is equivalent.
-The first rule is trivial: if the element of the pattern is a wildcard, then
-the corresponding element in the tuple can be of any type and value. The second
-rule is slightly less obvious, and requires the type definitions given in the
-previous section to be interpreted properly. One implication of the second rule
-is that it is impossible to do a non-wildcard match on anything other than
-integers, strings and booleans, since values of other types are not allowed in
-patterns. Another thing to keep in mind is that both values have to be of the
-same type, so the integer C<0> is not equivalent to the boolean C<false>. Nor
-is the string C<"15"> equivalent to the integer C<15>. However, integers are
-always equal if their numeric value is equivalent (provided they are within the
+The first rule is trivial: if the element of either the pattern or the tuple is
+a wildcard, then other element can be of any type and value. The second rule is
+slightly less obvious, and requires the type definitions given in the previous
+section to be interpreted properly. One implication of the second rule is that
+it is impossible to do a non-wildcard match on anything other than integers,
+strings and booleans, since values of other types are not allowed in patterns.
+Another thing to keep in mind is that both values have to be of the same type,
+so the integer C<0> is not equivalent to the boolean C<false>. Nor is the
+string C<"15"> equivalent to the integer C<15>. However, integers are always
+equal if their numeric value is equivalent (provided they are within the
specified range). This means that if, within an implementation, a tuple with an
element of type uint8 with value C<5> is matched against a pattern with an
element at the same location of type int64 and with the same value, then these
@@ -94,19 +96,17 @@ their characters have the same unicode values. Strings are thus matched in a
case-sensitive fashion. The above rules also imply that the tuple must hold at
least as many elements as the pattern.
+I<TODO:> Allow integer-formatted strings to do match integers of the same value?
+I<TODO:> Allow the integer C<10> in a pattern to match a float C<10.0> in a tuple?
-=head1 Communication primitives
-There are a total of four communication primitives: I<register> and I<response>
-for receiving messages and I<send> and I<request> to send messages. The term
-I<message> is a synonym for I<tuple> in this context - all communication is
-performed with tuples.
-I<TODO: describe what a "session" is.>
+I<TODO:> Describe the terms "network" and "session"
-=head2 Send / register
+I<TODO:> Refactor with the return-path being an argument of I<send>.
Send and register are the two simplest form of communication. A session uses
the I<register> primitive to indicate that it is interested in receiving tuples
@@ -132,7 +132,4 @@ session sent them. Besides that, there are no ordering restrictions: Messages
sent by two different sessions may be received by an other session in any
-=head2 Request / response
+I<TODO:> More ordering constraints on message receival?