On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
> Edward S. Peschko wrote:
>
> > Gordon Henriksen wrote:
> >
> > > Leave parsing and formatting entirely to libraries.
> > > Absolutely no need for that in the instruction set.
> >
> > well, I have a bit of a problem with that... As it was pointed out
> > before, people have gone hogwild with the parsing and formatting
> > routines, and its a bloodbath of modules on CPAN with different
> > methods for time parsing.
>
> "Not an opcode" doesn't mean "balkanized." There is a parrot/stdlib
> directory.
fair enough, but then where does the distinction lie? Why put gmtime, et al.
in opcodes? As well as addmonth?
If you are optimising for simplicity and , it surely makes sense to put these in
the standard library.
If you are optimising for speed, then it makes sense to put them in opcodes.
It all comes down to how fast one is versus the other. If everything is going
to be built in the standard library based off of bytecode then there will be
a performance hit. How severe, I don't know, but definitely a performance hit.
And given the prevalence of string and date manipulation in every day tasks,
I would suggest not having that performance hit.
> > But how many times are you going to need to parse formats
> > like '3 weeks from next Wednesday?'.
>
> Uh. Yeah.
>
> This sort of creeping featuritis is why date formatting and especially
> parsing do NOT belong as opcodes. It's too big a problem to solve in the
But I don't see the 'creeping featuritis' that you see. As well as the
memory imprint problems that you see. Is parrot going to link with libc?
If so, you get a ton of functionality for (almost) free, just by doing an
intelligent wrapper around strftime. As well as providing much of your
localization support. And you get a natural boundary on what functionality should
be put (in the core) versus what should be put in a module.
And any scheme that Larry would come up with would be implemented in terms
of what would be in parrot.
The problem would then come down to filling in deficiencies of individual
C89 implementations (which hopefully will lessen as time goes on), making
an intelligent interface into strftime, and doing a reverse lookup.
How I'd love to be able to do in my code:
my @date_formats =
map( strftime( "%a %b %e %T %Z %Y", r_strftime( "%b %d %Y",
$_)) ,
@ls_formatted_dates );
where r_strftime converted back to floating point seconds and then strftime
reconverted back into @date_formats..
or
my $secs = gmclock();
my @oracle_dates = map( strftime("%d-%b-%Y", addmonths( $secs, $_)), (1..10))
making 10 dates each spaced a month apart and formatting them for inclusion into
oracle.
Given the prevalence in which this is done, I'd want to do it *fast*.
As I see it, with an opcode this will be as fast as possible, approaching
C speed.
So - if you can guarantee that there isn't going to be a lot of overhead
by putting it in stdlib, then sure by all means it should be put there.
> Someone depends on formats like "3 weeks from next Wednesday" on a
> regular basis. You might not need to format dates from the Chinese
> lunar calendar but you can bet that it's vital to someone.
Look at strftime(3C) some time. I'd say that the problem has been
to a large extent solved. Yes, it doesn't handle TAI or other epochs, which could
be handled by an offset, and yes, there aren't certain
I would think that most of this can
> parsing? (Guessing.) Oh, baby. Global time zone database? Bring it on. A
> kl-hw (Klingon Homeworld) locale? But of course!
Most of the above is already there (well, maybe not klingon). Do you want to
reinvent everything? What's not there could be implemented in terms of a
wrapper around the opcode. Or augmented inside the opcode. It would be a judgement
call as to which though.
> There'll always be pressure to further enhance the feature, increasing
> parrot's *core* memory footprint. You can't skip loading the implem-
> entation of core parrot ops like you can avoid DateTime.pm.
Resist the temptation then. Like I said, strftime provides quite a lot.
>
> So keep it to (un)loadable user code, and provide a class that solves
> 90%
> of the problem in the stdlib.
like I said, if there isn't a performance penalty for this, then go ahead.
If there is a substantial performance penalty for every time I manipulate a date,
you could easily make the argument 'so keep the core ops relatively small, which
solve 90% of the problem, and put the rest into a wrapper inside stdlib.'
>
> Also, trying to nail down a rich interface before seeing what Larry has
> in mind for Perl 6 date handling is roughly a waste of time....
well, no, I don't think so.. At least if I was developing perl6 I'd
want some input on it. The RFCs after all are 3 years old, and at some point
there is going to have to be a merging between perl6-internals and perl6-language..
Ed
