Well it would make everything consistent with:

(let [{:keys [a b]}
      (list :a 1 :b 2)]
 [a b])
;;> [1 2]

vectors though are both associative and sequential so gets tricky

user=> (let [{a 0} [:hi :there]] a)
:hi

Hum... That's true. Never thought about that, and I guess this kind of makes sense why it works for sequences and not for vectors. Though in practice seems not as useful. But I never thought of doing [& {a :a}] and now that I know, it's not a big deal, and allows both form if.you ever want to destructure the vector by its index or instead as a key/value pair map.

I mean, that's not new, it's always worked liked that :)

well, since 1.2

Haha ya, but for some reason I just never really thought about it lol. I think I assumed & was like only for function varargs, but it makes sense since I think function args are just destructured as if they were a vector.

Designing for Scalability with Erlang/OTP is a good one

it's full of little insights useful in non erlang contexts. I quite enjoyed reading it

thanks!

oh I forgot that one: https://www.erlang-in-anger.com/ Fred Hebert is a good writter and the bits about flow control are excellent

and it's free...

but it's way more erlang centric, I guess with that one you could cherry pick parts to read

otplike could be of interest https://github.com/suprematic/otplike

> It is obvious that due to JVM limitations otplike cannot replace Erlang/OTP and otplike will `NEVER` be seen as Erlang/OTP alternative.

other than the threading model - which might get patched before wet bulb temperatures kill us all - i wonder what else is a limitation

Per process gc/stack/heap, so isolation is quite extreme and allows some patterns hard to replicate on the jvm

It's also full of tricks internally to allow this share nothing approach without being wastful when operating on the same host. Also message passing works across the network natively... etc etc. I really like erlang (used it professionally) but I think it might not be a good idea to try to replicate this kind of stuff on the jvm

At least not now

hmmm - so the message passing part is something that akka solves no?

I'd agree that the ability to share memory is an issue, but you could just choose not to right?

or like, choose not to make use of that

Not a direct answer, but when having a "message-passey" system there's likely a pure-functional system hidden underneath (which is obviously a good thing) Many production codebases aren't pure-functional. If yours doesn't happen to be, perhaps you'd have it reasonably easy to make it so. The benefit being: you can create test suites that exercise failure scenarios comprehensively/generatively and instantly. This is very different to hand-crafting failure scenarios that run slowly (because they have to run kafka, datomic, spin up an aws instance, w/e)

I will add a sample

table public."this""is stupid": INSERT: id[integer]:5 sometext[text]:'tere2' somedate[timestamp with time zone]:'2021-03-19 12:13:07.609859+02'

instaparse?

This is output from postgres test_decoding plugin and i'm trying to avoid reinventing a lot if wheels when parsing this.

It has funny oddities "" meaning an escaped double quote

Instaparse looks good, will check it out

Uhh https://calcite.apache.org/?

found some instaparse grammar here: https://github.com/untangled-web/sql-datomic/blob/master/resources/sql-92.instaparse.bnf

Calcite probably won't do as the syntax is just similar to sql semantics, not sql itself

I wonder if there's a json plugin for the wal/logical decoding

wal2json? https://wiki.postgresql.org/wiki/Logical_Decoding_Plugins

I can not rely on being able to install plugins on source postgres database

Source can be hosted postgres like rds, i can not install anything there.

+1 instaparse

ah, thought that wal2json was present on rds (https://aws.amazon.com/blogs/database/stream-changes-from-amazon-rds-for-postgresql-using-amazon-kinesis-data-streams-and-aws-lambda/), but yeah +1 instaparse

instaparse working like a champ, thanks 🙂

I would think just have a *cache-results?* var that gets set to true for prod?

I’m not super experienced yet but have seen that idiom in a few different projects

Dynamic vars are slow and the thread locality can bite you

You could put the cache or a config flag in an Integrant (or Component or...) system but it might be a bit heavyweight

Also the Reloaded workflow with e.g. Integrant can reset the cache along with everything else

Maybe could just use:

(defn abs [n] (if (neg? n) (-' n) n))

Personally I'm hoping for any ergonomic improvements to qualified keyword usage (https://clojure.atlassian.net/browse/CLJ-2123?filter=10021)

that is probably the thing next most farthest along

Recently I’ve been hurting for a map-kv. (map (fn [[k v]] (…))) works fine, but it’d be nice to be able to use a #() with %1 == k, %2 == v instead

I don’t like #(..) with multiple arguments — I’ll use (fn [..] ..) as soon as there are multiple arguments. I almost never map over a hash map — I use reduce-kv for that.

Hum, seems a bit frivolous compared to just (map + (keys foo))

But why not

I no longer wish for these since I got comfortable with transducers and came across cgrand's xforms. They could benefit libraries though

Actually, having more transducers in core would be nice.

(map + (keys foo)) doesn't return a map; I would appreciate a (map-keys + foo) that produced a new map with the keys updated

Oh, is that the idea of map-keys ? I see I see. Though reduce-kv is pretty damn close, but ya I can see it being a bit more convenient. Then I would actually like a map-kv that returned a map.

https://clojure.atlassian.net/browse/CLJ-1959

https://gist.github.com/seancorfield/6e8dd10799e9cc7527da5510c739e52f — using a gist via deps.edn to get map-keys / map-vals

I see. Ya, I don't know... I expect every Clojure dev to have their own "my-extra-utils" library, and this seems it could go there, amongst a bunch of other conveniences. I don't know which one are used so often that it makes sense to promote them to core or not. I wouldn't mind anyways. Though the name instinctively made it feel to me like it's mapping over the keys, not that it would become a non-lazy type preserving function.

Naming is hard. But functions like this are common in “util” libraries out there. I haven’t felt a need for them in core.

I’ve always just used reduce-kv for any transformation over a hash map. Well, since it was added to Clojure in 1.4 🙂

I feel I rarely need to apply the same transform to all values in a map. Generally my maps model compound types, so the keys are specifically to distinguish the kind of values. And so I rarely need to make the same value change to all of them. With reduce-kv I can switch on the key to apply the appropriate transformation to the value.

https://github.com/cgrand/xforms#simple-examples

Java.util.functions support that would be really great

What is DCL?

DynamicClassLoader. Needed for add-libs.

oh I thought Dead Code ... but what does the L stand for? ;)

I always have a case where I started a repo and forgot some lib

I think it be an awesome feature for exploration and experimentation

That comment from Stu? On https://clojure.atlassian.net/browse/CLJ-2540 or somewhere else?

Yes, on that issue.

I'll keep dreaming 😁

Multiline string that doesn't need to be escaped.

#text DELIMITER
Here I can now write whatever I want including with " : \ \ / / (foo)
All kind of error character.
DELIMITER

That would be horrible syntax in Clojure tho’…

How about

#__ 
Multi
Line
Comments!
__#

Well I don't want it for comments 😂, it's basically for embedding other languages into Clojure or for templating.

Ohhh I see

I once did this https://github.com/henrik42/extended-lisp-reader as an experiment. Won't run anymore I guess.

like the js template literals

When I last thought of it, I thought a new tag reader would be best:

#text end
Whatever multiline string here.
end

Reader tags still require legal Clojure forms though.

Sorry, not a tagged literal, like an additional reader form

More like #()

Which lets you pick the delimiter the reader will use on the next form for strings.

reader dispatch

Ya, so you tell the reader the following string is delimited by this symbol.

I would suggest you try actually implementing it in a fork of Clojure and see what problems you run into. I think you’ll find it far harder than it looks (and I still think it would be horrible syntax).

e.g.:

#+
Yolo!
+

He’s suggesting something like #" sym unconstrained arbitrary text sym I think.

(presumably with required newlines after the first sym and before the second one to make it a bit more tractable?)

#+EOT
yolo! "string!"
EOT

I think that is doable

This is quite easy to hack into https://github.com/borkdude/edamame or tools.reader in the dispatch table

Ya, the user picks the delimiter, it's a bit like how as-> has you pick the name of the symbol to bind. That way the user can choose a delimeter they know their string won't contain and so they won't need to escape.

perhaps the hardest part of this would be updating all the tooling that needs to know how to move over forms

lots of code in tooling would need to be updated and it might be quite tricky

this is always the case with adding new dispatches to the reader table

Most tooling relies on tools.reader though

CIDER certainly does not and that's about 40% marketshare

But ya, it is one downsides. It also secretly open the door to things much closer to reader macros. Because tagged literal can now accept arbitrary text and parse and interpret it.

I bet I could hack the above idea in edamame within an hour or so, but since it will never be in Clojure, I won't even bother

With what else I've seen you do, I'm sure you could haha.

i would be surprised in Cursive used tools reader for its structural movements and such

and obviously calva/conjure/Chlorine and others don't use tools reader as well

Cursive probably uses something more along the lines of rewrite-clj since editors / linters etc need something more precise than s-expressions

Well if people think it be a nice to have, go upvote: https://ask.clojure.org/index.php/8520/text-block-literal-string-literal-unsescaped-string-literal 😜

calva uses clojure-lsp which uses rewrite-clj / clj-kondo (which is also based on rewrite-clj)

and rewrite-clj uses tools.reader but not in the way you typically do

I think that’s one of the few things on ask that I’ve downvoted 🙂

It was.you!! :rolling_on_the_floor_laughing:

I've had two times where I really wish Clojure had it. For scripting, it is quite nice if you need to generate some file, you can template things easily with this, without needing a seperate file, which when you have a script you don't really want resources along with it and all that. And for embedding JavaScript inside Hiccup for simple server side rendered websites.

Early on Clojure considered XML literals I think I read somewhere once

does it use that kind of stuff for movements? not analysis but for moving to the next form; for determining what "the last form" is when sending the last form

define "it"?

Part of what drew me to Scala was XML literals. After I used them in a project, I felt they were a terrible idea! 🙂

@dpsutton if you want to offer any kind of refactoring, you have to know locations and preserve whitespace, exactly what rewrite-clj is for, but I assume Cursive has its own variant of this, possibly written in Java or part of some proprietary IntelliJ API

i mean, if you put your caret at a paren and say "send this form to the repl", the determination of what the last form is is certainly in a js implementation of paredit or parinfer right?

and this multiline string allowing arbitrarily unmatched delimiters would wreak havoc on that stuff

its not impossible, but i'm just thinking of all the paredits and parinfers that would have to be updated to handle this

paredits also handle ;; with arbitrary text?

and yes i'm not talking about analysis which will likely use tools.reader

yeah that's fair

I like your twist to it borkdude.

#+SYM
Here's the big string.
SYM

#my/xml #+END
<xml>
  <foo bar="wtv">
<\xml>
END

yep

and docstrings without escaped strings as well.

True:

(defn foo
  #+DOC
  This function does bla
  Example:
   (foo "value" 1)
   ;;> "value1"
  DOC
[a b]
...)

Me too :)

@U04V70XH6 Could you elaborate a bit on why you felt that way? What do you think about JSX that's rampant in the frontend world right now?

I hate that too 🙂

What about ERB like templates?

Scala is already fairly punctuation heavy so allowing arbitrary blocks of text full of < and > just makes for very distracting-looking code.

I’ll be honest, I find large blocks of SQL embedded as strings in Clojure to be distracting too. Although we have plenty of that at work. Where we’re not using HoneySQL, that is.

This is why Scala chose [] for generics ;)

Hmm, right, I can see that. A cognitive load creep. :)

Templates of any stripe are fine outside the code.

Scala was trying to learn from C++’s mistake with < > for templates because of the contextual lexing issue of >>.

Well I guess if a code base started using this for all strings. But I expect it be for rare instances. Like a quick on-click JS function inside Hiccup, or in a script where you need to create some config file from and want to quickly template it without setting up resources, and all. And for doc-strings it actually looks much cleaner to me. Seeing all the escape characters in them is distracting.

how do literate programming tools solve this - they must have a solution for this. do they start with foo.template.clj or so?

I don't know, any Rubyist or Perlers? Do heredoc end up polluting things?

(it will likely be unsurprising to hear that I’m no fan of literate programming either — for similar reasons)

Then why do I see you face in the contributors here: https://github.com/gdeer81/marginalia/tree/master/test/marginalia/test

=)

Well it seems heredoc is quite controversial. My idea was one day when I'm bored I'd make an Emacs unescape plugin instead. Where it visually unescapes things inside Clojure strings, and automatically escapes them as I type/paste (but visually won't show the escapes. Maybe this already exists actually...

it seems marginalia just uses comments and strings, no special stuff

@U04V15CAJ Because I wanted to give it a fair whip — and used it to build an entire project at work. This came up on ClojureVerse recently, BTW.

https://clojureverse.org/t/what-is-your-favourite-way-to-document-your-programs/7353

cool. I have made some diagrams with http://draw.io which works on all platforms. it's not as as good as omnigraffle but it works and it's free

they have a desktop app too. I'm off now, g'nite.

gn

@didibus re Perl/Ruby heredocs: our Perl code at work, iirc, only has a few heredocs and I can’t think of any in our ruby codebase either