From: Richard J. <ri...@an...> - 2004-08-06 09:14:18
Attachments:
functions.mli
functions.ml
|
Some probably controversial, yet very useful functions attached for discussion[1]. First up, 'short_day' and 'short_month' take a number and convert it to a printable day or month name. Thus: printf "%d %s %d" day (short_month month) year The controversial point about these functions is that they are not properly internationalised. Not only have they not been translated, but they don't consider national conventions (eg. the Japanese way of writing dates is completely different). However, they are jolly useful. Perhaps ExtLib should add some way to convert the date time (ie. Dbi.date) to a fully localised, printable, UTF-8 string, with various format options ("long" format vs "short" format)? This would require ExtLib to be internationalized, which I believe is not the case at the moment. Second up, some functions which are extremely useful when writing web apps. 'image_identify' takes an image (as a binary block of data stored in a string) and works out the MIME type, and image size (width x height). 'image_thumbnail' takes an image and returns an image thumbnail, based on various size constraints. The catch is that to do this, we use external programs from ImageMagick. This makes it very Unix specific. I'm guessing this is against the ExtLib policy of being "pure OCaml". 'mime_type_of_filename' takes the extension of a filename (eg. '.gif') and works out from that the MIME type. As currently implemented it uses /etc/mime.types. A copy of /etc/mime.types could be bundled with ExtLib to make this work, or a static table could be used in the case where /etc/mime.types didn't exist on the system. Thoughts? Rich. [1] The attached versions don't compile, because they depend on some other functions which I've written. Compilable versions available on demand. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles, RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/ |
From: Bardur A. <oca...@sc...> - 2004-08-06 09:38:07
|
On Fri, Aug 06, 2004 at 10:14:05AM +0100, Richard Jones wrote: [--snip--] Just a technical beef: > > let image_identify data = > let filename = output_tempfile data in > let in_chan = Unix.open_process_in ("identify " ^ filename) in This is very bad form: What if filename contains shell metacharacters or spaces? [--snip--] > (* Make a thumbnail of an image. This uses the ImageMagick program 'convert'. > *) > let image_thumbnail data max_width max_height = > let filename = output_tempfile data in > let cmd = sprintf "convert -size %dx%d %s -resize %dx%d -" > max_width max_height filename max_width max_height in And again here. -- Bardur Arantsson <ba...@im...> <ba...@sc...> - Women... can't live with 'em... can't shoot 'em. Al Bundy | Married With Children |
From: Richard J. <ri...@an...> - 2004-08-06 09:52:40
|
On Fri, Aug 06, 2004 at 11:37:25AM +0200, Bardur Arantsson wrote: > > let filename = output_tempfile data in > > let in_chan = Unix.open_process_in ("identify " ^ filename) in > > This is very bad form: What if filename contains shell > metacharacters or spaces? 'output_tempfile' is guaranteed not to contain shell metacharacters or spaces, so it's OK. > [--snip--] > > (* Make a thumbnail of an image. This uses the ImageMagick program 'convert'. > > *) > > let image_thumbnail data max_width max_height = > > let filename = output_tempfile data in > > let cmd = sprintf "convert -size %dx%d %s -resize %dx%d -" > > max_width max_height filename max_width max_height in > > And again here. Ditto. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment NET::FTPSERVER is a full-featured, secure, configurable, database-backed FTP server written in Perl: http://www.annexia.org/freeware/netftpserver/ |
From: skaller <sk...@us...> - 2004-08-06 10:06:00
|
On Fri, 2004-08-06 at 19:52, Richard Jones wrote: > On Fri, Aug 06, 2004 at 11:37:25AM +0200, Bardur Arantsson wrote: > > > let filename = output_tempfile data in > > > let in_chan = Unix.open_process_in ("identify " ^ filename) in > > > > This is very bad form: What if filename contains shell > > metacharacters or spaces? > > 'output_tempfile' is guaranteed not to contain shell metacharacters or > spaces, so it's OK. guarranteed by which ISO standard? Does Windows conform? -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |
From: Bardur A. <oca...@sc...> - 2004-08-06 10:12:01
|
On Fri, Aug 06, 2004 at 10:52:34AM +0100, Richard Jones wrote: > On Fri, Aug 06, 2004 at 11:37:25AM +0200, Bardur Arantsson wrote: > > > let filename = output_tempfile data in > > > let in_chan = Unix.open_process_in ("identify " ^ filename) in > > > > This is very bad form: What if filename contains shell > > metacharacters or spaces? > > 'output_tempfile' is guaranteed not to contain shell metacharacters or > spaces Are you sure? Does it not allow the user to set $TMPDIR (or some such) in the environment to override the location? If it does not, then it could be argued that it broken because the location of tempfiles cannot be changed by the user (as one would reasonably expect). If it does, then it must allow spaces and shell metachars to "get through"...? [--snip--] Anyway, I feel it's rather ugly to rely on external programs (as opposed to libraries) for such functionality. In a sense it's even more of an "external" dependency than interfacing with C libraries since those can at least be linked statically. Image manipulation also goes a bit against the whole "generally useful modules/functions" philosophy of ExtLib, doesn't it? -- Bardur Arantsson <ba...@im...> <ba...@sc...> The fact that nobody understands you doesn't mean you're an artist. |
From: skaller <sk...@us...> - 2004-08-06 10:01:42
|
On Fri, 2004-08-06 at 19:14, Richard Jones wrote: > Some probably controversial, yet very useful functions attached for > discussion[1]. > Dow function is not internationalised, so not acceptable. Check Camomile, it knows about locales. File types OTOH refer to standardised names so should be OK even though they're English, however hooks to external programs aren't such a good idea -- would that work on Windows? OSX? -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |
From: Richard J. <ri...@an...> - 2004-08-06 10:15:48
|
On Fri, Aug 06, 2004 at 08:05:50PM +1000, skaller wrote: > On Fri, 2004-08-06 at 19:52, Richard Jones wrote: > > On Fri, Aug 06, 2004 at 11:37:25AM +0200, Bardur Arantsson wrote: > > > > let filename = output_tempfile data in > > > > let in_chan = Unix.open_process_in ("identify " ^ filename) in > > > > > > This is very bad form: What if filename contains shell > > > metacharacters or spaces? > > > > 'output_tempfile' is guaranteed not to contain shell metacharacters or > > spaces, so it's OK. > > guarranteed by which ISO standard? I wrote output_tempfile, so guaranteed by my 'Jones' standard. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles, RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/ |
From: Bardur A. <oca...@sc...> - 2004-08-06 10:23:47
|
On Fri, Aug 06, 2004 at 11:15:40AM +0100, Richard Jones wrote: > On Fri, Aug 06, 2004 at 08:05:50PM +1000, skaller wrote: > > On Fri, 2004-08-06 at 19:52, Richard Jones wrote: > > > On Fri, Aug 06, 2004 at 11:37:25AM +0200, Bardur Arantsson wrote: > > > > > let filename = output_tempfile data in > > > > > let in_chan = Unix.open_process_in ("identify " ^ filename) in > > > > > > > > This is very bad form: What if filename contains shell > > > > metacharacters or spaces? > > > > > > 'output_tempfile' is guaranteed not to contain shell metacharacters or > > > spaces, so it's OK. > > > > guarranteed by which ISO standard? > > I wrote output_tempfile, so guaranteed by my 'Jones' standard. > Could you post the code for it? That might make it a bit easier to argue about :) -- Bardur Arantsson <ba...@im...> <ba...@sc...> - I *never* apologize Lisa. I'm sorry, but that's just the way I am. Homer Simpson | The Simpsons |
From: Richard J. <ri...@an...> - 2004-08-06 10:57:25
|
On Fri, Aug 06, 2004 at 12:23:30PM +0200, Bardur Arantsson wrote: > Could you post the code for it? That might make it a bit > easier to argue about :) No, because looking at it now, it does contain the bug you described... Better to rewrite it rather than post broken code. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment "One serious obstacle to the adoption of good programming languages is the notion that everything has to be sacrificed for speed. In computer languages as in life, speed kills." -- Mike Vanier |
From: skaller <sk...@us...> - 2004-08-06 11:36:32
|
On Fri, 2004-08-06 at 20:15, Richard Jones wrote: > On Fri, Aug 06, 2004 at 08:05:50PM +1000, skaller wrote: > > On Fri, 2004-08-06 at 19:52, Richard Jones wrote: > > > On Fri, Aug 06, 2004 at 11:37:25AM +0200, Bardur Arantsson wrote: > > > > > let filename = output_tempfile data in > > > > > let in_chan = Unix.open_process_in ("identify " ^ filename) in > > > > > > > > This is very bad form: What if filename contains shell > > > > metacharacters or spaces? > > > > > > 'output_tempfile' is guaranteed not to contain shell metacharacters or > > > spaces, so it's OK. > > > > guarranteed by which ISO standard? > > I wrote output_tempfile, so guaranteed by my 'Jones' standard. Hehe .. OK. Curious how you make that assurance though. Typically temporary files live in some directory chosen by the user. /tmp on Unix, but who knows on Windows? -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |
From: Nicolas C. <war...@fr...> - 2004-08-06 10:27:45
|
> Some probably controversial, yet very useful functions attached for > discussion[1]. > > First up, 'short_day' and 'short_month' take a number and convert it > to a printable day or month name. Thus: > > printf "%d %s %d" day (short_month month) year > > The controversial point about these functions is that they are not > properly internationalised. Not only have they not been translated, > but they don't consider national conventions (eg. the Japanese way of > writing dates is completely different). > > However, they are jolly useful. Perhaps ExtLib should add some way to > convert the date time (ie. Dbi.date) to a fully localised, printable, > UTF-8 string, with various format options ("long" format vs "short" > format)? > > This would require ExtLib to be internationalized, which I believe is > not the case at the moment. a Date module for manipulating dates and times would be better than just theses two functions, and could handle severate kind of formating without relying on C locales (globals are evil). Even if in the first time the Data module is designed to support only a few kind of formats ( english one is well known, I can add french support , ... ) we might improve it later. > Second up, some functions which are extremely useful when writing web > apps. > > 'image_identify' takes an image (as a binary block of data stored in a > string) and works out the MIME type, and image size (width x height). > > 'image_thumbnail' takes an image and returns an image thumbnail, based > on various size constraints. > > The catch is that to do this, we use external programs from > ImageMagick. This makes it very Unix specific. I'm guessing this is > against the ExtLib policy of being "pure OCaml". Not only Unix specific is not ExtLib-compatible, but also the fact that it depends on 3rd party library (Pcre for example). Also, theses kind of functions are useful , as you said, "when writing web apps". That means they're not so much 'generic usage' since they don't apply to many other domains. I'm not against having a Web module in ExtLib that would provide a lot of conviniant functions for Web applications (server or http client) but they should be all part of a well designed and useful module which we might take time to build. Any proposals for Date and Web modules are of course welcome Nicolas Cannasse |
From: Richard J. <ri...@an...> - 2004-08-06 10:56:31
|
On Fri, Aug 06, 2004 at 12:26:38PM +0200, Nicolas Cannasse wrote: > a Date module for manipulating dates and times would be better than just > theses two functions, and could handle severate kind of formating without > relying on C locales (globals are evil). Even if in the first time the Data > module is designed to support only a few kind of formats ( english one is > well known, I can add french support , ... ) we might improve it later. Perl has a very extensive module with date support: http://search.cpan.org/dist/Date-Calc/Calc.pod It could be used as a model, and the license is reasonably compatible for us to create a derived work. At Merjis we're particularly interested in "business weeks", defined in ISO 8601. They're strange because sometimes the "business year" doesn't actually coincide with the actual year :-) I have a fair-sized library for dealing with ISO weeks now. Yes, I can have a go at dates and times this afternoon, and I'll post something. I'll assume that we're only interested in Gregorian dates, not in Julian dates, Chinese calendar, Japanese nengo, or the like. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment PTHRLIB is a library for writing small, efficient and fast servers in C. HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/ |
From: Richard J. <ri...@an...> - 2004-08-06 11:01:26
|
Sorry, couple of other points: What's the policy for internationalizing ExtLib? At a basic level, any strings should be translated using gettext. There are other more complex issues beyond this too. At the moment we have 'date' and 'time' types in Dbi. There are no other date and time types defined in the whole of OCaml AFAIK. One of the bigger innovations in .NET was actually having a single type to represent calendar dates across the whole API (including database access). Worth doing? It has to be designed correctly, because an incorrectly designed standard date type is probably worse than not having one at all. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet |
From: skaller <sk...@us...> - 2004-08-06 11:43:41
|
On Fri, 2004-08-06 at 20:56, Richard Jones wrote: > Perl has a very extensive module with date support: > > http://search.cpan.org/dist/Date-Calc/Calc.pod > > It could be used as a model, and the license is reasonably compatible > for us to create a derived work. Just a comment -- when you rewrite an algorithm in another language the result is not a derived work from a Copyright viewpoint. Copyright is specifically intended, under the United States constitution, to make its intellectual content *public* and freely available. A work is derived only if you reuse some of the encoding. -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |
From: Richard J. <ri...@an...> - 2004-08-06 14:10:17
|
Attached is an implementation of the important parts of Perl's Date::Calc module in Objective CAML. The coverage is about 50% - if I feel inspired I'll make up the other 50% later this afternoon. I deliberately omitted some of the functions in Perl Date::Calc which involved either i18n or access to the system clock. (Access to the system clock is already adequately provided by the Unix module). There is also a test suite which covers some of the tests supplied in Date::Calc. It's definitely a good idea to include the tests with ExtLib, and to have them run on a regular basis. This code is very much a translation of the Perl source code, which is distributed under either Artistic or GPL or LGPL. I've asked the upstream author if the linking exception is possible, but have received no reply yet. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment MONOLITH is an advanced framework for writing web applications in C, easier than using Perl & Java, much faster and smaller, reusable widget-based arch, database-backed, discussion, chat, calendaring: http://www.annexia.org/freeware/monolith/ |
From: skaller <sk...@us...> - 2004-08-07 00:22:46
|
On Sat, 2004-08-07 at 00:10, Richard Jones wrote: > It's definitely a good idea to include the tests with > ExtLib, and to have them run on a regular basis. I agree with that, perhaps Nicolas would consider how to structure it? Test code shouldn't be mixed up with the library code itself. Testing also raises issues of how to build a test harness to run the tests and report the results. I'd suggests a separate CVS module for this. The distribution should include the tests and test harness though. -------- Sigh. Of course the best way to do this is to use a LP tool, but Perl is probably OK. Shell and make is BAD for many reasons, best to minimise use of it (probably it can't be eliminated). One is tempted to consider using Ocaml script, but static typing may get in the way, and the flaky dynamic linkage certainly will. Its unfortunate but like licence issues, build/test technology is going to be a thorn. -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |
From: Bardur A. <oca...@sc...> - 2004-08-07 05:42:41
|
On Sat, Aug 07, 2004 at 10:22:36AM +1000, skaller wrote: > On Sat, 2004-08-07 at 00:10, Richard Jones wrote: > > It's definitely a good idea to include the tests with > > ExtLib, and to have them run on a regular basis. > > I agree with that, perhaps Nicolas would consider > how to structure it? OUnit looks quite reasonable (not that I'm an expert on unit testing or anything, but...): http://home.wanadoo.nl/maas/ocaml/ > > Test code shouldn't be mixed up with the library code > itself. That would kind of defeat the purpose of unit testing where you're meant to test if the implementation conforms to specification (not to implementation). > Testing also raises issues of how to build > a test harness to run the tests and report the results. > Well, that's already provided by OUnit. [--snip--] -- Bardur Arantsson <ba...@im...> <ba...@sc...> - Lousy two-legged pants. Homer Simpson | The Simpsons |
From: Nicolas C. <war...@fr...> - 2004-08-07 08:19:46
|
> On Sat, Aug 07, 2004 at 10:22:36AM +1000, skaller wrote: > > > On Sat, 2004-08-07 at 00:10, Richard Jones wrote: > > > It's definitely a good idea to include the tests with > > > ExtLib, and to have them run on a regular basis. > > > > I agree with that, perhaps Nicolas would consider > > how to structure it? > > OUnit looks quite reasonable (not that I'm an expert on > unit testing or anything, but...): > > http://home.wanadoo.nl/maas/ocaml/ We already considered before adding a module such as OUnit into Extlib. If some people are writing test code for it, they could rely on such a module that would be put in Extlib. Using OUnit itself is a matter of personal taste, I'll leave the choice to unit testing gurus :) Nicolas Cannasse |
From: Brian H. <bh...@sp...> - 2004-08-07 20:29:22
|
On Sat, 7 Aug 2004, Bardur Arantsson wrote: > On Sat, Aug 07, 2004 at 10:22:36AM +1000, skaller wrote: > > > On Sat, 2004-08-07 at 00:10, Richard Jones wrote: > > > It's definitely a good idea to include the tests with > > > ExtLib, and to have them run on a regular basis. > > > > I agree with that, perhaps Nicolas would consider > > how to structure it? > > OUnit looks quite reasonable (not that I'm an expert on > unit testing or anything, but...): > > http://home.wanadoo.nl/maas/ocaml/ Which, despite it's low version number, is quite usable (having used it). What's mainly missing is the pretty GUI interface and colorful scroll bars- the core engine is basically complete. > > > > > Test code shouldn't be mixed up with the library code > > itself. > > That would kind of defeat the purpose of unit testing > where you're meant to test if the implementation conforms > to specification (not to implementation). There are (at least) two levels of unit testing we want to consider: external unit testing, which gaurentees the library implements the interface correctly, and can (and probably should be) kept external to the library. Second is internal unit testing, which does need to be in the same file, so it can see all the abstract types and hidden functions to test them. My general tendancy so far has been to use the M4 macro preprocessor to include the .ml file in to a seperate test file, then compile the test file. I'm not sure we want to add a dependency on M4, tho. > > > Testing also raises issues of how to build > > a test harness to run the tests and report the results. > > > > Well, that's already provided by OUnit. > I think he meant "how do we write a makefile to run the tests and report the results". -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian |
From: skaller <sk...@us...> - 2004-08-08 01:37:39
|
On Sun, 2004-08-08 at 06:36, Brian Hurt wrote: > There are (at least) two levels of unit testing we want to consider: > external unit testing, which gaurentees the library implements the > interface correctly, and can (and probably should be) kept external to the > library. Second is internal unit testing, which does need to be in the > same file, so it can see all the abstract types and hidden functions to > test them. Actually, I'd be happy with something far less rigid, at least at the start: we just need a way to collect and run contributed tests. Ad hoc testing isn't going to guarrantee anything, but its better than nothing, IMHO. There is a LOT more work building and running tests than actually writing library functions: we should concentrate on the latter. However currently, there aren't even cursory tests that demonstrate one function from some module can actually be linked into a program and runs. > > > Testing also raises issues of how to build > > > a test harness to run the tests and report the results. > > > > > > > Well, that's already provided by OUnit. > > > > I think he meant "how do we write a makefile to run the tests and report > the results". Yes, I meant how do we write a *program* to do that .. note I didn't say 'makefile'. I'm generally not in favour of makefiles, shell script, or Unix tools. They don't work on all platforms, including many Unix platforms. I personally prefer script in some high level language such as Perl or Python, I suppose Ocaml is an option too: although dynamic typing and loading seems weaker, at least Ocaml is sure to be installed :) -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |
From: Nicolas C. <war...@fr...> - 2004-08-07 08:14:34
|
On Sat, 2004-08-07 at 00:10, Richard Jones wrote: > > It's definitely a good idea to include the tests with > > ExtLib, and to have them run on a regular basis. > > I agree with that, perhaps Nicolas would consider > how to structure it? I don't :) (I'm not sure I got the message from Richard you're answering to, I hope my answer is not OT ) Personaly, I don't like unit tests, I prefer a lot source code peer review and user feedback which provide more accurate informations of what could (or is) going wrong. Big problems with unit tests is code coverage : you have to be sure that your test cover all the cases that your code is handling . For example for testing a red-black tree, you need to write some code that tests all cases of insertions with different balancing rules, while reading the code you can simply check that the algorithm is correctly implemented. But if some people want to provide some tests for ExtLib, I'm not against it, but it should be used by "testers" (developpers and CVS users for example) and I don't think we should put them in the distribution. A separate module "extlib-test" on CVS could be created. Regards, Nicolas Cannasse |
From: Blair Z. <bl...@or...> - 2004-08-06 15:33:36
|
Richard Jones wrote: > On Fri, Aug 06, 2004 at 12:26:38PM +0200, Nicolas Cannasse wrote: > >>a Date module for manipulating dates and times would be better than just >>theses two functions, and could handle severate kind of formating without >>relying on C locales (globals are evil). Even if in the first time the Data >>module is designed to support only a few kind of formats ( english one is >>well known, I can add french support , ... ) we might improve it later. > > > Perl has a very extensive module with date support: > > http://search.cpan.org/dist/Date-Calc/Calc.pod As an FYI, many of the Perl people got fed up with all the different date time modules and started a new set of modules to provide the same functionality, but hopefully learning from experience. http://datetime.perl.org/ http://datetime.perl.org/faq.html#1.3%3A%20Why%20use%20DateTime%3F If we build these date/time modules for Ocaml, we could leverage this. I would look at this before just deciding to copy Date::Calc. Regards, Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: Richard J. <ri...@an...> - 2004-08-06 17:01:52
Attachments:
gregorianDate.mli
|
On Fri, Aug 06, 2004 at 08:32:53AM -0700, Blair Zajac wrote: > Richard Jones wrote: > >Perl has a very extensive module with date support: > >http://search.cpan.org/dist/Date-Calc/Calc.pod > > As an FYI, many of the Perl people got fed up with all the different date > time modules and started a new set of modules to provide the same > functionality, but hopefully learning from experience. > > http://datetime.perl.org/ There seem to be some problems with the Datetime concept and OCaml. The main problem I can see is the fact that Datetime is fundamentally object oriented. I'd prefer to see a solution where dates are represented (ideally) by tuples or by structures, because this allows simple pattern matching. However, I understand that the complexity behind a general datetime type may make this difficult to achieve. FWIW, GregorianDate (derived from Date::Calc) is relatively simple and self-contained. It represents dates as tuples of either (year, month, day) or (year, week) (for ISO 8601 business dates). It doesn't depend on any existing representations, nor would anything depend on it. It clearly (from the name) only deals with the Gregorian calendar. So I'd like to propose it as a "good enough" candidate for ExtLib, because it's independent and can even be deprecated later without affecting anything but the direct users of that one module. See attached the .mli with documentation. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment 'There is a joke about American engineers and French engineers. The American team brings a prototype to the French team. The French team's response is: "Well, it works fine in practice; but how will it hold up in theory?"' |
From: Nicolas C. <war...@fr...> - 2004-08-06 17:26:42
|
> On Fri, Aug 06, 2004 at 08:32:53AM -0700, Blair Zajac wrote: > > Richard Jones wrote: > > >Perl has a very extensive module with date support: > > >http://search.cpan.org/dist/Date-Calc/Calc.pod > > > > As an FYI, many of the Perl people got fed up with all the different date > > time modules and started a new set of modules to provide the same > > functionality, but hopefully learning from experience. > > > > http://datetime.perl.org/ > > There seem to be some problems with the Datetime concept and OCaml. > The main problem I can see is the fact that Datetime is fundamentally > object oriented. I'd prefer to see a solution where dates are > represented (ideally) by tuples or by structures, because this allows > simple pattern matching. However, I understand that the complexity > behind a general datetime type may make this difficult to achieve. > > FWIW, GregorianDate (derived from Date::Calc) is relatively simple and > self-contained. It represents dates as tuples of either (year, month, > day) or (year, week) (for ISO 8601 business dates). It doesn't depend > on any existing representations, nor would anything depend on it. It > clearly (from the name) only deals with the Gregorian calendar. So > I'd like to propose it as a "good enough" candidate for ExtLib, > because it's independent and can even be deprecated later without > affecting anything but the direct users of that one module. See > attached the .mli with documentation. > > Rich. I think that a DateTime module would be more useful than only dates. We could represent as a Unix.tm structure or as a float returned by Unix.time() , and provide some printing and extracting facilities. type day = Mon | Tue | Wed | Thu | Fri | Sat | Sun type month = Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec type date_time = float val now : unit -> date_time val date : day:int -> month:int-> year:int -> date_time val time : sec:int -> min:int -> hour:int -> date_time val add : date_time -> date_time -> date_time val sub : date_time -> date_time -> date_time val day : date_time -> day val month : date_time -> month val year : date_time -> year val year_day : date_time -> int type local = | US | UK | FR | JP val format : local -> date_time -> string val format_date : local -> date_time -> string val format_time : local -> date_time -> string and all other need functions.... Regards, Nicolas Cannasse |
From: skaller <sk...@us...> - 2004-08-07 00:53:52
|
On Sat, 2004-08-07 at 03:26, Nicolas Cannasse wrote: > > On Fri, Aug 06, 2004 at 08:32:53AM -0700, Blair Zajac wrote: > > I think that a DateTime module would be more useful than only dates. > We could represent as a Unix.tm structure or as a float returned by > Unix.time() , and provide some printing and extracting facilities. Its possible the way to do this is build a completely separate resource. In particular, I doubt ExtLib developers have the expertise to do this. > val format : local -> date_time -> string > val format_date : local -> date_time -> string > val format_time : local -> date_time -> string But Python at least uses a printf style format which is clearly superior. The format of a date is not just locale sensitive!!! It depends on what you want to use it for. Sometime YY/MM/DD is enough, and sometimes you want Thu Jan 1, 2006, and sometimes when you print the time you have to say "UTC" afterwards etc etc etc. So let's separate the two major issues here: (1) Time representation (2) Formatting The correct general way to do formatting is with a bunch of very specific routines that do bits of the job, which you can glue together as desired. Such as dow -> locale -> short_day_string eg "Mon" dow -> locale -> long_day_string eg "Monday" We can use HOF to make our own custom formatters then. Perhaps a printf style interpreter would be useful (I don't know: I don't use them). That's issue 2. Issue 1 is also difficult. A scientist measuring atomic or astronomical time periods may just need a different kind of representation to a business person. Times themselves as used by scientists are quite different to 'timezone' kind of times. All this applies to computing too. So it just isn't so easy to provide a good set of calculators for times. To do either (1) or (2) you really do need to already know the relevant ISO Standards. Its one thing to provide basic facilities like 'Unix.time' which follow standards we're familiar with for C and Posix. But to go further is fraught with difficulties requiring a lot of work to resolve. For example -- you can account for 'leap' years and missing seconds in the 'correct' way according to international agreement -- but doing so can be VERY expensive computationally and may not be necessary in a particular computation. Typically --- when it comes to sensitive calculations, most implementors have to reinvent the wheel. Even if they get it wrong, having complete control over the business rules is mandatory. For example a Telco computing call charges between two places in different timezones is going to be extremely wary of any library function that purports to calculate time periods from times, because the telco has to follow their advertised charging policy, which has to conform to local regulations -- would you really trust a function to subtract two dates in these circumstances, unless it said "Conforms to ISO XXXX" (and even then .. ) Hehe - an interesting example in Australia, a court ruled you turn 18 the day BEFORE your birthday. That had all kinds of implications here, as you might imagine: age of consent, voting, going to the pub, etc etc :) -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |