That doesn't seem to free one from the need to take special care when
assigning potentially large lazy values to names with def.
If exercising special care on a case-by-case basis is not a problem,
then it's already possible to say
(do (def ...) nil)
or similar, as mentioned above. You can als
I'd rather see something at the beginning or at the end of the statement.
like ^:toss (def ...)
or (def ...) ;;
On Tue, May 15, 2012 at 6:50 AM, Michał Marczyk
wrote:
> Workaround:
>
> (do (def foo (build-something-enormous)) nil)
>
> As for the reason for this behaviour -- probably non other
Workaround:
(do (def foo (build-something-enormous)) nil)
As for the reason for this behaviour -- probably non other than it's
just the easiest thing for def in ClojureScript to do; "it" being to
inherit the return value from the JavaScript assignment def compiles
to.
Sticking a void () around t
Returning the symbol seems odd at least to me. I think the best we could do
is have a compiler flag so that defs can return nil for REPLs.
On Tuesday, May 15, 2012, kovas boguta wrote:
> Yeah, that is sort of what I was implying in "changing the semantics of
> def"
>
> Though I wasn't ready to to
Yeah, that is sort of what I was implying in "changing the semantics of def"
Though I wasn't ready to totally committed to that, since I don't
understand the properties of symbols in clojurescript.
Like, how do go from the symbol to the javascript object we've just
bound to the symbol?
On Tue,
Clojurescript doesn't have vars, so why not have def return the symbol ?
Le 15 mai 2012 à 06:14, kovas boguta a écrit :
> I think this is a pretty valid feature request.
>
> The main question is, can this be done without having vars in clojurescript.
>
> One way to do it is to surpress output
I think this is a pretty valid feature request.
The main question is, can this be done without having vars in clojurescript.
One way to do it is to surpress output somehow, under certain conditions.
Either as a token at the end of a repl input, or in the semantics of def itself.
I don't have an
On Mon, May 14, 2012 at 4:41 PM, David Nolen wrote:
> On Mon, May 14, 2012 at 7:27 PM, Mark Engelberg
> wrote:
>
>> (def tree (function-that-produces-an-enormous-tree 2))
>>
>
> Isn't doing this at the top level bad form?
>
The purpose of a REPL is for interactive experimentation. I want to gi
On Mon, May 14, 2012 at 7:27 PM, Mark Engelberg wrote:
> (def tree (function-that-produces-an-enormous-tree 2))
>
Isn't doing this at the top level bad form?
> So there are a couple examples of things that are harder to do when your
> REPL prints the values that are attached to variables. But
(def tree (function-that-produces-an-enormous-tree 2))
Want do that in Clojurescript, and you'll be treated to tons and tons of
nested tree data printed to the REPL.
Want to time something that's supposed to be lazy, to make sure it's really
lazy, and see how long it takes to produce the eager as
Do you have a more specific example of why this is a problem?
On Monday, May 14, 2012, Mark Engelberg wrote:
> In Clojure, when you def a variable, the REPL prints the name of the
> variable rather than the value.
> In Clojurescript, when you def a variable, the REPL prints the value
> assigned t
In Clojure, when you def a variable, the REPL prints the name of the
variable rather than the value.
In Clojurescript, when you def a variable, the REPL prints the value
assigned to the variable.
This is problematic when working with lazy values. Is there any particular
reason the Clojurescript R
12 matches
Mail list logo
