Re: Terminating 'clj' REPL session

[Oleksandr Shulgin]

On Sat, Dec 9, 2017 at 11:37 PM, Alan Thompson  wrote:

> Hi - Just downloaded the new Clojure 1.9.0 package.  When I tried the repl
> I noticed that it doesn't respond to either `exit` or `quit` as one might
> expect from the lein repl:
>
> ~/cool/tools > clj
> Clojure 1.9.0
> user=> (+ 2 3)
> 5
> user=> exit
> CompilerException java.lang.RuntimeException: Unable to resolve symbol:
> exit in this context, compiling:(NO_SOURCE_PATH:0:0)
> user=>
> user=> quit
> CompilerException java.lang.RuntimeException: Unable to resolve symbol:
> quit in this context, compiling:(NO_SOURCE_PATH:0:0)
> user=> ^D
> ~/cool/tools >
>
>
> Lein repl for comparison:
>
> ~/tupelo > lein repl
> nREPL server started on port 37115 on host 127.0.0.1 - Clojure 1.9.0
> tupelo.core=> exit
> Bye for now!
>
> ~/tupelo >
>
> ~/tupelo > lein repl
> nREPL server started on port 40639 on host 127.0.0.1 - Clojure 1.9.0
> tupelo.core=> quit
> Bye for now!
> ~/tupelo >
>
>
> The new repl does terminate upon CRTL-D or CRTL-C, but many users will
> probably be confused that `quit` and `exit` are not accepted.
>

To recap, my lein repl starts with the following help banner:

Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

That doesn't suggest that `exit` alone without the function call is going
stop the main loop.

The problems begin when one tries to use it in the middle of an unfinished
s-expr, a primary reason could be that the user doesn't understand the
changed prompt:

user=> (+ 1
  #_=> exit
  #_=> )

CompilerException java.lang.RuntimeException: Unable to resolve symbol:
exit in this context, compiling:(/tmp/form-init4088985676787273132.clj:1:1)

Actually, a more likely scenario is like this:

user=> (+ 1
  #_=> exit
  #_=> quit
  #_=> help
  #_=> why are you doing this to me?

Nor does (exit) call works, which is contrary to the help doc:

user=> (+ 1
  #_=> (exit))

CompilerException java.lang.RuntimeException: Unable to resolve symbol:
exit in this context, compiling:(/tmp/form-init4248691177104478700.clj:2:1)

An interesting thing is the same issue is discussed currently on the
PostgreSQL mailing list about behavior of psql:


https://www.postgresql.org/message-id/flat/94e59791-e788-4ebb-80a9-9c871ff5df64%40manitou-mail.org

In particular, the following suggestion seems to provide a reasonable way
out of this problem:


https://www.postgresql.org/message-id/flat/94e59791-e788-4ebb-80a9-9c871ff5df64%40manitou-mail.org#1735.1512761160%40sss.pgh.pa.us

Not sure if this can be done with Clojure, short of employing reader macros
in some way?

Cheers,
--
Alex

-- 
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: Immutable names of things?

[Jozef Wagner]

I think it's a great idea and it may even be a missing piece in the 'Grow, 
not Break' approach https://youtu.be/oyLBGkS5ICk?t=1946 , namely to the 
problem that good names are hard to come by. 

Suppose a library author wants to make a breaking change to some function. 
They change the doc-name of the 'old' function to e.g. foo-old, and reuse 
foo for the new 'version' of the function. Existing code using this library 
would work as before, but in the sources the visible name would 
automagically update to the `foo-old`, thus informing developers that 
there's a new/better flavor of foo available. This is IMO a far better 
approach then inventing new names like new-foo, foo2, or my.ns2/foo, for 
functions that are meant to succeed their legacy variants.

Jozef

On Thursday, December 7, 2017 at 6:37:10 AM UTC+1, Didier wrote:
>
> Warning: This is the spawn of an idea, not very well refined, and that is 
> little extravagant.
>
> I've been doing some hammock time, and I've been thinking that names in a 
> programming language are kind of a complecting of two things, the human 
> readable form, and the machine identifier. What if a function always had 
> the same name, which never changed, from the moment the function was 
> created. This would be fine, until a human finds it didn't like the name 
> anymore, and thus a refactor of the name would occur, requiring to change 
> all references to the function. This is also true say of a spec, if you 
> want to change the name of the spec, its a big refactor to update all usage 
> of it. So var names and spec names are troubling in that if humans want to 
> refer to it differently, they also break all machine reference to them.
>
> So I thought, how awesome would it be if each named things in a 
> programming language would be given a unique machine name, which can be 
> used everywhere, and the name you saw was just meta-data for the programmer 
> to have a more human readable/descriptive name.
>
> The problem is I'm not sure how to do this with a text based programming 
> language. I can imagine a language where constructs would be first class, 
> not based on text, and thus all construct could be assigned a unique id and 
> a name, and the IDEs could easily hide the unique ids and project a view of 
> the construct with the human name instead. Code would be stored in a 
> structured format, and obviously a standard editor would not work, and an 
> IDE of some form would be required.
>
> So right now, my idea is that maybe you can compromise. If you added 
> support for Vars and specs, so that they can have like a doc-name. It would 
> be like a doc-string a bit, but it expects a name instead. That name could 
> be the human readable name, you could change it freely. The normal var name 
> or spec name would continue to be used as normal to refer to this var/spec 
> from other code. At its most basic it means you can have the normal name be 
> anything, maybe a name you don't like that much, or you could go further 
> and make it a guid if you want. Then you could make the doc-name the name 
> you want to use when talking to other people, or when people read the code. 
> Now IDEs could support this doc-name, so they could show the doc-name in 
> place everywhere you have code referring to the normal name. They could 
> auto-complete from doc-name to normal name, etc.
>
> So an IDE could still kind of hide this for you, and make it appear like 
> everything is just doc-name pointing to each other, and refactoring would 
> not require changing all code that refers to it, but actually its just a 
> change of the doc-name on the var or spec being pointed to, but the IDE 
> could quickly replace the new doc-name in place of the normal name 
> everywhere else.
>
> Where it would be maybe a bit more confusing, is when using an editor that 
> would not support doc-names to that extent. In those cases, you can ignore 
> doc-name, consider it just like one more piece of documentation.
>
> Doc-name could be optional too, so if you plan on working by yourself, or 
> just in a simple editor, you can ignore this whole thing and work as normal.
>
> Now maybe this whole thing is solved by having a powerful renaming 
> refactoring tool that can hunt for all usage and update the name everywhere 
> in a sound way, but that's harder to do in Clojure, and still breaks when 
> its a library for example, as you can't just refactor all consumers without 
> having both access to their code base, and even if you do, its tedious to 
> pull down everything in your desktop and set it up for such a refactor.
>
> I'd be interested in thoughts about this, even if its just, that sounds 
> like a terrible idea :p.
>
> 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 thi

[ANN] Pinpointer: yet another spec error reporter

[OHTA Shogo]

Hi, all

I’m happy to announce the first release of Pinpointer, yet another 
implementation of spec error reporter based on a precise error analysis.

- https://github.com/athos/Pinpointer

Pinpointer provides functionalities very similar to the existing spec error 
reporters (eg. Expound[1], Inspectable[2] etc.), that is, reporting spec 
errors in a more human-readable way.

[1] https://github.com/bhb/expound
[2] https://github.com/jpmonettas/inspectable

Unlike those libraries, which analyze spec errors using several heuristics, 
Pinpointer performs a systematic error analysis traversing a pair of the 
spec and the input. This makes it possible to report the error even in 
complicated cases where s/conformer would transform the input value, like 
the following:

=> (require '[pinpointer.core :as p] '[clojure.spec.alpha :as s])
=> (p/pinpointer (s/and string? (s/conformer seq) (s/* #{\a})) "aabaa")
Detected 1 spec error:
--
(1/1)


Cause: (\a \a \b \a \a)
  ^^   
 Expected: #{\a}


   --- This comes originally from ---


 Original: "aabaa"
   ^^^
 Spec
  Applied: (s/and string? (s/conformer seq) (s/* #{\a}))


--
nil
user=>


(BTW the above example is just a demo for Pinpointer's capability, and it 
doesn't mean to encourage you to write specs like that.)

On the other hand, one of the downsides of the library is that Pinpointer 
has to know in advance the behaviors of the spec macros involved in a spec 
form for its error analysis. Note also that, Pinpointer occasionally uses  
eval under the hood (at least for now), so it’s basically intended to be 
used for development purpose only.

I hope you’ll like it :)

Thanks,
Shogo

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

[ANN] clj-async-profiler — embeddable profiler with flame graphs, based on Java's async-profiler

[Alexander Yakushev]

I've just released a wrapper 
around https://github.com/jvm-profiling-tools/async-profiler that allows 
controlling the profiler directly from the REPL of the program you want to 
profile. The JAR file ships the profiling agent and the flamegraph 
generation script from https://github.com/brendangregg/FlameGraph, so that 
you can profile your code and instantly generate flame graphs from it.

Introductory blog 
post: http://clojure-goes-fast.com/blog/profiling-tool-async-profiler/
Repository: https://github.com/clojure-goes-fast/clj-async-profiler

Hope you'll like it!

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

[ANN] clj-async-profiler — embeddable profiler with flame graphs, based on Java's async-profiler

[Alex Miller]

Totally awesome - nice work!

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

Clojure CLI tool fails to resolve weird transitive dependencies.

[Jonathan Fischer]

I apologize, I'm not certain of the right name for this.

I'm pulling in libgdx and its dependencies.  In Leiningen, my dependencies 
vector looks like this:

  :dependencies [[org.clojure/clojure "1.8.0"]
 [com.badlogicgames.gdx/gdx "1.9.6"]
 [com.badlogicgames.gdx/gdx-backend-lwjgl3 "1.9.6"]
 [com.badlogicgames.gdx/gdx-platform "1.9.6" :classifier 
"natives-desktop"]]


Which expands out to this (in lein deps :tree, leaving out the Clojure core 
libs and nrepl and whatnot):

 [com.badlogicgames.gdx/gdx-backend-lwjgl3 "1.9.6"]
   [com.badlogicgames.jlayer/jlayer "1.0.1-gdx"]
   [org.jcraft/jorbis "0.0.17"]
   [org.lwjgl/lwjgl-glfw "3.1.0"]
   [org.lwjgl/lwjgl-glfw "3.1.0" :classifier "natives-linux"]
   [org.lwjgl/lwjgl-glfw "3.1.0" :classifier "natives-macos"]
   [org.lwjgl/lwjgl-glfw "3.1.0" :classifier "natives-windows"]
   [org.lwjgl/lwjgl-jemalloc "3.1.0"]
   [org.lwjgl/lwjgl-jemalloc "3.1.0" :classifier "natives-linux"]
   [org.lwjgl/lwjgl-jemalloc "3.1.0" :classifier "natives-macos"]
   [org.lwjgl/lwjgl-jemalloc "3.1.0" :classifier "natives-windows"]
   [org.lwjgl/lwjgl-openal "3.1.0"]
   [org.lwjgl/lwjgl-openal "3.1.0" :classifier "natives-linux"]
   [org.lwjgl/lwjgl-openal "3.1.0" :classifier "natives-macos"]
   [org.lwjgl/lwjgl-openal "3.1.0" :classifier "natives-windows"]
   [org.lwjgl/lwjgl-opengl "3.1.0"]
   [org.lwjgl/lwjgl "3.1.0"]
   [org.lwjgl/lwjgl "3.1.0" :classifier "natives-linux"]
   [org.lwjgl/lwjgl "3.1.0" :classifier "natives-macos"]
   [org.lwjgl/lwjgl "3.1.0" :classifier "natives-windows"]
 [com.badlogicgames.gdx/gdx-platform "1.9.6" :classifier "natives-desktop"]
 [com.badlogicgames.gdx/gdx "1.9.6"]


And the classpath ends up like this:

/Users/jfischer/Desktop/Clojure/gdx-skeleton/test:/Users/jfischer/Desktop/Clojure/gdx-skeleton/src:/Users/jfischer/Desktop/Clojure/gdx-skeleton/dev-resources:/Users/jfischer/Desktop/Clojure/gdx-skeleton/resources:/Users/jfischer/Desktop/Clojure/gdx-skeleton/target/default/classes:/Users/jfischer/.m2/repository/org/clojure/clojure/1.8.0/clojure-1.8.0.jar:/Users/jfischer/.m2/repository/com/badlogicgames/gdx/gdx-backend-lwjgl3/1.9.6/gdx-backend-lwjgl3-1.9.6.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-openal/3.1.0/lwjgl-openal-3.1.0.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-openal/3.1.0/lwjgl-openal-3.1.0-natives-windows.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl/3.1.0/lwjgl-3.1.0.jar:/Users/jfischer/.m2/repository/com/badlogicgames/gdx/gdx/1.9.6/gdx-1.9.6.jar:/Users/jfischer/.m2/repository/org/jcraft/jorbis/0.0.17/jorbis-0.0.17.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-openal/3.1.0/lwjgl-openal-3.1.0-natives-macos.jar:/Users/jfischer/.m2/repository/cider/cider-nrepl/0.15.0/cider-nrepl-0.15.0.jar:/Users/jfischer/.m2/repository/com/badlogicgames/gdx/gdx-platform/1.9.6/gdx-platform-1.9.6-natives-desktop.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-glfw/3.1.0/lwjgl-glfw-3.1.0.jar:/Users/jfischer/.m2/repository/clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-glfw/3.1.0/lwjgl-glfw-3.1.0-natives-macos.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-glfw/3.1.0/lwjgl-glfw-3.1.0-natives-windows.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-opengl/3.1.0/lwjgl-opengl-3.1.0.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl/3.1.0/lwjgl-3.1.0-natives-windows.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl/3.1.0/lwjgl-3.1.0-natives-linux.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-jemalloc/3.1.0/lwjgl-jemalloc-3.1.0.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-jemalloc/3.1.0/lwjgl-jemalloc-3.1.0-natives-windows.jar:/Users/jfischer/.m2/repository/com/badlogicgames/jlayer/jlayer/1.0.1-gdx/jlayer-1.0.1-gdx.jar:/Users/jfischer/.m2/repository/org/tcrawley/dynapath/0.2.5/dynapath-0.2.5.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-glfw/3.1.0/lwjgl-glfw-3.1.0-natives-linux.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl/3.1.0/lwjgl-3.1.0-natives-macos.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-jemalloc/3.1.0/lwjgl-jemalloc-3.1.0-natives-linux.jar:/Users/jfischer/.m2/repository/org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-openal/3.1.0/lwjgl-openal-3.1.0-natives-linux.jar:/Users/jfischer/.m2/repository/org/lwjgl/lwjgl-jemalloc/3.1.0/lwjgl-jemalloc-3.1.0-natives-macos.jar


Importantly, there's a jar there for each of those classifiers.

If I try and replicate the same thing using deps.edn:

{:deps
  {org.clojure/clojure {:mvn/version "1.8.0"}
   com.badlogicgames.gdx/gdx {:mvn/versin "1.9.6"}
   com.badlogicgames.gdx/gdx-backend-lwjgl3 {:mvn/version "1.9.6"}
   com.badlogicgames.gdx/gdx-platform {:mvn/version "1.9.6" :classifier 
"natives-desktop"}}}


I don't get all of the jars with different classifiers:

src:/Users/jfischer/.m2/repository/org/clojure/clojure/1.8.0/clojure-1.8.0.jar:/Users/jfischer/.m2/repository/org/jcraf

Re: Clojure CLI tool fails to resolve weird transitive dependencies.

[David Bürgin]

On 11/12/17 20:47, Jonathan Fischer wrote:
> com.badlogicgames.gdx/gdx {:mvn/versin "1.9.6"}

Typo?


-- 
David

-- 
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: Clojure CLI tool fails to resolve weird transitive dependencies.

[Jonathan Fischer]

Ha, I think that must’ve snuck in there during editing. Fixing that particular 
typo didn’t help any. :D

> On Dec 11, 2017, at 12:22 PM, David Bürgin  wrote:
> 
> On 11/12/17 20:47, Jonathan Fischer wrote:
>> com.badlogicgames.gdx/gdx {:mvn/versin "1.9.6"}
> 
> Typo?
> 
> 
> -- 
> David
> 
> -- 
> 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/t_DA1T36VKQ/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.

-- 
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: Clojure CLI tool fails to resolve weird transitive dependencies.

[David Bürgin]

Hm, looks like this is an open issue:
https://dev.clojure.org/jira/browse/TDEPS-12


-- 
David

-- 
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: Clojure CLI tool fails to resolve weird transitive dependencies.

[Jonathan Fischer]

Yep, that looks like what I'm seeing. 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.

IF, WHEN or SOME

[Stephen Feyrer]

Hi there,

I have been trying to shake this thought for a while now.  Essentially, my
thought was if you can return a function why not decision component of an
IF, WHEN or SOME statement?  That would give you a re-usable named choice.

Then you could write:

(celebration: do-something do-something-else)


This would be equivalent to writing:

(def success [apples bananas pears])

(defn celebration: [x y] (if (empty? success) x y))

(celebration: (do-something do-something-else))


I'm reasonably certain of the foolishness of this thought but occasionally,
I have doubts.

Maybe I'm barking up the wrong tree or possibly I've seen something like
this before and forgotten about it.  Perhaps, this is just taking things
too far...  Either way, it's deferring the choice until it's needed.  In
the right hands it could make for more readable code.

For completeness sake, to define the first form above you'd use:

(defc celebration: (if (empty? success)))


A more usable example might look like:

(def nums [1 2 3 4 5 6 7 8])

(defc even-nums: (some (even? nums)))

I guess this makes the real question, is it a good thing to be able to
defer choice like this?


Btw, defc would be like def-choice but other options might be deft -
def-test or defp - def-predicate.


--
Kind regards

Stephen

-- 
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, WHEN or SOME

[Timothy Baldridge]

I talked a bit about this in my video on Boolean Blindness:
https://www.youtube.com/watch?v=K1LaaJMscCc

Might be worth a watch.

On Mon, Dec 11, 2017 at 4:56 PM, Stephen Feyrer 
wrote:

> Hi there,
>
> I have been trying to shake this thought for a while now.  Essentially, my
> thought was if you can return a function why not decision component of an
> IF, WHEN or SOME statement?  That would give you a re-usable named choice.
>
> Then you could write:
>
> (celebration: do-something do-something-else)
>
>
> This would be equivalent to writing:
>
> (def success [apples bananas pears])
>
> (defn celebration: [x y] (if (empty? success) x y))
>
> (celebration: (do-something do-something-else))
>
>
> I'm reasonably certain of the foolishness of this thought but
> occasionally, I have doubts.
>
> Maybe I'm barking up the wrong tree or possibly I've seen something like
> this before and forgotten about it.  Perhaps, this is just taking things
> too far...  Either way, it's deferring the choice until it's needed.  In
> the right hands it could make for more readable code.
>
> For completeness sake, to define the first form above you'd use:
>
> (defc celebration: (if (empty? success)))
>
>
> A more usable example might look like:
>
> (def nums [1 2 3 4 5 6 7 8])
>
> (defc even-nums: (some (even? nums)))
>
> I guess this makes the real question, is it a good thing to be able to
> defer choice like this?
>
>
> Btw, defc would be like def-choice but other options might be deft -
> def-test or defp - def-predicate.
>
>
> --
> Kind regards
>
> Stephen
>
> --
> 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: Immutable names of things?

[Eric Normand]

Hi Didier,

Are you familiar with Unison (http://unisonweb.org/)? It has this same 
feature. Functions are named by a hash of their code (the AST). Names refer 
to hashes. So if you want to recompile a function, you can optionally 
choose newer versions of all of the functions. But changing a function's 
code does not make the old version go away. Other functions compiled 
against the old versions will still use the old versions. It basically 
pushes the version control down to the function level instead of the whole 
project.

The effect was that you could have a dynamically-recompiled language 
experience without breaking anything that was already compiled. You could 
redefine everything about a function (it's type signature, it's code, etc) 
but existing stuff would keep working. Then when the function was to your 
liking, you could recompile everything to use the new version.

Eric



On Wednesday, December 6, 2017 at 11:37:10 PM UTC-6, Didier wrote:
>
> Warning: This is the spawn of an idea, not very well refined, and that is 
> little extravagant.
>
> I've been doing some hammock time, and I've been thinking that names in a 
> programming language are kind of a complecting of two things, the human 
> readable form, and the machine identifier. What if a function always had 
> the same name, which never changed, from the moment the function was 
> created. This would be fine, until a human finds it didn't like the name 
> anymore, and thus a refactor of the name would occur, requiring to change 
> all references to the function. This is also true say of a spec, if you 
> want to change the name of the spec, its a big refactor to update all usage 
> of it. So var names and spec names are troubling in that if humans want to 
> refer to it differently, they also break all machine reference to them.
>
> So I thought, how awesome would it be if each named things in a 
> programming language would be given a unique machine name, which can be 
> used everywhere, and the name you saw was just meta-data for the programmer 
> to have a more human readable/descriptive name.
>
> The problem is I'm not sure how to do this with a text based programming 
> language. I can imagine a language where constructs would be first class, 
> not based on text, and thus all construct could be assigned a unique id and 
> a name, and the IDEs could easily hide the unique ids and project a view of 
> the construct with the human name instead. Code would be stored in a 
> structured format, and obviously a standard editor would not work, and an 
> IDE of some form would be required.
>
> So right now, my idea is that maybe you can compromise. If you added 
> support for Vars and specs, so that they can have like a doc-name. It would 
> be like a doc-string a bit, but it expects a name instead. That name could 
> be the human readable name, you could change it freely. The normal var name 
> or spec name would continue to be used as normal to refer to this var/spec 
> from other code. At its most basic it means you can have the normal name be 
> anything, maybe a name you don't like that much, or you could go further 
> and make it a guid if you want. Then you could make the doc-name the name 
> you want to use when talking to other people, or when people read the code. 
> Now IDEs could support this doc-name, so they could show the doc-name in 
> place everywhere you have code referring to the normal name. They could 
> auto-complete from doc-name to normal name, etc.
>
> So an IDE could still kind of hide this for you, and make it appear like 
> everything is just doc-name pointing to each other, and refactoring would 
> not require changing all code that refers to it, but actually its just a 
> change of the doc-name on the var or spec being pointed to, but the IDE 
> could quickly replace the new doc-name in place of the normal name 
> everywhere else.
>
> Where it would be maybe a bit more confusing, is when using an editor that 
> would not support doc-names to that extent. In those cases, you can ignore 
> doc-name, consider it just like one more piece of documentation.
>
> Doc-name could be optional too, so if you plan on working by yourself, or 
> just in a simple editor, you can ignore this whole thing and work as normal.
>
> Now maybe this whole thing is solved by having a powerful renaming 
> refactoring tool that can hunt for all usage and update the name everywhere 
> in a sound way, but that's harder to do in Clojure, and still breaks when 
> its a library for example, as you can't just refactor all consumers without 
> having both access to their code base, and even if you do, its tedious to 
> pull down everything in your desktop and set it up for such a refactor.
>
> I'd be interested in thoughts about this, even if its just, that sounds 
> like a terrible idea :p.
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure

Re: [ANN] Pinpointer: yet another spec error reporter

[Ben Brinckerhoff]

Very cool! Excellent work.


On Monday, December 11, 2017 at 7:23:38 AM UTC-7, OHTA Shogo wrote:
>
> Hi, all
>
> I’m happy to announce the first release of Pinpointer, yet another 
> implementation of spec error reporter based on a precise error analysis.
>
> - https://github.com/athos/Pinpointer
>
> Pinpointer provides functionalities very similar to the existing spec 
> error reporters (eg. Expound[1], Inspectable[2] etc.), that is, reporting 
> spec errors in a more human-readable way.
>
> [1] https://github.com/bhb/expound
> [2] https://github.com/jpmonettas/inspectable
>
> Unlike those libraries, which analyze spec errors using several 
> heuristics, Pinpointer performs a systematic error analysis traversing a 
> pair of the spec and the input. This makes it possible to report the error 
> even in complicated cases where s/conformer would transform the input 
> value, like the following:
>
> => (require '[pinpointer.core :as p] '[clojure.spec.alpha :as s])
> => (p/pinpointer (s/and string? (s/conformer seq) (s/* #{\a})) "aabaa")
> Detected 1 spec error:
> --
> (1/1)
>
>
> Cause: (\a \a \b \a \a)
>   ^^   
>  Expected: #{\a}
>
>
>--- This comes originally from ---
>
>
>  Original: "aabaa"
>^^^
>  Spec
>   Applied: (s/and string? (s/conformer seq) (s/* #{\a}))
>
>
> --
> nil
> user=>
>
>
> (BTW the above example is just a demo for Pinpointer's capability, and it 
> doesn't mean to encourage you to write specs like that.)
>
> On the other hand, one of the downsides of the library is that Pinpointer 
> has to know in advance the behaviors of the spec macros involved in a spec 
> form for its error analysis. Note also that, Pinpointer occasionally uses  
> eval under the hood (at least for now), so it’s basically intended to be 
> used for development purpose only.
>
> I hope you’ll like it :)
>
> Thanks,
> Shogo
>

-- 
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: Immutable names of things?

[Didier]

I'll have a look at all these other projects, its very interesting. Unison 
seems to embody the spirit or Richs talk about never changing anything too. 
I guess I was trying to think how could you bring some of this to Clojure. 
And in a way, if the constructs like functions had an id and a name, you 
could start building out things like that more so. Which is where I thought 
about the potential of considering the existing name as an id, and having 
something else for naming the construct.

I guess, if I think about it some more, Clojure could save its code as the 
AST straight up using EDN. Someone could build an IDE on top of that, which 
never allows you to change the text, but only works directly at the EDN 
level with the clojure code as data. It would be a lot of work, but 
possible I think.

On Monday, 11 December 2017 16:12:37 UTC-8, Eric Normand wrote:
>
> Hi Didier,
>
> Are you familiar with Unison (http://unisonweb.org/)? It has this same 
> feature. Functions are named by a hash of their code (the AST). Names refer 
> to hashes. So if you want to recompile a function, you can optionally 
> choose newer versions of all of the functions. But changing a function's 
> code does not make the old version go away. Other functions compiled 
> against the old versions will still use the old versions. It basically 
> pushes the version control down to the function level instead of the whole 
> project.
>
> The effect was that you could have a dynamically-recompiled language 
> experience without breaking anything that was already compiled. You could 
> redefine everything about a function (it's type signature, it's code, etc) 
> but existing stuff would keep working. Then when the function was to your 
> liking, you could recompile everything to use the new version.
>
> Eric
>
>
>
> On Wednesday, December 6, 2017 at 11:37:10 PM UTC-6, Didier wrote:
>>
>> Warning: This is the spawn of an idea, not very well refined, and that is 
>> little extravagant.
>>
>> I've been doing some hammock time, and I've been thinking that names in a 
>> programming language are kind of a complecting of two things, the human 
>> readable form, and the machine identifier. What if a function always had 
>> the same name, which never changed, from the moment the function was 
>> created. This would be fine, until a human finds it didn't like the name 
>> anymore, and thus a refactor of the name would occur, requiring to change 
>> all references to the function. This is also true say of a spec, if you 
>> want to change the name of the spec, its a big refactor to update all usage 
>> of it. So var names and spec names are troubling in that if humans want to 
>> refer to it differently, they also break all machine reference to them.
>>
>> So I thought, how awesome would it be if each named things in a 
>> programming language would be given a unique machine name, which can be 
>> used everywhere, and the name you saw was just meta-data for the programmer 
>> to have a more human readable/descriptive name.
>>
>> The problem is I'm not sure how to do this with a text based programming 
>> language. I can imagine a language where constructs would be first class, 
>> not based on text, and thus all construct could be assigned a unique id and 
>> a name, and the IDEs could easily hide the unique ids and project a view of 
>> the construct with the human name instead. Code would be stored in a 
>> structured format, and obviously a standard editor would not work, and an 
>> IDE of some form would be required.
>>
>> So right now, my idea is that maybe you can compromise. If you added 
>> support for Vars and specs, so that they can have like a doc-name. It would 
>> be like a doc-string a bit, but it expects a name instead. That name could 
>> be the human readable name, you could change it freely. The normal var name 
>> or spec name would continue to be used as normal to refer to this var/spec 
>> from other code. At its most basic it means you can have the normal name be 
>> anything, maybe a name you don't like that much, or you could go further 
>> and make it a guid if you want. Then you could make the doc-name the name 
>> you want to use when talking to other people, or when people read the code. 
>> Now IDEs could support this doc-name, so they could show the doc-name in 
>> place everywhere you have code referring to the normal name. They could 
>> auto-complete from doc-name to normal name, etc.
>>
>> So an IDE could still kind of hide this for you, and make it appear like 
>> everything is just doc-name pointing to each other, and refactoring would 
>> not require changing all code that refers to it, but actually its just a 
>> change of the doc-name on the var or spec being pointed to, but the IDE 
>> could quickly replace the new doc-name in place of the normal name 
>> everywhere else.
>>
>> Where it would be maybe a bit more confusing, is when using an editor 
>> that would not support doc-names to that extent. In those

Re: Immutable names of things?

[John Newman]

This might be a step towards a more clojury way:
http://blog.datomic.com/2012/10/codeq.html

John

On Mon, Dec 11, 2017 at 7:53 PM, Didier  wrote:

> I'll have a look at all these other projects, its very interesting. Unison
> seems to embody the spirit or Richs talk about never changing anything too.
> I guess I was trying to think how could you bring some of this to Clojure.
> And in a way, if the constructs like functions had an id and a name, you
> could start building out things like that more so. Which is where I thought
> about the potential of considering the existing name as an id, and having
> something else for naming the construct.
>
> I guess, if I think about it some more, Clojure could save its code as the
> AST straight up using EDN. Someone could build an IDE on top of that, which
> never allows you to change the text, but only works directly at the EDN
> level with the clojure code as data. It would be a lot of work, but
> possible I think.
>
>
> On Monday, 11 December 2017 16:12:37 UTC-8, Eric Normand wrote:
>>
>> Hi Didier,
>>
>> Are you familiar with Unison (http://unisonweb.org/)? It has this same
>> feature. Functions are named by a hash of their code (the AST). Names refer
>> to hashes. So if you want to recompile a function, you can optionally
>> choose newer versions of all of the functions. But changing a function's
>> code does not make the old version go away. Other functions compiled
>> against the old versions will still use the old versions. It basically
>> pushes the version control down to the function level instead of the whole
>> project.
>>
>> The effect was that you could have a dynamically-recompiled language
>> experience without breaking anything that was already compiled. You could
>> redefine everything about a function (it's type signature, it's code, etc)
>> but existing stuff would keep working. Then when the function was to your
>> liking, you could recompile everything to use the new version.
>>
>> Eric
>>
>>
>>
>> On Wednesday, December 6, 2017 at 11:37:10 PM UTC-6, Didier wrote:
>>>
>>> Warning: This is the spawn of an idea, not very well refined, and that
>>> is little extravagant.
>>>
>>> I've been doing some hammock time, and I've been thinking that names in
>>> a programming language are kind of a complecting of two things, the human
>>> readable form, and the machine identifier. What if a function always had
>>> the same name, which never changed, from the moment the function was
>>> created. This would be fine, until a human finds it didn't like the name
>>> anymore, and thus a refactor of the name would occur, requiring to change
>>> all references to the function. This is also true say of a spec, if you
>>> want to change the name of the spec, its a big refactor to update all usage
>>> of it. So var names and spec names are troubling in that if humans want to
>>> refer to it differently, they also break all machine reference to them.
>>>
>>> So I thought, how awesome would it be if each named things in a
>>> programming language would be given a unique machine name, which can be
>>> used everywhere, and the name you saw was just meta-data for the programmer
>>> to have a more human readable/descriptive name.
>>>
>>> The problem is I'm not sure how to do this with a text based programming
>>> language. I can imagine a language where constructs would be first class,
>>> not based on text, and thus all construct could be assigned a unique id and
>>> a name, and the IDEs could easily hide the unique ids and project a view of
>>> the construct with the human name instead. Code would be stored in a
>>> structured format, and obviously a standard editor would not work, and an
>>> IDE of some form would be required.
>>>
>>> So right now, my idea is that maybe you can compromise. If you added
>>> support for Vars and specs, so that they can have like a doc-name. It would
>>> be like a doc-string a bit, but it expects a name instead. That name could
>>> be the human readable name, you could change it freely. The normal var name
>>> or spec name would continue to be used as normal to refer to this var/spec
>>> from other code. At its most basic it means you can have the normal name be
>>> anything, maybe a name you don't like that much, or you could go further
>>> and make it a guid if you want. Then you could make the doc-name the name
>>> you want to use when talking to other people, or when people read the code.
>>> Now IDEs could support this doc-name, so they could show the doc-name in
>>> place everywhere you have code referring to the normal name. They could
>>> auto-complete from doc-name to normal name, etc.
>>>
>>> So an IDE could still kind of hide this for you, and make it appear like
>>> everything is just doc-name pointing to each other, and refactoring would
>>> not require changing all code that refers to it, but actually its just a
>>> change of the doc-name on the var or spec being pointed to, but the IDE
>>> could quickly replace the new doc

Symbols and Vars for specs?

[Didier]

s/def docs says: "Given a namespace-qualified keyword or resolvable symbol 
..."

But I'm unable to s/def a spec using a resolvable symbol:

(def foo 123)
(s/def foo int?)
(s/get-spec foo) => nil
(s/get-spec 'foo) => nil
(s/get-spec #'foo) => #object[clojure.spec.alpha$spec_impl$reify__797 
0x7215d8f3 "clojure.spec.alpha$spec_impl$reify__797@7215d8f3"]

So it works with the var, but not the symbol. Also, doing (s/def 'foo int?) 
fails with an assertion error.

Is it true that specs can be registered with the key being a 
namespace-qualified keyword, a resolvable symbol or a Var? Or is the doc 
misleading?

-- 
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: Symbols and Vars for specs?

[Alex Miller]

On Monday, December 11, 2017 at 7:01:20 PM UTC-6, Didier wrote:
>
> s/def docs says: "Given a namespace-qualified keyword or resolvable symbol 
> ..."
>

Symbols are used to register function specs (with the same qualified symbol 
as the var it's stored with).


> But I'm unable to s/def a spec using a resolvable symbol:
>
> (def foo 123)
> (s/def foo int?)
>

This actually will work
 

>
> (s/get-spec foo) => nil
>

get-spec is actually a function and will receive it's arguments evaluated. 
So here you are actually doing the same as `(s/get-spec 123)`. Instead, 
quote and qualify the symbol:

(s/get-spec 'user/foo)

or use syntax quote to take advantage of the fact that syntax quote 
resolves symbols automatically:

(s/get-spec `foo)
 

>
> (s/get-spec 'foo) => nil
>

Needs to be qualified as above
 

> (s/get-spec #'foo) => #object[clojure.spec.alpha$spec_impl$reify__797 
> 0x7215d8f3 "clojure.spec.alpha$spec_impl$reify__797@7215d8f3"]
>
>
There is actually some helper code right now in s/get-spec that also knows 
how to extract the symbol from the var name (noted in the docstring) - this 
is useful in some of the stest functions.
 

> So it works with the var, but not the symbol. Also, doing (s/def 'foo 
> int?) fails with an assertion error.
>
> Is it true that specs can be registered with the key being a 
> namespace-qualified keyword, a resolvable symbol or a Var? Or is the doc 
> misleading?
>

Again, I think the key here though is that while this will work, it's not 
the expected way to use it. You can't declare a spec for a non-function var 
created via def. Or rather you can, but spec will ignore it in instrument 
and fail on check.

Where symbol-keyed specs is intended to be used is with functions:

(defn foo [x] (+ x 123))
(s/fdef foo :args int? :ret int?)
(s/form (s/get-spec `foo))  
;;=> (clojure.spec.alpha/fspec :args clojure.core/int? :ret 
clojure.core/int? :fn nil)

;; also accepts key lookups for the function spec parts:
(s/form (:args (s/get-spec `foo)))
;;=> clojure.core/int?


-- 
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: Immutable names of things?

[John Newman]

What if the code segments were hashed by zipper coordinates instead of
line-column location? I like this idea of structurally navigating the code
as an AST of EDN :)

John

On Mon, Dec 11, 2017 at 7:55 PM, John Newman  wrote:

> This might be a step towards a more clojury way: http://blog.datomic.com/
> 2012/10/codeq.html
>
> John
>
> On Mon, Dec 11, 2017 at 7:53 PM, Didier  wrote:
>
>> I'll have a look at all these other projects, its very interesting.
>> Unison seems to embody the spirit or Richs talk about never changing
>> anything too. I guess I was trying to think how could you bring some of
>> this to Clojure. And in a way, if the constructs like functions had an id
>> and a name, you could start building out things like that more so. Which is
>> where I thought about the potential of considering the existing name as an
>> id, and having something else for naming the construct.
>>
>> I guess, if I think about it some more, Clojure could save its code as
>> the AST straight up using EDN. Someone could build an IDE on top of that,
>> which never allows you to change the text, but only works directly at the
>> EDN level with the clojure code as data. It would be a lot of work, but
>> possible I think.
>>
>>
>> On Monday, 11 December 2017 16:12:37 UTC-8, Eric Normand wrote:
>>>
>>> Hi Didier,
>>>
>>> Are you familiar with Unison (http://unisonweb.org/)? It has this same
>>> feature. Functions are named by a hash of their code (the AST). Names refer
>>> to hashes. So if you want to recompile a function, you can optionally
>>> choose newer versions of all of the functions. But changing a function's
>>> code does not make the old version go away. Other functions compiled
>>> against the old versions will still use the old versions. It basically
>>> pushes the version control down to the function level instead of the whole
>>> project.
>>>
>>> The effect was that you could have a dynamically-recompiled language
>>> experience without breaking anything that was already compiled. You could
>>> redefine everything about a function (it's type signature, it's code, etc)
>>> but existing stuff would keep working. Then when the function was to your
>>> liking, you could recompile everything to use the new version.
>>>
>>> Eric
>>>
>>>
>>>
>>> On Wednesday, December 6, 2017 at 11:37:10 PM UTC-6, Didier wrote:

 Warning: This is the spawn of an idea, not very well refined, and that
 is little extravagant.

 I've been doing some hammock time, and I've been thinking that names in
 a programming language are kind of a complecting of two things, the human
 readable form, and the machine identifier. What if a function always had
 the same name, which never changed, from the moment the function was
 created. This would be fine, until a human finds it didn't like the name
 anymore, and thus a refactor of the name would occur, requiring to change
 all references to the function. This is also true say of a spec, if you
 want to change the name of the spec, its a big refactor to update all usage
 of it. So var names and spec names are troubling in that if humans want to
 refer to it differently, they also break all machine reference to them.

 So I thought, how awesome would it be if each named things in a
 programming language would be given a unique machine name, which can be
 used everywhere, and the name you saw was just meta-data for the programmer
 to have a more human readable/descriptive name.

 The problem is I'm not sure how to do this with a text based
 programming language. I can imagine a language where constructs would be
 first class, not based on text, and thus all construct could be assigned a
 unique id and a name, and the IDEs could easily hide the unique ids and
 project a view of the construct with the human name instead. Code would be
 stored in a structured format, and obviously a standard editor would not
 work, and an IDE of some form would be required.

 So right now, my idea is that maybe you can compromise. If you added
 support for Vars and specs, so that they can have like a doc-name. It would
 be like a doc-string a bit, but it expects a name instead. That name could
 be the human readable name, you could change it freely. The normal var name
 or spec name would continue to be used as normal to refer to this var/spec
 from other code. At its most basic it means you can have the normal name be
 anything, maybe a name you don't like that much, or you could go further
 and make it a guid if you want. Then you could make the doc-name the name
 you want to use when talking to other people, or when people read the code.
 Now IDEs could support this doc-name, so they could show the doc-name in
 place everywhere you have code referring to the normal name. They could
 auto-complete from doc-name to normal name, etc.

 So an IDE could still

RE: Immutable names of things?

[Sean Corfield]

FWIW, this was a bit like the approach taken in Expectations – functions were 
given names based on a hash of the code in the test, meaning that old functions 
(tests) stayed around if you change the tests (which created a newly named 
function). This led to problems with REPL usage since you could not tell which 
was a “live” function as opposed to an old one. Consequently, if you had a bad 
test and fixed it, the old test was still around and would still fail when you 
tried to “run all tests”.

Just offering this as a data point for problems that can be caused for tooling 
with this sort of approach…

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Eric 
Normand 
Sent: Monday, December 11, 2017 4:12:37 PM
To: Clojure
Subject: Re: Immutable names of things?

Hi Didier,

Are you familiar with Unison (http://unisonweb.org/)? It has this same feature. 
Functions are named by a hash of their code (the AST). Names refer to hashes. 
So if you want to recompile a function, you can optionally choose newer 
versions of all of the functions. But changing a function's code does not make 
the old version go away. Other functions compiled against the old versions will 
still use the old versions. It basically pushes the version control down to the 
function level instead of the whole project.

The effect was that you could have a dynamically-recompiled language experience 
without breaking anything that was already compiled. You could redefine 
everything about a function (it's type signature, it's code, etc) but existing 
stuff would keep working. Then when the function was to your liking, you could 
recompile everything to use the new version.

Eric



On Wednesday, December 6, 2017 at 11:37:10 PM UTC-6, Didier wrote:
Warning: This is the spawn of an idea, not very well refined, and that is 
little extravagant.

I've been doing some hammock time, and I've been thinking that names in a 
programming language are kind of a complecting of two things, the human 
readable form, and the machine identifier. What if a function always had the 
same name, which never changed, from the moment the function was created. This 
would be fine, until a human finds it didn't like the name anymore, and thus a 
refactor of the name would occur, requiring to change all references to the 
function. This is also true say of a spec, if you want to change the name of 
the spec, its a big refactor to update all usage of it. So var names and spec 
names are troubling in that if humans want to refer to it differently, they 
also break all machine reference to them.

So I thought, how awesome would it be if each named things in a programming 
language would be given a unique machine name, which can be used everywhere, 
and the name you saw was just meta-data for the programmer to have a more human 
readable/descriptive name.

The problem is I'm not sure how to do this with a text based programming 
language. I can imagine a language where constructs would be first class, not 
based on text, and thus all construct could be assigned a unique id and a name, 
and the IDEs could easily hide the unique ids and project a view of the 
construct with the human name instead. Code would be stored in a structured 
format, and obviously a standard editor would not work, and an IDE of some form 
would be required.

So right now, my idea is that maybe you can compromise. If you added support 
for Vars and specs, so that they can have like a doc-name. It would be like a 
doc-string a bit, but it expects a name instead. That name could be the human 
readable name, you could change it freely. The normal var name or spec name 
would continue to be used as normal to refer to this var/spec from other code. 
At its most basic it means you can have the normal name be anything, maybe a 
name you don't like that much, or you could go further and make it a guid if 
you want. Then you could make the doc-name the name you want to use when 
talking to other people, or when people read the code. Now IDEs could support 
this doc-name, so they could show the doc-name in place everywhere you have 
code referring to the normal name. They could auto-complete from doc-name to 
normal name, etc.

So an IDE could still kind of hide this for you, and make it appear like 
everything is just doc-name pointing to each other, and refactoring would not 
require changing all code that refers to it, but actually its just a change of 
the doc-name on the var or spec being pointed to, but the IDE could quickly 
replace the new doc-name in place of the normal name everywhere else.

Where it would be maybe a bit more confusing, is when using an editor that 
would not support doc-names to that extent. In those cases, you can ignore 
doc-name, consider it just like one more piece of documentati

Re: [ANN] clj-async-profiler — embeddable profiler with flame graphs, based on Java's async-profiler

[Luke Burton]

> On Dec 11, 2017, at 6:42 AM, Alexander Yakushev  wrote:
> 
> I've just released a wrapper around 
> https://github.com/jvm-profiling-tools/async-profiler that allows controlling 
> the profiler directly from the REPL of the program you want to profile. The 
> JAR file ships the profiling agent and the flamegraph generation script from 
> https://github.com/brendangregg/FlameGraph, so that you can profile your code 
> and instantly generate flame graphs from it.
> 
> Introductory blog post: 
> http://clojure-goes-fast.com/blog/profiling-tool-async-profiler/
> Repository: https://github.com/clojure-goes-fast/clj-async-profiler
> 
> Hope you'll like it!


Like it?? I had to *physically prevent* myself from dropping what I was doing 
to hack on this, already having a full plate at work … I've wanted something 
like this for such a long time! 

My first reaction is to create a pedestal interceptor that allows you to 
remotely trigger a flamegraph. I first saw this in rack-mini-profiler 
 though I'm sure others 
have done it too.

My second reaction is to wonder how difficult it would be to aggregate samples 
across a cluster of machines running the same code, similar to 
riemann-jvm-profiler .

My third reaction is to wonder how close you can get to having an "always on" 
flamegraph. I want a scrubber so I can reintroduce the time dimension. Imagine 
having a report of some perf issues and being able to say "let's go see what 
the flamegraph looked like at that time" - that'd be some Star Trek level 
observability right there.

Great work!

Luke.

-- 
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: [ANN] clj-async-profiler — embeddable profiler with flame graphs, based on Java's async-profiler

[Alexander Yakushev]

Alex and Luke, thank you for your kind words!

Regarding your questions, Luke. #3. Authors of async-profiler promise that 
it's quite low-overhead. Of course, some experimentation and benchmarking 
is needed, but I think it is possible to have the profiler always on. Some 
work would be required too: async-profiler doesn't flush intermediate data, 
so an "always on" profiler would probably have to restart repeatedly in 
predefined timespans, say every 1 minute.

Re: #2. That would be actually quite simple. The format of folded 
stacktraces before they hit the flamegraph is is the following:

 


For example:


clojure.core$main.invoke;my_app$_main;my_app$init-config; 1
clojure.core$main.invoke;my_app$_main;my_app$do_hard_work;my_app$burn_cpu; 
254


You can mash such files from multiple machines together, adding the numbers 
where stacks match.

Best regards,
Alex

On Monday, December 11, 2017 at 4:42:23 PM UTC+2, Alexander Yakushev wrote:
>
> I've just released a wrapper around 
> https://github.com/jvm-profiling-tools/async-profiler that allows 
> controlling the profiler directly from the REPL of the program you want to 
> profile. The JAR file ships the profiling agent and the flamegraph 
> generation script from https://github.com/brendangregg/FlameGraph, so 
> that you can profile your code and instantly generate flame graphs from it.
>
> Introductory blog post: 
> http://clojure-goes-fast.com/blog/profiling-tool-async-profiler/
> Repository: https://github.com/clojure-goes-fast/clj-async-profiler
>
> Hope you'll like it!
>

-- 
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, WHEN or SOME

[Stephen Feyrer]

Hi Tim,

Thank you.


--
Kind regards

Stephen.

On 11 December 2017 at 23:58, Timothy Baldridge 
wrote:

> I talked a bit about this in my video on Boolean Blindness: https://www.
> youtube.com/watch?v=K1LaaJMscCc
>
> Might be worth a watch.
>
> On Mon, Dec 11, 2017 at 4:56 PM, Stephen Feyrer 
> wrote:
>
>> Hi there,
>>
>> I have been trying to shake this thought for a while now.  Essentially,
>> my thought was if you can return a function why not decision component of
>> an IF, WHEN or SOME statement?  That would give you a re-usable named
>> choice.
>>
>> Then you could write:
>>
>> (celebration: do-something do-something-else)
>>
>>
>> This would be equivalent to writing:
>>
>> (def success [apples bananas pears])
>>
>> (defn celebration: [x y] (if (empty? success) x y))
>>
>> (celebration: (do-something do-something-else))
>>
>>
>> I'm reasonably certain of the foolishness of this thought but
>> occasionally, I have doubts.
>>
>> Maybe I'm barking up the wrong tree or possibly I've seen something like
>> this before and forgotten about it.  Perhaps, this is just taking things
>> too far...  Either way, it's deferring the choice until it's needed.  In
>> the right hands it could make for more readable code.
>>
>> For completeness sake, to define the first form above you'd use:
>>
>> (defc celebration: (if (empty? success)))
>>
>>
>> A more usable example might look like:
>>
>> (def nums [1 2 3 4 5 6 7 8])
>>
>> (defc even-nums: (some (even? nums)))
>>
>> I guess this makes the real question, is it a good thing to be able to
>> defer choice like this?
>>
>>
>> Btw, defc would be like def-choice but other options might be deft -
>> def-test or defp - def-predicate.
>>
>>
>> --
>> Kind regards
>>
>> Stephen
>>
>> --
>> 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.
>

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