Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
On 4/9/2010 4:53 AM, Moritz Lenz wrote: Am 09.04.2010 13:34, schrieb Mark J. Reed: The date still corresponds to an actual day. If I set it to Feb 31, I should get back Mar 2 or 3 depending on the year. While I'm having trouble thinking of a good specific example, it's a capability I've taken advantage of many times, in holiday calculations, calendar conversions, and such. I believe it's Python's datetime module that has unchecked_* methods for the purpose. Maybe in p6 the setters could do the correction if the exception is resumed? Too much magic. Sounds to me like you want a named parameter for a setter, like :force or :unchecked or so. Anyway, I'm not sure such a feature needs to be in the core, at least not in 6.0.0. Unless forming a duration based on various units is really simple, un-checked setters makes generating new Instants from one ones simpler. It is very useful to be able to implement the operators tomorrow, yesterday, thirty_days_from_now, twelve_hours_ago, etc, just by incrementing through the appropriate setter, especially in one-liners. -- m...@biggar.org mark.a.big...@comcast.net
Re: Range and continuous intervals
Darren Duncan wrote: In reply to Jon Lang, What I'm proposing here in the general case, is a generic collection type, Interval say, that can represent a discontinuous interval of an ordered type. A simple way of defining such a type is that it is a Set of Pair of Ordered, where each Pair defines a continuous interval in terms of 2 ordered end-points, and the whole set is discontinuous (or replace Pair with 2-element Seq). There is no need for a separate type for this as it's just an internal storage optimization method for the type Set. Note that a sparse enough value just degenerates into a Set anyway. -- m...@biggar.org mark.a.big...@comcast.net
Re: infectious traits and pure functions
Martin D Kealey wrote: But if you have objects and nested functions, the exact inference rule gets a whole lot more complicated. With exceptions, threads and co-routines it's a nightmare. In the general case, if your language has both pure and impure functions, proving (at compile time) that something is not impure is an NP-complete problem. Worse it's equivalent to the halting problem (I.e., not solvable). In general any non-trivial property of a program of the form Does this program ever do ... is equivalent to the halting problem. Mark Biggar -- m...@biggar.org mark.a.big...@comcast.net
Re: Collapsing Junction states?
Darren Duncan wrote: Larry Wall wrote: It seems simpler to say that one() produces bags rather than sets. If we don't make other modifications to the language then this would mean that a Junction is defined over a union type, Set|Bag with additional behaviors, depending on what operator constructed it. Now maybe that's fine. Or alternately, why not just redefine a Junction for consistency to say it is a Bag with additional behaviors rather than a Set with additional behaviors? Would doing this break anything? Do any intended uses of a Junction specifically versus a plain Set|Bag involve asking how many instances of a value there are, or asking how many distinct values or value instances are in the Junction? Aside from the 3 answers: exactly none, exactly one, one or more? The meaning of any() and all() do not change if the collection is allowed to be a Bag instead of a Set. There are two reasonable meanings for one(), either duplicates collapse done to single members of the collection or duplicates cancel (or are ignored, same thing). The later interpretation would mean that one(1,2,3,3) is the same as one(1,2), but constants aren't the interesting case, one(@a) is. I suppose we could define a :uniq(true|false) adverb to modify the meaning of one() so we could have both interpretations. Mark Biggar
Re: Short-circuiting user-defined operators
Paul wrote:
--- Austin Hastings [EMAIL PROTECTED] wrote:
Dave Whipp wrote:
Joe Gottman wrote:
Getting deep -- sorry. :)
Alternatively, there might be a new parameter type that indicates
that the parameter is not evaluated immediately:
sub infix:!! ($lsh, $rhs is deferred) {...}
If the standard is pass-by-ref it wouldn't trip any side effects unless
you did so in your code, right? So is this necessary?
There are two reasonable semantics for deferred parameters:
1) lazy evaluation with caching, where the evaluation of the
actual expression in the call is deferred until the sub
actauly makes use of it and the result is then cached and
reused as necessary. Any side effects happen only once.
2) ALGOL style pass by name, where the actual expression from the
call is turned into a clouser called a thunk which is called
when ever the sub access the parameter. Note that the thunk
may need to be an lvalue clouser to handle is rw paramenters.
Side effects happen each time the thunk is called. Also changes
to the thunks environment can effect its value when called.
Either of those can have threading added as well.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: A6: argument initializations via //=, ||=, ::=
Damian Conway wrote:
I don't see how ::= (compile-time-bind) can be used as the
initialize-if-non-existent operator.
I mean, it happens in the wrong phase (compile-time, not run-time) and
it does the wrong thing (binding, not assignment).
The only case I can think of where is might be useful is with a
optional parameter with an is rw trait, so you could provide an
default binding. Possible example:
sub myprint(+$file is IO:File is rw ::= IO:STDOUT, [EMAIL PROTECTED]) {...}
open f /a/d/v/f/r;
myprint file = f, Hello World!\n; # goes to f
myprint Differnet World!\n;# goes to IO:STDOUT
although maybe what I really want is := instead.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: a thought on multiple properties
Jonathan Scott Duff wrote:
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be completely off, as I'm still digging my way
through A6):
class Foo {
method bar is public is rw {
}
}
Becoming:
class Foo {
method bar is public rw {
}
}
Guess it just reads a bit better to me.
I don't think that junctions make sense here. Besides, the is is
optional:
class Foo {
method bar is public rw const frob knob { ... }
}
What we do need is some way of bundling a bunch of traits together
under a simple name. This is especially useful for long involved
types. Some of the type name examples in A6 are very long and
if you needed to use the type several places, are not only a pain to
type but you run into the is it real the same every where problem
and the did I change it every where problem. As a general principle
any time you have a long complicated token string that need to be
use multiple places, you need a way to assign it a short hand name.
Yes, a string macro will do it, but has a couple of problems:
1) difficult to generate associated error messages
2) macros are very heavy weight for this
Defining a Class for this is also overkill.
Maybe something like
rule traitdef :w { trait ident trait* ; }
So instead of saying:
my %pet is Hash of Array of Array of Hash of Array of Cat;
sub feed (%cats is Hash of Array of Array of Hash
of Array of Cat) {...}
You could say
trait cat_table is Hash of Array of Array of Hash
of Array of Cat;
my cat_table %pet;
sub feed (cat_table %cats) {...}
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Wrappers vs. efficiency - quick comment
John Siracusa wrote: From A6: I worry that generalized wrappers will make it impossible to compile fast subroutine calls, if we always have to allow for run-time insertion of handlers. Of course, that's no slower than Perl 5, but we'd like to do better than Perl 5. Perhaps we can have the default be to have wrappable subs, and then turn that off with specific declarations for speed, such as is inline. I think there's a lot of room between allow this subroutine to be wrapped and inline this subroutine. Whatever the specific declaration for speed is that forbids runtime wrapping of a subroutine, it should not be spelled inline. (although inline may imply dontwrapmeplease or whatever :) I don't see how a sub being inline-able prevents being wrap-able. In most langausges an inline declaration is only a suggestion and often there is a real version of the sub in addition to any inlined copies. Besides a wrapped inline sub is in no different situation as a inlined sub being called in another inlined sub, this seem to be all part of what the compiler has to be able to do to deal with a recursive sub that is also declared inline. -- Mark Biggar [EMAIL PROTECTED]
Re: Arrays: Default Values
Austin Hastings wrote: There is no reason why primitive-typed arrays can't have a default. It is the confusion of default with undef that is causing this problem. If I have: my int @a; print @a[4]; What comes out? Notice, there's no is default(woo-woo) in there. Just a plain old primitive array. I imagine that each primative type will have a default default :-) int0 str'' num0.0 etc. and if we define a prop is no_default then you get what ever junk happens to be in memory. (this for even more speed) -- Mark Biggar [EMAIL PROTECTED]
Re: Arrays: Default Values
In my opinion, default values for arrays should only come into play for array elements that have NEVER been assigned to or that have been explicity undef'ed. If an assigment is made to an array element then the array element should end up the assigned value (modulo necessary type conversions) and the array's default value should not play any part in the assignment. After an explisit assignment of an array element the only way that the array's default value should magically reappear is if an undef of the element is done. Any other way to handle things, like some of the other ways proposed will only lead to mysterious bugs and programmer missunderstandings. -- Mark Biggar [EMAIL PROTECTED]
Re: String concatentation operator
Martin D Kealey wrote: On Mon, 2002-11-18 at 18:10, Dave Whipp wrote: Why do we need to use preemptive threads? If Parrot is a VM, then surely the threading can be implemented at its level, or even higher. And what about *lower*? Like down among the CPUs? I want Perl to run 128 times faster on a 128 CPU machine... now I know that's not entirely realistic, but it should be able to run at least say 60 times faster. Amdahl's law applies here: no amount of paralellism will speed up an inheirently sequential algorithm -- Mark Biggar [EMAIL PROTECTED]
