On May 25, 2015, at 5:52 AM, Michael Tiedtke wrote: > As I had to find out Racket's module system doesn't support cyclic > dependencies. In that case I should use units. But as far as I have > understood the concept of full fledged units I must either write a lot of > redundant code like signature auto^, implementation auto@, import auto^, > require "auto.rkt", export auto^ etc > OR I could create a lot of files following a certain naming conventions when > using whole module units. Both approaches are more hassle than managing the > respective files of my "framework" with copy&paste and via include.
The whole point of units is to avoid copy and paste. (Indeed, the entire history of programming languages is abut avoiding copy and paste.) While I agree that units are syntactically somewhat more cumbersome, the overhead is tolerable in my opinion. Then again as a co-conspirator of units, you wouldn't expect me to say anything else. Warning: units have limited type support, and it's only being turned into code for HEAD now. > Isn't there any simple way to declare cyclic dependencies? Most PLs don't have cyclic modules. (They may pretend to have modules but don't, which is why cyclic linking works.) The normal way of dealing with cyclic dependencies is to cut the static ties and replace them with dynamic ones, usually callbacks via lambdas and/or overriding in classes. > Can I put the signature and the implementation into one file? Yes. > How do I require or import such an interdependent unit framework? Do I have > to use invoke-unit or require or ...? Let's call #lang-modules, compilation packages (CP) here. Units are run-time values. They are first-class, like numbers. They come with a range of operations, like booleans. These include: creation, linking, and invoking. You can also store them in containers. You can even print them: > (displayln (unit (import) (export))) #<unit:stdin::49> As such a CP can provide and require units. You can also protect units with contracts. Signatures are syntactic constructs. At run-time they are gone. The point of CPs is that you can provide and require syntactic constructs, too. So yes, you can provide and require signatures but it doesn't mean providing/requiring them at run-time. They are dealt with at compile time. At compile time, you can also manipulate signatures with operations such as extending them. (Perhaps there's nothing else.) ;; --- I recommend you make 3-line examples of signatures, units, linking expressions (compounds) and invocations -- all in one CP. Then you may wish to separate them into different CPs, without changing the syntax, just use require/provide. Finally you may wish to use the special CP languages for declaring signatures and units. And finally you want to play with inferred linking. Holler when you get stuck -- Matthias -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
