1. Re: Data validation (was Re: Stu--- Just how many times has this changed?)
On Wed, 02 Jun 2004 12:16:08 +1000, Patrick Barnes
<mistertrik at hotmail.com> wrote:
>That sounds a little convoluted,
Not much worse than some of my ideas, however it made me think it is
impossible to make badly written type definitions fast, and perhaps we
should instead be trying to define a set of rules which allow fast
type checking to occur, eg:
1. type must have "sequence of <whatever>"
2. no loops or calls to user-defined routines
[[ I think this is the really critical point ]]
If you need to test each element, or you need a loop to process a
single element, then do so in the <whatever> definition.
3. no use of some built-in functions like length() - again you can use
them within the <whatever> definition, but at the top level it
kinda means you expect to be passed the entire object every time.
4. no modification of external data (no, I can't think why I just
typed that either, so that may be specious)
Such info is relatively easy to gather when parsing a type definition,
and we should emit warnings at the end type statement (if the
definition begins with "sequence of") when the rules are broken.
Some related (parse-level) needs are:
1. A subscript of a "sequence of <whatever>" object retains the
<whatever> type.
2. A slice of a "sequence of <whatever>" object retains the
"sequence of <whatever>" type.
3. append, prepend, and & retain the type of their arguments.
If the type is correct already, no need to typecheck.
Of course that will break somewhat when using literals, function
results, +-*/ etc, so possibly not all that important.
4. x[i]=, x[i..j]=, x=append(x, x=prepend(x, and x&= only pass the
altered slice of x to the type check routine.
--Those rules govern whether the "typecheck" bytecode is emitted,
I'm trying not to imply a mod to the core datatype handling.
Pete
PS Actually, that second list is not entirely dissimilar to what
Patrick just said 
)
