I'd be for deprecating defn-
- it creates symmetry (no defmacro-, no def-, defmulti- etc)
- The '-' is too small a visual cue to distinguish it from defn. In
short, it is hard to read. I personally prefer the obviousness of (defn
^:private [x] :foo)
--
You received this message
On Sun, Sep 18, 2011 at 6:12 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
And yes, defn- should be located elsewhere than in core. +1 for moving it
out of core, at least, defn- should not be make publicly available by core.
I'm of more or less the opposite appearance: anything that
I also think it is worth remembering the difficulty people have with getting
started with Clojure (wrt to IDEs). There are *so* many third party
libraries out there at the moment that a beginner could easily be
overwhelmed. The more self contained and feature complete the core is the
better.
I also think it is worth remembering the difficulty people have with getting
started with Clojure (wrt to IDEs). There are *so* many third party
libraries out there at the moment that a beginner could easily be
overwhelmed. The more self contained and feature complete the core is the
Wouldn't a set of standard entries in a lein project file be sufficient for a
beginner?
I’m not sure that Clojure needs something as packaged as the Haskell Platform
(http://hackage.haskell.org/platform/), and it certainly should not be part of
core.
On 19/09/2011, at 4:33 PM, Stuart
On Sun, 2011-09-18 at 13:10 -0400, Stuart Halloway wrote:
This is a good question. I don't know why I never noticed [update's]
absence. Have other people missed this?
I would say about half the calls to update-in I've written took literal
vectors with one expression in them. Including the two
Count me among those who would like to see at least def- added to core, and
possibly private versions of the other types of def as well.
--
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
I would rather see defn- removed, than add any more foo- functions. If
there are any more function attributes we want to tag things with
(say, automatically memoized?) that would be 2^N new convenient
definition forms, in an already-packed clojure.core namespace. And
it's not hard at all to (let
I would rather see defn- removed, than add any more foo- functions.
+1
--
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
Thanks for the reference Mark, much appreciated.
I add the private meta-data by hand, but (defn- foo 2) is so much more succinct
than (def ^:private foo 2) - where ^:private is almost half the declaration. I
also find the placement of the meta-data tag to be intrusive and disruptive
when
+1 for easily controlling the surface area of an API and explanatory
defs over inline/expanded literals.
Sent from my iPad
On 18 Sep 2011, at 10:14, Rob Lally rob.la...@gmail.com wrote:
Thanks for the reference Mark, much appreciated.
I add the private meta-data by hand, but (defn- foo 2) is
Just to pile on with Alan here: defn- is the oddball here, a vestige of a time
when metadata on vars was more cumbersome and less common. Adding a def- would
cover one very particular case; to make the point rhetorically, what def* form
would be required to produce (for example):
(def
I would rather see defn- removed, than add any more foo- functions.
We will see this subject line in this mailing list every few months until the
end of time, or until def- is added to core.
The burden, no matter how distributed, of answering that question forevermore
greatly outweighs the
We will see this subject line in this mailing list every few months until the
end of time, or until def- is added to core.
So be it.
The burden, no matter how distributed, of answering that question forevermore
greatly outweighs the burden of moving a def- macro from a contrib file to a
On Sep 18, 2011, at 3:38 PM, Stuart Halloway wrote:
The burden, no matter how distributed, of answering that question
forevermore greatly outweighs the burden of moving a def- macro from a
contrib file to a core file. It even outweighs the aesthetic concerns (which
I confess I don't
The API already contains `find` and `contains?`, which are woefully
misleading names. That's not a big deal: I'm *terrible* at naming. I tell
people that all the time. I've learned to accept it. It doesn't detract from
my wonderfulness. It doesn't detract from the underlying wonderfulness
On Sun, Sep 18, 2011 at 6:38 AM, Stuart Halloway
stuart.hallo...@gmail.comwrote:
Alan covered the biggest problem succinctly: it pollutes the language core
to provide convenience APIs that are combinatorial in nature.
I don't understand your comment about polluting the language core. Do you
I don't understand your comment about polluting the language core. Do you
really think people are going to use def- for some other purpose? If you
don't, then it is not pollution.
Fair enough. Maybe pollution wasn't the best word. Introducing a combinatorial
set of names is a [some other
On Sep 18, 2011, at 1:10 PM, Stuart Halloway wrote:
The other example that immediately leaps to mind is that the family of
get-in, get, and update-in implies the existence of update. It is rather
startling to me that update does not exist in the core.
This is a good question. I don't
@Chas, update uses a function to perform the update. Think of it as being
like swap! and alter, but for persistent associative structures. So you can
write something like: (update {:foo 0} :foo inc) to increment the value of
:foo.
update is to update-in as assoc is to assoc-in.
If you write a
On Sep 18, 10:44 am, Chas Emerick cemer...@snowtide.com wrote:
On Sep 18, 2011, at 1:10 PM, Stuart Halloway wrote:
The other example that immediately leaps to mind is that the family of
get-in, get, and update-in implies the existence of update. It is rather
startling to me that update
What really puzzles me is that it doesn't seem to be generally
regarded as idiomatic Clojure style to just use top-level (let)s for
your private globals. This has lots of benefits:
- If you do this you can make them actually, genuinely private, rather
than just marked as please don't use this
-
Personally, I don't use this particular style for.. probably pretty poor
reasons. I find that I end up declaring every constant that might be needed in
a file in a single let at the top of the file because:
a) Clojure's declare before use semantics make ordering technically important
rather
ha ! ha !
I really like the comparison core/kitchen sink :)))
I find it appropriate.
It never really bothered me to require an external lib to get these
fancy definitions. And I use them every where
Core should restricted to ... core things. What makes Clojure run by itself.
Syntactic
What really puzzles me is that it doesn't seem to be generally
regarded as idiomatic Clojure style to just use top-level (let)s for
your private globals. This has lots of benefits:
- If you do this you can make them actually, genuinely private, rather
than just marked as please don't use
Hi all,
Whilst trying to minimise the visible surface areas of namespaces, I've often
felt the need for a def- function/macro that marks a def'ed var with :private
metadata. An analog of defn-, if you will.
Is there a reason that I shouldn't do this or a reason that it doesn't seem to
be a
A previous discussion on the topic can be found here [1]. You can
easily add the private metadata yourself:
Clojure 1.2: (def ^{:private true} size 25)
Clojure 1.3: (def ^:private size 25)
I think probably the reason against it is that generally there is not
as much reason to use a constant,
There are other nine defs in core that don't have a dash version,
either. I guess if they were to take def- they'd have to add the
others and then add any new defs in pairs. But there's no reason to
write ugly code; just write your own or use a contrib, if available.
On Sep 17, 7:54 am, Rob Lally
28 matches
Mail list logo
