named sub-expressions, n-ary functions, things and stuff
All,
As I've continued to develop my Perl-implemented and integratable
RDBMS, a number of aspects have inspired thought for posible
improvements for the Perl 6 language design.
For context, the query and command language of my RDBMS intentionally
overlaps with Perl 6 as much as reasonable; that is, it is a subset
of Perl 6 with a very simple syntax and with domain-specific
additions; so using it should be loosely like using Perl 6. Suffice
it to say that the more of these "additions" that end up being
provided by Perl 6 itself as options or features, the easier my job
will be in making an easily Perl 6 integratable RDBMS product.
The language has a partial profile like this:
- The type system consists of just strong types, each value and
variable is of a specific type, and all type conversions are explicit.
- The type system is explicitly finite, so no Inf etc values, and all
type generators take parameters which specify applicable limits (eg,
0 <= N < 256); a notable exception is that the Bool type is used as
is, without parameterization, because it is already a finite domain.
- There are no Undef or NaN etc values or variables.
- All type definitions include an explicit default value, eg 0 or ''.
- A failure always manifests as a thrown exception, and an exception
is the result of an operator that can't return a value within the
allowed domain, eg when one divides by zero.
- All logic is 2VL not 3+VL.
- All data types are immutable.
- All operators are prefix operators, invoked on their package name,
like with modules that don't export, and not as object methods.
- All operators and functions take exclusively named arguments, and
argument lists are always bounded in parenthesis.
- All core operators and types are pure functions, with no
side-effects, except for the assignment operator, certain shorthands,
and IO-like or monad functions.
- System defined storable types/type-generators include, otherwise as
defined in Perl 6: Bool, Int, Num, Str, Blob.
- Additional system defined storable types include: DateTime etc,
spacial types, the set based concept of a Tuple type, the set based
Relation type.
- All operators that make sense in an n-ary form are declared with
just one main argument which is the list of operands; this includes:
'+', '*', '~', 'and', 'or', 'min', 'max', 'avg', 'union',
'intersection', (relational) 'join'; said operators can also double
for use in list (eg, relation) summarization.
- System defined transient (non-storable) types include: Seq, Set,
Bag; their primary purpose is to facilitate list arguments such for
n-ary operators that hold the operands, or as a short hand for
representing a sorted query result; note that if one wants to store
the same sort of thing, they define an appropriate Relation type
instead.
- It is valid for all generic collection type values to consist of
zero elements; so eg, a Tuple can have zero attributes; zero-ary
values also happen to be the default values for their corresponding
types.
- Users can define their own types and operators.
- Operators can be recursive.
- Any collection type can be composed of any other type, including
collection types.
- Multiple update operations aka variable assignments can be
performed in a single statement, and this statement is atomic; rvalue
expressions see the same consistent system state before any
assignments, and all assignments are performed after all rvalues are
computed; I suppose like Perl's list assignment.
- Multi-level transactions are supported, where any statements within
a transaction level are collectively atomic and can succeed or fail;
any block marked as atomic, and all named routines and try-catch
blocks are atomic; in the last case, a thrown exception indicates a
failure of the block.
- A database is centrally a persistent-like collection of Relation variables.
- A database as a whole, and each of its parts by extension, is
always perceived by users as being in a consistent state, where all
of its defined constraints or business rules are satisfied; any given
mutating statement will only change it from one consistent state to
another, with no inconsistent state visible between statement
boundaries at any level (in ACID terms, it is serializable isolation).
Note that a number of the above features in combination result in a
language grammar that is extremely simple, though somewhat verbose.
But then, it is largely meant to be an explicit intermediate language
or AST that others can target.
Anyway, a few questions or suggestions about Perl 6 ...
1. I'm not sure if it is possible yet, but like Haskell et al (or
some SQL dialects "WITH" clause), it should be possible to write a
Perl 6 routine or program in a pure functional notation or paradigm,
such that the entire routine body is a single expression, but that
has named reusable sub-expressions.
For example, in pseudo-code:
routine foo ($bar) {
return
with
$bar *
Re: named sub-expressions, n-ary functions, things and stuff
On 11/13/06, Darren Duncan <[EMAIL PROTECTED]> wrote: - There are no Undef or NaN etc values or variables. A RDBMS language with no "null" would seem to be problematic.. although i guess you could just use 1-tuples where the empty tuple is treated as null. -- Mark J. Reed <[EMAIL PROTECTED]>
Re: generic ordinal-relevant operators
HaloO, Darren Duncan wrote: For the record, my preference is to have the generics be the shortest, [==,!==,<=>,<,>,<=,>=], and use [+,~] prefixes for Num or Str casting versions. And lengthen the bit-shift operators to use thin-tailed arrowheads as you suggested. I like this proposal for its orthogonality. And it allows to introduce some more binary boolean functions: ?< inhibition?> reverse inhibition ?>= implication ?<= reverse implication (dual of the above) ?== equivalence (dual of xor) The only ones we lack then are nand !&& and nor !|| :) But they fall out naturally from the meta boolean negation ---which means equivalence might be spelled !^^ as well. The low precedence versions might be spelled inh, rinh, imp and rimp. Hmm, and eqv ;) BTW, could we define that the arithmetic shift ops do just that, whereas the string ones do logical shift? And in addition that for the bit inversion +^$a == -1 - $a holds? Note that -1 == +^0. Note further that in infinite precision the arithmetic shift left maintains the sign in two's complement representation and we get the equality $a +<- $n == $a * 2**$n where Int $n >= 0. In this I assume a big endian representation. Hmm, and since + indicates numeric not integer we could even demand $a +-> $n == $a / 2**$n where Int $n >= 0. Well, and we could "shift" with non-Ints through these equalities. Not to mention the introduction of a base used in the shift provided as adverb: $a +->:10 $n == $a * 10**$n. Regards, TSa. --
Re: how to change the type of objects
HaloO, Darren Duncan wrote: What is the point of declaring a type as Rectangle, with those limitations, if you are going to mutate it into not being a Rectangle. There are three issues: 1) the subtyping relation 2) the preservation of object identity 3) the mutating add_vertex method Calling add_vertex() on a mutating Rectangle should necessarily die. This would drop 3) above, which is a violation of 1) as well if you consider throwing exceptions as type error. The better approach would be one of: 1. The user explicitly casts the Rectangle into a Polygon, and then invokes the add_vertex() on it. That is dropping 1) above. The same as my approach but non-automatic. 2. The Polygon class is immutable, and add_vertex() will create and return a new Polygon object with those properties, and the original is still the Rectangle. That drops 2) above, and aligns the type of add_vertex to :(Rectangle --> Polygon) in a pure setting. But I want this signature and all of the above in the sense that an object stays a subtype of Polygon all the time. Actually the return type is the type of the object *after* the call. So it's equivalent to $pg = $pg.add_vertex($x,$y). Note that this doesn't work when $pg is a Rectangle variable. The same applies to my approach even without assignment. So, one question remains unanswered: how does one achieve to get rid of a role? The subset case works automatically and the class case through .bless, I guess. Or is re-blessing not allowed? Note that a Rectangle type might offer things like .width and .height or a simplified .area implementation. Another very interesting point is that the vertex array might be available as a @.vertices array with the corresponding rw accessors so that the type morphing needs to trap e.g. Array::push calls. How would that be coded? Regards, TSa. --
Re: named sub-expressions, n-ary functions, things and stuff
And you may be forced to deal with NaN and Inf values if you are storing raw binary float values as they are built into the bit patterns. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: "Mark J. Reed" <[EMAIL PROTECTED]> > On 11/13/06, Darren Duncan <[EMAIL PROTECTED]> wrote: > > - There are no Undef or NaN etc values or variables. > > A RDBMS language with no "null" would seem to be problematic.. > although i guess you could just use 1-tuples where the empty tuple is > treated as null. > > -- > Mark J. Reed <[EMAIL PROTECTED]>
Re: generic ordinal-relevant operators
TSa writes: > Darren Duncan wrote: > > > For the record, my preference is to have the generics be the > > shortest, [==,!==,<=>,<,>,<=,>=], and use [+,~] prefixes for Num or > > Str casting versions. And lengthen the bit-shift operators to use > > thin-tailed arrowheads as you suggested. > > I like this proposal for its orthogonality. Bzzzt, wrong language! But Perl isn't an orthogonal language, it's a "diagonal" language. http://www.oreilly.com/catalog/pperl2/excerpt/ch01.html For what it's worth, I don't like the proposal because I was already having trouble getting my head round the number of different operators for asking "is this thing at least vaguely like this other thing". Please can proposals for new operators (not just operators, for that matter) be supported by examples along with the form: Look at this awkward code (which could plausibly occur in the wild), and look how less awkward the code is when rewritten using my proposed operator. > And it allows to introduce some more binary boolean functions: Woo, _more_ binary boolean functions -- what a boon! > ?< inhibition?> reverse inhibition > ?>= implication ?<= reverse implication (dual of the above) > ?== equivalence (dual of xor) > > The low precedence versions might be spelled inh, rinh, imp and rimp. > Hmm, and eqv ;) Personally I choose to use a language such as Perl in preference to, say, 6502 Assembly Language, to avoid operators being non-intuitive sequences of three letters. > BTW, could we define that the arithmetic shift ops do just that, > whereas the string ones do logical shift? And in addition that for > the bit inversion +^$a == -1 - $a holds? Note that -1 == +^0. Does that assume a two's complement system? Is that a safe assumption to make about everywhere Perl 6 will run? (Is it even a safe assumption to make about Perl 5?) > Note further that in infinite precision the arithmetic shift left > maintains the sign ... Do we expect Perl 6 to be running on infinite-precision systems? Smylers
[svn:perl6-synopsis] r13475 - doc/trunk/design/syn
Author: larry Date: Mon Nov 13 10:14:35 2006 New Revision: 13475 Modified: doc/trunk/design/syn/S03.pod Log: Added missing generic boolean comparisons as noted by dduncan++. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podMon Nov 13 10:14:35 2006 @@ -12,7 +12,7 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 8 Mar 2004 - Last Modified: 2 Nov 2006 + Last Modified: 13 Nov 2006 Number: 3 Version: 74 @@ -436,13 +436,18 @@ returns C, C, or C (which numerify to -1, 0, or +1). -=item * the C operator (less than, equal, or greater) is defined +=item * The C operator (less than, equal, or greater) is defined in terms of C, so C<$a leg $b> is now defined as C<~$a cmp ~$b>. The sort operator still defaults to C rather than C. The C<< <=> >> operator's semantics are unchanged except that it returns an C value as described above. In other words, C<< $a <=> $b >> is now equivalent to C<+$a cmp +$b>. +=item * For boolean comparison operators with non-coercive C +semantics, use the generic C and C infix operators. +As ordinary infix operators these may be negated (C and C) +as well as reduced (C<[before]> and C<[after]>). + =item * Binary C<< => >> is no longer just a "fancy comma". It now constructs a C object that can, among other things, be used to pass named arguments to functions. It provides scalar context to both sides. @@ -1663,6 +1668,7 @@ fff ^fff fff^ ^fff^ chaining binary != == < <= > >= eq ne lt le gt ge + before after ~~ =:= === eqv !== !~~ !eq !=:= !=== !eqv etc. tight and &&
Re: generic ordinal-relevant operators
Smylers wrote:
Bzzzt, wrong language!
But Perl isn't an orthogonal language, it's a "diagonal" language.
http://www.oreilly.com/catalog/pperl2/excerpt/ch01.html
In the section quoted, it was indicated that "orthogonal" and
"diagonal" are being used to mean "minimalist" and "loaded with
special-purpose tools" (by analogy to "move left, then up" vs. "go
straight to your target"). However, the sense that I'd use
"orthogonal" in this case is "similarly-named operators perform
similar tasks, and differently-named operators perform different
tasks" - i.e., change part of the name in a certain way, and the
functionality changes in a predicatable manner.
IOW, it's all about organizing your toolkit so that you can easily
find the right tool - whereas the meaning referred to above is more
akin to using a swiss army knife instead of a toolkit.
For what it's worth, I don't like the proposal because I was already
having trouble getting my head round the number of different operators
for asking "is this thing at least vaguely like this other thing".
I agree that the distinctions between the five different equality
tests (=:=, ===, eqv, ==, eq) are rather difficult to grasp (I'm still
having trouble getting the difference between '===' and 'eqv', and
would appreciate some help). Part of the problem, however, is that
the names chosen aren't always clear on what the differences are.
Sure, there's the analogy between the '=:=' comparison and the :=
"assignment" (i.e., binding) - so it's obvious to me that '=:=' is an
identity test ("are these two variables bound to the same thing?"),
just like ':=' means "bind this variable to that thing". But beyond
that, confusion reigns. The similarity between 'eqv' and 'eq' implies
a similarity to their operations that isn't there; likewise with '=='
and '==='. IOW, 'eqv' is not to '===' as 'eq' is to '=='; nor is
'eqv' to 'eq' as '===' is to '=='. And '==' means more than just "do
these two variables have the same value?" as one would suppose by
analogy to '=' ("assign a value to the variable") - it means "do these
two variables have the same _numeric_ value?".
By changing things around so that what's currently called 'eqv' is
instead called '==', and the current '==' and 'eq' get replaced by
'+==' and '~==' (which would be "diagonal") or are removed altogether
(which would be "orthogonal"), the analogies between the various
equality tests become more intuitive: '==' and '===' are different
variations of 'test for equality of value' (again, I'm not quite clear
on how they differ), while '+==' and '~==' (if included) are like
'==', except that they qualify their arguments as numbers or strings
before testing (in analogy to the unary + and ~ prefix operators).
--
The strongest argument that I can see _against_ redefining '==' to
mean 'generic equivalence' is that it has a long history of meaning
"numeric equality" in perl pre-6 - which is why I included an
alternate proposal that leaves all existing operator names unchanged.
Please can proposals for new operators (not just operators, for that
matter) be supported by examples along with the form:
Look at this awkward code (which could plausibly occur in the wild),
and look how less awkward the code is when rewritten using my proposed
operator.
Not quite following the letter of your request, but hopefully
capturing its spirit:
I don't like the fact that three very different operator names (cmp,
<=>, leg) all mean subtly different variations of the same thing (what
do legs have to do with comparisons?). I'd rather have it such that
similar operations (e.g., "determine the order between these two
terms") have similar operators - thus, (<=>, +<=>, ~<=>) instead of
(cmp, <=>, leg). I'm hoping to either regularize the set of
comparison operators by banishing letter-soup versions as described
above, or to streamline it by ditching the implicit-coercion forms
entirely: under this minimalist version of the proposal, if you want
to ensure a numeric comparison between $a and $b, you'd say '+$a <=>
+$b'; and a string comparison would be '~$a <=> ~$b'. Under the
"organized toolkit" version, they'd be "$a +<=> $b" and "$a ~<=> $b",
respectively.
--
I have a problem with extending the numeric-vs-string comparisons idea
to include boolean comparisons, and then using those as logical
operators: my problem is that the resulting operators start looking
less like operators ('→') and more like line noise ('?>='), and they
aren't very intuitive (logical implication generally is not thought of
as an ordinal comparison of truth values, and I'd expect an awful lot
of people to type something like '?->' or '?=>' and expect it to mean
implication). In addition, precedence and associativity don't
neccessarily match up correctly: these kinds of "logical operators"
would have a higher precedence than &&, and would be list-associative.
If you're going to add more logical operators (which I don't have much
of a problem with, other t
Re: named sub-expressions, n-ary functions, things and stuff
At 11:00 AM -0500 11/13/06, Mark J. Reed wrote: On 11/13/06, Darren Duncan <[EMAIL PROTECTED]> wrote: - There are no Undef or NaN etc values or variables. A RDBMS language with no "null" would seem to be problematic.. although i guess you could just use 1-tuples where the empty tuple is treated as null. In SQL, the "null" is used for multiple distinct meanings, including 'unknown' and 'not applicable', and having to deal with it makes an RDBMS more complicated to implement and use by an order of magnitude. In practice, there are multiple better ways that users can indicate "unknown" or "not applicable" etc, and that can be done using the other features. At 5:35 PM + 11/13/06, [EMAIL PROTECTED] wrote: And you may be forced to deal with NaN and Inf values if you are storing raw binary float values as they are built into the bit patterns. All data types in my RDBMS are boxed types that hide their implementation from the user, so details about bit patterns used by numbers are abstracted away; as particular implementations define it, numbers may not even be floats at all; they could be rationals or strings or whatever the implementer wants to use, but the user doesn't have to care. The only place raw bit patterns appear is in the Blob type, but those are undifferentiated so the bits don't mean anything but to the user. If users have a NaN or Inf they want to store, they can't do it as a database native finite integer or number; but like with nulls, there are other ways to record what users want to know. In any event, I'm interested in knowing what people think about having named sub-expressions supported in Perl 6 and/or giving it stronger pure functional syntax or paradigm support; pure functional means there are no variables or assignment, as far as users are concerned. -- Darren Duncan
Re: named sub-expressions, n-ary functions, things and stuff
Darren Duncan writes:
> 1. I'm not sure if it is possible yet, but like Haskell et al ..., it
> should be possible to write a Perl 6 routine or program in a pure
> functional notation or paradigm, such that the entire routine body is
> a single expression, but that has named reusable sub-expressions.
I realize it isn't pure functional, but in Perl a C block permits
arbitrary code to be treated as a single expression. Or to put it
another way round, you can use temporary variables inside the expression
that don't 'leak out' of it.
> For example, in pseudo-code:
>
> routine foo ($bar) {
> return
> with
> $bar * 17 -> $baz,
> $baz - 3 -> $quux,
> $baz / $quux;
> }
>
> This is instead of either of:
>
> routine foo ($bar) {
> return ($bar * 17) / ($bar * 17 - 3);
> }
That's obviously bad cos of the repetition.
> routine foo ($bar) {
> my $baz = $bar * 17;
> my $quux = $baz - 3;
> return $baz / $quux;
> }
But what does a functional form have over that? Or over the C
version:
my $whatever
= do { my $baz = $bar * 17; my $quux = $baz - 3; $baz / $quux };
Sure there are variables. But in terms of how your brain thinks about
it is it any different from the functional version -- labels being
associated with intermediate parts of the calculation?
Smylers
[svn:perl6-synopsis] r13476 - doc/trunk/design/syn
Author: larry Date: Mon Nov 13 17:09:46 2006 New Revision: 13476 Modified: doc/trunk/design/syn/S03.pod Log: Add infix min and max as form of "||" to enable meta mods like min= or »max« Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podMon Nov 13 17:09:46 2006 @@ -14,7 +14,7 @@ Date: 8 Mar 2004 Last Modified: 13 Nov 2006 Number: 3 - Version: 74 + Version: 75 =head1 Changes to Perl 5 operators @@ -448,6 +448,12 @@ As ordinary infix operators these may be negated (C and C) as well as reduced (C<[before]> and C<[after]>). +=item * Infix C and C may be used to select one or the other +of their arguments. Reducing listop forms C<[min]> and C<[max]> are +also available, as are the C and C assignment operators. +By default C and C use C semantics. As with all C-based +operators, this may be modified by an adverb specifying different semantics. + =item * Binary C<< => >> is no longer just a "fancy comma". It now constructs a C object that can, among other things, be used to pass named arguments to functions. It provides scalar context to both sides. @@ -1672,7 +1678,7 @@ ~~ =:= === eqv !== !~~ !eq !=:= !=== !eqv etc. tight and && -tight or|| ^^ // +tight or|| ^^ // min max conditional ?? !! assignment := ::= => (also = with simple lvalues)
Re: named sub-expressions, n-ary functions, things and stuff
At 11:24 PM + 11/13/06, Smylers wrote: Darren Duncan writes: > 1. I'm not sure if it is possible yet, but like Haskell et al ..., it should be possible to write a Perl 6 routine or program in a pure functional notation or paradigm, such that the entire routine body is a single expression, but that has named reusable sub-expressions. I realize it isn't pure functional, but in Perl a C block permits arbitrary code to be treated as a single expression. Or to put it another way round, you can use temporary variables inside the expression that don't 'leak out' of it. Hmm. I may have to think some more, but it appears that a C block may be sufficient for what I wanted, which was to embed reusable named parts inside of an arbitrary larger expression. Thank you. -- Darren Duncan
