On Wed, 5 May 2010 23:22:06 -0700
gary ng wrote:
> On Wed, May 5, 2010 at 10:34 PM, Meikel Brandmeyer wrote:
> > I'm deeply suspicious of such a behaviour. Why would + on a
> > date mean adding days? Why not hours? minutes? seconds?
> > months? years? I would always prefer plus-days over such a
On 6 May 2010 03:38, gary ng wrote:
>
> On Wed, May 5, 2010 at 3:18 PM, Meikel Brandmeyer wrote:
>>
>> On Wed, May 05, 2010 at 02:56:09PM -0700, gary ng wrote:
>> Right now, this can be handled as:
>> (ns foo
>> (:refer-clojure :as core :exclude (+)))
>>
>> (defn +
>> [matrix1 matrix2]
>> ...
Hi,
On 6 Mai, 08:22, gary ng wrote:
> Convention, mostly. Say in the security trading settlement world, they use
> terms like T+3 to mean transaction date + 3 days. Which is why I said, toy
> DSL. It is used in an implicit context. Everyone in that business knows what
> T+3 means. Just like we k
On Wed, May 5, 2010 at 10:34 PM, Meikel Brandmeyer wrote:
> I'm deeply suspicious of such a behaviour. Why would + on a
> date mean adding days? Why not hours? minutes? seconds?
> months? years? I would always prefer plus-days over such a
> behaviour, because I wouldn't have to think everytime, w
(+ today (- 14 remind-prior))
=> 2 weeks from today - a fixed remind before days
=> a date when I am going to be reminded for an event 2 weeks from
today
I'm deeply suspicious of such a behaviour. Why would + on a
date mean adding days?
Frink (as one example) resolves this through unit track
Hi,
On 6 Mai, 03:38, gary ng wrote:
> I am writing a toy DSL where I would like it to be able to do something like
> this:
>
> (+ today 3) => a date which is 3 days from today
> (+ 1 2) => 3
>
> such that the following is possible
>
> (+ today (- 14 remind-prior))
> => 2 weeks from today - a fix
On Wed, May 5, 2010 at 3:18 PM, Meikel Brandmeyer wrote:
> Hi,
>
> On Wed, May 05, 2010 at 02:56:09PM -0700, gary ng wrote:
> Right now, this can be handled as:
>
> (ns foo
> (:refer-clojure :as core :exclude (+)))
>
> (defn +
> [matrix1 matrix2]
> ... (core/+ num1 num2) ...)
>
>
>
Thanks. tho
On May 5, 3:47 pm, Meikel Brandmeyer wrote:
> Hi,
>
> On Wed, May 05, 2010 at 08:24:39AM -0700, Chas Emerick wrote:
> > variety of birds with one stone, and maybe slightly simplify the
> > mental model that one needs to have in place to understand namespaces.
>
> The model is already quite easy, n
Hi,
On Wed, May 05, 2010 at 02:56:09PM -0700, gary ng wrote:
> I have a question related to this.
>
> (ns foo (:use clojure.core))
>
> (defn + [x y] x)
>
> '+' is already referred because of the use and is an error right now. But
> this is a legitimate use of the symbol as 'foo' can be matrix
I have a question related to this.
(ns foo (:use clojure.core))
(defn + [x y] x)
'+' is already referred because of the use and is an error right now. But
this is a legitimate use of the symbol as 'foo' can be matrix and matrix
addition is different from standard number addition. Or is there a b
Hi,
On Wed, May 05, 2010 at 11:08:26PM +0200, Laurent PETIT wrote:
> But it's not worse than writing a new version of a macro and
> forgetting to recompile all the code depending directly or indirectly
> on the macro ...
Or redefining a defmulti loosing the methods. This was supposed to be
addre
2010/5/5 Meikel Brandmeyer :
> Hi Laurent,
>
> On Wed, May 05, 2010 at 10:12:52PM +0200, Laurent PETIT wrote:
>
>> > The question with the new style is: to which filter does f refer to?
>> >
>> > (ns some.name.space)
>> >
>> > (defn f [pred x] (filter pred x)) ; core filter?
>> >
>> > (defn filter
Hi Laurent,
On Wed, May 05, 2010 at 10:12:52PM +0200, Laurent PETIT wrote:
> > The question with the new style is: to which filter does f refer to?
> >
> > (ns some.name.space)
> >
> > (defn f [pred x] (filter pred x)) ; core filter?
> >
> > (defn filter [pred x] ...)
>
> I bet on core filter, s
Hi,
2010/5/5 Meikel Brandmeyer :
> Hi,
>
> On Wed, May 05, 2010 at 08:24:39AM -0700, Chas Emerick wrote:
>
>> variety of birds with one stone, and maybe slightly simplify the
>> mental model that one needs to have in place to understand namespaces.
>
> The model is already quite easy, no? Everythi
Hi,
On Wed, May 05, 2010 at 08:24:39AM -0700, Chas Emerick wrote:
> variety of birds with one stone, and maybe slightly simplify the
> mental model that one needs to have in place to understand namespaces.
The model is already quite easy, no? Everything is just a sequence
of statements read by C
+1 after 1.2
On May 5, 11:24 am, Chas Emerick wrote:
> We've been able to treat ns declarations *as* declarations for the
> most part, which is nice. IMO, last-var-wins pulls the veil away even
> more on the fact that namespaces are probably the most pervasively-
> stateful part of clojure.
>
>
We've been able to treat ns declarations *as* declarations for the
most part, which is nice. IMO, last-var-wins pulls the veil away even
more on the fact that namespaces are probably the most pervasively-
stateful part of clojure.
I remember various proposals floating around a long time ago to lo
Hi,
+1 for this change! I often start putting functions in a namespace,
trying around in the Repl and then refactoring stuff out into other
namespaces. But the original functions are still in place. Evaluating
the first namespace often blows up with the "already there" error. So
I have to manually
On 2010 May 5, at 10:32 AM, Stuart Halloway wrote:
A SIMPLER SOLUTION: WARN, DON'T ERR
That's a lot better than being dead with an error.
Is there a way to turn those warnings back into errors for those
really paranoid of us?
PROMOTION AND DEPRECATION
With "warn on nam
For a long time, people have been suggesting that various libraries be
promoted from contrib into clojure core. Last week, we started making
some of the necessary code changes.
THE PROBLEM
While the changes to Clojure itself are only additive and non-
breaking, they can nevertheles
20 matches
Mail list logo
