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 <th0mas.hu...@googlemail.com> 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 <agjf....@gmail.com> 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.
> 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.

Reply via email to