Idea: infir types of constants
Just surfing, I noticed something about the D programming language: The types of constants need not be specified explicitly as the compiler infers their types http://en.wikipedia.org/wiki/Type_inference from the right-hand sides of assignments. const fact_7 = Factorial!(7); Now in C++, templates can be used to make function return types go along with their argument types, for generic arguments. In Perl 6, I think you would have to arrange to write the return type later rather than sooner to do this: sub foo (::T $a, T $b) is of T and writing it the other way around would violate the one-pass parsing. So, how would you write the constant above in Perl 6, without knowing specifically what foo returned? I'm thinking of a situation where you have foo as a method of a generic class, or otherwise depends on a generic type parameter already. But, it could be an expression not just a function call, and depend on the generic types present in outer scopes in a less-than-simple way. my Type $x = $a ⊗ $b; With C++, I would have to hope that the template writer thought to give the return type of that function a snappy name, rather than just referring to it as an inline conglomeration that involves the generic types. The compiler knows what that type is. How do I refer to it? Can I say, declare $x to be the type of the right-hand-side, rather than making me name it and checking that I got it right, or leaving it off and not having compile-time checking and optimization for subsequent use of $x ? Here's an idea: a pseudo-type of the form ::?RHSTYPE. I could even capture it for subsequent use, like with generic type parameters: my ::?RHSTYPE ::ProdType $x = $a ⊗ $b; my ProdType $y = $x; --John
A TEMP block?
S06 Temporization, along with 'temp' variables, defines a TEMP block.
Do we really need such a thing? It appears to be a LEAVE block with another
level of indirection. Hmm, that is, the body of the TEMP block executes at its
normal place at run-time, unlike the episodic blocks it resembles; the return
value is appended to the LEAVE trait.
It seems difficult to generate a closure at run time (as opposed to just
cloning one specified at compile time), so I wonder why you would need to do
that.
It also makes me think about traits on cloned closures or specific instances of
routines. But again, I don't think we really need to have individual instances
of routines have their own traits distinct from the Routine object itself,
since you can accomplish that using variables subject to cloning within the
closure in the trait (e.g. the LEAVE trait).
In short, can we drop
TEMP {{ $next = $curr }}
?
Re: Clarify Design by Contract
John M. Dlugosz wrote:
PRE/POST on methods:
When applied to a method, the semantics provide support for the Design by
Contract style of OO programming: a precondition of a particular method is
met if all the PRE blocks associated with that method return true. Otherwise,
the precondition is met if all of the parent classes' preconditions are met
(which may include the preconditions of their parent classes if they fail,
and so on recursively.)
In contrast, a method's postcondition is met if all the method's POST blocks
return true and all its parents' postconditions are also met recursively.
If the PRE blocks on the method don't all return true, it appeals to the
preconditions on the base class of the class defining the method? I don't
get it. Why would a class-level precondition override a method-level
precondition? Why bother defining them on the method, if they are ignored if
they are false anyway?
Finally one that I'm able to answer ;-)
class MyMath {
method sqrt($x:) {
PRE { $x = 0 }
# your calculation here.
}
}
Now whenever you have an object of Type MyMath, you can be sure that
it's valid to pass any non-negative number to sqrt.
If a inherited class could harden that precondition, that assumption
would be false. That's why it's only allowed to weaken preconditions:
class MyComplexMath is MyMath {
method sqrt($x:){
PRE { True }
# your calculation here
}
}
This is described in depth in Object oriented software construction by
Bertrand Meyer.
If you want to harden a precondition, you can revert to addtional methods:
class MyMath {
method can_take_sqrt($x:){
$x = 0;
}
method sqrt($x:){
PRE { $x.can_take_sqrt }
...
}
}
class MyComplexMath is MyMath {
method can_take_sqrt($x:){
True
}
...
}
That way a user of class MyMath can always call can_take_sqrt() to check
if she can satisfy the precondition.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Idea: infir types of constants
John M. Dlugosz wrote: Just surfing, I noticed something about the D programming language: The types of constants need not be specified explicitly as the compiler infers their types http://en.wikipedia.org/wiki/Type_inference from the right-hand sides of assignments. const fact_7 = Factorial!(7); Doesn't perl do this when you don't specify a type? constant $pi = sub_that_calcs_pi(); Since static types are optional, I don't see the point in explicitly speccing type inference. That's only stating that type information is determined at compile time, which seems like an optimization to me that doesn't need to be in perl 6.0.0. Of course any implementer is welcome to do perform that optimization where possible ;-) Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Nomenclature Question - BEGIN etc.
How about 'contingent blocks', because they are contingent on some event, without having to use the word 'event'. Richard TSa wrote: HaloO, Larry Wall wrote: Hmm, maybe control event blocks and control events, then... I would call them flow blocks because this is where they are called and what they influence: the flow of execution. This nicely matches the flow charts used to describe the control flow. The other term I would thing is synonymous to flow is stream. But that's already taken for event stream, data stream and implies linearity whereas flow naturally implies branching. The third term I come up with is context blocks. But context in Perl 6 is something very different. Regards, TSa.
Re: Idea: infir types of constants
I'm thinking that if strong typing is enabled, mixing untyped and typed things will cause warnings or errors that need not be there. I'm thinking that 'constant' is more special than other variables, and that the formal description of strong typing and static types should say that the compiler =will= implicitly get the type for $pi rather than making it Any. Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: Doesn't perl do this when you don't specify a type? constant $pi = sub_that_calcs_pi(); Since static types are optional, I don't see the point in explicitly speccing type inference. That's only stating that type information is determined at compile time, which seems like an optimization to me that doesn't need to be in perl 6.0.0. Of course any implementer is welcome to do perform that optimization where possible ;-) Moritz
Re: Clarify Design by Contract
Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: This is described in depth in Object oriented software construction by Bertrand Meyer. OK, reading about it in Wiki, I see what it's supposed to do. PRE - derived classes may weaken but not strengthen. So if it fails, but the preconditions of the same method on the base class pass, that means you wrote the precondition wrong. Rather than ignoring that, shouldn't it be an error? --John
Re: Q on function returning
On Apr 13, 2008, at 1:20 , John M. Dlugosz wrote: So, what is the role of the inner and outer return types that are declared on the function? While some details have changed since then, you might want to review this thread: http://www.mail-archive.com/perl6-language@perl.org/msg21114.html (The meaning of returns) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Idea: infir types of constants
On Apr 13, 2008, at 2:02 , John M. Dlugosz wrote: In Perl 6, I think you would have to arrange to write the return type later rather than sooner to do this: sub foo (::T $a, T $b) is of T and writing it the other way around would violate the one-pass parsing. Just from looking at this (and not the Synopses) I would guess: our ::T sub foo (T $a, T $b) without needing to introduce a new twigil syntax for type variables. (Although I would wonder if the whole ::-prefix thing is asking for trouble; it looks like scoping to me.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Clarify Design by Contract
John M. Dlugosz wrote: Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: This is described in depth in Object oriented software construction by Bertrand Meyer. OK, reading about it in Wiki, I see what it's supposed to do. PRE - derived classes may weaken but not strengthen. So if it fails, but the preconditions of the same method on the base class pass, that means you wrote the precondition wrong. No. Only if it *always* fails. PRE conditions between a class and its ancestors are OR'ed - there's nothing wrong if one part of an OR branch evaluates to false. Rather than ignoring that, shouldn't it be an error? Only if the compiler can prove that the condition is always false. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Help understanding syntax in S06 Pairs as lvalues
:(:who($name), :why($reason)) := (why = $because, who = me); What do the symbols $name and $reason refer to? Are they names already in scope? Alternately, the my declarator can also force treatment of its argument as a signature. That would be my (:who($name), :why($reason)) := (why = $because, who = me); which declares $name and $reason, and poises them for aliasing to named return values. Signatures normally are used as the beginning of functions and introduce local variables. --John
the nature of 'temp'
Does 'temp' operate on the value or on the container?
The text starts, The temp macro temporarily replaces the value of an existing
variable... and the description seems consistent with that.
temp $*foo = 'foo';
The restore feature is generated by calling VAR($*foo).TEMP, and the method
Scalar.TEMP can call its own STORE method.
But then there is the example
temp bar := sub {...};
That is, it uses binding rather than assignment, which applies to the container
itself.
How can the container, which is Routine, know about the caller's bar symbol?
That is, bar.TEMP, might be defined in Routine to be
method TEMP ($self:)
{
...
return sub { $self := $originalvalue }
}
it can rebind the $self argument which it closed over, but that will not affect
the original caller's bar variable. The aliasing of parameters to arguments is
done by pointing to the same container.
Does anybody disagree with me? That just doesn't compute.
Now what we really want here is to temporarily replace the meaning of the
function call. Routine already has the ability to be changed in-place, which
is what .wrap does. So we should simply allow .STORE to use the same ability,
and then ordinary assignment, not binding, works.
temp bar = sub {...}; # use = not :=
The use of assignment calls the container's STORE, or whatever it will be named
on Callable containers (there is no precedent in Perl 5's tie interface). The
use of temp will call Routine.TEMP for a closure, and it can work exactly like
it does in a scalar: use its own STORE method to put back the saved value.
This change (just the one line of example) affects S06 under Temporization.
--John
RE: cross operator and empty list
-Original Message- From: Moritz Lenz [mailto:[EMAIL PROTECTED] Sent: Saturday, April 12, 2008 10:37 AM To: [EMAIL PROTECTED] Cc: p6l Subject: Re: cross operator and empty list [EMAIL PROTECTED] wrote: Technically the Cartesian cross operator doesn't have an identity value. It has. The set which contains only the emty set, or in perl terms ([]); Or am I missing something? Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ Should be a (any) 1 point set for the identity. How about considering models from category theory, rather than set theory ? Seems much more fruitful for computer issues than set theory. - Hugh Miller e-mail: [EMAIL PROTECTED]
context vs context
The term context is used for two different purposes. I don't like that. The context can refer to list context, item context etc. The context can also refer to the dynamic calling chain, which are Context objects navigated by the context function.
Re: cross operator and empty list
Miller, Hugh wrote: From: Moritz Lenz [mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Technically the Cartesian cross operator doesn't have an identity value. It has. The set which contains only the emty set, or in perl terms ([]); Or am I missing something? Should be a (any) 1 point set for the identity. How about considering models from category theory, rather than set theory ? Seems much more fruitful for computer issues than set theory. No an identity would be a set E such that for any set A: A x E = A, but no such set exists. A singleton set get close, but the result is only isomorphic (there is a natural bijection) not equal. Even in category theory you only get isomorphism. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
