Ken Wesson writes:
Hi Ken,
>> Why do I use a dynamic var in the first place? I want to use the
>> simple names in the lexical scope of the `with-schema-imports' block,
>> and I used a dynamic var only because the resolution takes place
>> somewhere in the function call tree originating from the
Ken Wesson writes:
Hi Ken,
>>> They're not, but if the LazySeq realization is not happening until
>>> after the scope of your with-schema-imports is exited, it would
>>> explain a thing or two. You may need to sprinkle some doalls about.
>>
>> Oh, yes. That was the exact issue. But clearly for
On Mon, Mar 21, 2011 at 4:03 AM, Tassilo Horn wrote:
> Why do I use a dynamic var in the first place? I want to use the simple
> names in the lexical scope of the `with-schema-imports' block, and I
> used a dynamic var only because the resolution takes place somewhere in
> the function call tree
Meikel Brandmeyer writes:
Hi Meikel,
>> Oh, yes. That was the exact issue. But clearly forcing realization
>> is not a good solution. Is there some better way to do what I want?
>> Maybe my macro should expand to something like that?
>>
>> ((fn [] (binding [...as before...] body)))
>
> Sham
Hi,
Am 20.03.2011 um 22:41 schrieb Tassilo Horn:
> Oh, yes. That was the exact issue. But clearly forcing realization is
> not a good solution. Is there some better way to do what I want?
> Maybe my macro should expand to something like that?
>
> ((fn [] (binding [...as before...] body)))
S
On Sun, Mar 20, 2011 at 5:41 PM, Tassilo Horn wrote:
> Ken Wesson writes:
>
> Hi Ken,
>
Does the resolving function run on, or use, another thread?
>>>
>>> No, it runs in the same thread. But some functions like `vseq' in
>>> the example produce LazySeqs. So if LazySeq-realization computat
Ken Wesson writes:
Hi Ken,
>>> Does the resolving function run on, or use, another thread?
>>
>> No, it runs in the same thread. But some functions like `vseq' in
>> the example produce LazySeqs. So if LazySeq-realization computations
>> are run in a different thread by default, that would exp
On Sun, Mar 20, 2011 at 5:17 PM, Tassilo Horn wrote:
> Ken Wesson writes:
>
>>> the println prints {Locality localities.Locality}, which is correct.
>>> However, my resolving function errors because there is no class
>>> Locality. In the error message, I also print the value of
>>> *schema-impor
Ken Wesson writes:
>> the println prints {Locality localities.Locality}, which is correct.
>> However, my resolving function errors because there is no class
>> Locality. In the error message, I also print the value of
>> *schema-imports*, and in fact, it is {}.
>
> Does the resolving function r
On Sun, Mar 20, 2011 at 4:16 PM, Tassilo Horn wrote:
> the println prints {Locality localities.Locality}, which is correct.
> However, my resolving function errors because there is no class
> Locality. In the error message, I also print the value of
> *schema-imports*, and in fact, it is {}.
Doe
Hi all,
I have a problem with a var that I want to be dynamically scoped. In my
DSL, I state types using symbols like 'localities.Locality, and at some
point some function resolves these types in some Java lib.
For convenience, I wanted to add a macro that binds simple names to
qualified names,
11 matches
Mail list logo
