From attila.lendvai at gmail.com Mon Nov 2 13:47:14 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 2 Nov 2009 14:47:14 +0100 Subject: [local-time-devel] exporting 'date and 'time from the local-time package Message-ID: hi! what we need is a shared 'date and 'time symbol between all our libs. local-time does not yet provide a date and a time type, but until it's done, punting by using specially crafter timestamps is a good enough solution... although exporting time will conflict with cl:time, but i still think that this is The Right Way(tm). rationale: - cl:time is the wrong name, it should be with-resource-usage-statistics or whatever el... - local-time will eventually provide date/time abstractions, at least in a form of (typep foo 'time) using a type with satisfies so, if no debate builds up about this, we'll add these two exported symbols eventually. -- attila From dherring at tentpost.com Mon Nov 2 17:30:56 2009 From: dherring at tentpost.com (dherring at tentpost.com) Date: Mon, 2 Nov 2009 12:30:56 -0500 Subject: [local-time-devel] exporting 'date and 'time from the local-time package In-Reply-To: References: Message-ID: Attila Lendvai wrote: > what we need is a shared 'date and 'time symbol between all our libs. What's wrong with using the fully-qualified symbol local-time:date? > although exporting time will conflict with cl:time, but i still think > that this is The Right Way(tm). rationale: > > - cl:time is the wrong name, it should be > with-resource-usage-statistics or whatever el... > - local-time will eventually provide date/time abstractions, at least > in a form of (typep foo 'time) using a type with satisfies What do time or date mean? CL:time is perfectly normal ("time an event"), except for the other nonstandard cruft which was added (but compare the unix command). As data structures, neither has a universal canonical form. If these names are to be exported, I think they should be given more specific names. - Daniel From attila.lendvai at gmail.com Mon Nov 2 20:26:14 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 2 Nov 2009 21:26:14 +0100 Subject: [local-time-devel] exporting 'date and 'time from the local-time package In-Reply-To: References: Message-ID: >> what we need is a shared 'date and 'time symbol between all our libs. > > What's wrong with using the fully-qualified symbol local-time:date? the package prefix is just noise in code heavily using these symbols, and then everything else should be prefixed with local-time: (or it needs to be private, local-time::time). alternatively we would be ok with these symbols only present in local-time, not exported, so that we can :import-from them. >> although exporting time will conflict with cl:time, but i still think >> that this is The Right Way(tm). rationale: >> >> ?- cl:time is the wrong name, it should be >> with-resource-usage-statistics or whatever el... >> ?- local-time will eventually provide date/time abstractions, at least >> in a form of (typep foo 'time) using a type with satisfies > > What do time or date mean? ?CL:time is perfectly normal ("time an event"), cl:time is only normal for people who are used to it and to the unix time command. ask a few 10 year olds who are just learning programming what they think this symbol might mean... i'm sure they will not mention memory allocation printed to standard output... :) (same applies to many other things, like the 101 key keyboard layout everybody keeps on using... why on earth should a 10 year old learn typing on a layout that was optimized for the mechanical bars keeping the buttons some 100 years ago? took me at most a week to get used to a kinesis, and i wasn't 10 when i bought mine... ) > except for the other nonstandard cruft which was added (but compare the > unix command). ?As data structures, neither has a universal canonical > form. well, they don't need a canonical form. they just need to encode a date or a time of day, which i will not define here because they exists in the common knowledge of people. i'm open for suggestions what to use instead of 'time to encode a point in a day. maybe 'date and 'time-of-day? > If these names are to be exported, I think they should be given more > specific names. i'm starting to lean towards just intern'ing and :import-from'ing them from local-time when our first shared dependency loads... -- attila From antony.sequeira at gmail.com Tue Nov 3 09:25:45 2009 From: antony.sequeira at gmail.com (Antony Sequeira) Date: Tue, 3 Nov 2009 01:25:45 -0800 Subject: [local-time-devel] exporting 'date and 'time from the local-time package In-Reply-To: References: Message-ID: <6fb33c150911030125s43100dd4jcb3ab0321c1087cb@mail.gmail.com> how about ltime and ldate that's a lowercase L :) From attila.lendvai at gmail.com Tue Nov 3 09:30:32 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 3 Nov 2009 10:30:32 +0100 Subject: [local-time-devel] exporting 'date and 'time from the local-time package In-Reply-To: <6fb33c150911030125s43100dd4jcb3ab0321c1087cb@mail.gmail.com> References: <6fb33c150911030125s43100dd4jcb3ab0321c1087cb@mail.gmail.com> Message-ID: > how about ltime and ldate > > that's a lowercase L :) the package conflict issue is only with cl:time. then it should be all prefixed: ldate, ltime and ltimestamp (or give up consistency, but that's usually the last option for me). -- attila