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 also say

  (def toss (constantly nil))

and use

  (toss (def ...)).

Sincerely,
Michał


On 16 May 2012 08:58, kovas boguta <kovas.bog...@gmail.com> wrote:
> 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
> <michal.marc...@gmail.com> wrote:
>> 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 the assignment (so that (def foo ...) would
>> do what (js* "void (~{})" (def foo ...)) does currently) would be a
>> straightforward way of suppressing the returned value. I can put
>> together the (trivial) patch to do that in :statement context in the
>> presence of a flag if this seems useful. The REPL could just set this
>> flag by default.
>>
>> Sincerely,
>> Michał
>>
>>
>> On 15 May 2012 06:14, kovas boguta <kovas.bog...@gmail.com> wrote:
>>> 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 ideal specific solution here, but I've noticed this
>>> problem as well and found it pretty annoying.
>>>
>>> There should be a way to solve it that is a reasonable compromise.
>>>
>>>
>>>
>>> On Mon, May 14, 2012 at 11:13 PM, Mark Engelberg
>>> <mark.engelb...@gmail.com> wrote:
>>>> On Mon, May 14, 2012 at 4:41 PM, David Nolen <dnolen.li...@gmail.com> 
>>>> wrote:
>>>>>
>>>>> On Mon, May 14, 2012 at 7:27 PM, Mark Engelberg <mark.engelb...@gmail.com>
>>>>> 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 give
>>>> names to the things I'm building so I can play with them in the REPL.
>>>> Nothing bad form about that.
>>>>
>>>>>
>>>>> Also I don't see how this isn't solved by modifying some habits.
>>>>>
>>>>> (defn test-tree [] (function-that-produces-an-enormous-tree 2))
>>>>> (time (test-tree))
>>>>>
>>>>
>>>> time prints out the value that is computed.  The above example would suffer
>>>> the same problem of printing out the tree at the REPL.  You could do
>>>> something like (time (do (test-tree) nil)) to suppress printing, but if you
>>>> want to do further interactive manipulations to the tree, you'd end up
>>>> recomputing it.  So then, you get into workarounds involving delay.  It
>>>> starts to get ugly, I think.
>>>>
>>>> Clojure's ability to give names to things without printing the values is a
>>>> feature I use every day in my interactive explorations.
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clojure@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with 
>>>> your
>>>> first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+unsubscr...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to