Re: Time::Local
On Tue, Aug 16, 2005 at 01:18:58PM +1200, Sam Vilain wrote: : On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote: : : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0 : : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of : : any UTC interferences. But there is an argument for making the zero point a : : recognizable boundary in civil time. : That's my leaning--if I thought it might encourage the abandonment of : civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC. : : If we're going with TAI, can't we just nail it to the epoch it defines, : instead? Because I'm a megalomaniac, silly dilly. Plus I like round numbers. Not to mention the fact that it makes it really easy to calculate days since 2000, give or take a squishy leapsecond or three. But the best part is that if we abandon UTC leap seconds for civil time, we don't have to remember leap seconds going forward, only backward from 2000. But mostly because I'm a megalomaniac, and think I can change the world. Larry
The value of +hello
Exegesis 3 contains this snippet, my $inflation; print Inflation rate: and $inflation = + until $inflation != NaN; but the rule that +hello evaluates to NaN is no longer mentioned in S03, according to Autrijus. He suggested I post here to get a ruling. -- Daniel Brockman [EMAIL PROTECTED]
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
On Thu, Aug 11, 2005 at 01:35:14AM +0800, Autrijus Tang wrote: On Wed, Aug 10, 2005 at 07:32:01PM +0200, TSa wrote: you wrote: Perl 6 in its unannotated form is also (mostly) a typeless languages, with only the five builtin types, much like Perl 5 is. Counting the sigil quadriga as 4, what is the fifth element? @ $ % :: In Perl5, :: is replaced by *. Strictly in Perl 5 there are 7 types SCALAR, ARRAY, HASH, CODE, GLOB, FORMAT and IO. (where IO might actually be 2 types, file handles and directory handles, and in turn FORMAT is implemented as a subtype of CODE. Also, internally there are 16 variants of SV*, with mostly a 1 to 1 mapping for all the types except SCALAR, which sort of absorbs the other 10. Except that the null SV type is easily directly morphable into any of the others. Mmm. I guess this about sums up Perl 5 - ultimately it's defined by the implementation in the C source. (IIRC first remarked on by Chip)) Nicholas Clark
Type inferencing for Perl5
On Tue, Aug 16, 2005 at 02:04:41PM +0100, Nicholas Clark wrote: On Thu, Aug 11, 2005 at 01:35:14AM +0800, Autrijus Tang wrote: On Wed, Aug 10, 2005 at 07:32:01PM +0200, TSa wrote: Counting the sigil quadriga as 4, what is the fifth element? @ $ % :: In Perl5, :: is replaced by *. Strictly in Perl 5 there are 7 types SCALAR, ARRAY, HASH, CODE, GLOB, FORMAT and IO. (where IO might actually be 2 types, file handles and directory handles, and in turn FORMAT is implemented as a subtype of CODE. Also, internally there are 16 variants of SV*, with mostly a 1 to 1 mapping for all the types except SCALAR, which sort of absorbs the other 10. Except that the null SV type is easily directly morphable into any of the others. It would be great if we can use a type-directed transform from Perl 5 syntax tree into PIL/Perl6, i.e. annotate each term with the 16 variants, maybe with union/intersection types that represents ambiguous context, such as: f(reverse(g())); Hm, I seem to remember that Gary Jackson (cc'ed) is working on that, as his Summer of Code project. Gary, can you share with us how you plan to approach that, and/or how to get involved to your project? Thanks, /Autrijus/ pgpjNvj5wXL3I.pgp Description: PGP signature
Re: GC API from discussion
On Mon, 15 Aug 2005 12:40:05 +0100, Adrian Howard [EMAIL PROTECTED] wrote: On 15 Aug 2005, at 02:13, David Formosa ((aka ? the Platypus)) wrote: After a very fruitful discussion I've rewritten my suggested GC API. Comments please. [snip] I'm speaking from complete ignorance since I've only been vaguely following the subject... but four additional things that strike me as useful (because I found them so in Pop-11 when I used it) would be: Stealing usefull things from other langagues is good. 1) Some way of declaring objects as being fixed so we can pass them to external code without having to worry about the GC moving them around. I think that the FFI would take care of that via handels. [...] 2) Some way of being able to tell the garbage collector to ignore the current contents of the heap for the purposes of GC. One Pop-11 idiom was to do something like: Part of that is why we have the GC::tardy traint and Cno GC::delay. But Cno GC::destroy preventing the desctruction of objects in its lexical scope. [...] 3) Some way of marking structures/fields so their reference doesn't count. Weakrefs basically. I have strongly thought about adding weakrefs into the API. However I recall $larry basically saying the need for weak refs means you have got your design wrong. However google doesn't seem to find it. Unless I hear words otherwise I'll add it in the next revision. 4) Hooks to run code before/after GC. Occasionally very useful. (e.g. with the gc hooks and heap locking/unlocking you could implement your own ephemeral GC system in Pop-11). Not all GC's have before and after concepts. (pure refcounting and mulithreaded models for example). I think that these hooks would be added via the object interface. Hopefully this makes some vague sort of sense. Thankyou it was helpfull. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Re: Time::Local
Taimu? TAI- -mu. Sorry. Couldn't resist the pun. (Bad Japanese pun, but nonetheless.) -Jasmine 2005/8/15, Sam Vilain [EMAIL PROTECTED]: On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote: : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0 : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of : any UTC interferences. But there is an argument for making the zero point a : recognizable boundary in civil time. That's my leaning--if I thought it might encourage the abandonment of civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC. If we're going with TAI, can't we just nail it to the epoch it defines, instead? Sam. -- Don't presume to lecture me about good and evil. I've been there, you've just seen a map. -Orson Scott Card -- http://www.spreadfirefox.com
Re: Time::Local
On Mon, 15 Aug 2005, Larry Wall wrote: But the best part is that if we abandon UTC leap seconds for civil time, we don't have to remember leap seconds going forward, only backward from 2000. So you want to take on the (very irritating, I tell you) burden of leap seconds going _backwards_ but not going forwards? But that's in contrast to your saying that the epoch would be December 31, 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Mon, Aug 15, 2005 at 09:21:14PM -0400, Jasmine Pues wrote:
: Taimu? TAI- -mu.
:
: Sorry. Couldn't resist the pun. (Bad Japanese pun, but nonetheless.)
Well, hmm, yes, taimu means time in Japanese, but only because it's
borrowed... ☺
On the other hand, if you're willing to coin a new Japanese word,
we can generate all the combinations of Jouyou Kanji that can be
pronounced TAI MU and see what they mean together:
#!/usr/bin/perl
use utf8;
binmode STDIN, :utf8;
binmode STDOUT, :utf8;
binmode STDERR, :utf8;
@tai = split /^/, 'END';
大 big
太 fat, big
体 body; health
台 stand, platform
対 oppose, against, pair
待 wait
代 replace, world, generation, fee
帯 belt, obi, wear, zone
隊 corps, unit
退 retreat, withdraw
貸 lend, loan
態 appearance, intent
耐 endure, bear
怠 be lazy, neglect
胎 womb
泰 calm, serene, big, thai
袋 bag, pouch
逮 chase, seize
替 exchange, swap
滞 stop, stagnate
END
@mu = split /^/, 'END';
武 military, warrior
務 (perform) duty
無 not, none, cease to be
謀 plot, strategem
矛 halberd, lance, spear
夢 dream
霧 mist, fog
END
chomp @tai;
chomp @mu;
for my $tai (@tai) {
($tk, $te) = split(' ', $tai, 2);
for my $mu (@mu) {
($mk, $me) = split(' ', $mu, 2);
printf %s%s%s / %s\n, $tk,$mk, $te, $me;
}
}
which gives us these possibilities.
大武 big / military, warrior
大務 big / (perform) duty
大無 big / not, none, cease to be
大謀 big / plot, strategem
大矛 big / halberd, lance, spear
大夢 big / dream
大霧 big / mist, fog
太武 fat, big / military, warrior
太務 fat, big / (perform) duty
太無 fat, big / not, none, cease to be
太謀 fat, big / plot, strategem
太矛 fat, big / halberd, lance, spear
太夢 fat, big / dream
太霧 fat, big / mist, fog
体武 body; health / military, warrior
体務 body; health / (perform) duty
体無 body; health / not, none, cease to be
体謀 body; health / plot, strategem
体矛 body; health / halberd, lance, spear
体夢 body; health / dream
体霧 body; health / mist, fog
台武 stand, platform / military, warrior
台務 stand, platform / (perform) duty
台無 stand, platform / not, none, cease to be
台謀 stand, platform / plot, strategem
台矛 stand, platform / halberd, lance, spear
台夢 stand, platform / dream
台霧 stand, platform / mist, fog
対武 oppose, against, pair / military, warrior
対務 oppose, against, pair / (perform) duty
対無 oppose, against, pair / not, none, cease to be
対謀 oppose, against, pair / plot, strategem
対矛 oppose, against, pair / halberd, lance, spear
対夢 oppose, against, pair / dream
対霧 oppose, against, pair / mist, fog
待武 wait / military, warrior
待務 wait / (perform) duty
待無 wait / not, none, cease to be
待謀 wait / plot, strategem
待矛 wait / halberd, lance, spear
待夢 wait / dream
待霧 wait / mist, fog
代武 replace, world, generation, fee / military, warrior
代務 replace, world, generation, fee / (perform) duty
代無 replace, world, generation, fee / not, none, cease to be
代謀 replace, world, generation, fee / plot, strategem
代矛 replace, world, generation, fee / halberd, lance, spear
代夢 replace, world, generation, fee / dream
代霧 replace, world, generation, fee / mist, fog
帯武 belt, obi, wear, zone / military, warrior
帯務 belt, obi, wear, zone / (perform) duty
帯無 belt, obi, wear, zone / not, none, cease to be
帯謀 belt, obi, wear, zone / plot, strategem
帯矛 belt, obi, wear, zone / halberd, lance, spear
帯夢 belt, obi, wear, zone / dream
帯霧 belt, obi, wear, zone / mist, fog
隊武 corps, unit / military, warrior
隊務 corps, unit / (perform) duty
隊無 corps, unit / not, none, cease to be
隊謀 corps, unit / plot, strategem
隊矛 corps, unit / halberd, lance, spear
隊夢 corps, unit / dream
隊霧 corps, unit / mist, fog
退武 retreat, withdraw / military, warrior
退務 retreat, withdraw / (perform) duty
退無 retreat, withdraw / not, none, cease to be
退謀 retreat, withdraw / plot, strategem
退矛 retreat, withdraw / halberd, lance, spear
退夢 retreat, withdraw / dream
退霧 retreat, withdraw / mist, fog
貸武 lend, loan / military, warrior
貸務 lend, loan / (perform) duty
貸無 lend, loan / not, none, cease to be
貸謀 lend, loan / plot, strategem
貸矛 lend, loan / halberd, lance, spear
貸夢 lend, loan / dream
貸霧 lend, loan / mist, fog
態武 appearance, intent / military, warrior
態務 appearance, intent / (perform) duty
態無 appearance, intent / not, none, cease to be
態謀 appearance, intent / plot, strategem
態矛 appearance, intent / halberd, lance, spear
態夢 appearance, intent / dream
態霧 appearance, intent / mist, fog
耐武 endure, bear / military,
Re: Time::Local
On Tue, Aug 16, 2005 at 10:24:41AM -0500, Dave Rolsky wrote: : On Mon, 15 Aug 2005, Larry Wall wrote: : : But the best part is that if we abandon UTC leap seconds for civil time, : we don't have to remember leap seconds going forward, only backward from : 2000. : : So you want to take on the (very irritating, I tell you) burden of leap : seconds going _backwards_ but not going forwards? Well, sure, but we have no choice about the ones that were already performed. We could certainly take on the burden of tracking leap seconds in the future as well, but my point is we don't know them in advance. The old ones stay put, but the new ones potentially change from year to year. (Though they might not, if we get rid of civil leap seconds.) : But that's in contrast to your saying that the epoch would be December 31, : 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? Yes, you misread it. I was angling for 00:00:00.0 UTC. But it scarcely matters if UTC keeps screwing around with leap seconds, and civil time stays locked to UTC. I personally think we should add a bunch of leap seconds at the beginning of every year divisible by 100, and leave the rest of the years alone. Larry
Re: Time::Local
On Tue, 16 Aug 2005, zowie wrote: Hmmm... at least backwards leap-seconds are fixed. Handling leap-seconds for all time requires net access or frequent software updates, but a single block of 32 comparisons handles everything up to A.D. 2000. Well, if you want accuracy you need to get that info one way or another, right? Although since most servers use NTP (or whatever MS uses), and that ultimately goes back to UTC from atomic clocks, you can always get an accurate local time (except _during_ leap a second when POSIX goes insane). Anyway, I don't think we should worry about this too much. There are a couple of ways to use epochs. One is to use it for sorting/comparison, like for file last mod times. In that case, the actual datetime the epoch represents is irrelevant. If you need to do anything with the actual datetime, I think it's best to turn it into some higher-level representation, like a date(time) object. The existing Time::Local bits in pugs are a reasonable start at a simple lightweight datetime class, and I'm hoping to be able to provide a more complete set of classes for date time bits in the future. If we can encourage people to always use one of these, then hopefully most people will never need to care what Perl6's epoch actually _means_. It's just a magic number you pass to some function or library. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Tue, Aug 16, 2005 at 08:37:24AM -0700, Larry Wall wrote: : But that's in contrast to your saying that the epoch would be December 31, : 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? Yes, you misread it. I was angling for 00:00:00.0 UTC. But it scarcely matters if UTC keeps screwing around with leap seconds, and civil time stays locked to UTC. I personally think we should add a bunch of leap seconds at the beginning of every year divisible by 100, and leave the rest of the years alone. ...This seems to be quite consistent with the rumoured US proposal to abolish leap seconds by adding leap hours every 500 years or so: http://www.post-gazette.com/pg/05210/545823.stm Ending leap seconds would make the sun start rising later and later by the clock -- a few seconds later each decade. To compensate, the U.S. has proposed adding in a leap hour every 500 to 600 years, which also accounts for the fact that the Earth's rotation is expected to slow down even further. That would be no more disruptive than the annual switch to daylight-saving time, said Ronald Beard of the Naval Research Laboratory, who chairs the ITU's special committee on leap seconds and favors their abolishment. It's not like someone's going to be going to school at four in the afternoon or something, he said. Thanks, /Autrijus/ pgpsTEMTIuNi9.pgp Description: PGP signature
Re: Time::Local
On Wed, 17 Aug 2005, Autrijus Tang wrote: ...This seems to be quite consistent with the rumoured US proposal to abolish leap seconds by adding leap hours every 500 years or so: Wow, a piece of US government policy I can actually support! Hell must be a cold place right now. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: GC API from discussion
On Mon, 15 Aug 2005 15:17:18 +0300, Yuval Kogman [EMAIL PROTECTED] wrote:
[...]
2) Some way of being able to tell the garbage collector to ignore
the current contents of the heap for the purposes of GC. One
Pop-11 idiom was to do something like:
[...]
We are trying to design a requirement based interface, so that the
GC can be changed, but behavior remains consistent.
This should be more like
do :GC::priority(:low) {
# anything that isn't GC::timely or possibly affecting
# something that is GC::timely is not cleaned up till
# later
}
I don't think that making use of use and no would be shorter and
far more Perlish. Also this allows us to switch off the
modifications.
So this would be
{
use GC::priority :low;
# anything that isn't GC::timely or possibly affecting
# something that is GC::timely is not cleaned up till
# later
}
do :GC::nodelay {
# the GC can work, but timeliness and throughput are
# ignored for the sake of performance of real code
# this means that most GCs are disabled, but a
# background thread GC will just have it's priority
# lowered
# implies that 'timely' now means 'at some point'
}
{
no GC::delay;
...
}
do :GC::nodestroy {
# the GC is told to completely freeze the state of
# things, delaying all work until after the block exits
# this means that you can rely on GC::timely objects
# being alive even when they shouldn't be.
# this is orthogonal to GC::nodelay - under plain
# GC::disabled objects may be collected for overall
# performance reasons, and then simply put on the
# finalize queue for finalization on block exit.
# applying both nodelay and nodestroy causes the GC
# system to completely turn off, so that objects are
# neither finalized nor collected.
}
{
no GC::destory;
...
}
do :GC::disabled {
# nodelay and nodestroy together
}
{
no CG::destory;
no GC::delay;
...
}
# Or
{
no GC;
...
}
do :GC::priority(:high) {
# work very hard to conserve memory
}
{
use GC::priority :high;
...
}
do :GC::critical {
# it's like GC::timely for everything
}
I'm not sure critical is the right name.
[...]
3) Some way of marking structures/fields so their reference doesn't count.
Weakrefs basically.
Yes... i think this is a container trait. Anybody got an opinion?
my $var is weakref = $object;
is GC::weak
This is getting me thinking though:
$*RUNTIME.Memory.GarbageCollector.dispose($object); # force it,
# even if it should be alive
Isn't that what we have undefine(...) for?
$*RUNTIME.Memory.GarbageCollector.clean($object); # check it
Possably as an argument for GC::delay(...) ?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Re: Time::Local
delurk A related question: I think it was stated, that the time will be some floating-point number. Will its precision be predetermined or will it be system-dependent? (Or maybe the precision is no-issue -- it could be important in comparisons, but one can argue one should always specify the smallest unit when comparing times. Only issues left are intervals; I vaguely remember something about losing precision when subtracting two close floating-point numbers.) I ask because I stumbled across uuu time (http://www.unununium.org/articles/uuutime) when I was looking for explanation of UTC/TAI/*J*D et al. It is counted from 2000-01-01 TAI in microseconds and stored in signed 64 bit integer. brano /delurk
Re: GC API from discussion
On Tue, Aug 16, 2005 at 05:32:50 -, David Formosa (aka ? the Platypus) wrote: I don't think that making use of use and no would be shorter and far more Perlish. Also this allows us to switch off the modifications. Uh, why didn't I think of that =) This is getting me thinking though: $*RUNTIME.Memory.GarbageCollector.dispose($object); # force it, # even if it should be alive Isn't that what we have undefine(...) for? No: my Dog $spot .= new; my $spot_II = $spot; # another reference $*RUNTIME.Memory.GarbageCollector.dispose($spot); # $spot_II is undefined now, because the object was disposed Furthermore: my Dog $spot .= new; my $spot_II = $spot; undefine($spot); # still referenced by a root set member undefine($spot_II); # no more refs # the object may still be alive, if it didn't say it needed # timely destruction -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!! pgpnaC1QBZzwK.pgp Description: PGP signature
Re: Time::Local
I vote for double-precision floating-point. Since double precision is good to 10^-15, that allows times to be specified to a precision of about 3 microseconds for the next century, and to a precision of 30 microseconds for the next millennium. Anyone who wants more precision than that is likely to have implemented his/her own library. Further, the trade between distance from the epoch and time resolution goes in the correct direction -- e.g. nobody wants microsecond precision when considering times 1,000,000 years in the past. Finally, floating point encapsulates nicely the practical nonexistence of simultaneity ( $t1 == $t2 makes no sense without a measure of the allowed slop; integer times force an implied slop scale. ) On Aug 16, 2005, at 10:39 AM, Brano Tichý wrote: delurk A related question: I think it was stated, that the time will be some floating-point number. Will its precision be predetermined or will it be system-dependent? (Or maybe the precision is no-issue -- it could be important in comparisons, but one can argue one should always specify the smallest unit when comparing times. Only issues left are intervals; I vaguely remember something about losing precision when subtracting two close floating-point numbers.) I ask because I stumbled across uuu time (http://www.unununium.org/ articles/uuutime) when I was looking for explanation of UTC/TAI/ *J*D et al. It is counted from 2000-01-01 TAI in microseconds and stored in signed 64 bit integer. brano /delurk
Re: The value of +hello
On Sun, Aug 14, 2005 at 03:48:22PM +0200, Daniel Brockman wrote: : Exegesis 3 contains this snippet, : :my $inflation; :print Inflation rate: and $inflation = + :until $inflation != NaN; : : but the rule that +hello evaluates to NaN is no longer : mentioned in S03, according to Autrijus. : : He suggested I post here to get a ruling. I'm not sure it ever was mentioned in S03, but we'd like to stick as close as we can to IEEE floating point, and that includes NaN as a value that can be stored not only in a Num but also in a num. (Along with +Inf and -Inf). I suppose machines that don't do IEEE floating point will have to emulate num with Num. If we go with class names being the undefined prototypical values, and if we assume that NaN is an unthrown exception variant of the undefined value for object types like Num, then we might even end up with Num == NaN, albeit with different exception information hidden inside. Num is not yet defined, whereas NaN is tried to convert 'hello' to number at inflate line 2 or some such. Larry
Re: GC API from discussion
On Mon, Aug 15, 2005 at 15:59:34 +0100, Adrian Howard wrote:
On 15 Aug 2005, at 13:17, Yuval Kogman wrote:
I'm not sure what you're proposing here. A separate arena for
stuff you want to allocate and not be moved by the GC? How would
I tell the compiler?
You won't, the language glue is responsible for setting that up for
you, and it does that by assuming it's always there, and the
compiler simply optimizes the cases where it's never going to be
needed.
How about
do : GC::priority(:new) {
# only GC things allocated during the lifetime
# of the block
}
I think that's not priority but limit or scoped or
origin(:local) or something like that...
Let's define some terms:
scope/origin - where objects are created
priority - how important is it that garbage is collected
(high priority == more cpu use, less ram use)
delay - pauses in the main flow that have nothing to do with
priority. No delay could mean less performaance, but more
responsiveness. Applicable to event loops and such.
timelyness - the property of an object such that it's
finalization subroutine is called the moment it becomes
unreachable. This is important for objects using finalizers for
resource management, especially when an unreleased resource
could cause deadlock.
finalization - the act of calling an object's finalize
subroutine, and the release of it's memory.
The aspects of control we need:
scope - which objects get cleaned up
priority - what performance tradeoffs we want to make
delay - whether or not the normal program flow will ever be
paused when it is known that no timely objects need to be
destroyed. Also possibly the maximum amount of time (in
milliseconds?) that a GC iteration may take.
timelyness - whether all objects, some objects (That are marked
using 'but' or by their class), or no objects should be checked
for timely destruction
finalization - whether objects should be cleaned up at all
Actually, since to my naive eyes it looks like the GC is a first
class object the problem can probably be solver better by adding
your own.
Well, as I see it the GC is a subobject of the runtime. The amount
of control that this object can give you can be checked using the
strong support for reflection that perl 6 will have, or by simply
asking the runtime to switch GC (if it lets you do that).
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah!
pgp8madRhKWJZ.pgp
Description: PGP signature
Re: The value of +hello
On Tue, Aug 16, 2005 at 10:00:14AM -0700, Larry Wall wrote: : If we go with class names being the undefined prototypical values, : and if we assume that NaN is an unthrown exception variant of : the undefined value for object types like Num, then we might even : end up with Num == NaN, albeit with different exception information : hidden inside. Num is not yet defined, whereas NaN is tried to : convert 'hello' to number at inflate line 2 or some such. I forgot to point out that you naturally lose that extra exception information when you store a Num into a num. Whether that warns or throws an exception or is silent is likely controlled by pragma. People doing complicated things with large matrices might prefer silence, whereas people doing scalar ops will usually prefer to know that something went wrong sooner, and not have to backtrace through the code to figure out where the NaN was generated. But maybe most of that naturally falls out of the num/Num distinction, since num will mostly be used in compact arrays. Larry
RE: Type inferencing for Perl5
The purpose of my project is to detect type-unsafe Perl 5. It's implemented with Malcom Beattie's compiler back-end. Naturally, my type inference cannot be sound due to the inherent ambiguities of Perl and things like 'eval string;', but I think it's enough for many purposes. Right now I'm using a simplified model of the Perl 5 type system. I don't really address CV, FORMAT, and IO types right now (although I will have to do so for interprocedural analysis). Also, I ignore the differences between most of the SV types -- I really only keep track of strings, references, integers, and doubles. As far as I know, union types are inefficient to the point of being impractical. For the purposes of this tool, I've taken an intermediate step by modeling the type system as a structural type, and I allow type variables to be introduced in specific places to model type ambiguity. For instance, if the type of some expression is an undistinguished scalar, I would model that by specifying the type up to scalar and put a variable type as the child. This is not as flexible as true union types, but it gets the job done (for the most part). Hopefully that will be sufficient for what you'd like to accomplish. Andy Lester (my SoC mentor) and I are going to try and get a release at some point this week. This will probably be the version that doesn't do aggregate data types, since I'm still struggling with that (I'm way past my deadline for that, but I'll get it done before the deadline). We probably need to talk more to see how this fits in with what you're doing. I don't know anything about Perl6, so I'm not sure how my project can be useful. However, I am excited to contribute to it in some way. I wrote a paper for the graded project last spring. It talks more about the formalism that I've been using, among other things. I don't want to spam the list with the PDF file. However, if someone wants it, let me know off-list and I will send it to you. -- Gary Jackson [EMAIL PROTECTED] -Original Message- From: Autrijus Tang [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 9:19 AM To: Perl6 Language List Cc: Gary Jackson Subject: Type inferencing for Perl5 On Tue, Aug 16, 2005 at 02:04:41PM +0100, Nicholas Clark wrote: On Thu, Aug 11, 2005 at 01:35:14AM +0800, Autrijus Tang wrote: On Wed, Aug 10, 2005 at 07:32:01PM +0200, TSa wrote: Counting the sigil quadriga as 4, what is the fifth element? @ $ % :: In Perl5, :: is replaced by *. Strictly in Perl 5 there are 7 types SCALAR, ARRAY, HASH, CODE, GLOB, FORMAT and IO. (where IO might actually be 2 types, file handles and directory handles, and in turn FORMAT is implemented as a subtype of CODE. Also, internally there are 16 variants of SV*, with mostly a 1 to 1 mapping for all the types except SCALAR, which sort of absorbs the other 10. Except that the null SV type is easily directly morphable into any of the others. It would be great if we can use a type-directed transform from Perl 5 syntax tree into PIL/Perl6, i.e. annotate each term with the 16 variants, maybe with union/intersection types that represents ambiguous context, such as: f(reverse(g())); Hm, I seem to remember that Gary Jackson (cc'ed) is working on that, as his Summer of Code project. Gary, can you share with us how you plan to approach that, and/or how to get involved to your project? Thanks, /Autrijus/
Re: DBI v2 - The Plan and How You Can Help
On Sat, Jul 09, 2005 at 10:25:32PM +1000, Adam Kennedy wrote: In particular, the DBI must not mandate impossible levels of support from the drivers. It will benefit you nothing if the DBI is immaculate and wonderful and incredibly all-singing and all-dancing, but no-one can write a driver for it because the requirements cannot be met by the actual DBMS that Perl + DBI needs to work with. I concur. Like CPAN as a whole, DBI's strength is in it's complete and near universal coverage of all databases, and insanely great (and occasisionally greatly insane) drivers that do strange and wonderful things. If we start sacrificing drivers by raising the bar too high, DBI as a whole suffers. Anyone proposing new features for DBI needs to be extremely careful of CYJ syndrome. Can't You Just (or sometimes Could You Just) syndrome is described here. http://c2.com/cgi/wiki?CouldYouJust http://www.oreillynet.com/pub/wlg/3593 http://c2.com/cgi/wiki?JustIsaDangerousWord Go read them now. I'll wait... That's a significant part of what happened to perl5-porters in The Bad Years. Many more talkers than doers and much use of we could do ... when the doing would clearly have to be done by someone else. I have an increasing suspicion that having open design processes like the Tim's call for comments plays a big part in it as well. Did I ever say we'd have an open design process? :-) I just called for suggestions, proposals, and random thoughts. It's my job to mix those in with my own random thoughts and try to distill something reasonably coherent and Practical. Then we'll go round the loop a few (dozen) times kicking the tires and mixing metaphors till enough people are happy enough. (I get the casting vote on behalf of the silent majority :) I was a little dissapointed that there wasn't greater focus on using Perl6 features - especially as it would have helped kick-start my own understanding of Perl6 topics that I expect to be significant (such as Roles and Pairs, to pick two at random). Perhaps the community of Perl6+DBI users is too small at this point. And nobody mentioned JDBC as a potential model. Odd that. Still, I'm sure things will liven up once I've put an initial sketch together... Tim.
Re: Generic classes.
On Mon, Aug 15, 2005 at 11:07:51AM -0700, Larry Wall wrote:
Sure, except that you're not really inheriting from a role here.
You're really inheriting from an anonymous class of the same name. :-)
Hmm, Anonymous class with the name 'Array of Any' sounds like
an oxymoron. Also consider:
role Foo {};
my Foo $x .= new;
my Foo $y .= new;
ref($x) eqv ref($y);# bool::true, surely?
If all the anonymous classes are actually the same class underneath, and
have the name that's identical to the role name, then where do their
anonymousness manifest?
Can we simply say Foo is a role can double as a class -- i.e. you
can choose to is it or does it? Then it follows that Array of Any
is a class, and Array of Int is also a class, etc.
Thanks,
/Autrijus/
pgpBkk8lgJ4Qc.pgp
Description: PGP signature
Re: DBI v2 - The Plan and How You Can Help
On 8/16/05, Tim Bunce [EMAIL PROTECTED] wrote:
I was a little dissapointed that there wasn't greater focus on using
Perl6 features - especially as it would have helped kick-start my own
understanding of Perl6 topics that I expect to be significant (such as
Roles and Pairs, to pick two at random). Perhaps the community of
Perl6+DBI users is too small at this point.
I'm afraid that DBI2 for Perl 6 will fall into the trap that I sometimes
feel like DBI1 fell into: the curse of being designed before the idioms and
Best Practices of API design in the language have been established.
I think it'll take years, and much actual production experience building
Perl 6 modules before the community learns what works and what doesn't for a
Perl 6 API (let alone implementation). So trying to pin down a properly
Perl-6-ish API before Perl 6 is even through the language design process
strikes me as a Very Bad Idea.
That could explain why there were so few Perl 6 related suggestions: no one
knows how to design a good Perl 6 API yet, and any guess is very likely to
be wrong. Instead, suggestions have focused on what we do know: DBI in Perl
5 and Perl 5 API design. In that spirit, here's my suggestion: no more
configuration through magic/tied hashes. (e.g., $dbh-{'AutoCommit'} = 1)
(Probably goes without saying, but I wanted to make sure someone said it ;)
Anyway, it maybe worthwhile to have a DBI 1.99 first, and then maybe a 1.999
after that. Basically, get one or two willing DBD authors who will help you
to test and then throw away the first two attempts at a Perl 6 DBI API.
Then at least you'll have some confidence when you commit to a DBI 2.0
API...which will be several years after Perl 6 is released, I hope.
Of course, *someone* has to go first so we can all learn what works best
in Perl 6. I'm just saying that maybe DBI, which took the bullet in Perl 5
to some degree, is under no obligation to do so again. (This assumes that
we'll have some way to use Perl 5 DBI within Perl 6 to tide us over, of
course...)
-John
Re: DBI v2 - The Plan and How You Can Help
At 4:04 PM +0100 8/16/05, Tim Bunce wrote: I was a little dissapointed that there wasn't greater focus on using Perl6 features - especially as it would have helped kick-start my own understanding of Perl6 topics that I expect to be significant (such as Roles and Pairs, to pick two at random). Perhaps the community of Perl6+DBI users is too small at this point. One way that the Perl 6 thought process can be started is in considering the design principles laid out in Damian's new Best Practices book. I said to Damian at OSCON that I thought the practices he was putting forward were intended to get people thinking now in Perl 5 about ways of doing things that will be the natural way of doing them in Perl 6; he said something along the lines that I had good insight. So these practices are probably some good things to keep in mind as we move forward. Now, speaking specifically in Perl 6 terms ... I suggest that DBI v2 has a more formal separation between interface and implementation. The parts of DBI can be grouped into these categories: 1. Role definitions for the public behaviour/API that DBI-using apps see. 2. Role definitions for the behaviour/API that DBI drivers/engines must have. 3. Class definitions that implement #1 and invoke #2. 4. Class definitions having a generic implementation of #2 or parts thereof, which a driver/engine can complete or override. 5. Basic utility classes that exist to the side of the above, which such as DBI drivers can optionally use to do some common things without rolling their own. 6. A basic test suite. I also recommend expelling some parts of the DBI distro into their own distros and/or leaving them to third parties. A prime example is the proxy server/client stuff; that should be a separate project. -- Darren Duncan
Re: Ambiguity of parsing numbers with underscores/methods
On 8/16/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: Hi, 1_234; # surely 1234 1e23; # surely 1 * 10**23 1._5; # call of method _5 on 1? 1._foo; # call of method _foo on 1? 1.e5; # 1.0 * 10**5? 1.efoo; # call of method efoo on 1? 1.e_foo;# call of method e_foo on 1? 0xFF.dead; # call of method dead on 0xFF? I think we should go with the method call semantics in all of the ambiguous forms, mostly because no such method: Int::e5 is clearer than silently succeeding and the error coming up somewhere else. Luke
Re: Ambiguity of parsing numbers with underscores/methods
On Tue, Aug 16, 2005 at 08:36:19PM +, Luke Palmer wrote: On 8/16/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: Hi, 1_234; # surely 1234 1e23; # surely 1 * 10**23 1._5; # call of method _5 on 1? 1._foo; # call of method _foo on 1? 1.e5; # 1.0 * 10**5? 1.efoo; # call of method efoo on 1? 1.e_foo;# call of method e_foo on 1? 0xFF.dead; # call of method dead on 0xFF? I think we should go with the method call semantics in all of the ambiguous forms, mostly because no such method: Int::e5 is clearer than silently succeeding and the error coming up somewhere else. To me, 1.e5 is not ambiguous. But maybe I've had too much dealing with floating point in a previous life. I'd find it hard defending a language that treated 1.e5 as a method call. Nicholas Clark
Re: DBI v2 - The Plan and How You Can Help
Tim Bunce wrote: And nobody mentioned JDBC as a potential model. Odd that. I was sorely tempted to do so (and did mention it a few times in my posts, along w/ ODBC and ADO.NET), but there are some things about JDBC which rub me the wrong way (e.g., explicit set/get methods for every data type; no true binding support; the lame bulk interface; etc.). I'm not crazy about all the DataSource business, either. But the threading support, the Factory pattern presented by Statement classes, the nice separation of metadata from statements/resultsets/connections, and XA would certainly be nice models to follow. One area of concern I have is the ability to subclass. I've been struggling w/ trying to subclass+extend JDBC the same way I subclass DBI for some things, and haven't found any app-neutral solutions just yet (trying to wrap another JDBC driver and expose its driver specific methods seems to require a lot of extra heavy lifting). Still, I'm sure things will liven up once I've put an initial sketch together... Tim. Dean Arnold Presicient Corp.
Re: GC API from discussion
On 16 Aug 2005, at 18:14, Yuval Kogman wrote:
On Mon, Aug 15, 2005 at 15:59:34 +0100, Adrian Howard wrote:
I'm not sure what you're proposing here. A separate arena for
stuff you want to allocate and not be moved by the GC? How would
I tell the compiler?
You won't, the language glue is responsible for setting that up for
you, and it does that by assuming it's always there, and the
compiler simply optimizes the cases where it's never going to be
needed.
Sorry - I don't understand. If I do:
call_to_external_c_library_foo( $foo );
call_to_external_c_library_bar( $bar );
Then how does the compiler know that $foo is only used temporarily
and can be moved around, while $bar is cached in the external library
and shouldn't be moved by any heap de-fragmentation that the garbage
collector might do?
How about
do : GC::priority(:new) {
# only GC things allocated during the lifetime
# of the block
}
I think that's not priority but limit or scoped or
origin(:local) or something like that...
[reasonable sounding terms snipped]
Sounds nice :-)
Actually, since to my naive eyes it looks like the GC is a first
class object the problem can probably be solver better by adding
your own.
Well, as I see it the GC is a subobject of the runtime. The amount
of control that this object can give you can be checked using the
strong support for reflection that perl 6 will have, or by simply
asking the runtime to switch GC (if it lets you do that).
Nice.
Thanks for answering my mad ramblings :-)
Cheers,
Adrian
Re: Time::Local
On Mon, 2005-08-15 at 22:24 -0700, Larry Wall wrote: : That's my leaning--if I thought it might encourage the abandonment of : civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC. : If we're going with TAI, can't we just nail it to the epoch it defines, : instead? Because I'm a megalomaniac, silly dilly. Plus I like round numbers. Not to mention the fact that it makes it really easy to calculate days since 2000, give or take a squishy leapsecond or three. But the best part is that if we abandon UTC leap seconds for civil time, we don't have to remember leap seconds going forward, only backward from 2000. Why on earth would you want to encourage such a short sighted programming practise? The earth wobbles like a spinning top. In fact its speed increased after the two major Earthquakes in Antarctica and Indonesia last December. Subtle adjustments are necessary to track this; perhaps including the possibility that the Earth's rotational speed might change by more than one second per day. Just why were the Mayan, Babylonian and Aztec calendars 360 days long, anyway? Were days 20 minutes longer then? These are questions I've been wondering as an old machine I have loses about this amount ... it would certainly explain it if the machine was actually so old it used a Mayan timer chip. (Sometimes the impossible has a coherency to it that the merely improbable simply lacks...) How about killing the argument by saying the epoch is only guaranteed by the language to be relative to the same value within the lifetime of a script, relative to 0.0 TAI in 1958 or whenever it was. Then Perl 6 implementations are free to pick their own epoch, and possibly also annotate the time via traits/properties as not being confirmed to be NTP synced, etc. Date modules (which, really, people should be using) then have something sensible to work with and can easily provide the alternate times. Environments that really can't guarantee an absolute epoch can simply return unanchored times and let the modules throw exceptions when you try to convert them to real times or times with impossible levels of accuracy. Sam.
