I like DI for “auto-wiring” the dependency graph so that things are started/stopped and passed to each other in the right order w/o me doing it manually. I can just declare what the dependencies between things are and the system handles all of this for me. That is what component-lib does: it builds a component graph, sorts it topologically and then passes dependencies around using closures. It’s also nice to be able to take that specification as a concrete value and then replace various components in the system for CLIs, testing, etc. Parameters are more convenient in some circumstances, but are a bit clunky when you have two instances of the same component (eg. a read-only and a read-write DB).

I’ve never been a fan of the Guice-style runtime DI via annotations, though. Too much magic and hard to debug.

Here’s matchacha’s component spec: https://gist.github.com/Bogdanp/58391f9723c49874c3ce9cf0bbc56220 . Another advantage of having a declarative spec of these things is you can build tools to visualize the graph. If I run raco koyo graph in matchacha’s root, I get:

Does the component-lib support circular dependencies? AFAIK, many OOP DI container support two kinds of injection: 1. constructor injection (1st pass) 2. setter injection (2nd pass that deal with circular dependencies)

It doesn’t.

Thanks. FP seems to discourage circular dependencies. It’s logical.

At my last job, DI started to click for me when I realized it was something like module system for stateful services. You sort of “import” loggers, database adapters, task queues, etc., and the state of the overall application at run time can then be understood to be in the same shape as the codebase (and can be decomposed along those lines for testing). I think it’s not that other abstraction techniques can’t be used for any given thing DI does, but that when people’s preferences bring them toward module-system-like abstractions for complex codebase development and stateful abstractions for complex application architecture, DI techniques play right to that niche.

When running scribbling --html file.scrbl I get this: Warning: some cross references may be broken due to undefined tags. How can I fix this?

If you now have installed your code as a package, you can run raco setup --pkgs <your-package-name>. It will automatically render your Scribble file (assuming you point to your Scribble file in info.rkt) with correct cross reference information.

I’d like to essentially make a contract on something void. I did (unconstrained-domain-> any/c) but that still checks for a) a procedure and b) that the procedure returns a single value. Is there some way to do even less? I tried #f in lieu of the contract expression, but it fails.

Use any instead of any/c

It won’t check the return arity

Why not just any/c?

If you use any/c instead of the whole contract, it will just check that the thing is just a single value

Right. Isn’t that what @raoul.schorer wants?

But then using a contract at seems not very useful :)

Myself I would probably just use procedure?

That way it’s checked only when the procedure is passed, not each time it is called

maybe also procedure-arity-includes/c iirc

Ah, yes indeed those are all pretty valid solutions. It’s good that I posted in #beginners :smiling_face_with_tear:

The reason for the void contract is that I have a contracted unit interface, with just 2 unsafe procedures in the middle of 15 others

so I just wanted to remove all checks on those 2

Oh, I underatnd it now. Thanks!

Why is raco pkg install apparently reading a test2.rkt file I have in the directory of the language? Or is it not? test2.rkt is indeed a program that fails with that error message. I don’t know where the problem is, but I’m surprised installing the package would run this program at all. %raco pkg install [...] raco setup: --- parallel build using 4 jobs --- [10:41:33] raco setup: 3 making: <pkgs>/jsonic4 string::1: read: expected a `)` to close `(` compilation context...: C:\sys\tolcom\current\little-languages\jsonic4\test2.rkt [...] raco pkg install: packages installed, although setup reported errors

I too have been confused my this previously. I think the installation process simply compiles all files in the folder. You can use the info.rkt file to exclude some files.

Oh, thank you so much!