Re: Java like static typing for Clojure?

[Antonin Hildebrand]

You could travel to the future and use ClojureScript with Kotlin as 
compilation target and a version of clojure.spec which resolves a subset of 
known constructs to Kotlin type annotations at compile-time :-p

Actually that idea of having a library of compile-time-recognizable spec 
constructs (like nil? string? or instance? predicates) is something I would 
like to see in ClojureScript today. It would generate type annotations for 
Closure Compiler to catch some class of simple bugs at compile time. But 
this is off-topic for this thread...

On Friday, October 21, 2016 at 7:41:31 PM UTC+2, Colin Fleming wrote:
>
> I tried it a couple of years ago, and my impressions were more or less the 
> same as CircleCI's here 
> . I found 
> the type annotation burden much higher than using a typed language such as 
> Kotlin, the type checking was very slow and the boundary between typed and 
> untyped code was really onerous. Ambrose has done some great work recently 
> though, so I should check it out again. However my general feeling is that 
> retrofitting something like Typed Clojure onto an existing language is 
> always going to be more difficult and fraught with problems than having a 
> language which was designed with the types in mind in the first place.
>
> Another possibility which I haven't had time to explore properly is Allen 
> Rohner's spectrum .
>
> Honestly, the easiest solution to my problem is probably just to use 
> Kotlin, which was designed by JetBrains for almost exactly my use case, has 
> great IDE support, and has a lot of smart people working full-time on it. 
> However that has a couple of problems: 1) it would make me sad and 2) I 
> would no longer be dogfooding Cursive all the time, which is a valuable 
> source of finding bugs during development. But at least I'd be spending all 
> my time on developing Cursive features, and not chasing NPEs or 
> investigating all this.
>
> On 21 October 2016 at 19:20, Josh Tilles  > wrote:
>
>> Out of curiosity, did you try Typed Clojure? It certainly has its rough 
>> edges, but you sound willing to bear the burden of annotating code with 
>> types (at the top-level, at least) and I *think* its treatment of Java 
>> interop does what you want: unless instructed otherwise, the typechecker 
>> assumes that arguments to Java methods must not be nil and that any Java 
>> method may return nil.
>>
>> On Thursday, October 20, 2016 at 8:39:04 AM UTC-4, Colin Fleming wrote:
>>>
>>> I recently spent a bunch of time researching exactly this. My motivation 
>>> was that my main project, Cursive, suffers from a ton of NPEs which I find 
>>> very difficult to manage. I wanted to see how difficult it would be to have 
>>> a typed Clojure-like thing, using something similar to Kotlin's type 
>>> system. Kotlin uses a type system which is similar to Java and has Java 
>>> interop as a primary goal, which I would also need since Java interop is 
>>> essential to me. It fixes a bunch of flaws in the Java type system and adds 
>>> new features like nullable types, which I now find it difficult to live 
>>> without.
>>>
>>> Before anyone asks, spec is not useful for me because it relies heavily 
>>> on generative testing to increase your confidence in your functions. I 
>>> can't use generative testing because my application is tied to a large Java 
>>> codebase which I cannot model to any useful degree. Essentially, spec 
>>> recommends runtime tests at the boundary of your system, and nearly my 
>>> entire system is interop boundary. I'm not interested in runtime checks 
>>> except where absolutely necessary - Kotlin does this for me transparently, 
>>> spec doesn't. 
>>>
>>> Here's a short list of my findings. I'm happy to expand on any of these 
>>> points if anyone is curious. It bears repeating - Java interop is 
>>> non-negotiable for me, and that makes a lot of this harder than it would be 
>>> otherwise.
>>>
>>> Disclaimer: I'm no programming language expert. This was hard for me, 
>>> and a surprising amount of it was new to me. I'd appreciate any corrections 
>>> or clarifications.
>>>
>>>1. Type systems are hard. I for one didn't appreciate the complexity 
>>>that goes into making them easy to use. Don't be fooled by the 20-line 
>>>implementations of Hindley-Milner.
>>>2. In particular, generics are very hard, and variance for generic 
>>>objects (i.e. the intersection of generic objects and OO) is the source 
>>> of 
>>>much difficulty.
>>>3. Type systems are split into two main camps - nominal typing (like 
>>>Java, where the types are identified by names) and structural typing, 
>>> where 
>>>the type of an object is defined by it's "shape", like Go's interfaces.
>>>4. One of the major benefits of Clojure is its heterogeneous 
>>>collections, a.k.a. "just use a map". This is very difficult to maintain 
>>> 

Re: Possible ClojureScript compiler issue...

[Antonin Hildebrand]

I think one reason why these issues are reported infrequently is because it 
is really hard to track them down. I can imagine people disable :advanced 
optimizations or restructure their code instead of hunting down the real 
cause. John went really far to isolate/demonstrate the issue.

Thanks for posting that sentinel idea, Thomas. It looks really simple. I 
think instead of sentinel object we could use some large random integer 
which could have similar performance profile as checking for boolean.

I would add another possible idea:

4. we could alter google closure compiler with ClojureScript-aware renaming 
logic, it would preserve prefix $cljs prefix when renaming properties[1]. 
Also in ClojureScript compiler we would rename all cljs-related properties 
to use this convention.

Pros:
1. This would decrease a chance of clashes. When someone runs into it - it 
would be quite self-describing that "$cljs" named property is involved.

Cons:
1. This would lead to slightly bigger generated code (all the $cljs 
prefixes which would previously disappear).
2. The bigger downside IMO is that we would have to maintain our own fork 
of Closure Compiler. Which is not that scary with git. It is pretty easy to 
automate rebasing of a few patch-commits on top of arbitrary complex 
foreign repo.

[1] 
https://github.com/google/closure-compiler/blob/5616a66e40c5dc6ec9be9beacfc0ea20d47bbcfc/src/com/google/javascript/jscomp/RenameProperties.java#L284



On Sunday, October 16, 2016 at 4:36:38 PM UTC+2, Thomas Heller wrote:
>
> FWIW I investigated the check with "true" and a sentinel value and found 
> them to both have a small performance impact over just checking for a 
> true-ish property.
>
> http://dev.clojure.org/jira/browse/CLJS-1658
>
> The impact is really small so it might be worth the trade-off.
>
> /thomas
>
> On Sunday, October 16, 2016 at 3:59:20 PM UTC+2, David Nolen wrote:
>>
>> It's true that there other scenarios where you can encounter this but it 
>> gets reported infrequently enough that I don't think these kinds of 
>> property name collisions are common.
>>
>> Still it has come up before and I think the simplest solution least 
>> likely to adversely affect performance is to test for a def'onced unique 
>> object instead of `true`.
>>
>> David
>>
>> On Sat, Oct 15, 2016 at 8:46 PM, Antonin Hildebrand <
>> antonin.h...@gmail.com> wrote:
>>
>>> Unfortunately, this problem is not specific to `js->clj` only.
>>>
>>> I believe in general under :advanced optimizations, any object which was 
>>> created or modified by a code which 
>>> was not subject of the same closure compiler optimization pass could 
>>> exhibit similar problems when used with ClojureScript core functions like 
>>> `satisfies?`.
>>>
>>> That also includes working with external data (your case), and working 
>>> with objects created/modified by adding properties by string names.
>>>
>>> To illustrate, I created a screenshot of cljs type instance with two 
>>> protocols, to see the internals in dev mode:
>>> https://dl.dropboxusercontent.com/u/559047/cljs-protocol-internals-01.png
>>> In the selected text I highlighted part of generated code for 
>>> `satisfies?` call.
>>>
>>> ClojureScript adds/checks $cljs prefixed properties to objects. These 
>>> internal properties get renamed by closure compiler.
>>> So any object which happens to have one of those renamed names 
>>> independently added as their property will potentially confuse functions 
>>> like `satisfies?`.
>>>
>>> Possible solutions I see:
>>>
>>> 1. use string names for clojurescript internal properties, and avoid 
>>> clashes by using "unique-enough" prefix even in advanced mode - still not 
>>> safe solution, but would minimize clash chances
>>>
>>> or 
>>>
>>> 2. start tracking which objects belong to cljs land, have one 
>>> "unique-enough" string name as a marker, clojurescript functions like 
>>> satisfies? would check this marker before proceeding further. Still dirty, 
>>> one could clobber cljs properties by modifying a cljs-land-object from 
>>> unaware Javascript code. And this would probably change behaviour of some 
>>> existing code.
>>>
>>> or
>>>
>>> 3. use prototypal inheritance and "hide" all ClojureScript internal 
>>> properties in a new link in the prototype chain, plain javascript objects 
>>> would miss this link so it could be easily detected, properties would not 
>

Re: Possible ClojureScript compiler issue...

[Antonin Hildebrand]

Unfortunately, this problem is not specific to `js->clj` only.

I believe in general under :advanced optimizations, any object which was 
created or modified by a code which 
was not subject of the same closure compiler optimization pass could 
exhibit similar problems when used with ClojureScript core functions like 
`satisfies?`.

That also includes working with external data (your case), and working with 
objects created/modified by adding properties by string names.

To illustrate, I created a screenshot of cljs type instance with two 
protocols, to see the internals in dev mode:
https://dl.dropboxusercontent.com/u/559047/cljs-protocol-internals-01.png
In the selected text I highlighted part of generated code for `satisfies?` 
call.

ClojureScript adds/checks $cljs prefixed properties to objects. These 
internal properties get renamed by closure compiler.
So any object which happens to have one of those renamed names 
independently added as their property will potentially confuse functions 
like `satisfies?`.

Possible solutions I see:

1. use string names for clojurescript internal properties, and avoid 
clashes by using "unique-enough" prefix even in advanced mode - still not 
safe solution, but would minimize clash chances

or 

2. start tracking which objects belong to cljs land, have one 
"unique-enough" string name as a marker, clojurescript functions like 
satisfies? would check this marker before proceeding further. Still dirty, 
one could clobber cljs properties by modifying a cljs-land-object from 
unaware Javascript code. And this would probably change behaviour of some 
existing code.

or

3. use prototypal inheritance and "hide" all ClojureScript internal 
properties in a new link in the prototype chain, plain javascript objects 
would miss this link so it could be easily detected, properties would not 
clash even if they got same names. ClojureScript functions like satisfies? 
would properly
walk the chain and read properties from proper link which belongs only to 
ClojureScript. Ale we would not need any special "magic" marker - the 
Javascript type of the link in prototype would safely identify it.
I believe this would be correct solution. But I guess, this would be too 
dramatic change in ClojureScript internals and might break a lot of other 
things I currently don't understand. Also performance could get a hit.

Better ideas, anyone? :-)

ps. don't use :advanced mode when programming atomic reactors in 
ClojureScript ;-p

On Saturday, October 15, 2016 at 10:59:14 PM UTC+2, John Szakmeister wrote:
>
> On Sat, Oct 15, 2016 at 2:49 PM, David Nolen  > wrote: 
> > This issue is somewhat to be expected if you're going to use `js->clj`. 
> This 
> > issue has nothing to do with ClojureScript compiler versions - you just 
> got 
> > lucky before. Google Closure will collapse properties, but some of these 
> > collapsed properties are going to be used to determine protocol 
> membership. 
> > That's it. 
>
> Wow.  I did not that expect that at all.  It makes sense, but it's 
> unfortunate. 
>
> > I suggest just avoiding `js->clj` and using your own simple helper for 
> > recursively converting JSON into Clojure values. Changing the 
> (admittedly 
> > questionable) behavior of `js->clj` will only lead to more breakage. 
>
> I'll definitely look at alternatives.  It'd be nice if js->clj had 
> documentation on this shortcoming though, and perhaps pointers to 
> better alternatives. 
>
> Thanks for the help David! 
>
> -John 
>

-- 
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: [?] cljs-devtools vs. dirac DevTools

[Antonin Hildebrand]

Hi,

I'm the author of both tools.

cljs-devtools is essential and you should start with it if you are 
developing under Chrome. It presents ClojureScript data structures when you 
print them via console.log. cljs-devtools must be configured as a library 
included in your project/app.

Dirac is a fork of Chrome DevTools with ClojureScript-specific features 
added. You use it instead of internal DevTools in Chrome. 
It is more advanced tool and requires some non-trivial setup. It is the 
next evolutionary step when you master your ClojureScript development 
environment.
There are many nice-to-have features (as listed on the homepage) but the 
distinguished one is to be able to REPL cljs code in the context of a 
paused breakpoint. 
This is obviously very advanced feature you would use debugging complex 
code once in 10 years, but I'm not aware of any other tool allowing this.
I would not recommend it to beginners, as they don't usually need that 
power.

Both tools are complementary. Dirac expects cljs-devtools as a soft 
dependency. It does not make much sense to use Dirac REPL without having 
cljs-devtools presenting cljs data structures in a friendly way.

good luck!
Antonin


On Monday, October 10, 2016 at 6:04:36 AM UTC+2, Philos Kim wrote:
>
> Could anyone explain the difference between cljs-devtools and dirac 
> DevTools?
>
> And which one to use when?
>
> https://github.com/binaryage/cljs-devtools
>
> https://github.com/binaryage/dirac
>
> Many thanks in advance.
>
>

-- 
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: why is it so annoying to run clojure code

[Antonin Hildebrand]

> Why not just uberjar it? 
Good point. I didn't know that was an option at the time. My google-fu 
didn't reveal this option at the time. As someone originally coming from 
non-java lands, I wasn't asking the right questions.

Just few weeks later I learned hard way that uberjars are not my good 
friend:
https://github.com/binaryage/dirac/releases/tag/v0.1.3

I assume those concepts are basic to someone with experience with java. I'm 
sorry for my ignorance. My path was ... -> Javascript -> ClojureScript -> 
Clojure. Not Java -> Clojure -> ClojureScript. 

I was just looking for a way to let people run my brand new cli tool from a 
command-line, a task originally estimated to 5 minutes :-)

On Sunday, June 12, 2016 at 3:24:31 AM UTC+2, James Reeves wrote:
>
> On 12 June 2016 at 01:36, Antonin Hildebrand  > wrote:
>
>> I wanted users of my library (which has dependencies) to run a helper 
>> tool from command-line (ideally with a simple wrapper bash script). And I 
>> didn't want to make them dependent on lein or boot.
>>
>> I came up with this (bash+maven+java):
>> https://github.com/binaryage/dirac/blob/master/scripts/agent-launcher.sh
>>
>> writing it was a horrific experience, I want that day back!
>> Antonin
>>
>
> Why not just uberjar it? You could upload it to GitHub as part of a 
> release (or S3, or wherever), then write a small script to download and run 
> it. It would be a couple of lines of bash, but have the same effect.
>
> - 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: why is it so annoying to run clojure code

[Antonin Hildebrand]

> What's the difference?
more than 1 lines of code[1] (not counting comments)

[1] https://gist.github.com/darwin/ede8911f7b493f17c1307433484f1d80

On Sunday, June 12, 2016 at 3:05:02 AM UTC+2, Witold Szczerba wrote:
>
> You did not want to make then depend on Lein, which is… a script, so you 
> wrote your own script and made users of your library depend on it. What's 
> the difference?
>
> On Sun, Jun 12, 2016 at 2:36 AM, Antonin Hildebrand <
> antonin.h...@gmail.com > wrote:
>
>> I wanted users of my library (which has dependencies) to run a helper 
>> tool from command-line (ideally with a simple wrapper bash script). And I 
>> didn't want to make them dependent on lein or boot.
>>
>> I came up with this (bash+maven+java):
>> https://github.com/binaryage/dirac/blob/master/scripts/agent-launcher.sh
>>
>> writing it was a horrific experience, I want that day back!
>> Antonin
>>
>> On Thursday, June 9, 2016 at 6:48:19 PM UTC+2, James Reeves wrote:
>>>
>>> You can run Clojure directly, but often you don't just need Clojure, but 
>>> other libraries as well. The "lein run" command not only runs your code, it 
>>> also handles downloading any dependencies your code might have.
>>>
>>> In Ruby terms, Leiningen is the equivalent of ruby + rbenv + bundler + 
>>> rake. I'm less familiar with the Python stack, but I believe python + 
>>> virtualenv + pip goes some way to having the same functionality.
>>>
>>> - James
>>>
>>> On 9 June 2016 at 17:08, Jiacai Liu  wrote:
>>>
>>>> I  started learning clojure recently, and I am annoyed at the way to 
>>>> run it (aka. lein run). why clojure script can't be run like python,ruby 
>>>> or 
>>>> scala, like python .py
>>>>
>>>> -- 
>>>> 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 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.

Re: why is it so annoying to run clojure code

[Antonin Hildebrand]

I wanted users of my library (which has dependencies) to run a helper tool 
from command-line (ideally with a simple wrapper bash script). And I didn't 
want to make them dependent on lein or boot.

I came up with this (bash+maven+java):
https://github.com/binaryage/dirac/blob/master/scripts/agent-launcher.sh

writing it was a horrific experience, I want that day back!
Antonin

On Thursday, June 9, 2016 at 6:48:19 PM UTC+2, James Reeves wrote:
>
> You can run Clojure directly, but often you don't just need Clojure, but 
> other libraries as well. The "lein run" command not only runs your code, it 
> also handles downloading any dependencies your code might have.
>
> In Ruby terms, Leiningen is the equivalent of ruby + rbenv + bundler + 
> rake. I'm less familiar with the Python stack, but I believe python + 
> virtualenv + pip goes some way to having the same functionality.
>
> - James
>
> On 9 June 2016 at 17:08, Jiacai Liu > 
> wrote:
>
>> I  started learning clojure recently, and I am annoyed at the way to run 
>> it (aka. lein run). why clojure script can't be run like python,ruby or 
>> scala, like python .py
>>
>> -- 
>> 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.

Re: [GSoC idea] Pluggable back-ends architecture for ClojureScript compiler

[Antonin Hildebrand]

I like the idea.

I was thinking about a similar project. The goal would be to design and 
implement user-configurable, pluggable system for "jacking" into 
ClojureScript compilation pipeline as discussed here[1].

The first dog-fooding application could be instrumentation middleware for 
collecting code-coverage information. I believe this could be implemented 
by rewriting forms between reader and analyzer. Or instrumenting AST output 
from analyzer before it gets passed to emit-phase.

just my 2cents,
Antonin

[1] http://blog.fogus.me/2012/04/25/the-clojurescript-compilation-pipeline/


On Sunday, February 21, 2016 at 9:20:18 AM UTC+1, Edward Knyshov wrote:
>
>
>
> *Pluggable back-ends architecture for ClojureScript compilerBrief 
> explanation:* There are a lot of ClojureScript script compiler forks 
> exist to provide different compilation targets other than js. Most of them 
> are currently stuck because of rapid ClojureScript development and 
> difficulties with keeping fork in sync with upstream. We could consider 
> refactoring ClojureScript to provide plugable backends architecture, 
> specifically to allow users replace code generation stage of compiler and 
> implement js generator as one of such backends.
>  
> *Expected results: *ClojureScript compiler is refactored to allow further 
> active development of plenty other backends to bootstrap Clojure in such 
> environments as c/c++, llvm, python, emacs lisp, lua, etc. Ability to use 
> clojure mostly everywhere.
>  
> *Knowledge:* ClojureScript, Clojure, JavaScript
>
> Need to know, what do you think guys.
>

-- 
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: Splitting Read into 2 steps?

[Antonin Hildebrand]

Hi Terje,

I think I had a similar problem when implementing parsing for Plastic[1] 
(an experimental editor in ClojureScript).
I wanted to use tools.reader (for robustness), but I needed more 
information about tokens from it (particularly comments, new-lines and 
whitespace).

I ended up hijacking log-source*[2] hook for that. I track[3] tokens via 
log-source* and build parse-tree myself.

It is a hacky solution, but I avoided rewriting tools.reader.
Antonin

[1] https://github.com/darwin/plastic
[2] 
https://github.com/darwin/tools.reader/commit/321abf7b4242b30c94052c93cdcf5d5d92c7dc38
[3] https://github.com/darwin/plastic/blob/master/src/meld/meld/tracker.cljs

On Monday, February 8, 2016 at 8:12:10 AM UTC+1, Terje Dahl wrote:
>
>
>
> I have been studying and and implementing my own version of LispReader / 
> tool.reader - for the purpose of syntax highlighting and visual token 
> manipulation.
> My question is this:
> Why not split this into 2 steps?
>
>1. Reads the input (from PushbackReader et al) and emits a stream of 
>tokens, preserving information about location in source, and applying 
>typing to tokens, if possible.
>2. Consumes the stream from step one, descending recursively, applying 
>reader-macros, resolving symbols in name-spaces, etc.
>
> This would allow for easier configuration of each step, such as:
>
>- turning exceptions on/off (useful for syntax highlighting)
>- custom reader-macros and custom classes of reader-macros
>- static analysis of code by controlling the namespacing/context
>
> Is there any reason not to do this?
> (Other than: This is the way it has always been done. This is the way 
> lisp-readers are aways implemented.)
>
> Perhaps such a development is already underway?
>
> Finally, if I wanted to implement such a solution, would it be to do it in 
> Java or Clojure?  Why? 
>
>

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