Ah, I see. The joy of using a language driven by educators (is the concise, literate, and patient communication!) The signature / unit stuff is indeed quite verbose and complex. Being an exploratory and somewhat experimental language, I've taken that as-is.
I'm sure you guys have considered everything, and it is really moot if it isn't there, but to my little mind, an extension to (require) that takes an interface, and an interface definition/file which is essentially a signature, might go a long way to providing this type of mechanism without the overhead of the whole sig/unit thing. Something like (require (for-interface net/ftp-interface "myftp.rkt")), so you could just swap out myftp.rkt, or simplify to (require net/ftp) with no changes to the dependent code. To facilitate building modules that are designed to implement an interface, it would be handy to have module support, something like (satisfies-interface net/ftp-interface). No reason, of course, not to satisfy multiple interfaces. This would allow one to code to a standard api, swap out implementations easily, get good direct compiler feedback. I've sure you've seen the TypeScript stuff, in which interfaces are of course helpful for compilation but are touted as a aide to programming tools, and go staking its claim with interfaces, so there can be other advantages as well. Don't know how this folds into the typed racket. except that contracted and typed interfaces would also be awesome. Anyway, yes, I just walked in off the street, so addito salis grano. Yes, I had to look that up. On Tue, Apr 23, 2013 at 9:35 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > On Apr 23, 2013, at 12:14 PM, Erik Pearson <e...@adaptations.com> wrote: > >> Thanks, I've started my signature/unit lesson now. It will take me a >> couple of days absorbing the documentation and poring over the racket >> usage to grasp it. The racket code has some really clean code that I >> can actually follow (in areas I'm familiar with, like networking >> protocols). Much better than toy factories and toy stores! >> >> But wait, I did notice in the docs the sidebar note: >> ftp@ and ftp^ are deprecated. They exist for backward-compatibility and will >> likely be removed in the future. New code should use the net/ftp module. >> >> I noticed the same for base64, and I presume it is a change across the >> code base. The net/ftp module is just a plain racket module. No >> sig/unit magic. I would think one of the neat uses of sig/unit would >> be to implement well known protocols like these, which might have a >> standard racket implementation but allow for specialized or enhanced >> ones. Fits the model of json encoding, decoding, manipulation quite >> well. What's up? > > > Short: > > Your thinking is correct but until now we haven't found a need for such > parameterizations. Perhaps we aren't doing enough networking code. Perhaps > our reaction against units went a bit too far. > > ;; --- > > Long and some history: In the 90s, we had no modules just units. We happily > programmed with units even though using them is a significant syntactic > overhead over a plain module system. Units were motivated by some use > cases (you need units if you'd like to parameterize modules over other > modules and especially if you use different instantiations within one > application). > > But Racket is really a programming language programming language (yes, > I mean to use this repetition and it is my favorite slogan-description) > and our major tool is the syntax system. Eventually we wanted to create > syntactic libraries. While we had a design that worked for units, it > looked cumbersome and we had no usable implementation (as in programmers > can use it immediately with the rest of Racket or PLT Scheme as it was > called then). > > Matthew eventually bit the bullet and added the modules we have now and > showed how modules can be libraries of syntax and DSLs etc. Modules became > so easily usable that we went with modules whenever it wasn't clear that > units would offer any benefits. Sometimes we even went to the effort to > eliminate units so that it became easier for the 'programmer on the street' > to use the libraries. > > So what you and others encounter in some places in the code base is easily > explained by this history. > > -- Matthias > -- Erik Pearson Adaptations ;; web form and function -- Erik Pearson Adaptations ;; web form and function ____________________ Racket Users list: http://lists.racket-lang.org/users
