Hello, Let me revive this by adding a data point on the usage of units. I have always thought in my mind units as allowing you to have a `plugin` system where you can plugin additional functionality at runtime.
However, I had never really gotten my hands dirty. I decided to have a got under the following premises: 1. I have a framework that allows one to run a user algorithm chosen at runtime. 2. This framework is sent to a client as a binary, therefore he won't have the original sources. 3. The user is free to implement a new algorithm, and the framework will plug it in at runtime, run his algo and exit. I don't think, but I am happy to be shown wrong, you can do this _without_ units. I have written a use case here: https://github.com/LinkiTools/unit-use-case The idea is to do the following: 1. Clone 2. raco exe -o run-algo framework/main.rkt 3. remove all other files from framework such that only run-algo remains 4. cd framework 5. `./run-algo -u fact 3` => 6 6. `./run-algo -u double 5` => 10 7. You could at this point distribute framework and public-sigs and get clients without access to internal framework sources to create its own algos. (I note that I have found that the bytecode lives inside the executable, and therefore any keen client would possibly be able to reverse engineer but I don't think that's an issue) This doesn't quite work yet because for some reason it says algo-base% in fact.rkt is not defined even though it's part of an import signature (framework^). Does anyone understand why this is the case? Also, Check Syntax crashes on main.rkt (but that doesn't block this from working) -- Issue #1991. Happy to have any comments on my use case for units. Cheers, Paulo Matos On 21/01/18 20:22, Alexis King wrote: > Hello, > > Racket’s units predate its module system. Indeed, it would seem that > units were originally intended to *be* Racket’s module system, but > evidently, that did not work out. My understanding is their replacement > was due in large part to the desire for a more predictable macro > compilation model, so Racket’s phased module system is by necessity far > more statically bound than units were ever designed to be (if anything, > units seem to have been designed with the express purpose of dynamic > linking, which is hard to reconcile with compile-time macroexpansion). > > Recently, however, I stumbled upon the paper in which the unit system > was initially presented, “Units: Cool Modules for HOT Languages” by > Flatt and Felleisen, and it outlines some interesting, reasonably > compelling motivations for dynamic linking of first-class modules. > However (though my memory may be imperfect here), I think I remember > Matthias mentioning at some point that units were one of the areas where > Racket “got it wrong”, and evidently whole-program construction via > units did not pan out. I’m curious about this, since units are still > distributed with Racket, so they clearly weren’t so wrong that they > needed to be relegated to the dustbin, and in theory they still have all > the interesting properties motivated by the original paper. Despite > that, units seem essentially unused in Racket except in a few small > places to allow modules with circular dependencies, not really taking > advantage of any of units’ additional expressive power. > > My question to the list is therefore this: are units truly “dead”, or > do they have redeeming qualities? Are there some situations where units > might be preferable to a solution involving, say, first-class functions > or the object system? If there are useful applications for units, why > are they essentially unused in modern Racket programming? Are units > theoretically useful but lacking in some implementation property that > makes them practically viable? If so, is that practical flaw inherent > to the concept of dynamically-linked, first-class modules, or is it > merely a deficiency in Racket’s implementation? > > Apologies for the meandering set of questions, but I am quite curious > to know more about this particular abstraction from the people who > experienced it, since its exploration long predates my exposure to > Racket. > > Alexis > -- Paulo Matos -- 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.
