Functions referenced in macro-expansions cannot be internal?

2016-03-31 Thread hiskennyness 
With Jellz (ne Cells in CL) I want to make reading an attribute of an 
object seem like a normal function call, but reading a cell actually looks 
like this:

(defn- svr [slot me] ;; svr = slot-value-read, me = short version of "self"
>   (when-let [sval (slot @me)]
> (cond
>  (jz-ref? sval)
>  (case (type @sval)
>:jzi (:val @sval)
>:jzf ((:rule @sval) me)
>(error "jz-ref? type unknown" ))
>  :else sval)))


svr is internal because I plan to hide it. Instead of coding (svr :mass 
kenny) I want to code (mass kenny). And instead of hand-coding:

(defn mass [me] (svr :mass me))


...I want to code (jz/def-jzo-slot :mass).

(defmacro def-jzo-slot [slot]
>   `(defn ~(symbol (subs (str slot) 1)) [~'me]
>  (com.tiltontec.jellz.api/svr ~slot ~'me)))


That worked fine until I moved my testing hacks into a proper test file in 
the test hierarchy and Clojure complained that svr was internal (I forget 
the exact language).

I broke down and made it defn instead of defn-, but was something else 
going on? I am used to Common Lisp which sees what I am up to and worries 
about the symbol being defined in the Cells package, not the package into 
which the macroexpansion will be happening.

I always thought that was very clever and classically XWIW (exactly what I 
want), btw.

This is not a big deal, but did I miss some way of keeping svr internal?

-kt

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Mutual Recursion Doesn't Compile

2016-03-31 Thread Lucas Sloan 
declare worked great.  Thanks!

On Thursday, March 31, 2016 at 10:56:02 AM UTC-7, Aaron Cohen wrote:
>
>
> On Thu, Mar 31, 2016 at 1:36 PM, Lucas Sloan  > wrote:
>
>> I have some mutually recursive code as follows:
>>
>>
> Depending on your preferences, either forward declare using "declare" or 
> use "letfn".
>
> Your next question will likely be, "How do I make mutually recursive 
> functions not run out of stack space?" and the answer for that is 
> "trampoline".
>
> https://clojuredocs.org/clojure.core/declare
> https://clojuredocs.org/clojure.core/letfn
> https://clojuredocs.org/clojure.core/trampoline
>
> --Aaron
>  
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Prismatic Schema -- Type signature of reducing functions

2016-03-31 Thread JvJ 

When using functions with schema type signatures for reduce, I run into 
output schema errors whenever I try to short-circuit the reducing operation 
by wrapping the return value in reduced.  How can I modify the type 
signature so that it accepts output values of types A and (reduced A)?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No *print-depth* in Clojure? How about recursive data structures?

2016-03-31 Thread Kenneth Tilton 
On Thu, Mar 31, 2016 at 1:02 PM, Timothy Baldridge 
wrote:

> >> I understand, but this library is all about state because it is about
> modelling long-lived entities over time as an unpredictable stream of
> events act on the model.
>
> No reason why that can't be handled as a graph of nodes + a single atom.
> That's how you would model this in something like Loom (
> https://github.com/aysylu/loom), and how I model all my dataflow graphs.
> Start creating recursive self-referencing data structures you're in for a
> world of hurt.
>



I think a part of me is game for seeing if I can support concurrent updates
to a cell-based universe, eg, have all eleven players update in parallel,
with Clojure STM resolving conflicting updates. But thanks for the
suggestion -- I have seen more than one reference to "everything in a
single atom".

I have to say, porting a hairy library like this is a great way to get up
to speed on a new language. Jellz may not go anywhere, but methinks I'll be
comfortable with Clojure by the time I am done.

Thanks for the input.

Cheers, Kenneth

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Mutual Recursion Doesn't Compile

2016-03-31 Thread jeaye 
On Thu, Mar 31, 2016 at 10:36:45AM -0700, Lucas Sloan wrote:
> I have some mutually recursive code as follows:
> 
> (ns tester.core
>   (:require [clojure.data.json :as json])
>   (:gen-class))
> 
> (defn getValuePathPairs
>   [json]
>   (cond
> (instance? clojure.lang.PersistentVector json) (getVectorValuePathPairs 
> json)
> (instance? clojure.lang.PersistentArrayMap json) (getMapValuePathPairs 
> json)
> (instance? Boolean json) [[json ""]]
> (instance? Number json) [[json ""]]
> (instance? String json) [[json ""]])
> )
> 
> (defn getVectorValuePathPairs
>   [vec]
>   (mapcat (fn [[i e]] 
>  (for [[leaf-value path] (getValuePathPairs e)] 
>[leaf-value (str "[" i "]" path)]))
>(map-indexed vector vec))
> )
> 
> 
> (defn getMapValuePathPairs
>   [m]
>   (mapcat (fn [[k v]]
> (for [[leaf-value path] (getValuePathPairs v)]
>   [leaf-value (str "[" k "]" path)]))
>   m)
> )
> 
> (defn -main
>   "I don't do a whole lot ... yet."
>   [& args]
>   (println (getValuePathPairs ["Blah" 1 true])))
> 
> getValuePathPairs calls getVectorValuePathPairs and getMapValuePathPairs, 
> which in turn call getValuePathPairs.  When I try to compile and run this 
> code I get the following error:
> 
> Exception in thread "main" java.lang.RuntimeException: Unable to resolve 
> symbol: getVectorValuePathPairs in this context, 
> compiling:(tester/core.clj:8:52)
> 
> 
> It appears from my experimentation that the issue is that when compiling 
> getValuePathPairs, 
> the function getVectorValuePathPairs isn't yet defined, as when I compile 
> this into a CIDER repl with the recursion taken out, then compiled again 
> with it put back it runs just fine.
> 
> 
> Googling about mutual recursion in clojure provides a lot of hits about 
> lack of tail call optimization, but no one saying that it's impossible to 
> do (given short recursive depths).  In this particular piece of code, I 
> could just inline the two inner functions, but I'd be giving up a lot of 
> readability.  Is there a way to compile mutually recursive code?  If not, 
> is there a good way to structure this sort of code so I can pull out small 
> functions and name them without running into this problem?

Why not forward declare the required functions with (declare ...)?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Mutual Recursion Doesn't Compile

2016-03-31 Thread Timothy Baldridge 
This is almost a perfect example of something that protocols could help
with (http://clojure.org/reference/protocols):

(defprotocol IGetValuePathPairs
  (getValuePathPairs [json]))

(extend-protocol IGetValuePathPairs
  Number
  (getValuePathPairs [json] ...)
  String
  (getValuePathPairs [json] ...))

And since your protocol is defined first, then you can recurse between the
functions just fine.

Timothy


On Thu, Mar 31, 2016 at 11:55 AM, Aaron Cohen  wrote:

>
> On Thu, Mar 31, 2016 at 1:36 PM, Lucas Sloan <
> predictably.defenestra...@gmail.com> wrote:
>
>> I have some mutually recursive code as follows:
>>
>>
> Depending on your preferences, either forward declare using "declare" or
> use "letfn".
>
> Your next question will likely be, "How do I make mutually recursive
> functions not run out of stack space?" and the answer for that is
> "trampoline".
>
> https://clojuredocs.org/clojure.core/declare
> https://clojuredocs.org/clojure.core/letfn
> https://clojuredocs.org/clojure.core/trampoline
>
> --Aaron
>
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Mutual Recursion Doesn't Compile

2016-03-31 Thread Aaron Cohen 
On Thu, Mar 31, 2016 at 1:36 PM, Lucas Sloan <
predictably.defenestra...@gmail.com> wrote:

> I have some mutually recursive code as follows:
>
>
Depending on your preferences, either forward declare using "declare" or
use "letfn".

Your next question will likely be, "How do I make mutually recursive
functions not run out of stack space?" and the answer for that is
"trampoline".

https://clojuredocs.org/clojure.core/declare
https://clojuredocs.org/clojure.core/letfn
https://clojuredocs.org/clojure.core/trampoline

--Aaron

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mutual Recursion Doesn't Compile

2016-03-31 Thread Lucas Sloan 
I have some mutually recursive code as follows:

(ns tester.core
  (:require [clojure.data.json :as json])
  (:gen-class))

(defn getValuePathPairs
  [json]
  (cond
(instance? clojure.lang.PersistentVector json) (getVectorValuePathPairs 
json)
(instance? clojure.lang.PersistentArrayMap json) (getMapValuePathPairs 
json)
(instance? Boolean json) [[json ""]]
(instance? Number json) [[json ""]]
(instance? String json) [[json ""]])
)

(defn getVectorValuePathPairs
  [vec]
  (mapcat (fn [[i e]] 
 (for [[leaf-value path] (getValuePathPairs e)] 
   [leaf-value (str "[" i "]" path)]))
   (map-indexed vector vec))
)


(defn getMapValuePathPairs
  [m]
  (mapcat (fn [[k v]]
(for [[leaf-value path] (getValuePathPairs v)]
  [leaf-value (str "[" k "]" path)]))
  m)
)

(defn -main
  "I don't do a whole lot ... yet."
  [& args]
  (println (getValuePathPairs ["Blah" 1 true])))

getValuePathPairs calls getVectorValuePathPairs and getMapValuePathPairs, 
which in turn call getValuePathPairs.  When I try to compile and run this 
code I get the following error:

Exception in thread "main" java.lang.RuntimeException: Unable to resolve 
symbol: getVectorValuePathPairs in this context, 
compiling:(tester/core.clj:8:52)


It appears from my experimentation that the issue is that when compiling 
getValuePathPairs, 
the function getVectorValuePathPairs isn't yet defined, as when I compile 
this into a CIDER repl with the recursion taken out, then compiled again 
with it put back it runs just fine.


Googling about mutual recursion in clojure provides a lot of hits about 
lack of tail call optimization, but no one saying that it's impossible to 
do (given short recursive depths).  In this particular piece of code, I 
could just inline the two inner functions, but I'd be giving up a lot of 
readability.  Is there a way to compile mutually recursive code?  If not, 
is there a good way to structure this sort of code so I can pull out small 
functions and name them without running into this problem?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No *print-depth* in Clojure? How about recursive data structures?

2016-03-31 Thread Timothy Baldridge 
>> I understand, but this library is all about state because it is about
modelling long-lived entities over time as an unpredictable stream of
events act on the model.

No reason why that can't be handled as a graph of nodes + a single atom.
That's how you would model this in something like Loom (
https://github.com/aysylu/loom), and how I model all my dataflow graphs.
Start creating recursive self-referencing data structures you're in for a
world of hurt.

On Thu, Mar 31, 2016 at 10:27 AM, Kenneth Tilton  wrote:

>
>
> On Thu, Mar 31, 2016 at 11:56 AM, Timothy Baldridge 
> wrote:
>
>> But we should mention that recursive data structures that contain refs
>> are a bit of a code-smell. Your structures are no longer immutable if they
>> contain refs which are mutable containers for immutable data. Something to
>> think about.
>>
>
> I understand, but this library is all about state because it is about
> modelling long-lived entities over time as an unpredictable stream of
> events act on the model.
>
> One good use case was a virtual RoboCup soccer team fed sensory data every
> 100ms and responding with actions such as turning, moving, and kicking.
>
> So we have a long-lived soccer player instance who observes the world,
> forms a strategy consisting of so many tactics and emits actions based on
> the current tactic. New information comes in and the tactic itself has a
> condition that says when it has succeeded or should be abandoned. etc etc.
>
> This is modeled with a player instance (or "model") and slots for strategy
> etc, each of which is a ruled cell working off the sensory data. These
> Cells depend on each other and notify their dependents when they change.
> Here comes the cycle: a Cell knows the model and slot-name it is mediating,
> so it is self sufficient: if someone tells me to recompute, I can do so
> without also being told the instance. I can then also invoke any observers,
> which are dispatched by slot name.
>
> Well, this much I can change: when someone asks for my value I just need
> to record two pieces of information, the model and slot-name.
>
> Of course my next problem is that no model is an island: they exist in
> trees where each node knows its parent (whassat? a DAG?). Hello cycle.
> Well, I guess just recording the model did that. Anyway, the solution that
> springs to mind is keeping one big dictionary keyed off a serial integer.
>
> Thank god for 64-bits. :)
>
> Thx, kt
>
>
>
>
>
>
>> On Thu, Mar 31, 2016 at 9:53 AM, James Reeves 
>> wrote:
>>
>>> On 31 March 2016 at 16:39, hiskennyness  wrote:
>>>
 In porting my modelling library Cells to Clojure I managed to get a
 stack overflow when the printer tried to print a recursive data structure*
 I have used in the Common Lisp version.

 * Basically, a ref holds a map in which some values are maps in which
 some values are the ref.

 In Lisp we have *print-depth* as well as *print-length* to deal with
 just this case.

 Is there some way I can deal with this, or are recursive data
 structures not really supported by Clojure?

>>>
>>> The same variables exist in Clojure: *print-level* and *print-length*
>>> respectively.
>>>
>>> - James
>>>
>>> --
>>> 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 unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>> --
>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/TGtavJVzVWk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email

Re: No *print-depth* in Clojure? How about recursive data structures?

2016-03-31 Thread Kenneth Tilton 
On Thu, Mar 31, 2016 at 11:56 AM, Timothy Baldridge 
wrote:

> But we should mention that recursive data structures that contain refs are
> a bit of a code-smell. Your structures are no longer immutable if they
> contain refs which are mutable containers for immutable data. Something to
> think about.
>

I understand, but this library is all about state because it is about
modelling long-lived entities over time as an unpredictable stream of
events act on the model.

One good use case was a virtual RoboCup soccer team fed sensory data every
100ms and responding with actions such as turning, moving, and kicking.

So we have a long-lived soccer player instance who observes the world,
forms a strategy consisting of so many tactics and emits actions based on
the current tactic. New information comes in and the tactic itself has a
condition that says when it has succeeded or should be abandoned. etc etc.

This is modeled with a player instance (or "model") and slots for strategy
etc, each of which is a ruled cell working off the sensory data. These
Cells depend on each other and notify their dependents when they change.
Here comes the cycle: a Cell knows the model and slot-name it is mediating,
so it is self sufficient: if someone tells me to recompute, I can do so
without also being told the instance. I can then also invoke any observers,
which are dispatched by slot name.

Well, this much I can change: when someone asks for my value I just need to
record two pieces of information, the model and slot-name.

Of course my next problem is that no model is an island: they exist in
trees where each node knows its parent (whassat? a DAG?). Hello cycle.
Well, I guess just recording the model did that. Anyway, the solution that
springs to mind is keeping one big dictionary keyed off a serial integer.

Thank god for 64-bits. :)

Thx, kt






> On Thu, Mar 31, 2016 at 9:53 AM, James Reeves 
> wrote:
>
>> On 31 March 2016 at 16:39, hiskennyness  wrote:
>>
>>> In porting my modelling library Cells to Clojure I managed to get a
>>> stack overflow when the printer tried to print a recursive data structure*
>>> I have used in the Common Lisp version.
>>>
>>> * Basically, a ref holds a map in which some values are maps in which
>>> some values are the ref.
>>>
>>> In Lisp we have *print-depth* as well as *print-length* to deal with
>>> just this case.
>>>
>>> Is there some way I can deal with this, or are recursive data structures
>>> not really supported by Clojure?
>>>
>>
>> The same variables exist in Clojure: *print-level* and *print-length*
>> respectively.
>>
>> - James
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/TGtavJVzVWk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kenneth Tilton
Founder/Developer
TiltonTec
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

k...@tiltontec.com
http://tiltontec.com
@tiltonsalgebra

646-269-1077

"In a class by itself." *-Macworld*

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

Re: No *print-depth* in Clojure? How about recursive data structures?

2016-03-31 Thread Kenneth Tilton 
On Thu, Mar 31, 2016 at 11:53 AM, James Reeves 
wrote:

> On 31 March 2016 at 16:39, hiskennyness  wrote:
>
>> In porting my modelling library Cells to Clojure I managed to get a stack
>> overflow when the printer tried to print a recursive data structure* I have
>> used in the Common Lisp version.
>>
>> * Basically, a ref holds a map in which some values are maps in which
>> some values are the ref.
>>
>> In Lisp we have *print-depth* as well as *print-length* to deal with just
>> this case.
>>
>> Is there some way I can deal with this, or are recursive data structures
>> not really supported by Clojure?
>>
>
> The same variables exist in Clojure: *print-level* and *print-length*
> respectively.
>

Doh! You can tell how often I use them.

But this is interesting: *print-level* at the top-level is nil, but the
default *behavior* seems to be limited. Same with *print-length*.

Perhaps the repl is helping out.

Thx, kt


> - James
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/TGtavJVzVWk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kenneth Tilton
Founder/Developer
TiltonTec
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

k...@tiltontec.com
http://tiltontec.com
@tiltonsalgebra

646-269-1077

"In a class by itself." *-Macworld*

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No *print-depth* in Clojure? How about recursive data structures?

2016-03-31 Thread Timothy Baldridge 
But we should mention that recursive data structures that contain refs are
a bit of a code-smell. Your structures are no longer immutable if they
contain refs which are mutable containers for immutable data. Something to
think about.

On Thu, Mar 31, 2016 at 9:53 AM, James Reeves  wrote:

> On 31 March 2016 at 16:39, hiskennyness  wrote:
>
>> In porting my modelling library Cells to Clojure I managed to get a stack
>> overflow when the printer tried to print a recursive data structure* I have
>> used in the Common Lisp version.
>>
>> * Basically, a ref holds a map in which some values are maps in which
>> some values are the ref.
>>
>> In Lisp we have *print-depth* as well as *print-length* to deal with just
>> this case.
>>
>> Is there some way I can deal with this, or are recursive data structures
>> not really supported by Clojure?
>>
>
> The same variables exist in Clojure: *print-level* and *print-length*
> respectively.
>
> - James
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No *print-depth* in Clojure? How about recursive data structures?

2016-03-31 Thread James Reeves 
On 31 March 2016 at 16:39, hiskennyness  wrote:

> In porting my modelling library Cells to Clojure I managed to get a stack
> overflow when the printer tried to print a recursive data structure* I have
> used in the Common Lisp version.
>
> * Basically, a ref holds a map in which some values are maps in which some
> values are the ref.
>
> In Lisp we have *print-depth* as well as *print-length* to deal with just
> this case.
>
> Is there some way I can deal with this, or are recursive data structures
> not really supported by Clojure?
>

The same variables exist in Clojure: *print-level* and *print-length*
respectively.

- James

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ClojureScript] Re: [ANN] Quil 2.4.0 and improved live editor

2016-03-31 Thread Elango Cheran 
Thanks, Nikita, for keeping up the good work.  This is great!

-- Elango

On Sat, Mar 26, 2016 at 11:50 AM, Nikita Beloglazov 
wrote:

> > FYI: The quil.info site has a broken link. The "Quil Intro" links to:
> > http://nbeloglazov.com/2014/05/29/quil-intro.html
> > But that's 404.
> > Alan
>
> Thanks for reporting, Alan. I was doing some work on nbeloglazov.com and
> accidentally broke it. It should be working now.
>
>
> > Do we have examples of where people are using Quil ?
>
> I believe people mostly using it for doing sketches/art. Also Quil is
> often used for teaching clojure, for example ClojureBridge:
> https://github.com/ClojureBridge/drawing and talk from last year clojure
> conj:
> https://www.youtube.com/watch?v=n0yN1GauxCA=PLZdCLR02grLrl5ie970A24kvti21hGiOf=7
>
> Nikita
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No *print-depth* in Clojure? How about recursive data structures?

2016-03-31 Thread hiskennyness 
In porting my modelling library Cells to Clojure I managed to get a stack 
overflow when the printer tried to print a recursive data structure* I have 
used in the Common Lisp version.

* Basically, a ref holds a map in which some values are maps in which some 
values are the ref.

In Lisp we have *print-depth* as well as *print-length* to deal with just 
this case.

Is there some way I can deal with this, or are recursive data structures 
not really supported by Clojure?**

** I would consider them effectively not supported if they cannot be 
printed.

I'll start looking for a non-recursive solution, but I thought I would ask 
in case I am missing something.

thx, kt

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Looking for a programmer: remote + flexi hours

2016-03-31 Thread Marcin Jekot | SWARM 

Hi,
My company https://swarmloyalty.co.za is looking for a functional programmer, 
preferably with some solid experience
in Clojure, but not a must. We are using Node/JS (for legacy), and
Clojure/ClojureScript (for any new things we write) + Android/iOS. Bonus if you
know ReactNative.

Hit me up on mar...@swarmloyalty.co.za for an interview.
Thanks, Marcin


Marcin Jekot | Co-Founder | swarmloyalty.co.za | +27849266611

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.