Re: core.async -- lazy evaluation on take

2015-02-16 Thread janpaulbultmann
Make the channel unbuffered, that way it turns into a rondevouz a la ada and 
every producer will block until a consumer takes something from it.

cheers Jan

> On 16.02.2015, at 21:45, Huey Petersen  wrote:
> 
> Hello,
> 
> I was playing around with having a lazy sequence abstracting over a paged 
> http request.  First off, maybe this is dumb, I dunno, lemme know ;p
> 
> So (resources "url") returns a seq and no http request is made, but (take 1 
> (resources "url")) makes a request and (take 50 (resources "url")) may make 
> multiple requests (depending on how many per page).
> 
> I'm wondering if it is possible to implement the same thing as a channel -- 
> no http request is made until someone tries to take from it.  More of a 
> curiosity.
> 
> 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
> --- 
> 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.

-- 
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: If code is data why do we use text editors?

2014-11-17 Thread janpaulbultmann

> Example 1:

I'm pretty sure one could create a set of rules with penalty scores, like latex 
does, for rendering the prettiest, most dense code.

> (-> (some lengthy collection expr here)
>   (map f2)
>   (reduce f1 #{}))

But I find this to be the most readable.

> [[(dec x)  y  wh  ]
>  [x(dec y)wh  ]
>  [xy  (inc w)  h  ]
>  [xy  w(inc h)]]

I wonder if this wouldn't be handled better by a matrix tagged literal.
I find manual column alignment to be a ridiculous time waster when refactoring 
code.
Few tools help and changing a single symbol messes up the entire function.

> (cond
>   (pred1) (consequence1)
>   (pred2 x z) (consequence2))
> 
> (cond
>   (pred1)
> (consequence1)
>   (pred2 x z)
> (consequence2))

This looks like it could be formatted with a penalty based rule system as well.

> All of this, of course, is to say nothing of the minor issues of preserving 
> comments; preserving comment column alignments where desired; and preserving 
> commas where useful in literal data (though I personally tend to eschew them).

In a structural editor you would probably have no comments in the source, see 
gorilla-repl or mathematica notebooks.

> Code is data, and sometimes the best way to format that data for human 
> readability is sufficiently ad-hoc that no autoindent/pprinter could do a 
> fully general good job.

These ad-hoc things might make the code astheatically pleasing, but hard to 
read imho.

Cheers Jan

-- 
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: If code is data why do we use text editors?

2014-11-17 Thread janpaulbultmann
To be honest I think that all the whitespace retaining approaches kinda miss 
the point.
The reason code is mannually formatted is only because it consists of 
characters in a grid aka text. To me manual formatting is a chore, most of the 
time I rely on paredits or codemirrors auto formatting capabilities anyways.

The ability to have a consistent idiomatic visual source structure enforced is 
a feature to me not a bug.

cheers Jan

> On 17.11.2014, at 20:19, Thomas Huber  wrote:
> 
> Yes that s ounds quite reasonable to me
> 
> Am Freitag, 14. November 2014 18:01:04 UTC+1 schrieb Jan-Paul Bultmann:
>> 
>> Yeah this would be awesome, but sadly representing Clojure code as data is 
>> as hard as representing Java.
>> All the reader macros make it a nightmare, and the closest thing you'll get 
>> is tools.analyzer AST nodes.
>> 
>> Session is certainly a step in the right direction, and I wish more people 
>> would embrace it,
>> but it works on text as well. Same pretty much goes for codeq, if that is 
>> not dead.
>> 
>> One could define a Clojure subset that is valid EDN though,
>> which would make everything from serialisable functions to a nano-pass 
>> compiler a lot easier.
>> This has to be the first step imho.
>> 
>> Cheers Jan
>> 
>>> On 14 Nov 2014, at 17:09, atucker  wrote:
>>> re
>>> As I understand it, Session and codeq are tools that somehow keep your code 
>>> in a database instead of plain text.
>>> 
 On Friday, 14 November 2014 12:42:57 UTC, Thomas Huber wrote:
 Hi, here is an idea that has been in my mind for a while. I wonder what 
 you think about it.
 
 In Clojure code is data, right? But when we program we manipulate flat 
 text files, not the data directly.
 Imagine your source code where a data structure (in memory). And 
 programming is done by manipulating this data structure. No text editor 
 and text files involved. 
 Your editor directly manipulates the source data and later saves it on 
 disk (maybe as a text file). 
 
 These are the benefits I can think of:
  - It enables you to use any Clojure function to manipulate your source 
 „code“. Giving you hole new opportunities for refactoring.This functions 
 can be provides as library. 
 
 - Really nice auto complete. 
 
 - Visual programming. Source code can be represented in many different 
 ways (not just text) . The easiest example I can think of is color. It can 
 be represented as text of course (#23FF02)
 but that’s a quite bad interface for humans. Why not display the actual 
 color and provide a color picker? Or what about music notes? Or Math 
 formulars? Or what about a tree view to move and rename functions like 
 files? 
 This could all be implemented in a way that every library can ship there 
 own „views“. I think this „views“ are basically macros that are not 
 limited to text. 
 
 - You don’t have to worry that you text files are in the same state as 
 your JVM (when developing interactive). You only work on your sourcedata 
 and it gets loaded into the JVM automatically.
 
 - Answer questions about your source code. What is the most called 
 function? Who depends on this namespace? Where is this function used? What 
 is the biggest function? Thinks like that become easy. Again you can ship 
 this queries as a library.
 
 
 
 The drawback is you can’t simply program using any text editor. You need a 
 special tool. But we have that anyway (syntax highlighting, paredit etc.). 
 Nobody programs using a bare text editor. 
 
 Maybe this idea is not new? What do you think?
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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.