I'll be quick here, as I haven't the time I wish I had.
The introduction seems weak. Simplicity doesn't come from a low number
of concepts. If it did, the SK-calculus would be the language all new
programmers would be starting with. It seems like offering a hook
beyond how "simple" it is should be part of your introduction. There
is the discussion of efficiency, but at least for me, this is one of
the least interesting parts about Cat. That said, I'm not sure how I'd
rework this...
> In the Cat specification instructions are referred to as functions,
> whether or not they have side-effects.
Do functions actually have side-effects? If all functions are unary
functions of stacks to stacks, it's easy to thread an implicit world
state through the entire program. I believe Backus's FL did something
similar. As far as I'm concerned, Cat is purely functional. Functions
of the type A ~> B are functions that read/write the world state on
the top of the stack. All other operations work below it.
> Functions can not be redefined, and are only visible after they are
> defined.
Does this mean recursive definitions are disallowed?
> In Joy parlance this is called a quotation, but I prefer to think of
> it as either an anonymous function or lambda expression.
Lambda expression might not be the term to use here as there are no
variables involved.
> A possible definition of bin_rec is shown Figure X.
So bin_rec must be a primitive? If so, that should probably be stated.
I assume that's the case for reasons related to the type system, as I
believe you can write it in Joy.
> For those who like big Greek words
I don't know who the intended audience of this is (I'm not familiar
with Doctor Dobbs), but I find this level of informality off-putting.
> Metadata is a form of structured comment that can be associated with
> a Cat program. I use it to document functions, and provide automatic
> unit tests.
Again, not sure on the audience, but "I use it" as opposed to "Its
intended use is" strikes me as odd.
> Static type systems are useful for documentation, static
> verification of code, and optimization.
And more!
> It is common practice in stack languages to document the stack
> effects of each instruction, i.e. what type of values are remove
> from the stack (the consumption), and what type of values are placed
> on the stack (the production).
That should be 'e.g.', not 'i.e.'.
> If the type annotation is omitted, Cat is able to infer the type
> automatically, using a variant of the Hindley-Milner algorithm [X]
Should be: "If a type annotation is omitted, Cat is able to infer a
type automatically using a variant of the Hindley-Milner algorithm [X]."
> Using the Cat interpreter "#t" will give you the type of any
> function on the stack.
I don't quite understand this sentence. Perhaps "Using '#t' in the Cat
interpreter"?
> The most important properties are: whether the required input types
> for a function are being supplied when it is called
Perhaps "values of the correct types" is better.
> A somewhat novel feature of the Cat type system is that all
> functions are row polymorphic [ref] (also called tail polymorphic)
I don't have time to get into this now, but I think there are cases
when you don't want functions to be row polymorphic. A trivial
example: Supplying a function that takes two arguments for use in a
callback. Simply requiring the function to unify with (A b c -> A)
would be insufficient, as you'd be allowed to pass something like (A b
c d e -> A b). I've had to introduce an additional concept to my type
system to address this. First-class stacks (evaluated on via Joy's
'infra') also seem to require this. I'll post in more detail soon I'm
sure...
> define quadratic { [dupd [sqr] dip swap [*] dip] dipd [* +] dip + }
If you take the arguments in reverse order, as you typically would,
you can do this:
2dup [* * swap] dip * + +
> Now we partially evaluate the "papply" functions:
Better than 'curry'. :)
Anyway, I hope something in there helped. Sorry I don't have time for
a more thorough reading.
- John
.
RSS Feed