Fork me on GitHub

And everything works fine now, but i would really like to understand the whole repl thing, any pointers ?


I thought that the JVM didn’t even support tail call optimization.


Have you guys been upgrading behind my back? [wags finger]


@akiva The JVM doesn’t. That’s why we have recur.


@vjunloc Honestly I have less experience with figwheel than the normal Clojure repl, but the biggest thing I’d keep in mind is that the REPL isn’t some separate thing, like it often is in other programming languages. The process that is compiling and serving up code is the same as the process that runs figwheel. Practically, this means that you can try out some code to see if it does what you want in the REPL before putting it in your source file. For many aspects of ClojureScript, it can also be the cool thing that triggers your views, and helps you debug them. For example, let’s say you’re using re-frame, and you want to set the title of the application to be something. In re-frame, you would write a handler for :set-title or something. You’d probably eventually want to use this from the front end code, but you can test and confirm that it’s working as expected in the REPL simply by running (re-frame/dispatch [:set-title “REPLs are cool”]). If you were displaying the title somewhere in your HTML, you’d even see the title change.


Well, here’s hoping the JVM catches up to modern technology.


TCO is really a language level optimization tho’, something a compiler can do. Clojure just chooses to make it explicit in the "syntax" you use so that you can be crystal clear about whether you have a "real" (stack-based) recursive call or not. I rather like the Clojure approach.


By contrast, in the Washington U. "Programming Languages" course, when you learn SML (to study statically typed FP), there’s a section that looks at refactoring recursive SML functions into tail-recursive ones so that the compiler can optimize them for you and you have to carefully study the code to determine whether you really have a tail-recursive version of the function — and it’s something that confuses a lot of the students in the course.


(and recursion is just not something folks often run into outside of FP, it seems, although I was doing it in assembler back in the early 80’s…)


Oh, I get your point, Sean. I was honestly just being a bit silly. I have no CS background; I’m an auto-didact so there are plenty of bits that I never got to engage.


I remember liking that F# also is very implicit about recursion.


"Silly ol’ Akiva" 😆 OK, I missed the humor 🙂


Hahaha. Basically yes.


It continually surprises me to run into programmers who aren’t familiar with recursion tho’… and I sort of know that it shouldn’t… I guess I was introduced to it so long ago that I can’t imagine programming without it 😐


It was new to me. I had been a professional OOP’er for years and never encountered it in a pure way.


But then it’s the same when folks ask me for a "good book about X" and I’m at a loss because when I had to learn X there weren’t any books about it 😆


(one of my early jobs, we debugged code by peeking at hex code in memory… and sometimes poking new values in to modify instructions to try to fix stuff)


Hah, yes! I used to hack sectors on my Commodore 64.


This was on an IBM 8100 minicomputer at an insurance computer.




And also my fix exposure to polyglot applications...


…written in a mix of COBOL and assembler!


Hardcore, that. I did some C64 assembly but then got seduced by UNIX and wanted to be a sys admin for YEARS.


Anyway, I’m grateful for the Clojure community. I’m pals with a lot of people from the .NET world which is where I spent basically 12 years or so but there’s just something that just slays me about Clojure and Lisps in general.


I appreciate the work you do.


Now someone hire me, dangit! I’m charming and overall an excellent creature!


I’m doing what I can to grow my team… here’s hoping other Clojure shops succeed and expand too!


Yep yep! I’m a total advocate.


@vjunloc different repl implementations implement their "UI" (the user facing bit) in different ways. I guess boot-cljs is doing things that Figwheel isn't. In general the Figwheel REPL is minimalist in this regard, e.g. it doesn't have readline-style history and editing, something that for instance lein repl does have. This keeps the code simple, and you can get the same result by using rlwrap


Seems rlwrap actually also does this "parens matching". I never realized, I would have told you immediately. So install rlwrap, and then run rlwrap lein figwheel, and all should be good. I guess this is also a Readline feature


Hmm. I found what was causing the issue in my REPL... the following code causes it to... "timeout".

(defn log [msg]
  (async/>!! core-in msg))
(log "test")


If I comment it out, it starts fine. If I change >!! to >! (trying to make it non-blocking) it errors on load with

[{:type clojure.lang.Compiler$CompilerException
   :message java.lang.AssertionError: Assert failed: >! used not in (go ...) block


@eslachance: Is there a go block that it should be in that it isn't seeing?


Not that I know of. I mean, that's code straight from Timothy Baldridge's core.async video which, admitedly, is about 2 years old.


It works when I run it in the REPL after it's started. Just doesn't let the REPL start when it's in my core.clj file.