Il giorno 25/mag/2015, alle ore 14.29, Matthias Felleisen ha scritto: > > 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.
Well, right now I consider include to be superior for my little program. > > 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. > Most implementations of an Algorithmic Language Scheme do have no problem with interdependent modules. Pretending to have modules and recreating inheritance with encapsulation are two distinct things. I'd say as long as they allow to seperate and reunite scopes with fine grained control they should be considered viable approaches to modules systems. Tying them to the file level might even be a good idea. Recreating header files reminds me of m4. Cutting static ties means to change the logic of my program because of typographic needs, i.e. the file is become too big. Honestly, I do that a lot of times but I don't see the reason why I shouldn't dispatch on type just to create a module out of my abstract class. The only reason why one needs modules is source code management and that mostly happens in combination with files. Then one needs hygiene in the top level environment to not go back to the LISP era - but other module systems allow me to do that. > > >> 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.) > Some self hosting environments one day might not even know about the distinction between compile time and run time anymore. As far as I remember the algorthmic language scheme was divided into to "stages": reader and interpreter. Interestingly enough Racket's module system doesn't handle interdependencies well while it's reader does have no problems with applying procedures which are defined only later on in the text. Other implementations can cope with interdependent modules but fail(ed) when you tried to use something before its definition. > ;; --- > > 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 > Yes, thanks again a lot. But for now I'm the lazy programmer stuck with include. -- 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.
