comp.lang.ada
 help / color / mirror / Atom feed
From: "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>
Subject: Re: calander package
Date: Wed, 14 Mar 2001 10:21:47 -0500
Date: 2001-03-14T15:22:13+00:00	[thread overview]
Message-ID: <98o2b5$46t$1@nh.pace.co.uk> (raw)
In-Reply-To: pgzr6.29799$zV3.2243883@news1.frmt1.sfba.home.com

That ought to be a clue to the powers-that-be in the Language Design
Business. If its something everyone ends up building - only with slight
variations - then maybe having a standard, language supplied (or at least
approved) version of it would be A Good Thing.

Same argument went around about math functions in Ada83. The argument
against having something like Ada.Numerics... was that a) it was easy enough
for people to extend Ada with packages on their own, b) it wasn't needed for
all systems everywhere, c) we've got more pressing problems to deal with
like getting Tasking to work at some rational speed. What happened was that
every compiler vendor ended up supplying their own Log and Trig functions in
their own way & nobody could write math related code that could count on
some sort of portable interface to the math routines.

Granted, time as strings, etc, is not as common as math functions, but its
still pretty common. What would be wrong with an appendix or some other
means of specifying "If you are going to have a Time-As-Strings package,
here's an agreed-upon spec to adhere to..."?

And since this issue is bound to come up with other utility code, perhaps
some thought could be given to a more general mechanism of adding utilities
to Ada in a semi-standard way? That is to say, maybe defining a root package
that can be extended with a utility environment that may or may not be
supplied by a vendor or user group could be a useful way of organically
growning de facto standard packages. If there was an agreed-upon
Ada.Utilities.... as the root and a handful of agreed-upon specs as a
starting point (Ada.Utilities.Timekeeping? Ada.Utilities.Whatever?) so that
extensions could be supplied & used in a conventional way, it might
encourage more development of this sort of thing.

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:pgzr6.29799$zV3.2243883@news1.frmt1.sfba.home.com...
>   It appears everyone has their own handy, but slightly different from
> everyone else, package. :(
>   I'll offer package Claw.Time at www.rrsoftware.com





  reply	other threads:[~2001-03-14 15:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-13  0:04 calander package arcele
2001-03-13 14:24 ` Marin David Condic
2001-03-14 11:52   ` Mario Amado Alves
2001-03-13 15:52 ` Ted Dennison
2001-03-13 16:45   ` Marin David Condic
2001-03-13 18:52     ` Ted Dennison
2001-03-13 19:50       ` Marin David Condic
2001-03-13 21:47         ` Randy Brukardt
2001-03-13 22:32           ` Marin David Condic
2001-03-14  2:04           ` Vincent Marciante
2001-03-14 14:47             ` Marin David Condic
2001-03-15  0:23             ` Jeffrey Carter
2001-03-15 17:45               ` Marin David Condic
2001-03-16 16:54               ` Robert A Duff
2001-03-14  0:51         ` tmoran
2001-03-14 15:21           ` Marin David Condic [this message]
2001-03-15  1:39             ` Randy Brukardt
2001-03-15 17:55               ` Marin David Condic
2001-03-16 14:50                 ` Planned increment for package Datetime Mario Amado Alves
2001-03-14  2:19       ` calander package Jeffrey Carter
2001-03-14  8:33 ` Pascal Obry
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox