On Mon, Apr 19, 2010 at 12:15 PM, falcon wrote:
> As I understand it, map is, itself, lazy. Does that mean that using
> map to implement these methods would create extra intermediate
> structures?
Yes.
> What if often used functions such as map/reduce/filter were macros,
> that could 'deforest'
As I understand it, map is, itself, lazy. Does that mean that using
map to implement these methods would create extra intermediate
structures?
What if often used functions such as map/reduce/filter were macros,
that could 'deforest' (to use Haskell terminology) these intermediate
structures? Impl
How about this:
Symbols in namespaces are optionally organized into groups. The
vehicle might be something as simple as a :group metadata entry on the
symbols. When symbols from other namespaces are referred, new local
copies are created with :group metadata equal to the namespace name.
When refer
On Mon, Apr 19, 2010 at 10:30 AM, falcon wrote:
> 1. core.clj is a gigantic library with more than 400 function
> definitions (378 defns and 62 defmacros to be exact). I didn't expect
> to find sequence related functions, such as map/reduce in core.
> Doesn't it make sense to move functions to mo
Something like the 'for' macro (if it is thought of as a non-general
monad) can be implemented in terms of reduce. Is there a reason
this isn't so?
I can think of two:
* filter and map are lazy. Implementing every? and some? in those
terms would needlessly introduce lazy sequences to the
