You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The "old" (or current as of this writing) implementation of classes and class instances eschews types entirely, so I wind up manually resolving each use of a class member to a particular instance of the class. This makes for an awkward programming experience.
In practice, old classes are approximately first-order abstractions -- a simple class like Functor is useful in limited contexts, but higher order classes like Arrow or V (abstract vector spaces) are impractical. To fully express the constructs in Haskell's diagrams library as classes, Algebraic Racket needs a "new" class syntax that actively supports higher order abstractions.
Dynamic dispatch boilerplate is tedious to write by hand, but it can be generated automatically whenever what to generate and where can be deduced from the code. To this end, the "new" class form will move to Racket-style internal definitions and a generic form (:) for member "type" annotations.
Note the absence of functor-dispatch.rkt in this version, which uses a hypothetical algebraic/types/dynamic module to associate contracts bound by : to member definitions. It would generate code that looks something like this:
The "old" (or current as of this writing) implementation of classes and class instances eschews types entirely, so I wind up manually resolving each use of a class member to a particular instance of the class. This makes for an awkward programming experience.
In practice, old classes are approximately first-order abstractions -- a simple class like
Functor
is useful in limited contexts, but higher order classes likeArrow
orV
(abstract vector spaces) are impractical. To fully express the constructs in Haskell's diagrams library as classes, Algebraic Racket needs a "new" class syntax that actively supports higher order abstractions.An illustrative example in the old syntax:
Dynamic dispatch boilerplate is tedious to write by hand, but it can be generated automatically whenever what to generate and where can be deduced from the code. To this end, the "new" class form will move to Racket-style internal definitions and a generic form (
:
) for member "type" annotations.Here's the same example in the new syntax:
Note the absence of
functor-dispatch.rkt
in this version, which uses a hypotheticalalgebraic/types/dynamic
module to associate contracts bound by:
to member definitions. It would generate code that looks something like this:The text was updated successfully, but these errors were encountered: