You can’t apply reg-parse because it is a macro. Is there any reason reg-parse must be a macro?

(defmacro reg-parse [l bind reg statement & more-clauses]
  `(if-let [~bind (re-find ~reg ~l)]
     ~statement
     ~(when (seq more-clauses)
        (apply list `reg-parse l more-clauses))))

this works

(defmacro reg-parse [l bind reg statement & more-clauses]
  `(if-let [~bind (re-find ~reg ~l)]
     ~statement
     ~(when (seq more-clauses)
        `(reg-parse ~l ~@more-clauses)))

it's immutable data - what's the harm in popping more?

but note that you're losing all the data being popped, so usually this is probably not a very useful thing to be doing

the goal is to get [1 2 3] then [1 2] then [1]

i check source of map/filter they use chunkXXX so iterate although returning lazy-seq but doesn't use chunk

why would it matter if take was chunked?

or if iterate produced a chunked seq?

from a consumer perspective, there is no difference. something might do more work in a chunk but it's unlikely to actually matter in most cases, esp when manipulating immutable collections

user> (iterate pop [1 2 3])
([1Error printing return value (IllegalStateException) at clojure.lang.PersistentVector/pop (PersistentVector.java:470).
Can't pop empty vector

that's actually the weird thing :) most coll ops have defined behavior for empty/nil

(like butlast)

user=> (take 10 (iterate butlast [1 2 3]))
([1 2 3] (1 2) (1) nil nil nil nil nil nil nil)

public PersistentVector pop(){
	if(cnt == 0)
		throw new IllegalStateException("Can't pop empty vector");

public IPersistentStack pop(){
		if(end - 1 == start)
			{
			return PersistentVector.EMPTY;
			}
		return new SubVector(_meta, v, start, end - 1);
	}

static public Object pop(Object x){
	if(x == null)
		return null;
	return ((IPersistentStack) x).pop();
}

I mean, you don't need to go that deep even:

user=> (doc pop)
-------------------------
clojure.core/pop
([coll])
  For a list or queue, returns a new list/queue without the first
  item, for a vector, returns a new vector without the last item. If
  the collection is empty, throws an exception.  Note - not the same
  as next/butlast.

I’ve seen it done, but I forgot how

Ah. Well. Not so hard!

https://stackoverflow.com/a/20687698

it is called tagged literal https://clojure.org/reference/reader#tagged_literals and it is not hard at all

it depends what you mean by a reader macro

common lisp has reader macros which can let you do things like use the lisp reader to reader json, or embed almost arbitrary syntax in common lisp programs (I think, haven't used them, just seen blog posts)

clojure doesn't have those

I believe the state reason it doesn't is because they don't compose well

clojure has tagged literals, which let you build representations for things to be read out of forms the reader already understands (it is compositional)

but not as general / powerful

If you aren't satisfied by tagged literals the solution is a fork, right?

depends on the problem

Well I know I for one was frustrated with the inability to make it so that I could have a #rope literal that allowed evaluated symbols inside it

that is totally possible

but that's more extending the evaluator than the reader

yeah

I'd love to hear how, my tests with it showed it as troublesome

Clojure 1.11.1
user=> (def f identity)
#'user/f
user=> (set! *data-readers* (assoc *data-readers* 'rope #'f))
{rope #'user/f}
user=> #rope foo
Syntax error compiling at (REPL:0:0).
Unable to resolve symbol: foo in this context
user=> '#rope foo
foo
user=> (defn f [x] (list 'quote x))
#'user/f
user=> #rope foo
foo
user=>

Might be worth it to get into another thread to not clutter this one. I'm not so lucky here with my usecase.

So like you said if you return a symbol it'll get evaluated as normal @U0NCTKEV8

However, if I return a custom data structure it can't recursively evaluate it.

And unfortunately the #=() syntax doesn't evaluate the arguments past the function

So the usecase I have in mind https://github.com/IGJoshua/ropes

Unfortunately I can't do something like

(let [[a b c] "xyz"]
  #rope [a b c])

because it'll return a rope with those symbols in it, not a rope with x y and z in it

yeah, it isn't really a templating system

Right, but I'd expect to be able to do this with data structures defined inside clojure core, and it's frustrating that I can't make a new data structure that's equally supported

you can make #rope return code that builds a rope when evaluted, not a rope itself, but that also has issues

that's a thought I guess

literal records have the same behavior, values aren't evaluated

Right.

What's the issue you're referring to with generating code that makes a rope rather than returning one? Stuff with identity?

It looks like it could actually solve my problem.

if you read without eval

right, it wouldn't be a rope

which is why I was thinking of falling back to the #= but that doesn't evaluate the args either for sensible reasons

So yeah, that all makes sense, it's kinda one or the other if you can't extend the evaluator.

you can have a #rope-template tag that produces code that creates a rope, and have all ropes still print using the #rope tag

I'll think about it for sure.

That’s what I do in #sicmutils for complex numbers, quaternions etc https://github.com/sicmutils/sicmutils/blob/main/src/sicmutils/complex.cljc#L77

And then I print using the reader literal tag https://github.com/sicmutils/sicmutils/blob/main/src/sicmutils/complex.cljc#L130

My understanding was transit was only supposed to be faster in the browser

Since the browser has a native JSON parser, but not a native EDN parser

Makes sense, thanks @U08JKUHA9

Hard to say without seeing the serialization code

we are using clj-ajax on the react native app

any number of things, usually related to having multiple versions of the record type or the protocol type

often the result of evaluating the source files multiple times

also possibly the result of having an aot'ed version on disk and then creating the type again, etc

given you are using the full time name in the extend call lib1.core.ARecord and don't require lib1.core in lib2.core it is likely the aot issue

a good rule of thumb is, if you use a type, you must require the namespace that creates that type

I am actually requiring the type in lib2, sorry for the oversimplified code

requiring is something you do for namespaces, not something you do for types

yes yes, I know

what do you mean by "requiring the type"

(ns lib2.core (:require [lib1.core :as lib1]))

another rule of thumb with protocols is when extending a protocol to a type you should own either the protocol or the type

the ISQLValue protocol basically breaks that rule of thumb by existing

and the issue that can arise when you break that rule is conflicts

like you could be loading some later code that defines a different extension of ISQLValue to ARecord

and those are last one wins

in this case lib1 is my own library so it's not likely there are other extensions lying around

agreed that there are issues with the general approach of ISQLValue, but we've been using it without issue on various types like clojure.lang.Keyword for a long time

you can look in the protocol to see what types it is extended to (see the user.Foo under impls)

user=> (defprotocol X (foo [x]))
X
user=> (defrecord Foo [])
user.Foo
user=> (extend-protocol X Foo (foo [x] x))
nil
user=> X
{:on user.X, :on-interface user.X, :sigs {:foo {:tag nil, :name foo, :arglists ([x]), :doc nil}}, :var #'user/X, :method-map {:foo :foo}, :method-builders {#'user/foo #object[user$eval156$fn__157 0x49aa766b "user$eval156$fn__157@49aa766b"]}, :impls {user.Foo {:foo #object[user$eval191$fn__192 0x963176 "user$eval191$fn__192@963176"]}}}
user=>

and you can capture the class for your record and extension time, and compare it to the class for the record when the extension seems to have failed to check to see if the record is being redefined

it does list ARecord , so I guess it must be that the record is getting redefined. What's the remedy for that? defonce?

figure out why it is being redfined and stop doing that

I mean there's only one namespace that calls defrecord, so I'm not sure how it's possible

there's no macro trickery or anything

something forcing a reloading of the code

specifically forcing a reload of the defrecord code, but not a reload of extension code (or possible reloading both but in the wrong order)

ah, that gives me something to go on. Thanks, I'll do some more digging