An Iterable?

eduction might be what you are looking for.

Or Flow?

I wonder how Eduction will fit into this given that it "reruns" every time, and I'm not sure how you'll "switch" or interleave between two eductions

Let me look that up, thanks!

There’s also sequence if you want to cache stuff (unlike eduction)

Clojure 1.10.3
user=> (ns a)
nil
a=> (def x 1)
#'a/x
a=> (ns b)
nil
b=> (def x 2)
#'b/x
b=> (in-ns 'user)
#object[clojure.lang.Namespace 0x6f6962ba "user"]
user=> (require 'a 'b)
nil
user=> @(ns-resolve 'a 'x)
1
user=> @(ns-resolve 'b 'x)
2

Wow. Thank you @U2FRKM4TW 🙂

If you're on 1.10 or later, you can use requiring-resolve to avoid the need to require the two nses:

Clojure 1.10.3
user=> (ns a)
nil
a=> (def x 1)
#'a/x
a=> (ns b)
nil
b=> (def x 2)
#'b/x
b=> (in-ns 'user)
#object[clojure.lang.Namespace 0x3ff57625 "user"]
user=> @(requiring-resolve 'a/x)
1
user=> @(requiring-resolve 'b/x)
2
user=> 

(`requiring-resolve` is also thread-safe at runtime which plain require is not, I believe)

Thanks @U04V70XH6

If you're worried about the arity mismatch, you could use a map instead of a variadic signature

yes that’s my gut reaction but i’m trying to figure out if its just stylistic or an actual concern

I think it comes down to personal choice but fwiw I'd use maps

agree. but if its personal choice i won’t mention it in the PR review. Thanks

looks ok to me

At that point I'd rather the arguments were in a map

How does this edit feel?

(defmulti foo [event & _args] event)

(defmethod foo :create-user [event & args]
  (assert (= (count args) 1))
  (let [[user-id] args]
    ...)

(defmethod foo :invite [event & args]
  (assert (= (count args) 2))
  (let [[user-id date] args]
    ...)

i don’t like that solution but i think that might highlight why it feels so weird to me. so its a good exploration

like that makes the code worse, but it makes it more honest. and that honesty to what is going on is what i don’t like about the solution

another option might be to wrap the variadic part up into a single parameter

(defmuli foo [event args] event)
(defmethod foo :create-user [event [user-id]])
(defmethod foo :invite [event [user-id date]])

(defmuli foo [event] first)
(defmethod foo :create-user [[event-id user-id]])
(defmethod foo :invite [[event-id user-id date]])

it feels to me like "an event" is a single thing and passing it around in pieces – its ID here, its parameters there – doesn't quite line up semantically

I think i would just go to maps. It just feels weird for it to be structurally different (ie, number of args). Maps with optional keys is a well-explored and comfortable space

Re-frame is moving in the same direction, I believe.

yeah, I don't know that I would necessarily advocate a vector as the structure of choice (it was just easy to mock up), just advocating the idea of putting it all in some singular structure

This might be silly, but why not just

(defn- foo-create-user [{:keys [user-id]}]
  …)

(defn- foo-invite [{:keys [user-id date]}]
  …)

(defn foo [event data]
  (condp = event
    :create-user (foo-create-user data)
    :invite      (foo-invite data)))

i kinda agree with you. it’s internal and not really open dispatch

Yesterday we found another reason for wrapping many sequential parameters into one structure (vector, map etc) - limitation of datomic db-functions with 10 arguments max 🙂 So, multi-sequential-arguments functions seems to look like stone age of programming and C language. Also they creates another problem - the order of arguments, followed by partial-curryng, existance of flip in Haskell and so on and so forth

> Re-frame is moving in the same direction, I believe. @U2FRKM4TW what makes you say that? I would very much like for re-frame to move in that direction with subscriptions and events

The lengthy discussion at https://github.com/day8/re-frame/issues/644

And if you prefer to use maps over vectors - you can do that already! :) Just make sure that your own code always uses only 2-element vectors where the first item is the event/sub ID and the second item is the arguments. You can even write your own dispatch and subscribe that do that for you.

That is great news, I'll spend some time reviewing that issue. I have been working on a library for my job written on top of re-frame that adds some functionality to subscriptions and events (I am trying to see if we can open source it, but have to make sure the company will allow it). It has been difficult to work with the positional nature of passing arguments in a vector, since part of the library involves automatically injecting arguments into the vectors. Events are easy enough to deal with using interceptors. Subscriptions are another story. I have it all working by appending the arguments to the end of query vectors but I would feel a lot better about it if I had a map to work with.

Always nice to see more libraries take full advantage of the "throw everything in one map with namespaced keys" pattern

Oh I'd love to see a library that can count when and what to sell/buy

Free money :D

I mean the main algorithm should be made by me, but I am sure there are some libraries which support such operations on stock market. And for sure this libraries implement common algorithms, statistics etc.

There should be some libraries which I can use for this purpose, but I don’t know yet I want to use them 😉

so something like backtesting and algorithms for technical indicators (e.g. macd, vwap)?

that would be interesting! please ping me if you find it!

sure, I will

I'm not familiar enough with space to make a recommendation, but I do remember seeing https://www.reddit.com/r/Clojure/comments/cpf0xh/code_review_wanted_for_my_stock_broker_api/ by @U064UGEUQ

thank you

Yeah my project was for interfacing with Interactive Brokers (a particular stock broker) @UCSJVFV35 has some work on doing more trading analysis in clojure here: https://github.com/clojure-quant/trateg

thanks, I will check this one too

I tried getting that one running @U064UGEUQ but wasn't successful. I am also interested @U0WL6FA77. Was just talking to another Clojurian about this stuff and how it seems like the backtesting infrastructure would be good to have shared.

Though I am particularly interested in crypto markets. I head that it might be difficult to have backtesting shared between crypto and traditional markets and most people focus on traditional

> crypto markets yes, this is what I am interested in too. Although I found interesting environment for some tests: eve online - this is a MMO game. But the math should be very similar. Of course effective algorithm is very individual thing. So I am thinking about make first simple ver. as a proof of concept for this game and next do it for cryptocurrency.

I know it sounds a little crazy, but it can make sense. We will see.

https://github.com/clojure-quant/trateg

What is interested about this library is that it uses tech ml dataset for very efficient handling of tables, and Goldy for visualisation in the browser. The library is alpha, but it is already quite powerful.

👍

Do you know good community (forum, slack, discord etc.) for software developing for cryptocurrency trading?

You'll have to implement equals yourself An object with meta is no the same object instance. The default equals implementation is identity

yes, that makes sense. any recommendations on the best way to do it, to say “identity of the thing wrapped in metadata”?

I guess I can just generate a UUID and use that, for this purpose

or switch to a defrecord

okay, nice, that is great.

roll back - what does the original question mean? metadata is never used for comparing equality

do you really mean "reify" objects have identity equality semantics and adding/changing metadata changes identity?

@U064X3EF3 yeah, take a look at

(defprotocol ICake (cf [x]))

(let [a (reify ICake (cf [x] x))
      b [1 2]]
  ;; the resulting map has TWO entries:
  (= 2 (count (assoc {a 1} (with-meta a {:k "v"}) 2)))

  ;; a vector manages to not use its metadata in equality / hashcode:
  (= 1 (count (assoc {b 1} (with-meta b {:k "v"}) 2))))

just want to clarify, that's not a special property of vectors, it's the default behavior - metadata does not affect equality or hashcode as a general principle

reified objects extending from Object get Object behavior, which is based on identity

but it is affecting equality for the reify in this example, right?

you could provide your own equals when you reify ICake that does something different

you are saying that is a bug, and it should work like vector

ah, identity vs equality, got it

I think the defrecord solution is the right one, I have gotten away with this funky reify thing long enough

equality defaults to value-based in Clojure, but identity-based in Java. when you use reify you are tapping into interop and choosing that world

reified objects get the value metadata api not the identity metadata api, but have identity based equality by default

functions have this same mismatch

user=> (let [f (fn [])] (= f (with-meta f {})))
false
user=>

using a record seems like a reasonable alternative, but it's but one option. I don't know all the dimensions to compare them on.

it could be cool to have an anonymous record macro a la reify

for what? reify can close over locals

what problem are you trying to solve that's not solved by records or reify

or just maps :)

was thinking "`deftype` is to reify what defrecord is to ???"

maps?

I don't understand the relationship from deftype to reify that you are trying analogize

a map-like that can also have custom protocol implementations that doesn't extend the protocols to the global map type

and those protocol impls can close over locals

it wouldn't be necessary to do this in clojure.core, could have a library build it on top of reify of course

this is not a feature request 😛 unless someone actually has a good reason for it. just was a thought.

maps could work if the protocol you're using supports implementation via metadata

what do you imagine "map-like" but "doesn't extend to the global map type" to mean?

you could mean "supports lookups" (ILookup) but is not a persistentmap (IPersistentMap / map?)

I think in most cases using such a thing you would quickly want the other parts of maps / records in most cases

we have a couple places where we've done things kind of like this in Java - TaggedLiteral, ReaderConditional or clojure (fspec comes to mind)

implementing only ILookup is trivial. the gap between there and what defrecord provides is large.

I am trying to tease this out a bit because there are times when I want the gross implementation guts of records but without records (and I'm sure this is in the ballpark of when people reach for Potemkin's various def-map-type, def-derived-map, def-abstract-type, deftype+ etc).

I think what I'm thinking of is solved by allowing your protocol to be extended via metadata

(defn postgres-component
  [config]
  ;; creates a new map-like object (i.e. allows get, assoc, dissoc, clojure equality semantics, seqable, etc.)
  (record config
    ;; extend some additional protocols
    IStart
    (-start [this]
      (assoc this :conn (create-connection config)))
    IStop
    (-stop [this]
      (close-connection! (:conn this)))
      (dissoc this :conn))))

I think having a parameterizable map constructor would also be cool, which I think is what things like def-map-type give. the ability to create something which, as you say, abstracts the gross guts of records but allows one to customize what happens on get assoc etc.

people have written such things, macros for custom map types, clj-http has a custom map type for headers making the keys case insensitive

yeah, I have several custom implementations of a map laying around my projects