Fork me on GitHub

1. start with a stack based language, like Forth 2. write it right-to-left instead of left-to-right 3. does this basically result in the applicative style languages ?


I haven't used Forth in a long time, but a large difference aside from ordering is that in Forth the stack is explicit and is used in place of local binding--there's only one dictionary, and typically functions implement local storage and intermediate state by manipulating the stack.


Back when I used Forth, its big advantage was that you could port it to a new piece of hardware in an afternoon.


so I've been doing a bit of jvm bytecode programming, and doing some forth too, and I noticed the following


suppose I want to write (foo a b c), I end up writing [instrs to calc + put a on the stack] [instrs to calc + put b on the stack] [instrs to calc + put c on the stack] [invoke foo]


this looks an awful lot like (roo (instrs to calc a) (instrs to calc b) (instrs to calc c))


It's all pretty similar at that level--function calls end up being push some args on the stack (or possibly passed in registers) with the call at the end in most computer architectures.


I guess it doesn't really matter until a result is needed in multiple function calls


Many conferences are announcing dates for fall 2018 already… I wish EuroClojure could announce the date so I could plan my summer. Definitely want to go there, but I might miss it due to a planned vacation, which happened before..


Good day, everyone.


I am pushing for Clojure adoption as one of the languages (well, I sell it as a functional processing framework , hehe)


What I am looking for is some kind of marketing material that would help me to sell it internally - adoption graphs, success stories, anything whatsoever that would persuade the stakeholders that are not in the know that it is worth considering.


Could anyone set me on the right track where to look?


@evmin Puppet Labs moved to Clojure and you can find their "success story" in many places


Thank you. Is there something from 2017 and preferrably from outside the usual Clojure circles?


Something that could pass as an "independent" review


probably it's easier to sell the ideas of immutability and functional programming than a specific language


I would sell clojure for those two ideas + interactivity / experimentation (REPL) which is unique to Clojure/Lisp compared to others (Haskell, Kotlin, etc)


anyone have insights on why ios safari (ipad) supports webgl1 but not webgl2 ?

Drew Verlee15:02:50

@evmin The first step to selling something is usually understanding your target audience. What does that person want, what are their motivations and fears? I would earn their trust before suggesting they change. Then help them bridge the gap between where they are and where you want them to be. People in tech are just as human as everyone else, they are swayed far more by their subconscious then they would care to admit. This doesn’t mean you should mis lead them, but their not going to hear a technical argument until you overcome the emotional ones.


That is all valid and true. The audience is mainly managerial/ivory tower architects. High propensity to place trust in external sources (i.e. Gartner reports, external consulting, etc). The technical users - the dev team - is currently sold. Just a bit of traction at the higher levels to make CLojure a household name.


@tbaldridge: I'm reading the paper on effects. Is the main problem for Clojure/Effects that Effect Handlers want to take a k representing rest of the computation So this is something that really doesn't play well with the JVM. And since Clojure uses JVM stacks instead of continuation passing style, it doesn't really play with will Clojure either.


Pretty much, you can hack around it, but it will never be fast on the JVM, at least without something like Truffle that allows you to define new semantics.


But yeah, to get it to work you really need multi-shot delimited continuations (full continuations won't work), and TCO.


Multi-shot, because k can be called many times. That's something that's not supported by many delimited continuation systems.


What if I am willing to give up backtracking handler + any hnandler that calls the continuation more than once? If I restricted the set of handlers I'm allowed to use, can this be made to work well with Clojure?


wouldn't that require introducing pervasive trampolining, at least?


which is possible, but also not cheap performance wise


In this case (IIRC) he used trampolines and return type dispatching. Where effects are raised by returning an effect object, and each function adds something to the trampoline as it detects the effect.


So it's basically an interpreter


right- that's going to get pricey in a tight loop


I'll qualify that - maybe there's a way to do that fast and I'd love to see it 😄

qqq21:02:33 looks abandoned as of 4 years ago as it turns out, all of my performance critical coded is written in insn/jvm-byte-code + cuda-. Given I am willing pay huge runtime penalties, what is the best way to get effects in Clojure?


that's pretty much it, yo uhave to implement a trampoline system, and pause/resume semantics for each frame (each AST, expression, etc) being executed.


A Microsoft research team did it in C, but they used setjmp/longjump and memcpy to copy stacks around:


The other option is to do what a old version of Eff did and do it all with monads. But the JVM isn't too happy with that either, and you still don't have TCO with monads


On a related question -- how do JVM schemes that support continuations implement them? Is it via trampolines, or are stack frames abstractly stored on the heap instead?


depends on the JVM scheme. Which one are you referring to?


many of them are interpreters, most likely


I don't have any in mind, I was wondering "if, instead of 'add continuations to clojure', the goal was 'a jvm scheme with continuations', what the optimal appraoch would be"


there really isn't an approach, the JVM restricts all stack manipulation for security reasons. So any approach is going to be semi-interpreted via trampolines.


a good example is bigloo scheme:


> implements call-with-current-continuation very poorly: not only is it implemented by copying the stack on every continuation capture, but the compiler also requires that compilation of any module that uses the operator be preceded by a special option that cripples many optimizations that the compiler would otherwise have made.


I'm starting to like my forth interpreter more and more, where the instruction stack is the continuation 🙂


Sure, like I said, TCO/continuations on the JVM require an interpreter


@tbaldridge if that's responding to me I intended that to illustrate your point rather than disagree


no, it was directed to @qqq, there's simplicity in a forth interpreter, but that same simplicity exists in scheme interpreters


So if I: 1. put trampolines everywhere 2. wrote all my code in I can then 3. get continuations in Clojure w/o hacking the compiler and 4. thus get Effects in clojure w/o hacking the compiler is that correct?


I think so - a weird side effect here would be generating a lot of classes - if you use clojure's approach of each lambda being a class at least, but I guess you are working low enough a level that you fully understand the cost and pressure of that


well you still need delimited continuations, to understand that I really recommend prototyping something really simple in Clojure


if you implement lambda, +, locals, if, and < you should be able to implement a small counting loop. Then implement a simple effect (like choice). Should be about 200 lines of Clojure code to do that, and you'll learn a lot in the process