[racket] Fwd: JSON module: why symbols for object keys? lists for arrays?

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
<matthias at ccs.neu.edu> wrote:
>
> On Apr 23, 2013, at 12:14 PM, Erik Pearson <erik at 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