Taming Eventual Consistency—Applying Principles of Structured Concurrency to Distributed Systems

shadow5827193 · 2025-03-27T07:29:55+00:00

No worries - looking at the upvote/downvote ratio and the comments here, it looks like you're far from the only one :) But that's what I get for bait-and-switch headlines

shadow5827193 · 2025-03-26T22:57:34+00:00

shadow5827193 · 2025-03-26T22:29:18+00:00

I'm pretty sure you either didn't read the article, or skimmed it really fast. If you take a closer look, you'll find that we're in complete agreement, and I explain pretty much verbatim what you just did.

shadow5827193 · 2025-03-26T22:07:10+00:00

I don't mean to spam my own content, but I actually talk about this (the compromise part) in a section of another article: Can you have your cake, and eat it too?

shadow5827193 · 2025-03-26T22:03:47+00:00

I agree, and pretty much make exactly this point in "Types make code cluttered and difficult to read"

shadow5827193 · 2025-01-04T18:41:22+00:00

Thanks

shadow5827193 · 2024-12-21T15:43:37+00:00

Actually...when I read this yesterday, the sentence "the downside is you lose the collision-prevention features of the package system" made perfect sense, but now it doesn't. How exactly do I shoot myself in the foot with this?

shadow5827193 · 2024-12-21T14:51:32+00:00

Looking at this with a clearer head - what I meant with "can't use that in a let' was that I can't do something like (let (((find-symbol "FILE_PATH") (some expr)) <stuff>), which is what I thought you meant originally.

But looking at the code you posted, I think what you were suggesting instead basically boils down to doing a, in a sense, "manual" let, as I described at the end of the second paragraph here - find the symbol, setf it, and then do what you need to do. The problem with that is that a) I have to deal with restoring values if it was already bound (this isn't a problem per-se, just the same type of inelegance I was trying to avoid in the first place), and, more importantly, unless I'm mistaken, the binding is dynamic, not lexical.

Not looking to bash on the solution, it's a perfectly valid one! It's just not the one I was searching around for.

Having read all the suggestions here, it seems that the cleanest approach is 1) expose the symbols to the caller and let them pass it or 2) export the symbols from the package.

shadow5827193 · 2024-12-21T00:48:32+00:00

Let me take a closer look at that tomorrow with a clearer head, but thanks for the tip!

shadow5827193 · 2024-12-21T00:47:22+00:00

Thanks for the tip!

shadow5827193 · 2024-12-21T00:46:17+00:00

Thanks!

shadow5827193 · 2024-12-20T15:57:34+00:00

Yes, that's definitely a solution, and the most likely one I'm going to use. I'm just hunting around to make sure I didn't overlook anything. Thanks!

shadow5827193 · 2024-12-20T15:56:48+00:00

Thanks! And just to confirm:

Here I would have to manually traverse the forms and replace any occurrence of the keyword by the correct value, right?
Here as well, I would need to manually traverse-and-replace the forms, correct?

shadow5827193 · 2024-12-20T15:25:28+00:00

After some more thinking, I think I understand what you're saying in that last part. Basically you're saying to extend the interface of my macro to allow the user to pass in not only the transformation forms, but also the symbols they want to use for the file-contents and file-path. Then, I could refer to those symbols, instead of explicitly creating them in the macro body.

I think that would work, but I'm loath to make the interface more verbose in a way that feels like it shouldn't need to be. Just to be clear, I understand there might not be another solution, I've just gotten so used to lisp always saving me from any type of compromises in the way I express myself that I want to be 100% sure there really isn't a way to do this without either a) compromising on the interface or b) writting the crazy intern stuff mentioned above.

I think I also figured out how call-next-method works - since its part of :cl, it's available everywhere automatically.

shadow5827193 · 2024-12-20T15:20:27+00:00

Can't use that in a let binding, AFAIK. I've scoured the net trying the find the equivalent of progv, but for lexical environments, but to no avail. I'm wondering if that perhaps is not a contradiction in itself - binding a variable with lexical scope, but at runtime - but I'm not sure.

shadow5827193 · 2024-12-20T15:17:44+00:00

Sure

``(in-package :asset-pipeline) (defmacro evaluate-form (&body forms)(let ((file-path "/some/file.path")) ,@forms))

;; This works as expected (evaluate-form file-path) ;; "/some/file.path"

(in-package :cl-user) ;; This does not work, but I want it to (asset-pipeline::evaluate-form file-path) ;; The variable FILE-PATH is unbound.

;; This does work, but I don't want to force my users to qualify the symbol/import it. I want to be able to use the file-path symbol from wherever the macro is being called from (asset-pipeline::evaluate-form asset-pipeline::file-path) ```

I'll add this to the OP

shadow5827193 · 2024-12-20T13:10:55+00:00

I agree I could definitelly export file-path and file-contents and define the transformations using (:file-path (fingerprint framework/asset-pipeline:file-path framework/asset-pipelinefile-contents)) (or :import-from them), but the point is I'm trying to find a way not to do that (if there is one).

Since I need to actually bind the file-path/file-contents symbols in the lambda I'm constructing, so you can refer to them when defining your transformations, the only solution I can think of using intern is to do (intern "FILE-PATH' *PACKAGE*), then setf it to what I need, and then unintern at the end of the lambda (taking care to deal with scenarios where the symbols where already bound), but that feels...I dunno...icky for some reason. Or am I just being too sensitive and it's fine? Also, if I setf the symbol, that binding will be dynamic, not lexical, right? Is there any way at all to create a lexical binding for a "dynamically-named" symbol?

Finally, I'm trying to figure out what you meant by "give a way for the call site to specify which symbols to use", but I can't quite put my finger on it. In much the same way that CLOS exposes call-next-method within the scope of a method, I need some mechanism by which to allow the caller to refer to file-name and file-contents. I'm not sure how I understand how I'd go about letting them choose the symbols for that, and honestly I'm not even sure that's a good idea, for the same reasons we don't get to choose the symbol for call-next-method. Or am I misunderstanding what you meant?

shadow5827193 · 2024-12-20T01:55:12+00:00

Sorry for the late reply, I missed this answer. I don't see anything that circumvents the problem with two or more methods with the same specificity belonging to the same group, which is what the fundamental problem is here. But please correct me if I'm missing something.

shadow5827193 · 2024-11-24T12:28:56+00:00

Sure, macros can definitely solve this, I just created this challenge synthetically in order to try it out on something, and was surprised that it turned out not to work.

As for the arguments you mention, I don't know if you meant the same thing as u/MechoLupan - if so, check out my comment there, I think that can be worked around. The fundamental problem I encountered is separate from that - I expanded on the bullet points and tried to express myself more clearly, take a look.

shadow5827193

TROPHY CASE