Re: idempotency

[Alan Malloy]

That's really a stricter requirement than idempotence (ie, functional 
purity). I don't believe the compiler ever does this. The JVM might, if 
it's able to inline some particular method call and discover therein that 
no mutation happens, but that's probably pretty rare given the amount of 
indirection that goes on when calling everything through the IFn interface.

On Saturday, June 30, 2012 5:30:02 PM UTC-7, Brian Marick wrote:
>
> In its optimization, does the Clojure compiler ever assume idempotency? 
> That is, does it ever look at a function application `(f x y z)` and say to 
> itself "I may freely substitute the result of the first application of `f` 
> to those particular arguments for any later call"? 
>
> I could imagine it doing that for built-ins (or just primitives?), but not 
> for user-defined functions (given the existence of atoms, etc.) I can also 
> imagine it not bothering for any calls. 
>
> - 
> Brian Marick, Artisanal Labrador 
> Contract programming in Ruby and Clojure 
> Occasional consulting on Agile 
>
>
>

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

Re: Protocol as an abstract data type

[David Nolen]

On Sat, Jun 30, 2012 at 11:15 PM, Mark Engelberg
 wrote:
>
> In any case, I feel like I understand better how you've structured things in
> ClojureScript and what can and can't be done easily with protocols.  Thanks!

I think predicate dispatch + protocols could eliminate the existing
closed cases.

David

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

Re: Protocol as an abstract data type

[Warren Lynn]

implementation which only supports one abstract protocol!)  I don't feel 
strongly about last specifically, but if people wanted it to behave 
polymorphically, I'd be happy to volunteer to write the code.

Thanks a lot for the detailed analysis and volunteering to write the code. 
Not surprisingly, I am interested in seeing the code. I already put your 
protocol based implementation into my clj-cc lib. So you are going to write 
another version for ClojureScript? Or you are going to write a host 
independent version? 

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

Re: Protocol as an abstract data type

[Mark Engelberg]

OK, I get it now.

Protocols are attached to very specific capabilities.

With this structure, it is easy to:

Write a function that operates on an input that fulfills a specific
protocol.
Write a function that operates on an input that fulfills (all of) multiple
protocols.
Write a function that operates on a closed (non-extensible by outsiders)
union of abstract data types (i.e., it satisfies *either* this protocol or
that protocol).
Write a function that has a default case, and can be extended by other
concrete data types.
Write a function that supports a closed union of abstract data types, but
can still be extended by other concrete types.

Pretty much the only thing you can't do with protocols is:

Write a function that supports an open union of abstract data types, for
example:
"I want this function to be able to work with objects that support nth, or
objects that support the protocol for queues, and I want to leave it open
to other kinds of abstract protocols I might not be able to think of right
now."

It's a limitation for sure.  It is easy to think of scenarios like last
where you want to offer one implementation for the abstract concept of
sequential types, one for the abstract concept of reversible types, one for
the abstract concept of random access types, and possibly leave it open for
extension.  But I can see why this kind of need for abstract extensibility
might be rare, given the many other combinations that are well-supported by
protocols.

Regarding the specific use-case of last, in theory, I think it could be
done in almost exactly the same way that nth is implemented.  last would
dispatch to a protocol containing -last to provide an extension point for
concrete data types, and in a cond could test to see if various abstract
protocols were satisfied, and if so use the corresponding last
implementation.  There's no point of extension for other abstract
protocols, but that's not a huge deal (and certainly no worse than the
current implementation which only supports one abstract protocol!)  I don't
feel strongly about last specifically, but if people wanted it to behave
polymorphically, I'd be happy to volunteer to write the code.

In any case, I feel like I understand better how you've structured things
in ClojureScript and what can and can't be done easily with protocols.
Thanks!

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

Re: Protocol as an abstract data type

[Mark Engelberg]

Never mind, found it.

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

Re: Protocol as an abstract data type

[Mark Engelberg]

On Sat, Jun 30, 2012 at 9:36 PM, David Nolen  wrote:

> Look at the implementation of nth. Or how polymorphic unification works in
> ClojureScript core.logic for ISequential. I misspoke a bit, should have
> clearer that I simply meant that ILast (probably something else entirely)
> needs to be carefully considered since the logic needs too be moved to the
> actual fn or into a protocol default case in order to cover ISeq (which
> isn't a good idea anyway - IBoundedSeq or some such makes more sense to me).
>
>
OK, can you just give me the link to the relevant file?  I don't understand
the github clojurescript file directory structure.

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

Re: Protocol as an abstract data type

[David Nolen]

Look at the implementation of nth. Or how polymorphic unification works in
ClojureScript core.logic for ISequential. I misspoke a bit, should have
clearer that I simply meant that ILast (probably something else entirely)
needs to be carefully considered since the logic needs too be moved to the
actual fn or into a protocol default case in order to cover ISeq (which
isn't a good idea anyway - IBoundedSeq or some such makes more sense to me).

On Saturday, June 30, 2012, Mark Engelberg wrote:

> This is a continuation of issues raised in the thread about making the
> core "last" function behave in a polymorphic manner.
>
> The separation of interfaces from implementation in Java serves several
> purposes, but one thing it does is it allows the creation of abstract data
> types, i.e., a type that is defined in terms of what it can do, rather than
> what it is comprised of or how it is implemented.
>
> Right now, in Clojure, ISeq is an interface, and by extension, it is an
> abstract type.  One benefit this has is that we can polymorphically
> dispatch, via a protocol, for example, on whether something is an ISeq.  We
> can easily create a function that applies to anything to which you can
> "first" and "rest", and at the same time, we can leave the function open to
> extension by other types.
>
> However, once ISeq is made into a protocol (which has already been done in
> ClojureScript and may conceivably be done in the future in Clojure), there
> is a problem.  No longer can you dispatch via protocols on whether
> something is an ISeq.  In other words, by using a protocol to define ISeq.
> we have lost its capabilities to express an abstract data type.  Protocols
> provide a way to polymorphically dispatch to various concrete data types
> but appear to lose the ability to dispatch based on the abstract data type,
> i.e., dispatching on what the object can *do*.
>
> A hypothetical polymorphic last function, proposed in that previous
> thread, is a great example of why one would want to do this.  A naive
> implementation of a polymorphic last could take the form "(cond (vector? s)
> ... (seq? s) ...)", but this is a closed implementation.  If we want to
> keep the implementation open for extension, you could use something like
> the protocol-based code I wrote there, but it absolutely relies on these
> abstract data types being represented as Java interfaces rather than other
> protocols.
>
> David says that in 10,000 lines of code, there hasn't yet been something
> that required protocols to dispatch on other protocols, but in nearly the
> same breath he says that a polymorphic last function is impractical because
> of this limitation.  The difficulty, he notes, is that a hypothetical ILast
> protocol can't be made to automatically work for all implementers of ISeq.
> Every single person who ever wanted to implement ISeq would also have to
> implement ILast.  I would argue that as soon as you're ruling out ideas
> such as a polymorphic last function specifically because it would make it
> too difficult to maintain in a protocol-based system, that is clear
> evidence that indeed, we *are* running into a real limitation of protocols.
>
> So, I would like to better understand this limitation, and brainstorm with
> everyone about workarounds.
>
> I have some thoughts and ideas about this, but I want to better understand
> the ClojureScript architecture first.  David, could you walk me through the
> implementation of nth, which is a very similar kind of function?  I was
> able to find the part of the code on Github where you define an IIndexed
> protocol which provides a protocol for nth.  However, I was unable to find
> the place in the code where you implement nth in linear time for all those
> who implement ISeq and faster for random-access collections.  Can you point
> me to the relevant source code?  Is nth open to extension to other abstract
> data types?  Is nth guaranteed to work and gain the default implementation
> for new data types that implement ISeq?  Do coders need to remember to
> implement IIndexed any time ISeq is implemented, and if so, how is that
> documented?
>
> Thanks!
>
> --
> 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 '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  'clojure%2bunsubscr...@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

Re: idempotency

[Softaddicts]

You should then use memoize explicitly then. Of course, avoid this if
you have side effects in the function.

Luc


> In its optimization, does the Clojure compiler ever assume idempotency? That 
> is, does it ever look at a function application `(f x y z)` and say to itself 
> "I may freely substitute the result of the first application of `f` to those 
> particular arguments for any later call"?
> 
> I could imagine it doing that for built-ins (or just primitives?), but not 
> for user-defined functions (given the existence of atoms, etc.) I can also 
> imagine it not bothering for any calls.
> 
> -
> Brian Marick, Artisanal Labrador
> Contract programming in Ruby and Clojure
> Occasional consulting on Agile
> 
> 
> -- 
> 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
> 
--
Softaddicts sent by ibisMail from my ipad!

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

Protocol as an abstract data type

[Mark Engelberg]

This is a continuation of issues raised in the thread about making the core
"last" function behave in a polymorphic manner.

The separation of interfaces from implementation in Java serves several
purposes, but one thing it does is it allows the creation of abstract data
types, i.e., a type that is defined in terms of what it can do, rather than
what it is comprised of or how it is implemented.

Right now, in Clojure, ISeq is an interface, and by extension, it is an
abstract type.  One benefit this has is that we can polymorphically
dispatch, via a protocol, for example, on whether something is an ISeq.  We
can easily create a function that applies to anything to which you can
"first" and "rest", and at the same time, we can leave the function open to
extension by other types.

However, once ISeq is made into a protocol (which has already been done in
ClojureScript and may conceivably be done in the future in Clojure), there
is a problem.  No longer can you dispatch via protocols on whether
something is an ISeq.  In other words, by using a protocol to define ISeq.
we have lost its capabilities to express an abstract data type.  Protocols
provide a way to polymorphically dispatch to various concrete data types
but appear to lose the ability to dispatch based on the abstract data type,
i.e., dispatching on what the object can *do*.

A hypothetical polymorphic last function, proposed in that previous thread,
is a great example of why one would want to do this.  A naive
implementation of a polymorphic last could take the form "(cond (vector? s)
... (seq? s) ...)", but this is a closed implementation.  If we want to
keep the implementation open for extension, you could use something like
the protocol-based code I wrote there, but it absolutely relies on these
abstract data types being represented as Java interfaces rather than other
protocols.

David says that in 10,000 lines of code, there hasn't yet been something
that required protocols to dispatch on other protocols, but in nearly the
same breath he says that a polymorphic last function is impractical because
of this limitation.  The difficulty, he notes, is that a hypothetical ILast
protocol can't be made to automatically work for all implementers of ISeq.
Every single person who ever wanted to implement ISeq would also have to
implement ILast.  I would argue that as soon as you're ruling out ideas
such as a polymorphic last function specifically because it would make it
too difficult to maintain in a protocol-based system, that is clear
evidence that indeed, we *are* running into a real limitation of protocols.

So, I would like to better understand this limitation, and brainstorm with
everyone about workarounds.

I have some thoughts and ideas about this, but I want to better understand
the ClojureScript architecture first.  David, could you walk me through the
implementation of nth, which is a very similar kind of function?  I was
able to find the part of the code on Github where you define an IIndexed
protocol which provides a protocol for nth.  However, I was unable to find
the place in the code where you implement nth in linear time for all those
who implement ISeq and faster for random-access collections.  Can you point
me to the relevant source code?  Is nth open to extension to other abstract
data types?  Is nth guaranteed to work and gain the default implementation
for new data types that implement ISeq?  Do coders need to remember to
implement IIndexed any time ISeq is implemented, and if so, how is that
documented?

Thanks!

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

idempotency

[Brian Marick]

In its optimization, does the Clojure compiler ever assume idempotency? That 
is, does it ever look at a function application `(f x y z)` and say to itself 
"I may freely substitute the result of the first application of `f` to those 
particular arguments for any later call"?

I could imagine it doing that for built-ins (or just primitives?), but not for 
user-defined functions (given the existence of atoms, etc.) I can also imagine 
it not bothering for any calls.

-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Occasional consulting on Agile


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

Re: Why cannot "last" be fast on vector?

[Mark Engelberg]

On Sat, Jun 30, 2012 at 10:24 AM, Warren Lynn  wrote:

> I think some people agree with me something is broken here (puzzler, for
> example. Please correct me is I am wrong as I don't want to hijack other
> people's opinion).
>

One really nice thing about the Clojure community is that from the very
beginning, Rich instilled a value that we should generally avoid talking in
terms of a "sky is falling" mentality, and avoid using terms like
"broken".  Generally speaking, the community has been trained to avoid
engaging with people who make such exaggerated claims.  This has a  couple
of beneficial effects: first, it helps keep criticisms grounded and
constructive, second, it tends to limit the destructive potential of people
who are just trolling.  As a result of this community ethic, you'll find
that if you keep calling Clojure broken, people will just tune you out.

So no, I don't agree that last is "broken".  I claimed that last *could* be
made polymorphic, and that if, it were up to me, I *would* make it
polymorphic because I think there's little downside and it's generally
better to make functions behave in an intuitive way; I believe that the
name last implies fast access for data structures which offer fast access
to the last element.

However, I, like most of the others here, don't regard this as a big deal.
The first time I read through the docs, I noted that last wasn't a
particularly useful function because of its linear time bound.  So I just
don't use it.  If I need fast access to the last element, I use a vector,
and I use the peek function.  It's not the way I would design things, but
it's not a big deal, either.  There are a number of aspects of Clojure I
feel that way about, and it doesn't stop me from wanting to use it.

Now I *do* find this discussion interesting, particularly because of things
that David has said about protocols and ClojureScript, and the limitations
that this may place on design.  Ever since protocols were introduced, I
have been very intrigued to see how they would play out in practice.  I
would like to discuss this issue further, but I will start a new thread to
do so...

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

Re: ANN Monger 1.1.0-beta1

[Bruce Durling]

Michael,

On Sat, Jun 30, 2012 at 9:11 PM, Michael Klishin
 wrote:
>  * An alternative Ring session store that stores session data in a way that's 
> not interoperable with non-Clojure applications
>   but works well with namespaced keywords that Friend [3] relies on

Excellent news. I look forward to using Monger & friend together.

cheers,
Bruce

-- 
@otfrom | CTO & co-founder @MastodonC | mastodonc.com

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

class loading on startup

[Maris]

When debugging class loading issues I noticed that clojure tries to 
load many non-existing classes.
For example  this__5587__auto__,  gf__x__8266 ,  f__5717__auto__.

It happens on startup, in static init block of RT.java.
Are those type hints generated by some macro ?

protected Class findClass(String name) throws ClassNotFoundException{
Reference cr = classCache.get(name);
if(cr != null)
{
Class c = cr.get();
if(c != null)
return c;
else
classCache.remove(name, cr);
}
try {
return super.findClass(name);
} catch (ClassNotFoundException e)
{
log.log(Level.SEVERE,"FAILED to load " + name);
throw e;
}
}

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

Clojure in OSGi and *use-context-classloader*

[Maris]

I am using clojure in apache karaf which has Thread context class loader 
set to karaf jars.

I changed use-context-classloader to false in RT.java:

final static public Var USE_CONTEXT_CLASSLOADER =
Var.intern(CLOJURE_NS, Symbol.intern("*use-context-classloader*"), 
F).setDynamic();

For some reason booleanCast(USE_CONTEXT_CLASSLOADER.deref()) doesn't always 
return false  and RT still managed to create DynamicClassloader with thread 
context 
classloader as parent.  Of course,   it wasn't able to find any clojure 
classes.

To make it work I commented out this line in baseLoader() method.

else if (booleanCast(USE_CONTEXT_CLASSLOADER.deref())) {
return Thread.currentThread().getContextClassLoader();
}

Why booleanCast(USE_CONTEXT_CLASSLOADER.deref()) doesn't always return 
false ? 

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

[ANN] clj-cc lib

[Warren Lynn]

Available here:
https://github.com/wrn/clj-cc

This is a very simple lib (for now only three functions) that I created in 
response to people's suggestions in the following two threads:

   1. Why cannot "last" be fast on 
vector?
 
   2. General subsequence 
function
 

The purpose of this lib is to collect functions I think should be added to 
or replace existing ones in clojure.core, and to gather community support 
for that.

Please check it out if you are interested. Thank you.

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

ANN Monger 1.1.0-beta1

[Michael Klishin]

Monger [1] is a Clojure MongoDB driver for a more civilized age: friendly, 
flexible, well documented
and with batteries included.

1.1.0-beta1 is released to clojars [2]. This release includes a bunch of small 
improvements:

 * An alternative insert function many people have been suggesting
 * Clojure reader extensions for MongoDB-specific data types and Joda Time 
types (just like monger.joda-time does for clojure.data.json protocols)
 * An alternative Ring session store that stores session data in a way that's 
not interoperable with non-Clojure applications
   but works well with namespaced keywords that Friend [3] relies on

The alternative insert function (monger.collection/insert-and-return) that 
returns the exact inserted document
(with _id generated if needed) and not the write result. More details and the 
rationale can be found in
the change log:

https://github.com/michaelklishin/monger/blob/master/ChangeLog.md

Otherwise this release is completely backwards compatible with 1.0.0.

1. http://clojuremongodb.info
2. https://clojars.org/com.novemberain/monger
3. https://github.com/cemerick/friend/

MK

mich...@defprotocol.org



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: verify that a fn throws an exception via testing?

[Dimitrios Jim Piliouras]

I am away in holidays and missed your response Brian...Thanks a lot for
taking the time to reply and of course thanks for midje! I will consult the
entire midje wiki once I go back to an actual office!!!

Jim

On Mon, Jun 25, 2012 at 11:05 PM, Brian Marick  wrote:

>
> On Jun 25, 2012, at 6:21 AM, Jim - FooBar(); wrote:
> > (fact (try (fn-that-throws-exc bad-arg)
> > (catch Exception e :works)) => :works)
>
> (fact
>  (fn-that-throws-exc bad-arg) => (throws Exception))
>
> You can also check the message, run a predicate over the exception, etc.
>
> https://github.com/marick/Midje/wiki/Checkers
>
> >
> > Ah, ok.  Midje seems to support that, too.  See
> >
> >
> https://github.com/marick/Midje/wiki/Prerequisites-that-throw-exceptions
>
> This is actually for sort of the opposite purpose. You're writing a
> function that needs to be able to handle an exception. That exception is
> hard to generate. So this is a way to artificially create and throw one.
>
>
> -
> Brian Marick, Artisanal Labrador
> Now working at http://path11.com
> Contract programming in Ruby and Clojure
> Occasional consulting on Agile
>
>
> --
> 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

Re: Would a"def-" macro for private varibales make sense?

[Sean Corfield]

On Sat, Jun 30, 2012 at 7:30 AM, Vinzent  wrote:
> It's better to use ^:private metadata on the symbol naming the var, since
> there is also defmacro, defmulti, etc, which not have hyphened versions too.

It seemed to be consensus that defn- was probably not a good idea but
was too common to remove...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Why cannot "last" be fast on vector?

[Sean Corfield]

On Sat, Jun 30, 2012 at 7:09 AM, Warren Lynn  wrote:
> As I mentioned before, the issue here is not just a fast "last". The issue
> here is I find the design of Clojure "wrong", or confusing. That really
> shakes my confidence in the whole system.

Some of Clojure's design decisions take a while to really internalize.
Several folks here have explained them but you're still not satisfied.
I don't think there's much more they can do at this point.

> According to the book "Clojure Programming" by Chas, one of the Clojure's
> principles is to "build on abstractions" and to separate abstractions from
> concrete types. Now I have a little deeper contact with Clojure and my
> impression is that is not the reality.

But it is the abstractions specifically that lead to the situation you
are in, with last operating the way it does, as several folks have
explained.

Some have suggested you read through and understand the implementation
of Clojure. That may help you understand the abstractions better (it
may not). But, as has been stated (repeatedly) in this thread, Clojure
is this way for a (good) reason. I actually think Stu's post was one
of the clearest explanations...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Why cannot "last" be fast on vector?

[Warren Lynn]

On Saturday, June 30, 2012 1:03:04 PM UTC-4, Las wrote:
>
> Warren,
>
> I think the issue is this:
>
> You claim there is sg. broken in clojure while admitting that you know 
> little about how the design decision was made.
>
> People that know clojure's implementation and the history of design 
> decisions inside-out offered advice why they think it is not broken, they 
> took time to explain the rationale for decision and even offerred advice 
> how to "fix it" for yourself should you insist on your view of the matter.
>
> It seems to me you 
> a) need to reread these arguments to perhaps get a better grasp
> b) have chosen to ignore them.
>
> While you have right to do either of them, if it's b) not even the 
> "clojure gods" can really help you unless you actually spend some time with 
> the internals of clojure. ;-).
>
> Las
>
>
>
First, this will be my last post on this thread, so I will be absolved from 
"attention seeking". But really, as you have pointed out, things are 
getting in a kind of circle and we may just need to sit back and think for 
a while.

I think some people agree with me something is broken here (puzzler, for 
example. Please correct me is I am wrong as I don't want to hijack other 
people's opinion). For the other people who don't agree with me, I am not 
really ignoring their argument (I tried hard to reply to each of them), it 
is just, I am not really convinced. No I don't know the language 
inside-out, and I don't know much about the implementation. But I was 
trying to keep my discussion on the high-level abstraction. If somebody 
told me "Warren, I agree with you that the abstractions and design 
principles need some fixing, but man it is very hard to do now, take my 
word for it", even nothing changed I will feel better using Clojure because 
at least people admit there is a problem and there is a chance it will get 
fixed in the future (on on another host language). So far I have not get 
that kind of feedback.

We all choose what we think is right for us, so there is no imposing 
anything on anybody. I appreciate the fact at least there is the language 
Clojure we can talk about.

Thanks you all for the participation.

And I will much more comfortalbe Of course in the end


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

Re: Why cannot "last" be fast on vector?

[László Török]

Warren,

I think the issue is this:

You claim there is sg. broken in clojure while admitting that you know
little about how the design decision was made.

People that know clojure's implementation and the history of design
decisions inside-out offered advice why they think it is not broken, they
took time to explain the rationale for decision and even offerred advice
how to "fix it" for yourself should you insist on your view of the matter.

It seems to me you
a) need to reread these arguments to perhaps get a better grasp
b) have chosen to ignore them.

While you have right to do either of them, if it's b) not even the "clojure
gods" can really help you unless you actually spend some time with the
internals of clojure. ;-).

Las

2012/6/30 Warren Lynn 

> Craig:
>
> If the dominant community attitude is "before you know everything about
> Clojure, you have no right to comment", then that itself will be the reason
> not to use Clojure. But I think that is just you, not the community.
>
> Although I am glad some people paid attention to this post, I have far
> more important things to do than seeking some attention from strangers. I
> hope I stimulated some thinking here. I am a lisp lover, and I feel Clojure
> has a good potential of being a great and practical language, but it has
> its broken parts too and I wish they get fixed, so I will have a better
> experience using it. That is my goal (obvious I hope).
>
>
> On Saturday, June 30, 2012 12:17:39 PM UTC-4, Craig Brozefsky wrote:
>>
>> Warren Lynn  writes:
>>
>> >As I mentioned before, the issue here is not just a fast "last". The
>> >issue here is I find the design of Clojure "wrong", or confusing.
>> That
>> >really shakes my confidence in the whole system.
>>
>> To say stuff like this, then be demure about digging into the code and
>> understanding how things work, followed by asking for others to be do
>> the coding and be and advocate for your rather vague feeling of unease,
>> strikes me as passive-aggressive attention seeking.  To do such while
>> top posting, well, it's just too much for me. 8^)
>>
>> --
>> Craig Brozefsky 
>> Premature reification is the root of all evil
>>
>  --
> 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
>



-- 
László Török

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

Re: Why cannot "last" be fast on vector?

[Warren Lynn]

Craig:

If the dominant community attitude is "before you know everything about 
Clojure, you have no right to comment", then that itself will be the reason 
not to use Clojure. But I think that is just you, not the community.

Although I am glad some people paid attention to this post, I have far more 
important things to do than seeking some attention from strangers. I hope I 
stimulated some thinking here. I am a lisp lover, and I feel Clojure has a 
good potential of being a great and practical language, but it has its 
broken parts too and I wish they get fixed, so I will have a better 
experience using it. That is my goal (obvious I hope).

On Saturday, June 30, 2012 12:17:39 PM UTC-4, Craig Brozefsky wrote:
>
> Warren Lynn  writes: 
>
> >As I mentioned before, the issue here is not just a fast "last". The 
> >issue here is I find the design of Clojure "wrong", or confusing. 
> That 
> >really shakes my confidence in the whole system. 
>
> To say stuff like this, then be demure about digging into the code and 
> understanding how things work, followed by asking for others to be do 
> the coding and be and advocate for your rather vague feeling of unease, 
> strikes me as passive-aggressive attention seeking.  To do such while 
> top posting, well, it's just too much for me. 8^) 
>
> -- 
> Craig Brozefsky  
> Premature reification is the root of all evil 
>

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

Re: Why cannot "last" be fast on vector?

[Craig Brozefsky]

Warren Lynn  writes:

>As I mentioned before, the issue here is not just a fast "last". The
>issue here is I find the design of Clojure "wrong", or confusing. That
>really shakes my confidence in the whole system.

To say stuff like this, then be demure about digging into the code and
understanding how things work, followed by asking for others to be do
the coding and be and advocate for your rather vague feeling of unease,
strikes me as passive-aggressive attention seeking.  To do such while
top posting, well, it's just too much for me. 8^)

-- 
Craig Brozefsky 
Premature reification is the root of all evil

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

Re: Using core.logic at a lower level

[Konrad Hinsen]

Michael Fogus writes:

 > It's not a total solution to all of your requirements, but core.unify
 > is meant for use as a library.  See
 > https://github.com/fogus/unifycle/blob/master/src/fogus/unifycle.clj
 > for examples.

Looks interesting, but I do need logic variables as distinct entities
that can be created and then submitted to constraints by unification.

In fact, what I want to do is use logic variables for dataflow
programming. The main point of building on top of core.logic would be
to avoid rewriting a unification engine that handles logic variables
also inside (potentially nested) data structures.

David Nolen writes:

 > I don't forsee the protocols or functions around logic vars &
 > unification changing. I'm actually quite happy with how flexible &
 > extensible it's turned out to be. cKanren is just around the corner
 > and unification has been left alone.

That sounds promising indeed.

Konrad.

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

Re: Why cannot "last" be fast on vector?

[Warren Lynn]

On Saturday, June 30, 2012 9:51:56 AM UTC-4, stuart@gmail.com wrote:
>
> Having separate "peek" and "last", with documented performance 
> characteristics, makes it straightforward to reason about how code is 
> likely to perform, a point that Mark made earlier.
>
>
As I said before, I strongly feel mixing abstraction and speed path is the 
wrong direction to take. Let me elaborate a little bit more:

1. What's the purpose of high level language and dynamic typing? To 
abstract so we can be more efficient in writing code (Note: code itself my 
not run fast)  and the code is easier to read and maintain. Statically 
typed language has less abstraction power (although it still tries hard 
with things like C++ templates), but faster. Dynamic language has higher 
abstraction power but slower performance. So it is wrong to me to throw 
away the strength of abstraction of a dynamic language in pursuit of 
performance. Performance is of course important, but not at the expense of 
broken abstraction. Maybe that can be done on rare cases that may have a 
huge impact of performance on the whole system, but it seems wrong to do it 
as a "design choice".

2. The argument that if a function takes its pre-designated speed 
characteristics, even when its possible to be faster on a particular type, 
will encourage better code performance or performance analysis, is a very 
convoluted one. If you say: by making "last" slow on vectors, it will force 
people to use "peek", then why not make it even slower on vectors? (how 
about putting a "sleep" there for vectors?). If you say "no, no, sometimes 
people may still use "last" on vectors and we still want the best 
performance in that case", then why not make it as fast as we can?

3. Maybe we don't have one now, but we will have a profiler in the future 
if the language will be put into serious use. With a profiler you can see 
where the performance bottleneck is, and a programmer can reason "Ah, this 
part is slow because I used "last" on a large list", give we already 
documented that "last" will take linear time on lists. So he can choose the 
right data type instead of switching functions. If the abstraction is done 
right, switching a data type should not be difficult.


It is a fundamental design principle of Clojure that, when given two 
> approaches, A and B, make primitive the one that could be used to build the 
> other.  Clojure's "peek" and "last" might be useful to somebody building 
> the "last" that Warren wants.  Warren's "last" is *useless* for building 
> the "peek" and "last" that Clojure already has.
>
>  
>
Not arguing against having Warren's "last".  Just saying that c.c/last 
> ain't broken, and is simpler.
>
>
I don't understand the argument that because a higher level function cannot 
be used to build a lower level function, so it is not worth working on or 
fixing. We can build Clojure with Java but Clojure cannot be used to build 
Java, so we don't need to work on Clojure? 

Keeping both type specific low level functions and abstraction level 
function is less of a problem to me, but I would avoid it if possible.

Stu
>
>
>

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

Re: Would a"def-" macro for private varibales make sense?

[Vinzent]

It's better to use ^:private metadata on the symbol naming the var, since 
there is also defmacro, defmulti, etc, which not have hyphened versions too.

суббота, 30 июня 2012 г., 17:49:36 UTC+6 пользователь Goldritter написал:
>
> For functions I have a "defn" macro to create public functions and a 
> "defn-" macro to define private functions.
> For variables I have only "def". Would it make sense to also have a "def" 
> macro for public variables and a "def-" macro for private variables, also 
> variables which can be only accessed from within the namespace?
>
>
>

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

core.incubator 0.1.1 released

[Chas Emerick]

Hi all,

Version 0.1.1 of the core.incubator project has been released.  It may take a 
couple of hours for the release to be synced up to Maven central.

The project itself can be found here:

https://github.com/clojure/core.incubator

The only change in this version compared to 0.1.0 is the addition of the `<<` 
string interpolation macro (originally described here: 
http://cemerick.com/2009/12/04/string-interpolation-in-clojure/).

Cheers,

- Chas

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

Re: Why cannot "last" be fast on vector?

[Warren Lynn]

As I mentioned before, the issue here is not just a fast "last". The issue 
here is I find the design of Clojure "wrong", or confusing. That really 
shakes my confidence in the whole system.

I am also not talking about implementations, which is a separate issue that 
I don't know much yet 

According to the book "Clojure Programming" by Chas, one of the Clojure's 
principles is to "build on abstractions" and to separate abstractions from 
concrete types. Now I have a little deeper contact with Clojure and my 
impression is that is not the reality.

On Saturday, June 30, 2012 3:47:58 AM UTC-4, Craig Brozefsky wrote:
>
> Warren Lynn  writes: 
>
> >Although I have not yet looked at any of Clojure's internals yet, I 
> >suspect the change won't be too difficult (for the right person). So 
> I 
> >hope/wish someone with enough knowledge, skills and influence will 
> >agree with me and advocate a review of the design ("last" may not be 
> >the only one with issues) and fix some of those things before things 
> >get too messy down the road. 
>
> Err, I don't think this is an issue of "design" let alone something 
> worthy of getting a bit weepy about Clojure failing to be worthy of use 
> in your production system as implied by your previous posts. 
>
> Here is a version of last for clojure.core that will use peek on 
> vectors. 
>
> (def 
>  ^{:arglists '([coll]) 
>:doc "Return the last item in coll." 
>:added "1.0" 
>:static true} 
>  last (fn ^:static last [s] 
> (if (vector? s) 
>   (peek s) 
>   (if (next s) 
> (recur (next s)) 
> (first s) 
>
> If the intent of specifying "in linear time" in the docstring was to 
> guarantee the user that we would be looping over a sequence using 
> first/next, then it should explicitely say so and not just imply it by 
> mentioning linear time.  Otherwise, I see the phrase as a warning, and 
> not as a guarantee. 
>
> David Nolen asked about drop-last and take-last and but-last. 
>
> drop-last is defined as returning lazy sequences.  A 
> change to them that returned a vector with it's tail peeked off would be 
> a change to the language.  I am not so keen on that. 
>
> take-last returns a seq, and it's not obvious after a whiskey just how 
> to rewrite it to be more efficient for vectors and not just end up 
> making it linear scaling on n for vectors. 
>
> However, butlast is documented as returning a seq, so changing pop on a 
> vector might have some performance advantage, and not change the 
> outcomes of the function.  Here is what that would look like. 
>
> (def 
>  ^{:arglists '([coll]) 
>:doc "Return a seq of all but the last item in coll, in linear time" 
>:added "1.0" 
>:static true} 
>  butlast (fn ^:static butlast [s] 
>(if (and (not (empty? s)) 
> (vector? s)) 
>  (pop s) 
>  (loop [ret [] s s] 
>(if (next s) 
>  (recur (conj ret (first s)) (next s)) 
>  (seq ret)) 
>
> These changes don't really bring any new entanglement between 
> clojure.core and the clojure.lang java objects -- because the language 
> defines explicitely how vector conj/peek.  However, going thru 
> clojure.core and optimizing it based on knowledge of implementation in 
> clojure.lang would be complecting - thus punishable by exile to the 
> bitcoin mines. 
>
>
> -- 
> Craig Brozefsky  
> Premature reification is the root of all evil 
>

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

Why cannot "last" be fast on vector?

[David Nolen]

On Friday, June 29, 2012, Mark Engelberg wrote:

> On Fri, Jun 29, 2012 at 4:50 PM, David Nolen wrote:
>
>> ISeq *is* an interface on Clojure JVM. But ideally it would be
>> protocol as in ClojureScript. But then all ISeq implementing types
>> must also implement this new protocol you are suggesting to get these
>> basic *generic* sequence operations we enjoy today.
>>
>>
> I see, you're not saying it can't be done in Clojure, you're saying it
> wouldn't work on ClojureScript.  It seems to me that's a limitation of
> either ClojureScript, or protocols, or both.  My guess is that it's a
> limitation of ClojureScript, because my understanding is that in Clojure,
> every protocol generates a Java interface, so I can't think of any reason
> why you couldn't list that generated interface as a "type" in another
> protocol (although I haven't tried it).
>

It is a host detail one can take advantage of in Clojure. But it is not a
feature of protocols. In fact using protocols this way will fail. You have
to go under the hood to the generated interface. And even then doesn't work
for extend-typed things.

As far as whether this is a problem for large software I don't share you
concerns. ClojureScript is getting towards 7000 lines of standard library.
Not problems yet. core.logic is approaching 40 protocols and 3000 lines of
code. No problems encountered and none foreseen when the full functionality
is ported to ClojureScript.

Why does this seem to scale? Because Clojure's interfaces were already
written in a protocol style. Inheritance doesn't matter much, and they only
define 2-3 methods on average.

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

Re: Why cannot "last" be fast on vector?

[Stuart Halloway]

Having separate "peek" and "last", with documented performance characteristics, 
makes it straightforward to reason about how code is likely to perform, a point 
that Mark made earlier.

It is a fundamental design principle of Clojure that, when given two 
approaches, A and B, make primitive the one that could be used to build the 
other.  Clojure's "peek" and "last" might be useful to somebody building the 
"last" that Warren wants.  Warren's "last" is *useless* for building the "peek" 
and "last" that Clojure already has.

Not arguing against having Warren's "last".  Just saying that c.c/last ain't 
broken, and is simpler.

Stu

> Even not a single action is taken because of this thread, I still would not 
> consider the thread fruitless. It helped me (and maybe others) understand the 
> issue better.
> 
> My point was: you need a clear documentation on a coherent, consistent 
> abstraction, and let the programmer to understand. Just clear documentation 
> is not enough. You can document a very messy system in clear documentation 
> (maybe the US tax code?).
> 
> Here, we are having both "peek" and "last", which is not coherent to me. 
> consider the documentation on an alternative design:
> 
> last: get the last element from an ordered collection. for queues and linked 
> lists, it takes linear time. for vectors, it takes constant time.
> 
> and get rid of "peek" (we already have "first" for linked list and queues, 
> right?)
> 
> Which one is cleaner?
> 
> 
> On Friday, June 29, 2012 3:27:57 PM UTC-4, Sean Corfield wrote:
> On Fri, Jun 29, 2012 at 7:51 AM, Warren Lynn  wrote: 
> > 1. Put good documentations on the functions, and the programmer needs to 
> > have some idea what data structure is fast/slow for what use. 
> 
> At the risk of continuing what is quickly becoming a rather fruitless 
> thread, I figured I'd quote the docstrings from last and peek: 
> 
> last: Return the last item in coll, in linear time 
> 
> peek: For a list or queue, same as first, for a vector, same as, but 
> much more efficient than, last. If the collection is empty, returns 
> nil. 
> 
> That seems like pretty good documentation to me. (last my-vector) is 
> documented to be a linear operation. (peek my-vector) is documented to 
> be "much more efficient". last is not dependent on the type of its 
> argument, peek is. 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
> 
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
> 
> -- 
> 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

Stuart Halloway
Clojure/core
http://clojure.com

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

Re: Would a"def-" macro for private varibales make sense?

[Ambrose Bonnaire-Sergeant]

This topic has come up before. The conclusion from people of authority is
that clojure.core is not the place for this macro, but may be appropriate
for some other library.

Thanks,
Ambrose

On Sat, Jun 30, 2012 at 7:49 PM, Goldritter <
marcus.goldritter.lind...@googlemail.com> wrote:

> For functions I have a "defn" macro to create public functions and a
> "defn-" macro to define private functions.
> For variables I have only "def". Would it make sense to also have a "def"
> macro for public variables and a "def-" macro for private variables, also
> variables which can be only accessed from within the namespace?
>
>
>  --
> 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

Would a"def-" macro for private varibales make sense?

[Goldritter]

For functions I have a "defn" macro to create public functions and a 
"defn-" macro to define private functions.
For variables I have only "def". Would it make sense to also have a "def" 
macro for public variables and a "def-" macro for private variables, also 
variables which can be only accessed from within the namespace?


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

Re: Why cannot "last" be fast on vector?

[Craig Brozefsky]

Sam Ritchie  writes:

>Perhaps place them inside a protocol, where core supplies

I don't think a protocol is needed to identify a performance
characteristic, which as far as I can tell really is limited to vectors.

The definition of vector? itself is sufficient.

Also, consider that last is defined as part of the very base of core,
before protocols get loaded, and even before defn is available.  Using a
protocol to optimize at that level is gonna get dirty dirty.

See my reply to Warren my proposed change to core.  Those defs can be
dropped into clojurescript too, btw.

-- 
Craig Brozefsky 
Premature reification is the root of all evil

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

Re: Why cannot "last" be fast on vector?

[Craig Brozefsky]

Warren Lynn  writes:

>Although I have not yet looked at any of Clojure's internals yet, I
>suspect the change won't be too difficult (for the right person). So I
>hope/wish someone with enough knowledge, skills and influence will
>agree with me and advocate a review of the design ("last" may not be
>the only one with issues) and fix some of those things before things
>get too messy down the road.

Err, I don't think this is an issue of "design" let alone something
worthy of getting a bit weepy about Clojure failing to be worthy of use
in your production system as implied by your previous posts.

Here is a version of last for clojure.core that will use peek on
vectors.

(def 
 ^{:arglists '([coll])
   :doc "Return the last item in coll."
   :added "1.0"
   :static true}
 last (fn ^:static last [s]
(if (vector? s)
  (peek s)
  (if (next s)
(recur (next s))
(first s)

If the intent of specifying "in linear time" in the docstring was to
guarantee the user that we would be looping over a sequence using
first/next, then it should explicitely say so and not just imply it by
mentioning linear time.  Otherwise, I see the phrase as a warning, and
not as a guarantee.

David Nolen asked about drop-last and take-last and but-last.

drop-last is defined as returning lazy sequences.  A
change to them that returned a vector with it's tail peeked off would be
a change to the language.  I am not so keen on that.

take-last returns a seq, and it's not obvious after a whiskey just how
to rewrite it to be more efficient for vectors and not just end up
making it linear scaling on n for vectors.

However, butlast is documented as returning a seq, so changing pop on a
vector might have some performance advantage, and not change the
outcomes of the function.  Here is what that would look like.

(def 
 ^{:arglists '([coll])
   :doc "Return a seq of all but the last item in coll, in linear time"
   :added "1.0"
   :static true}
 butlast (fn ^:static butlast [s]
   (if (and (not (empty? s))
(vector? s))
 (pop s)
 (loop [ret [] s s]
   (if (next s)
 (recur (conj ret (first s)) (next s))
 (seq ret))

These changes don't really bring any new entanglement between
clojure.core and the clojure.lang java objects -- because the language
defines explicitely how vector conj/peek.  However, going thru
clojure.core and optimizing it based on knowledge of implementation in
clojure.lang would be complecting - thus punishable by exile to the
bitcoin mines.


-- 
Craig Brozefsky 
Premature reification is the root of all evil

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