Re: [stack] Notation for typed arrays in Cat

Christopher Diggins <[email protected]> wrote:
> I am again playing with the idea of how to introduce typed arrays in to Cat.
>  The following is the notation that I prefer, but I am concerned about
>  the confusion of ['a] meaning a list of 'a in types, and [a] meaning a
>  quotation in the code:

Factor uses {} for arrays and [] for quotations (and lists). It does
seem to me that there should be a way to denote different type
treatment, especially if the two entities behave differently in other
ways (for example, lists could be conceptually sequential, while
arrays could be conceptually parallel; thus, "i" would work on lists,
while the combinators we're talking about would be expected to execute
an array).

>  Another syntax I am seriously considering is:
>  uncons : ('a* -> 'a* 'a)
>  cons : ('a* 'a -> 'a*)
>  empty : ('a* -> 'a* bool)
>  count : ('a* -> 'a* int)

This nicely expresses "an unknown number of elements of this single
type", which is (I believe) what you mean by "array". What would an
array literal look like in Cat, though? It _should_ (one would think)
be possible to tell the difference between an untyped list and a typed
array reasonably quickly.

>  And yet another contender is:
>  uncons : (list('a) -> list('a) 'a)
>  cons : (list('a) 'a -> list('a))
>  empty : (list('a) -> list('a) bool)
>  count : (list('a) -> list('a) int)
>  This last one is interesting because it opens the door to the
>  possibility of full-blown meta-programming at the type-level. There
>  are hints of how the type-system could be used as a programming
>  language.

Indeed true!

> Of course if I could also keep it postfix:
>  uncons : ('a list -> 'a list 'a)
>  cons : ('a list 'a -> 'a list)
>  empty : ('a list -> 'a list bool)
>  count : ('a list -> 'a list int)
>  This might be more consistent, but for some reason I feel more
>  comfortable with the prefix notation. It delineates the world of types
>  from the world of values more clearly for me.

I think the reason you feel more comfortable with prefix is simple:
your type notation is not a concatenative language. Making "list"
pretend to be a concatenative operator would require the reader to
"know" in advance that "list" isn't a valid typename.

Suppose the user defined a typename which worked like 'list', but
which was named 'a'. All of a sudden, all functions which used the
symbol a for one of their types would become syntax errors.

So... I agree with you.

>  Any thoughts or opinions on the subject would be appreciated.

I'm just an echo.

>  - Christopher

-Wm